my experiments with an arbitrary GPS module offering a PPS discipline showed that it is easily archievable to create a local clock (ntpd based) with a clock precision of 1 microsecond even with cheap low-power soc computers: I was using a Raspberry Pi.
The most interesting finding was the clock drift in correlation with the air pressure. Air pressure change obviously influences the quarz on the raspberrypi. http://www.dl8rds.de/index.php/NTP-Server_with_Raspberry_Pi_and_Sure_Electronics_GPS_Eval_board vy73 markus dl8rds Am Mittwoch, den 16.08.2017, 22:27 +0200 schrieb Marcus Müller: > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
