This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Michel Pelletier pelletier.michel at gmail.comHi Peter, thanks so much for your reply, On Mon, Nov 11, 2013 at 6:00 AM, Peter Stuge <peter at stuge.se> 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: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20131114/31a4ed54/attachment.htm>