multiple devices in one process?

Michel Pelletier pelletier.michel at gmail.com
Mon Nov 11 05:14:06 UTC 2013


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: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20131110/e037d3e8/attachment.html>


More information about the osmocom-sdr mailing list