multiple devices in one process?
leif at sm5bsz.com
Tue Nov 12 18:35:18 UTC 2013
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
> 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
> 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?
More information about the osmocom-sdr