From nunojpg at gmail.com Sat Nov 2 19:03:55 2013 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Sat, 2 Nov 2013 19:03:55 +0000 Subject: Fwd: rtl_test patch Message-ID: I'm not sure it this was overlooked or if I should format it any other way... Regards, Nuno ---------- Forwarded message ---------- From: Nuno Gon?alves Date: Sun, Apr 21, 2013 at 6:59 PM Subject: rtl_test patch To: osmocom-sdr at lists.osmocom.org Corrects bugs where: Cumulative PPM error is always "342" if execution stopped before first PPM_DURATION. PPM error alias to wrong values if over +-1045 (this happens quite a lot actually due to bug reported at [1]). Behavior changes: Cumulative PPM error value is now printed every PPM_DURATION so the user can check when it is settled. [1] http://lists.osmocom.org/pipermail/osmocom-sdr/2013-April/000584.html Thanks, Nuno Signed-off-by: Nuno Goncalves diff --git a/src/rtl_test.c b/src/rtl_test.c index f5a56b8..c705e04 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -55,6 +55,8 @@ static int ppm_benchmark = 0; static int64_t ppm_count = 0L; static int64_t ppm_total = 0L; +static uint32_t samp_rate = DEFAULT_SAMPLE_RATE; + #ifndef _WIN32 static struct timespec ppm_start; static struct timespec ppm_recent; @@ -108,6 +110,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx) { uint32_t i, lost = 0; int64_t ns; + int real_rate; if (uninit) { bcnt = buf[0]; @@ -141,17 +144,23 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx) if (ppm_now.tv_sec - ppm_recent.tv_sec > PPM_DURATION) { ns = 1000000000L * (int64_t)(ppm_now.tv_sec - ppm_recent.tv_sec); ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec); - printf("real sample rate: %i\n", + printf("real sample rate: %i", (int)((1000000000L * ppm_count / 2L) / ns)); - #ifndef __APPLE__ - clock_gettime(CLOCK_REALTIME, &ppm_recent); - #else - gettimeofday(&tv, NULL); - ppm_recent.tv_sec = tv.tv_sec; - ppm_recent.tv_nsec = tv.tv_usec*1000; - #endif + ppm_total += ppm_count / 2L; ppm_count = 0L; + + #ifndef _WIN32 + ns = 1000000000L * (int64_t)(ppm_now.tv_sec - ppm_start.tv_sec); + ns += (int64_t)(ppm_now.tv_nsec - ppm_start.tv_nsec); + real_rate = (int)(ppm_total * 1000000000L / ns); + printf(" cumulative PPM error: %.1f\n", + (1000000.0 * (real_rate - (int)samp_rate)) / samp_rate); + #else + printf("\n"); + #endif + + ppm_recent = ppm_now; } #endif } @@ -213,13 +222,10 @@ int main(int argc, char **argv) int sync_mode = 0; uint8_t *buffer; uint32_t dev_index = 0; - uint32_t samp_rate = DEFAULT_SAMPLE_RATE; uint32_t out_block_size = DEFAULT_BUF_LENGTH; int device_count; int count; int gains[100]; - int real_rate; - int64_t ns; while ((opt = getopt(argc, argv, "d:s:b:tpS::")) != -1) { switch (opt) { @@ -365,15 +371,6 @@ int main(int argc, char **argv) if (do_exit) { fprintf(stderr, "\nUser cancel, exiting...\n"); - if (ppm_benchmark) { -#ifndef _WIN32 - ns = 1000000000L * (int64_t)(ppm_recent.tv_sec - ppm_start.tv_sec); - ns += (int64_t)(ppm_recent.tv_nsec - ppm_start.tv_nsec); - real_rate = (int)(ppm_total * 1000000000L / ns); - printf("Cumulative PPM error: %i\n", - (int)round((double)(1000000 * (real_rate - (int)samp_rate)) / (double)samp_rate)); -#endif - } } else fprintf(stderr, "\nLibrary error %d, exiting...\n", r); -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_ppm.diff Type: application/octet-stream Size: 2512 bytes Desc: not available URL: From laforge at gnumonks.org Tue Nov 5 15:58:25 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 5 Nov 2013 16:58:25 +0100 Subject: OsmoDevCon 2014 / Date / Venue Message-ID: <20131105155825.GK12353@nataraja.gnumonks.org> Hi all, time is moving fast, and I want to start some initial discussion and planning for OsmoDevCon 2014. There are basically four questions which I'm raising below. Please provide your feedback to the osmocom-event-orga mailing list only, to avoid cross-posting over all the project lists. = Who? = My intention is to keep it an 'active developer/contributer only' event, like we had it before. I would also want to keep the group relatively small, to keep the 'Osmocom family' atmosphere. If desired, we could have one half or full day of public prsentations in a larger auditorium, but the developer meeting should be a close group, as known so far. = Where? = If we keep the number of attendees within the same range as this year, then I'm sure we could again hold it at the same venue. I know it is not perfect, but it is a place that we have access to, 24 hours per day, and free of cost for community projects like osmocom.org. If the community wants a larger event, then this is something that would require more funds and much more time organizing. And that is something that I personally could not offer to take care of, sorry. I'm happy to attend and support any larger events, but I'm unable to take care of fundraising and venue research. = When? = Q1/2014. In January, I'm not aware of any 'blocker' events. February, there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg March 17-21). Did I miss any other FOSS / mobile event that might clash in Q1? So my preference woudl be to do it either late January (23-26) or in February (6-9 or 13-16). Any preferences regarding preferred schedule? Once we have some concencus here on the list [and we want to do it in the same size / venue], I'll talk to IN-Berlin. = What? = I think that question is easy to answer, if we have the above three figured out... There's no shortage of topics, I suppose. You can start adding your suggestions to http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From pelletier.michel at gmail.com Mon Nov 11 05:14:06 2013 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 10 Nov 2013 21:14:06 -0800 Subject: multiple devices in one process? Message-ID: I've been thought-experimenting with capturing data from two devices and measuring their correlation. For example, if two rtl-sdr processes are launched to read one sample block from two devices, how closely do the two devices' samples line up with each other in time? I'm expecting that there will be no reliable correlation. My working theory is that each process calls into libusb_handle_events_timeout according to its own process schedule and that there is no way to coordinate these two calls to happen closely enough in time for the transfers to happen in a more synchronized fashion. Threads do not appear to be any better solution to the problem. I'm not an expert in usb transfers, or libusb, or rtlsdr for that matter, so I'm going only on what I can glean from reading the source code of librtlsdr.c and libusb documentation. libusb does say however that it can specifically handle multiple devices in one async loop. Multiple bulk transfers can be set up to multiple devices in one process, and one call to libusb_handle_events_* can be used to handle those transfers. My thinking is that because the triggering event for both samples is now the same function call in the same process, the samples will be more synchronized, ideally down to some reliably offset of say a few microseconds. Juha Vierinen's hard-hack to make two devices use a coherent sample clock makes this idea even more interesting to me. But, it doesn't look like librtlsdr can handle multiple devices. I'm game to take a stab at a patch that can extend its functionality. But I wanted to run this idea by the community first before spending code time on figuring this out. Do the experts here think that there is any potential benefit to be gained by taking this approach? -Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon Nov 11 14:00:13 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 11 Nov 2013 15:00:13 +0100 Subject: multiple devices in one process? In-Reply-To: References: Message-ID: <20131111140013.25251.qmail@stuge.se> Michel Pelletier wrote: > I'm expecting that there will be no reliable correlation. TL;DR: That's correct. You'll always have some tens of ms of jitter. > My working > theory is that each process calls into libusb_handle_events_timeout > according to its own process schedule and that there is no way to > coordinate these two calls to happen closely enough in time for the > transfers to happen in a more synchronized fashion. That's also correct. This is not a function of host software. > Threads do not appear to be any better solution to the problem. There isn't. > I'm not an expert in usb transfers, or libusb I do know USB and libusb and the key in this case is how bulk transfers are scheduled on the bus - namely optimized for throughput. Bulk transfers fill whatever bus time is free up to the maximum throughput the device can handle. And even if we imagine that you could have two host controllers with a synchronized schedule (not possible without rewriting the kernel USB stack) you still don't know what happens inside the USB device, there is no guarantee that it doesn't introduce jitter too. USB is not a low latency synchronized interconnect, it is optimized for throughput. Reliable scheduling over USB *is* possible, but not using bulk and not with too high throughput. //Peter From peter at stuge.se Tue Nov 12 17:11:53 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 12 Nov 2013 18:11:53 +0100 Subject: multiple devices in one process? In-Reply-To: References: Message-ID: <20131112171153.21921.qmail@stuge.se> David Jacobowitz wrote: > So, is there any way to line up samples post-hoc? Of course you can develop an elaborate hardware+software system to inject, recover, and sync onto an in-band clock. Or you could just buy hardware which already does what you need. //Peter From leif at sm5bsz.com Tue Nov 12 18:35:18 2013 From: leif at sm5bsz.com (Leif Asbrink) Date: Tue, 12 Nov 2013 19:35:18 +0100 Subject: multiple devices in one process? In-Reply-To: References: Message-ID: <20131112193518.e2b4f54e9a3ae546b7e9e4d7@sm5bsz.com> Hello Michel, The problem of correlation between two dongles (or any two independent radio receivers) has nothing to do with the USB transfer. If you have two dongles that run independently and connect them to a common signal source you can simply inject a pulse and see it come out at as sample number xxxx from one dongle and sample number yyyy from the other. Then you can simply provide a buffer that delayes one or the other signal so they appear to be syncronized. If you send in a second pulse perhaps one minute later you would find that the pulses no longer appear synchronized. Then, you need to insert a fractional re-sampler that changes the sampling rate for one of the channels. (Better to feed both dongles from the same sampling clock.) Once time is synchronized you would find a strong correlation between the amplitudes on the two signals, but the frequencies and phases will not agree. There will be a strong correlation but only over very short periods of time. To fix that you have to find the frequency difference and shift the frequency of one or the other signal for them to agree. That is just a complex multiplication and it would lead to longer coherence times in the correlation. Once you have reached this far the correlation will give precise info on how to adjust the fractional resampler and the frequency shift for the coherence time to become longer (or infinite if you use a singal generator as the signal source.) The problem is that the fractional resampler will read a little slower from the dongle than the direct read from the other dongle. That means that the delay in the buffer will grow continously reflecting how the two clocks drift in time vs eachother. - Leif > I've been thought-experimenting with capturing data from two devices and > measuring their correlation. For example, if two rtl-sdr processes are > launched to read one sample block from two devices, how closely do the two > devices' samples line up with each other in time? > > I'm expecting that there will be no reliable correlation. My working > theory is that each process calls into libusb_handle_events_timeout > according to its own process schedule and that there is no way to > coordinate these two calls to happen closely enough in time for the > transfers to happen in a more synchronized fashion. Threads do not appear > to be any better solution to the problem. I'm not an expert in usb > transfers, or libusb, or rtlsdr for that matter, so I'm going only on what > I can glean from reading the source code of librtlsdr.c and libusb > documentation. > > libusb does say however that it can specifically handle multiple devices in > one async loop. Multiple bulk transfers can be set up to multiple devices > in one process, and one call to libusb_handle_events_* can be used to > handle those transfers. My thinking is that because the triggering event > for both samples is now the same function call in the same process, the > samples will be more synchronized, ideally down to some reliably offset of > say a few microseconds. Juha Vierinen's hard-hack to make two devices use a > coherent sample clock makes this idea even more interesting to me. > > But, it doesn't look like librtlsdr can handle multiple devices. I'm game > to take a stab at a patch that can extend its functionality. But I wanted > to run this idea by the community first before spending code time on > figuring this out. Do the experts here think that there is any potential > benefit to be gained by taking this approach? > > -Michel From ea4eoz at gmail.com Tue Nov 12 18:59:44 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Tue, 12 Nov 2013 19:59:44 +0100 Subject: rtl_fm and r820t tuner Message-ID: Hello! I noticed a problem with rtl_fm and r820t tuners. In few words, it doesn't matter what value of gain you set with the -g parameter. The r820t tuner will be always at its lower gain, this is deaf as a doorknob. Otherwise, the same dongles works fine with GNU Radio or GQRX for example, and gain can be set without problems. rtl_fm gain works nicely on e4k tuners. Someone else have noticed this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ea4eoz at gmail.com Tue Nov 12 20:08:54 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Tue, 12 Nov 2013 21:08:54 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: References: Message-ID: *>>> Are you sure you are setting a supported gain value?* Of course! No matter what setting you put into -g parameter, the tuner is always at its lowest gain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From keenerd at gmail.com Tue Nov 12 20:20:18 2013 From: keenerd at gmail.com (keenerd) Date: Tue, 12 Nov 2013 15:20:18 -0500 Subject: rtl_fm and r820t tuner In-Reply-To: References: Message-ID: On 11/12/13, Miguel A. Vallejo wrote: > I noticed a problem with rtl_fm and r820t tuners. In few words, it doesn't > matter what value of gain you set with the -g parameter. The r820t tuner > will be always at its lower gain, this is deaf as a doorknob. Are you sure? rtl_fm -f 100M -g 50 > /dev/null Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 .... Found Rafael Micro R820T tuner .... Tuner gain set to 49.60 dB. -Kyle http://kmkeen.com From ea4eoz at gmail.com Tue Nov 12 21:02:30 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Tue, 12 Nov 2013 22:02:30 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: References: Message-ID: *>>> Are you sure?* Yes. For the skeptics: ~$ rtl_fm -f 89000000 -R -s 1000000 -g 0 - | baudline -stdin -samplerate 1000000 -quadrature -flipcomplex -channels 2 -format le16 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 1x. Buffer size: 4.10ms Tuned to 89500000 Hz. Sampling at 2000000 Hz. Output at 1000000 Hz. Exact sample rate is: 2000000.052982 Hz Tuner gain set to 0.00 dB. Result: https://dl.dropboxusercontent.com/u/102802145/baudline0dB.jpg ~$ rtl_fm -f 89000000 -R -s 1000000 -g 30 - | baudline -stdin -samplerate 1000000 -quadrature -flipcomplex -channels 2 -format le16 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 1x. Buffer size: 4.10ms Tuned to 89500000 Hz. Sampling at 2000000 Hz. Output at 1000000 Hz. Exact sample rate is: 2000000.052982 Hz Tuner gain set to 29.70 dB. Result: https://dl.dropboxusercontent.com/u/102802145/baudline30dB.jpg GQRX, LNA gain = 0dB Result: https://dl.dropboxusercontent.com/u/102802145/gqrx0dB.jpg GQRX, LNA gain=30dB Result: https://dl.dropboxusercontent.com/u/102802145/gqrx30dB.jpg It's clear rtl_fm does not set any gain to the r820t tuner -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Tue Nov 12 21:53:40 2013 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 12 Nov 2013 22:53:40 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: References: Message-ID: <5282A364.8060502@steve-m.de> Hi, On 12.11.2013 22:02, Miguel A. Vallejo wrote: > It's clear rtl_fm does not set any gain to the r820t tuner Can't confirm. Using the current master, an R820T stick, and the exact same commands you posted I get the following: http://steve-m.de/pics/rtl_fm/0db.png http://steve-m.de/pics/rtl_fm/30db.png Can you please try the following patch and report back your output? diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 9b76a96..8a52602 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -948,6 +948,7 @@ int rtlsdr_set_tuner_gain(rtlsdr_dev_t *dev, int gain) if (dev->tuner->set_gain) { rtlsdr_set_i2c_repeater(dev, 1); r = dev->tuner->set_gain((void *)dev, gain); + fprintf(stderr, "%s(%d) -> %d\n", __FUNCTION__, gain, r); rtlsdr_set_i2c_repeater(dev, 0); } @@ -993,6 +994,7 @@ int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int mode) if (dev->tuner->set_gain_mode) { rtlsdr_set_i2c_repeater(dev, 1); r = dev->tuner->set_gain_mode((void *)dev, mode); + fprintf(stderr, "%s(%d) -> %d\n", __FUNCTION__, mode, r); rtlsdr_set_i2c_repeater(dev, 0); } Regards, Steve From jsalsburg at bellsouth.net Tue Nov 12 21:57:49 2013 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Tue, 12 Nov 2013 15:57:49 -0600 Subject: multiple devices in one process? In-Reply-To: References: Message-ID: <010601cedff2$3b404330$b1c0c990$@net> USB 2.0 has a built-in hardware latency. If you are unwilling to go through the trouble of special coding, be sure to use the USB Dongles alone on their own PCI USB Card, this will minimize latency. Hardware may be forced to respond at will if Assembly Code is used to exercise the interfaces, utilizing acquisition calls controlled by processor interrupts. A Real Time Clock (RTC) in internal Hardware or an external RTC can be used to trigger Processor Interrupts initiating any function in the (Assembly) code and attached hardware. Using a patch will not work with any reasonable accuracy, depending on the Hardware, (an educated guess) of a many microseconds. Patching indicates high level control (high level language like C++, Python, etc), only low level control will call the hardware anywhere near the timing desired. If you are to access two different devices, their data should be both buffered together in parallel through a first-in-first-out buffer, perhaps even with the RTC time stamp to quantize the packets therefore allowing subsequent coherence in post processing. In high speed audio and video interfaces, very high speed is used, like Firewire and Thunderbolt to stream the data into memory, eliminating most of the hardware latency you are experiencing. The maximum acquisition rate for USB 2.0 is about 48,000 samples per second, times 24 bit depth, times 8, and that is for a fast computer doing nothing else but recording the data stream. From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Michel Pelletier Sent: Sunday, November 10, 2013 11:14 PM To: osmocom-sdr at lists.osmocom.org Subject: multiple devices in one process? I've been thought-experimenting with capturing data from two devices and measuring their correlation. For example, if two rtl-sdr processes are launched to read one sample block from two devices, how closely do the two devices' samples line up with each other in time? I'm expecting that there will be no reliable correlation. My working theory is that each process calls into libusb_handle_events_timeout according to its own process schedule and that there is no way to coordinate these two calls to happen closely enough in time for the transfers to happen in a more synchronized fashion. Threads do not appear to be any better solution to the problem. I'm not an expert in usb transfers, or libusb, or rtlsdr for that matter, so I'm going only on what I can glean from reading the source code of librtlsdr.c and libusb documentation. libusb does say however that it can specifically handle multiple devices in one async loop. Multiple bulk transfers can be set up to multiple devices in one process, and one call to libusb_handle_events_* can be used to handle those transfers. My thinking is that because the triggering event for both samples is now the same function call in the same process, the samples will be more synchronized, ideally down to some reliably offset of say a few microseconds. Juha Vierinen's hard-hack to make two devices use a coherent sample clock makes this idea even more interesting to me. But, it doesn't look like librtlsdr can handle multiple devices. I'm game to take a stab at a patch that can extend its functionality. But I wanted to run this idea by the community first before spending code time on figuring this out. Do the experts here think that there is any potential benefit to be gained by taking this approach? -Michel _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3426 / Virus Database: 3222/6830 - Release Date: 11/12/13 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsalsburg at bellsouth.net Tue Nov 12 23:17:55 2013 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Tue, 12 Nov 2013 17:17:55 -0600 Subject: FW: multiple devices in one process? Message-ID: <012801cedffd$6bac7fb0$43057f10$@net> Woops, the mistake I am making is that the dongles are independent USB devices, there is no way to synchronize each Dongle's Acquisition. This is another reason to interface these Dongles with a BusPirate and 24bit Audio Board. From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Jay Salsburg Sent: Tuesday, November 12, 2013 3:58 PM To: osmocom-sdr at lists.osmocom.org Subject: RE: multiple devices in one process? USB 2.0 has a built-in hardware latency. If you are unwilling to go through the trouble of special coding, be sure to use the USB Dongles alone on their own PCI USB Card, this will minimize latency. Hardware may be forced to respond at will if Assembly Code is used to exercise the interfaces, utilizing acquisition calls controlled by processor interrupts. A Real Time Clock (RTC) in internal Hardware or an external RTC can be used to trigger Processor Interrupts initiating any function in the (Assembly) code and attached hardware. Using a patch will not work with any reasonable accuracy, depending on the Hardware, (an educated guess) of a many microseconds. Patching indicates high level control (high level language like C++, Python, etc), only low level control will call the hardware anywhere near the timing desired. If you are to access two different devices, their data should be both buffered together in parallel through a first-in-first-out buffer, perhaps even with the RTC time stamp to quantize the packets therefore allowing subsequent coherence in post processing. In high speed audio and video interfaces, very high speed is used, like Firewire and Thunderbolt to stream the data into memory, eliminating most of the hardware latency you are experiencing. The maximum acquisition rate for USB 2.0 is about 48,000 samples per second, times 24 bit depth, times 8, and that is for a fast computer doing nothing else but recording the data stream. From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Michel Pelletier Sent: Sunday, November 10, 2013 11:14 PM To: osmocom-sdr at lists.osmocom.org Subject: multiple devices in one process? I've been thought-experimenting with capturing data from two devices and measuring their correlation. For example, if two rtl-sdr processes are launched to read one sample block from two devices, how closely do the two devices' samples line up with each other in time? I'm expecting that there will be no reliable correlation. My working theory is that each process calls into libusb_handle_events_timeout according to its own process schedule and that there is no way to coordinate these two calls to happen closely enough in time for the transfers to happen in a more synchronized fashion. Threads do not appear to be any better solution to the problem. I'm not an expert in usb transfers, or libusb, or rtlsdr for that matter, so I'm going only on what I can glean from reading the source code of librtlsdr.c and libusb documentation. libusb does say however that it can specifically handle multiple devices in one async loop. Multiple bulk transfers can be set up to multiple devices in one process, and one call to libusb_handle_events_* can be used to handle those transfers. My thinking is that because the triggering event for both samples is now the same function call in the same process, the samples will be more synchronized, ideally down to some reliably offset of say a few microseconds. Juha Vierinen's hard-hack to make two devices use a coherent sample clock makes this idea even more interesting to me. But, it doesn't look like librtlsdr can handle multiple devices. I'm game to take a stab at a patch that can extend its functionality. But I wanted to run this idea by the community first before spending code time on figuring this out. Do the experts here think that there is any potential benefit to be gained by taking this approach? -Michel _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3426 / Virus Database: 3222/6830 - Release Date: 11/12/13 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3426 / Virus Database: 3222/6830 - Release Date: 11/12/13 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 7crqzutduvtx at gmail.com Wed Nov 13 02:02:15 2013 From: 7crqzutduvtx at gmail.com (Joel) Date: Wed, 13 Nov 2013 02:02:15 +0000 Subject: Latest commit of gr-osmocom (v0.1.0-44-g0d10f5e9 / 0.1.1git) fails to build Message-ID: <5282DDA7.1020802@gmail.com> Hello, Make ouputs the following error messages when building the latest commit of gr-osmocomsdr [rev:0d10f5e9bc950d6d2b3c39ae574e2d325a0fbeb6] $ make Scanning dependencies of target gnuradio-osmosdr [ 2%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o [ 5%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o [ 8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o [ 11%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o [ 13%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o [ 16%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o [ 19%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o /home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function ?virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)?: /home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:467:26: error: ?RTLSDR_TUNER_R828D? was not declared in this scope } else if ( tuner == RTLSDR_TUNER_R828D ) { ^ make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 OS: Fedora 19 x64 I am currently using the previous commit: b8441496288aa319f4aeaabd9df63c58be53e916 which builds fine on my workstation. I haven't tested the commits made between this and the latest revisions. Regards, Joel From citizenr at gmail.com Wed Nov 13 04:35:49 2013 From: citizenr at gmail.com (Rasz) Date: Wed, 13 Nov 2013 05:35:49 +0100 Subject: multiple devices in one process? In-Reply-To: <010601cedff2$3b404330$b1c0c990$@net> References: <010601cedff2$3b404330$b1c0c990$@net> Message-ID: On 12/11/2013, Jay Salsburg wrote: > USB 2.0 has a built-in hardware latency. If you are unwilling to go through > the trouble of special coding, be sure to use the USB Dongles alone on > their > own PCI USB Card, this will minimize latency. As Leif said earlier USB latency/jitter is not a problem. Dongles sample into internal buffer. You get this buffer over USB, you are fine as long as it doesnt overflow. Sync dongle clocks (feed them from one clock source) and there will be no jitter over time. -- Who logs in to gdm? Not I, said the duck. From steve at steve-m.de Wed Nov 13 07:54:27 2013 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 13 Nov 2013 08:54:27 +0100 Subject: Latest commit of gr-osmocom (v0.1.0-44-g0d10f5e9 / 0.1.1git) fails to build In-Reply-To: <5282DDA7.1020802@gmail.com> References: <5282DDA7.1020802@gmail.com> Message-ID: <52833033.2060502@steve-m.de> Hi, On 13.11.2013 03:02, Joel wrote: > Make ouputs the following error messages when building the latest commit > of gr-osmocomsdr [rev:0d10f5e9bc950d6d2b3c39ae574e2d325a0fbeb6] > ?RTLSDR_TUNER_R828D? was not declared in this scope Please build and install the latest version of rtl-sdr first. Regards, Steve From j-pi at seznam.cz Wed Nov 13 08:32:58 2013 From: j-pi at seznam.cz (=?UTF-8?B?SmnFmcOtIFBpbmthdmE=?=) Date: Wed, 13 Nov 2013 09:32:58 +0100 Subject: Latest commit of gr-osmocom (v0.1.0-44-g0d10f5e9 / 0.1.1git) fails to build In-Reply-To: <5282DDA7.1020802@gmail.com> References: <5282DDA7.1020802@gmail.com> Message-ID: <5283393A.6010408@seznam.cz> You need latest version of rtl-sdr Dne 13.11.2013 03:02, Joel napsal(a): > Hello, > > Make ouputs the following error messages when building the latest > commit of gr-osmocomsdr [rev:0d10f5e9bc950d6d2b3c39ae574e2d325a0fbeb6] > > $ make > Scanning dependencies of target gnuradio-osmosdr > [ 2%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o > [ 5%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o > [ 8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o > [ 11%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o > [ 13%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o > [ 16%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o > [ 19%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o > /home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function > ?virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)?: > /home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:467:26: error: > ?RTLSDR_TUNER_R828D? was not declared in this scope > } else if ( tuner == RTLSDR_TUNER_R828D ) { > ^ > make[2]: *** > [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error 1 > make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 > make: *** [all] Error 2 > > OS: Fedora 19 x64 > > I am currently using the previous commit: > b8441496288aa319f4aeaabd9df63c58be53e916 which builds fine on my > workstation. I haven't tested the commits made between this and the > latest revisions. > > Regards, > > Joel > From 7crqzutduvtx at gmail.com Wed Nov 13 08:44:38 2013 From: 7crqzutduvtx at gmail.com (Joel) Date: Wed, 13 Nov 2013 08:44:38 +0000 Subject: Latest commit of gr-osmocom (v0.1.0-44-g0d10f5e9 / 0.1.1git) fails to build In-Reply-To: <5283393A.6010408@seznam.cz> References: <5282DDA7.1020802@gmail.com> <5283393A.6010408@seznam.cz> Message-ID: <52833BF6.3090709@gmail.com> Cheers all, That fixed the issue. On 11/13/2013 08:32 AM, Ji?? Pinkava wrote: > You need latest version of rtl-sdr > > > Dne 13.11.2013 03:02, Joel napsal(a): >> Hello, >> >> Make ouputs the following error messages when building the latest >> commit of gr-osmocomsdr [rev:0d10f5e9bc950d6d2b3c39ae574e2d325a0fbeb6] >> >> $ make >> Scanning dependencies of target gnuradio-osmosdr >> [ 2%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o >> [ 5%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o >> [ 8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o >> [ 11%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o >> [ 13%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o >> [ 16%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o >> [ 19%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o >> /home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function >> ?virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)?: >> /home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:467:26: error: >> ?RTLSDR_TUNER_R828D? was not declared in this scope >> } else if ( tuner == RTLSDR_TUNER_R828D ) { >> ^ >> make[2]: *** >> [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error 1 >> make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 >> make: *** [all] Error 2 >> >> OS: Fedora 19 x64 >> >> I am currently using the previous commit: >> b8441496288aa319f4aeaabd9df63c58be53e916 which builds fine on my >> workstation. I haven't tested the commits made between this and the >> latest revisions. >> >> Regards, >> >> Joel >> From ea4eoz at gmail.com Wed Nov 13 11:21:24 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Wed, 13 Nov 2013 12:21:24 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: <5282A364.8060502@steve-m.de> References: <5282A364.8060502@steve-m.de> Message-ID: *>>> Can you please try the following patch and report back your output?* Sorry, but diff --git doesn't work in my system: diff: unrecognized option '--git' diff: Try 'diff --help' for more information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ea4eoz at gmail.com Wed Nov 13 12:22:18 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Wed, 13 Nov 2013 13:22:18 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: References: <5282A364.8060502@steve-m.de> Message-ID: Well, never mind. I added the two lines by hand: ~$ rtl_fm -f 89000000 -R -s 1000000 -g 0 - | baudline -stdin -samplerate 1000000 -quadrature -flipcomplex -channels 2 -format le16 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 1x. Buffer size: 4.10ms Tuned to 89500000 Hz. Sampling at 2000000 Hz. Output at 1000000 Hz. Exact sample rate is: 2000000.052982 Hz rtlsdr_set_tuner_gain_mode(1) -> 0 rtlsdr_set_tuner_gain(0) -> 0 Tuner gain set to 0.00 dB. ~$ rtl_fm -f 89000000 -R -s 1000000 -g 30 - | baudline -stdin -samplerate 1000000 -quadrature -flipcomplex -channels 2 -format le16 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 1x. Buffer size: 4.10ms Tuned to 89500000 Hz. Sampling at 2000000 Hz. Output at 1000000 Hz. Exact sample rate is: 2000000.052982 Hz rtlsdr_set_tuner_gain_mode(1) -> 0 rtlsdr_set_tuner_gain(297) -> 0 Tuner gain set to 29.70 dB. Hope this helps... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lightningbolts at gmail.com Wed Nov 13 12:59:24 2013 From: lightningbolts at gmail.com (Chris Hanson) Date: Wed, 13 Nov 2013 07:59:24 -0500 Subject: PL/CTCSS/DCS squelch on rtl_fm? Message-ID: <5B964D0A-3827-4FD4-9CA6-D14C19205E44@gmail.com> Has anyone considered adding this or found a work around for those noisy stations that keep breaking the squelch? Thanks Chris From ea4eoz at gmail.com Wed Nov 13 14:34:35 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Wed, 13 Nov 2013 15:34:35 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: References: Message-ID: *>>> I am still not sure of what your problem is.* I think it was clear: No matter what gain I set to rtl_fm with the -g switch, the tuner is ALWAYS at its lowest gain. *>>> It looks to me like the tuner gain is getting set.* For me too *>>> Does any other program work with that dongle?* *>>> Perhaps the tuner chip is fried. * No it isn't. It works just fine with GQRX or SDR#. The problem seems related to rtl_fm only. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ea4eoz at gmail.com Wed Nov 13 14:53:03 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Wed, 13 Nov 2013 15:53:03 +0100 Subject: RTL-SDR source in GNU-Radio 3.7.1 weird behaivour at 900 ksps Message-ID: Hi again. I noticed a strange behaivour from RTL-SDR source in GNU-Radio 3.7.1 When sample rate is set to 900ksps, actual output sample rate is only 300 ksps. You can check this easily connecting a RTL_SDR Source to a WX Gui FFT Sink and a RF signal generator. For example, on RTL-SDR Source set sample rate to 900000 and frequency to 144000000 Hz. On the WX GUI FFT Sink, set sample rate to 900000 and base frequency to 144000000 Hz. Now apply a signal on 144.1 MHz. The FFT Display will show it at 144.3 MHz. Apply a signal on 144.05 MHz. The FFT Display will show it at 144.15 MHz. Now on the WX GUI FFT Sink, set sample rate to 300000 and repeat the above steps. The signal will be displayed at its right places. Interestingly, setting sample rate to 1Msps works fine. Tested with both E4000 and R820T dongles. Any advice? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Nov 13 14:59:15 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 13 Nov 2013 15:59:15 +0100 Subject: RTL-SDR source in GNU-Radio 3.7.1 weird behaivour at 900 ksps In-Reply-To: References: Message-ID: > Any advice? Stick with what works. The driver will accept any sample rate and ask the RT2232 for it ... but since there is no real documentation, there is no way to know if that will really work or create issue inside the RTL2232 chip ... That's the problem with using stuff in ways they weren't design for. For consistent results, you should stick with commonly used samples rates like 1M 1.024M 1.2M 2M 2.048M 2.4M Avoid things lower than 1M and avoid weird, not-often used, values. Cheers, Sylvain From ea4eoz at gmail.com Wed Nov 13 15:06:50 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Wed, 13 Nov 2013 16:06:50 +0100 Subject: RTL-SDR source in GNU-Radio 3.7.1 weird behaivour at 900 ksps In-Reply-To: References: Message-ID: *>>> For consistent results, you should stick with commonly used samples* *>>> rates like 1M 1.024M 1.2M 2M 2.048M 2.4M Avoid things lower than 1M* *>>> and avoid weird, not-often used, values.* Thank you Sylvain. I thought 900 ksps was one of the standard rates in the RTL2832 chip, so that's why I used it, to keep cpu usage low because my application must work in a Intel Atom N270, the smallest one. In fact I used many times 900ksps with GNURadio 3.6.x without any problem at all. I'll use 1Msps for now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leif at sm5bsz.com Wed Nov 13 16:27:08 2013 From: leif at sm5bsz.com (Leif Asbrink) Date: Wed, 13 Nov 2013 17:27:08 +0100 Subject: RTL-SDR source in GNU-Radio 3.7.1 weird behaivour at 900 ksps In-Reply-To: References: Message-ID: <20131113172708.4eb01a668f754ac69b76c1c5@sm5bsz.com> Hello Miguel, In Linrad I have these defines: #define MAX_RTL2832_SAMP_RATE_H 2400000 #define MIN_RTL2832_SAMP_RATE_H 900001 #define MAX_RTL2832_SAMP_RATE_L 300000 #define MIN_RTL2832_SAMP_RATE_L 230000 900 kHz does not work, try 900001 Hz. The range 300001 to 900000 Hz does not work with RTL2832. 73 Leif A. Vallejo" wrote: > Hi again. > > I noticed a strange behaivour from RTL-SDR source in GNU-Radio 3.7.1 > > When sample rate is set to 900ksps, actual output sample rate is only 300 > ksps. > > You can check this easily connecting a RTL_SDR Source to a WX Gui FFT Sink > and a RF signal generator. > > For example, on RTL-SDR Source set sample rate to 900000 and frequency to > 144000000 Hz. > > On the WX GUI FFT Sink, set sample rate to 900000 and base frequency to > 144000000 Hz. > > Now apply a signal on 144.1 MHz. The FFT Display will show it at 144.3 MHz. > > Apply a signal on 144.05 MHz. The FFT Display will show it at 144.15 MHz. > > Now on the WX GUI FFT Sink, set sample rate to 300000 and repeat the above > steps. The signal will be displayed at its right places. > > Interestingly, setting sample rate to 1Msps works fine. > > Tested with both E4000 and R820T dongles. > > Any advice? > > Thank you! From ea4eoz at gmail.com Wed Nov 13 22:31:08 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Wed, 13 Nov 2013 23:31:08 +0100 Subject: RTL-SDR source in GNU-Radio 3.7.1 weird behaivour at 900 ksps In-Reply-To: <20131113172708.4eb01a668f754ac69b76c1c5@sm5bsz.com> References: <20131113172708.4eb01a668f754ac69b76c1c5@sm5bsz.com> Message-ID: Oooops! I forgot the "one" in 900001 Thank you, and sorry for the inconveniences -------------- next part -------------- An HTML attachment was scrubbed... URL: From ea4eoz at gmail.com Wed Nov 13 23:23:33 2013 From: ea4eoz at gmail.com (Miguel A. Vallejo) Date: Thu, 14 Nov 2013 00:23:33 +0100 Subject: rtl_fm and r820t tuner In-Reply-To: <528403C1.3080402@earthlink.net> References: <528403C1.3080402@earthlink.net> Message-ID: *>>>Please humor me. How are you determining that the gain is not being set?* See my previous message with Baudline captures: ~$ rtl_fm -f 89000000 -R -s 1000000 -g 0 - | baudline -stdin -samplerate 1000000 -quadrature -flipcomplex -channels 2 -format le16 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 1x. Buffer size: 4.10ms Tuned to 89500000 Hz. Sampling at 2000000 Hz. Output at 1000000 Hz. Exact sample rate is: 2000000.052982 Hz Tuner gain set to 0.00 dB. Result: https://dl.dropboxusercontent.com/u/102802145/baudline0dB.jpg ~$ rtl_fm -f 89000000 -R -s 1000000 -g 30 - | baudline -stdin -samplerate 1000000 -quadrature -flipcomplex -channels 2 -format le16 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 2x. Oversampling output by: 1x. Buffer size: 4.10ms Tuned to 89500000 Hz. Sampling at 2000000 Hz. Output at 1000000 Hz. Exact sample rate is: 2000000.052982 Hz Tuner gain set to 29.70 dB. Result: https://dl.dropboxusercontent.com/u/102802145/baudline30dB.jpg GQRX, LNA gain = 0dB Result: https://dl.dropboxusercontent.com/u/102802145/gqrx0dB.jpg GQRX, LNA gain=30dB Result: https://dl.dropboxusercontent.com/u/102802145/gqrx30dB.jpg I know its very strange but I lost two days trying to make work a project here before I realized rtl_fm was outputting only noise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pelletier.michel at gmail.com Thu Nov 14 16:19:12 2013 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Thu, 14 Nov 2013 08:19:12 -0800 Subject: multiple devices in one process? In-Reply-To: <20131111140013.25251.qmail@stuge.se> References: <20131111140013.25251.qmail@stuge.se> Message-ID: Hi Peter, thanks so much for your reply, On Mon, Nov 11, 2013 at 6:00 AM, Peter Stuge wrote: > Michel Pelletier wrote: > > I'm expecting that there will be no reliable correlation. > I do know USB and libusb and the key in this case is how bulk > transfers are scheduled on the bus - namely optimized for throughput. > Bulk transfers fill whatever bus time is free up to the maximum > throughput the device can handle. > > And even if we imagine that you could have two host controllers with > a synchronized schedule (not possible without rewriting the kernel > USB stack) you still don't know what happens inside the USB device, > there is no guarantee that it doesn't introduce jitter too. > > USB is not a low latency synchronized interconnect, it is optimized > for throughput. > > Reliable scheduling over USB *is* possible, but not using bulk and > not with too high throughput. > Rasz has pointed out in a follow up message that two coherently clocked dongles will buffer data internally and the actual arrival time of the data in-process is irrelevant. I think the important point is the event time that the sampling is triggered, and getting the two triggering events to be as closely synchronized as possible. It seems to me that the jitter would be more predictable, and minimized, if it were the case that rtlsdr could setup two bulk transfers in the same process, and wait on those two devices in the same libusb_handle_events_* call. You have a point in general that you don't know what is going on inside the usb device, and for things like hard drives or network devices that seek or wait on external physical processes (the movement of a head, the arrival of a packet) would have no predictable timing. But it seems to me the rtl dongles have no external physical dependency like that, when you tell them to sample it happens as soon as the dongle receives the command. The data is buffered, and then transferred to the host at some later point. What I want to achieve is the minimizing of the time between the two triggering events and then measuring that jitter. I'd like to setup the experiment where two coherently clocked dongles both sample from a good timing source, say the GPS L1 frequency, and then compare the two sample blocks against each other to see how they are offset against each other in time and if that offset is reasonably bound across many samples. It seems like I will need to do a little hacking to setup a process capable of this functionality, and will report back with any information I have. -Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From leif at sm5bsz.com Wed Nov 20 22:24:45 2013 From: leif at sm5bsz.com (Leif Asbrink) Date: Wed, 20 Nov 2013 23:24:45 +0100 Subject: MiricsFlexiTV-MSI3101 In-Reply-To: <51B8C4CE.2080003@roma1.infn.it> References: <51B8C4CE.2080003@roma1.infn.it> Message-ID: <20131120232445.b30578b073999e951d366733@sm5bsz.com> Hi All, I have a USB dongle with a Mirics tuner which I have tried to get running with libmirisdr. It seems the library is not complete and that it does not configure the chip correctly. I can set a sampling rate and the get sampling rate returns the value that I have set, but the routine to actually set the rate is missing. The sampling rate always becomes 9.142 MHz. As a test I have set the frequency to 500 MHz. The received frequencies are in the range 488.4 to 496.3 MHz. Something is very wrong with the data. If I inject a signal on 490.0 MHz I see four equally strong signals on 496.6, 498.8, 501.2 and 503.4. When the signal is moved towards the center frequency 492.35 MHz, the 498.8 and 501.2 signals move towards the center while the other two signals move towards the passband ends. When looking at the narrowband spectrum of one signal I can see it is actually several equispaced carriers. I have been told that the driver here works: http://blog.palosaari.fi/2013/08/mirics-msi3101-sdr-linux-driver.html Unfortunately I am not much of a programmer, I can not understand how to use the info: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/mirics libmirisdr is easy to understand. Very similar to rtlsdr. It would be very interesting to be able to use this dongle and to check what performance one might get from it. Regards Leif On Wed, 12 Jun 2013 20:58:22 +0200 marzano wrote: > A quite good (AM/SW)/FM/DAB/DVB-T USB dongle. > Mirics FlexiTV MSi3101 (two chips MSi001+MSi2500) > http://www.mirics.com > http://www.mirics.com/node/31 > Data sheets available, register yourself at Mirics portal. > RF Tuner: MSi001/MSi002 ( used by FUNcubrePro+ ?), seems better than R820T > ADC and HiSpeed USB interface: MSi2500 . ADC 10 bit , better than > 8 bit RTL2832U aDC. > Windows binary software available: FMDABplayer, DVB_T decoder, > Windows lib.dll and API doc. > > IO-DATA GV-TV100 stick sold on Japan . > Stick, chips and dev board available from Mirics. > > Linux software at address > http://cgit.osmocom.org/libmirisdr/ > It seems project on stand-by . > Can author Steve Markgraf comment ? > > Francesco > From jsalsburg at bellsouth.net Thu Nov 21 01:17:39 2013 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Wed, 20 Nov 2013 19:17:39 -0600 Subject: MiricsFlexiTV-MSI3101 In-Reply-To: <20131120232445.b30578b073999e951d366733@sm5bsz.com> References: <51B8C4CE.2080003@roma1.infn.it> <20131120232445.b30578b073999e951d366733@sm5bsz.com> Message-ID: <00f701cee657$790d96c0$6b28c440$@net> Here is what I do to figure out how tuners work... http://dangerousprototypes.com/docs/Bus_Pirate http://www.saleae.com/ http://www.signalhound.com/ Using the I2C recorder of the Bus Pirate, I record (hack) the operational traffic on the Tuner's I2C Bus. This traffic is recorded during the operation of the Dongle when it is being initialized by the software that came with the Dongle. This reveals all the Initialization commands and operational commands of the tuner. It is always prudent to record this operational traffic when the tuner is operating on a PC with its included software so nothing is left for guessing. If the Bus Pirate not being fast enough, I use a SALEAE LOGIC 16 to record the I2C traffic. After I characterize the I2C traffic, I use the Bus Pirate to exercise the tuner's I2C Bus and display its IF output with the SIGNALHOUND Tracing Generator/Spectrum Analyzer to test and qualify the accuracy of the tuner's commands. The Dongle's Init and Control SDR libraries are then possible to write. I have used this technique to hack those Set Top Digital-to-Analog Set Top TV Converter Boxes of which millions are available (K-Mart). Those converter boxes have very good LNA/tuners in them unlike the Dongles. I use a 96ksps, 24bit Audio Card on the set top box tuner's Zero IF output for a high quality receiver. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink Sent: Wednesday, November 20, 2013 4:25 PM To: osmocom-sdr at lists.osmocom.org Subject: Re: MiricsFlexiTV-MSI3101 Hi All, I have a USB dongle with a Mirics tuner which I have tried to get running with libmirisdr. It seems the library is not complete and that it does not configure the chip correctly. I can set a sampling rate and the get sampling rate returns the value that I have set, but the routine to actually set the rate is missing. The sampling rate always becomes 9.142 MHz. As a test I have set the frequency to 500 MHz. The received frequencies are in the range 488.4 to 496.3 MHz. Something is very wrong with the data. If I inject a signal on 490.0 MHz I see four equally strong signals on 496.6, 498.8, 501.2 and 503.4. When the signal is moved towards the center frequency 492.35 MHz, the 498.8 and 501.2 signals move towards the center while the other two signals move towards the passband ends. When looking at the narrowband spectrum of one signal I can see it is actually several equispaced carriers. I have been told that the driver here works: http://blog.palosaari.fi/2013/08/mirics-msi3101-sdr-linux-driver.html Unfortunately I am not much of a programmer, I can not understand how to use the info: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/mirics libmirisdr is easy to understand. Very similar to rtlsdr. It would be very interesting to be able to use this dongle and to check what performance one might get from it. Regards Leif On Wed, 12 Jun 2013 20:58:22 +0200 marzano wrote: > A quite good (AM/SW)/FM/DAB/DVB-T USB dongle. > Mirics FlexiTV MSi3101 (two chips MSi001+MSi2500) > http://www.mirics.com > http://www.mirics.com/node/31 > Data sheets available, register yourself at Mirics portal. > RF Tuner: MSi001/MSi002 ( used by FUNcubrePro+ ?), seems better than > R820T ADC and HiSpeed USB interface: MSi2500 . ADC 10 bit , better than > 8 bit RTL2832U aDC. > Windows binary software available: FMDABplayer, DVB_T decoder, > Windows lib.dll and API doc. > > IO-DATA GV-TV100 stick sold on Japan . > Stick, chips and dev board available from Mirics. > > Linux software at address > http://cgit.osmocom.org/libmirisdr/ > It seems project on stand-by . > Can author Steve Markgraf comment ? > > Francesco > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3426 / Virus Database: 3629/6852 - Release Date: 11/20/13 From j.arndt at sis-germany.com Wed Nov 27 13:36:22 2013 From: j.arndt at sis-germany.com (Jochen Arndt) Date: Wed, 27 Nov 2013 14:36:22 +0100 Subject: E4000 tuner gain settings Message-ID: <5295F556.5090909@sis-germany.com> During implementation of signal strength calculations I came across some problems with E4000 tuners. The RTLSRD library uses these E4000 gains: const int e4k_gains[] = { -10, 15, 40, 65, 90, 115, 140, 165, 190, 215, 240, 290, 340, 420 }; These are the gains from Table 6 of the data sheet plus the mixer gain of 12 db for the last value and 4 db for all others. But the last gain of 30 db from Table 6 is only valid when LNA gain enhancement is enabled. Cite from datasheet section 1.16 LNA Gain enhancement: "The LNA gain numbers quoted throughout this document assume that this register is programmed to the recommended value." The RTLSDR libary actually does not change the LNA gain enhancement register AGC11 with manual gain mode and clears it with automatic gain mode. So the last two values of the e4k_gains array must be: 290 = 250 + 40 (max. LNA gain + low mixer gain) 370 = 250 + 120 (max. LNA gain + high mixer gain) With enabled LNA enhancement, the last value would be 420 = 250 + 120 + 50 (max. LNA gain + high mixer gain + enhancement) However, enabling LNA gain enhancement did not work (like the larger LNA gain step size of 5 db). I have verified the above by measuring pure carrier signals of different strength using FFT and subtracting the total gain. Using the corrected values, the changings in the measured signals correspond to the changings of the transmitted signal. With automatic control, the values has been also compared with the input power calculated from the RSSI indicator and LNA gain. The second to last value of Table 6 is also 25 db. I assume that this is a misprinting and the correct value is 22.5 db. Then the corresponding e4k_gains array entry must be changed from 290 to 265. Mixer Gain (automatic mode) In automatic mode, the mixer control register AGC7 is set to 0x01. This will enable autonomous control with a threshold value of zero resulting in always using the high mixer gain of 12 db. When the received signal is inside the automatic gain range (> -50 dbm), the output voltage of the LNA is so high that applying any amplifying afterwards usually results in overdrive samples. Therefore, the automatic mixer gain should be disabled or set to switch to high mixer gain at max. LNA gain by setting control register AGC7 to 0x1D. For the same reason, the total IF gain should be set to less than 10 db. Applications using automatic gain control can then increase the IF gain when the input signal is below -50 dbm to extend the sensitivity range. NOTE: Section 1.15.2 of the datasheet states that writing 0x15 to AGC7 corresponds to a LNA gain threshold of 7.5 db. This is obviously wrong (verified by reading the mixer Gain2 register with different signals). I hope this is helpful Jochen Arndt