An initial gnuradio GRC flowgraph for measuring Time Intervals, and dumping raw binary to a file is now on github. There are two helper Python files: one to convert from binary to floating-point-ASCII-text, and another to take that from raw measurements to Time-Intervals.
That file can be sent straight into TVB's ADEV.C program. The TEXT-to-TimeInterval python program pretty aggressively defines outliers and throws them out. This is due to a bug in the particular SDR being used which seems to insert random large glitches into the 1-Hertz output. The flowgraph and python code are quite simple, undoubtly one would want to tweak it. I've measured an external disciplined signal input to the SDR running on it's internal crystal oscillator, and another measurement of a GPSDO that is both the external clock reference for the SDR and simultaneously the unknown. The purpose is this later is to characgterize what the background ADEV looks like. The GPSDO compared to itself is of course a lot better and pretty straight as 1/tau for an hour or so becausue it's just measuring anything bad the SDR does to it. https://github.com/Tom-McDermott/SDR-time-interval -- Tom, N5EG On Mon, Dec 14, 2015 at 10:01 PM, Tom McDermott <tom.n...@gmail.com> wrote: > Hi Iain, > > I'll publish a flowgraph soon. I built a Out-Of-Tree module to decimate > the output > down to one sample per reading to keep the output file small for even long > runs. > On the order of about 48000:! decimation. Strange thing is - it works > when the > QT Time Sink is enabled, but gives very wrong outputs when the QT Time Sink > is Disabled (the only change). > > So I suspect my custom OOT is doing something wrong, but not sure why > enabling/disabling the scope display changes the gnuradio behavior so much. > I'd like to get more to the bottom of this before publishing the code. > > Have done some short runs throwing 48,000 samples/sec to the output file, > then post > processing that in Python, and it gives the same results as my OOT module > when the > QT GUI is showing. Very strange, but the data file is much too verbose: > 700 Megabytes/hour. > > -- Tom, N5EG > > > > On Mon, Dec 14, 2015 at 1:15 AM, Iain Young <i...@g7iii.net> wrote: > >> Hi Tom, >> >> On 14/12/15 03:15, You wrote: >> >> I've constructed a homebrew setup to measure time intervals using a >>> software defined radio. Basically a single-channel downconversion to >>> about one hertz, then count samples from the SDR clock to time stamp >>> the zero crossings. This is done in gnuradio and saved to a file for >>> post processing. The resolution is theoretically good, but the accuracy >>> is unknown. >>> >> >> Very interesting. Would you consider making your flowgraph available ? >> >> I have done similar things with just thresholding and looking for the >> start of second (or minute) marker of various distant radio clocks, and >> then graphing how far apart they were, as well as feeding NTP. >> >> >> 73s >> >> Iain >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
