10 ms timing certainty is actually pretty hard to achieve across USB2! But: as far as I can see, it'd be rather easy to say, tune both sticks to DVB-T, cross-correlate to find the relative offset, tune to the frequency of interest and work from there. That is, if the delay spread in the cellular channel < 10ms, but considering that would be equivalent to a path length difference of 3000 km...
I don't think the tuning process itself would interrupt the sampling, right (Sylvain)? Cheers, Marcus On 08/16/2017 07:40 PM, b.shube...@sirinsoftware.com wrote: > Say we need +-10ms accuracy in timestamps. Precision Time Protocol in LAN > should sync PC's clocks with enough accuracy. > And then using USRP-like methods - set current/start time - get first sample > in known time? Of course USB will add > undetermined delays but no external GPS required. > > On Wed, 2017-08-16 at 16:57 +0100, Derek Kozel wrote: >> It should be pointed out that the hardware based timestamping is only needed >> if you need time alignment better than a >> half second or so. With USB transfers, various buffers, NTP based alignment >> of the host computer's time, and some >> extra code on the host side you could do a coarse time alignment, probably >> with less than a half second of error. >> >> You could also time align the streams if both radios receive the same signal >> and you know the distance (and other >> details depending on the precision needed) between the transmitter and your >> two receivers. This is done by many >> protocols like the cellular standards to create a distributed timebase, but >> quickly becomes non-trivial. >> >> The B200 does timestamping in the FPGA and can use a 1PPS signal to align to >> GPS time. It is more expensive than the >> HackRF, but much less than the $3000 mentioned above. >> >> On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote: >>> On Wed, Aug 16, 2017 at 5:11 PM, <b.shube...@sirinsoftware.com> wrote: >>>> What type of hardware? I thought from hardware point of view only precise >>>> clock is required and all the other >>> things in >>>> firmware. I've naively thought i could modify hackrf firmware to get this >>>> feature. >>> Mostly a FPGA and a PPS input from a GPS receiver. >>> >>> Each individual sample has a timestamp of when it has been received. >>> And you can also reset the timestamp on the next PPS edge. >>> >>> Technically it would be possible to modify the hackrf firmware and >>> repurpose some GPIOs and have all samples transmitted to the host be >>> in timestamped packets and implements timestamping in the on-board >>> ARM. >>> For additional hardware you'd only need an external GPS receiver (or >>> some other way to have both a single freq reference + single sync >>> pulse). >>> >>> Cheers, >>> >>> Sylvain >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
