On Nov 12, 2013 8:25 AM, "David Jacobowitz" <[email protected]> wrote: > > > So, is there any way to line up samples post-hoc? > > For example, using external hardware one could inject another signal, still within the tuned bandwidth, but away from the signal of interest. Then you could line up the synchronizing signal. I'm guessing this signal would actually have to be modulated with some kind of sync pulse or maybe even timestamp. That sounds kludgey and expensive, though, not in the realm of "gee, these cheapo USB sticks are cool." :-) > >
This would work. The above commentary on sample jitter isn't quite right: sample alignment only has anything to do with USB latency during the command to begin streaming. During streaming, latency variation has no effect because it is the dongles' clocks which determine the sample time, not the host's. If the dongles are synchronized as per Juha's hack, the time offset will be constant. In this light, threading and USB transfer scheduling are irrelevant. The only alignment possible is during the command to begin streaming. No matter what, calibration will be required to achieve any useful sort of coherence. The dongles' lack of overflow detection makes this a little sketchy, too, as the outputs will slip randomly with respect to each other in case of dropped samples. --n > > > On Mon, Nov 11, 2013 at 3:00 AM, <[email protected]> wrote: >> >> Send osmocom-sdr mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.osmocom.org/cgi-bin/mailman/listinfo/osmocom-sdr >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of osmocom-sdr digest..." >> >> >> Today's Topics: >> >> 1. multiple devices in one process? (Michel Pelletier) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 10 Nov 2013 21:14:06 -0800 >> From: Michel Pelletier <[email protected]> >> To: [email protected] >> Subject: multiple devices in one process? >> Message-ID: >> <CACxu= [email protected]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> >> 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-0001.html > >> >> ------------------------------ >> >> _______________________________________________ >> osmocom-sdr mailing list >> [email protected] >> http://lists.osmocom.org/cgi-bin/mailman/listinfo/osmocom-sdr >> >> >> End of osmocom-sdr Digest, Vol 24, Issue 4 >> ****************************************** > >
