osmocom-sdr

osmocom-sdr@lists.osmocom.org

906 discussions

Compile fail
by Youpi Youpla 04 Dec '13

04 Dec '13

Hi list, Thanks for your software it's awesome ! I'm currently experiencing issue building gr-osmosdr. This is my gnuradio configuration: #gnuradio-config-info -v 3.6.1 This command was used to download gr-osmosdr: git clone git://git.osmocom.org/gr-osmosdr then: git checkout gr3.6 && mkdir build&&cd build&&cmake ../ Cmake generate everything without errors, however when I run make -j8 I get the following output: [ 75%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/uhd/uhd_sink_c.cc.o /home/RFTEST/GSM/gr-osmosdr/lib/file/file_source_c.cc: In member function ‘virtual double file_source_c::set_sample_rate(double)’: /home/RFTEST/GSM/gr-osmosdr/lib/file/file_source_c.cc:133:18: error: ‘format’ is not a member of ‘boost’ std::cerr << boost::format("WARNING: Overriding original sample rate of %g with %g") ^ make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o] Error 1 make[2]: *** Waiting for unfinished jobs.... /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc: In member function ‘virtual double uhd_sink_c::set_bandwidth(double, size_t)’: /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:290:16: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth’ return _snk->get_bandwidth(chan); ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc: In member function ‘virtual double uhd_sink_c::get_bandwidth(size_t)’: /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:295:16: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth’ return _snk->get_bandwidth(chan); ^ In file included from /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:21:0: /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc: In member function ‘virtual osmosdr::freq_range_t uhd_sink_c::get_bandwidth_range(size_t)’: /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:302:41: error: ‘class uhd_usrp_sink’ has no member named ‘get_bandwidth_range’ BOOST_FOREACH( uhd::range_t bw, _snk->get_bandwidth_range(chan) ) ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc: In member function ‘virtual double uhd_sink_c::set_bandwidth(double, size_t)’: /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:291:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc: In member function ‘virtual double uhd_sink_c::get_bandwidth(size_t)’: /home/RFTEST/GSM/gr-osmosdr/lib/uhd/uhd_sink_c.cc:296:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/uhd/uhd_sink_c.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 Am I'm missing a library or something ? Thanks !

1 0

E4000 tuner gain settings
by Jochen Arndt 27 Nov '13

27 Nov '13

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

1 0

MiricsFlexiTV-MSI3101
by marzano 21 Nov '13

21 Nov '13

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

3 2

multiple devices in one process?
by Michel Pelletier 14 Nov '13

14 Nov '13

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

5 5

Re: rtl_fm and r820t tuner
by Miguel A. Vallejo 14 Nov '13

14 Nov '13

*>>>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.

1 0

RTL-SDR source in GNU-Radio 3.7.1 weird behaivour at 900 ksps
by Miguel A. Vallejo 13 Nov '13

13 Nov '13

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!

3 4

rtl_fm and r820t tuner
by Miguel A. Vallejo 13 Nov '13

13 Nov '13

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?

3 7

Latest commit of gr-osmocom (v0.1.0-44-g0d10f5e9 / 0.1.1git) fails to build
by Joel 13 Nov '13

13 Nov '13

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

3 3

FW: multiple devices in one process?
by Jay Salsburg 13 Nov '13

13 Nov '13

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(a)lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Jay Salsburg Sent: Tuesday, November 12, 2013 3:58 PM To: osmocom-sdr(a)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(a)lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Michel Pelletier Sent: Sunday, November 10, 2013 11:14 PM To: osmocom-sdr(a)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

1 0

Re: multiple devices in one process?
by Peter Stuge 12 Nov '13

12 Nov '13

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

1 0

← Newer
1
...
58
59
60
61
62
63
64
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr