Re: [time-nuts] Suggestion for a timing GPS receiver (Trimble / Ublox / other?)
Paride Legovini via time-nuts writes: > I plan to build a decent GPS/GNSS-based Stratum 1 NTP server, and I'm > looking for a good and possibly affordable timing GPS receiver. Unless you plan to use the timing receiver for some other function, it really is overkill for the purpose of setting up an NTP server and otherwise also requires you to set up a proper antenna in order to benefit from the extra precision. > Am I overlooking something or missing interesting options? I think that setting up at least three "good enough" NTP stratum-1 servers in your network gets you much better synchronization than trying to get a single one more precise. To that end, you can set one up for around $60 if you use a raspberryPi and a NavSpark mini w/ patch antenna (if you have reasonable reception with that). You'll find that the NTP clients will not see any measurable improvement once you have the NTP servers down below 10µs deviation and it's possible to get each individual server consistently below 1µs with a bit of care. Having at least three stratum-1 in your network will keep the clients synchronized correctly when inevitably one of the servers will have the occasional problem that makes its time wander off for a while. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ 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.
Re: [time-nuts] Cheap jitter measurements
Bob kb8tq writes: >> Similarly, the box should be able to give me a pulse at a known time. > > how do you set up NTP to do that? Not at all, that must be done in the kernel if you want any accuracy at all. But you could modify an existing device driver (for the LPT port) to use GPIO instead to give you a PPS out (you'll probably want some offset to the true second so it doesn't interfere with the PPS input). I think it'd be best to combine a highres timer with some spin-loop to keep that PPS pulse closer to the clock (it's been done that way for other timing critical stuff before, not really a new idea). Or, if it's only slightly offset from the PPS in anyway, you could piggyback onto the PPS reception. > In both cases (pulse in and pulse out) the first step is to ask NTP > “when was that?”. You still have a pretty big chunk of NTP in the > middle of the process …. If NTP only “knows” what is happening (or can > control what is happening) to +/- 300 ns. The guts of your data will > be limited to the same 300 ns. That's not quite how that works. The resolution theoretically goes down to nanoseconds and is ultimately limited by the timer clock. In the case of the rasPi that means about 52ns, but this is swamped by the jitter of the interrupt latency. But you can feed NTP better timestamps if you figure out how to get them; on the Beaglebone you can use the RPU (Dan Drown has been measuring some latencies that way), on the rasPi you could use the VC4 (this is tricky business due to insufficient documentation, but the hardware should be capable of scanning the GPIO at 250MHz) or even an external TICC. The other option is to use an MCU (or an FPGA) w/ Ethernet and hardware timestamping to build a single-purpose NTP stratum-1 box. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ 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.
Re: [time-nuts] Cheap jitter measurements
Gary E. Miller writes: > It tests the time to do two back to back clock_gettime(). Output > looks like this: > > # ./clock_test > samples 101, delay 1000 ns > min 67 ns, max 302 ns, mean 176 ns, median 197 ns, StdDev 52 ns > > You run it a few times and you will see the granularity in the > measurements is 10's of ns, or more, depending on your CPU. …and it has to be 52ns since the timer that's used by the kernel on the newer rasPi runs off the 19.2MHz clock. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ 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.
Re: [time-nuts] getting accurate timing on RTL-SDR output
Jim Lux writes: > So now the challenge is to "line em up". An obvious approach is to > transmit an inband pilot tone with some sync pattern, received by all, > and I'm working on that too. A maybe not-so obvious approach would be to use RTL-SDR that have been modified for direct sampling (usually via the Q branch) and inject your timing pulse there. That would limit the disturbance of the actual signal while still relatively easy to extract from the data stream. > But right now, I have the idea of capacitively coupling the 1pps pulse > from the GPS to the antenna input - the fast rising and falling edge > are broad band and show up in the sampled data. The trouble is that you are going to impair the already low dynamic range. The ENOB on the I/Q ADC is around 7bit only. > And you can see, no surprise, that the sample clock in the RTL isn't > dead on - over the 10 seconds, it looks like it drifts about 30- 50 > microseconds - that is, the RTL clock is slow by 3-5 ppm. Not all of these are created equal. Several manufacturers claim to factory calibrate their TCXO to better than 0.5ppm. I have currently two RTL-SDR that certainly are within 1ppm. These things get quite hot, so it definitely takes some time before they stabilize even if they do have a TCXO in them. > SO here's the question for the time-nuts hive-mind... > What's a good (or not so good) way to develop an estimator of the > timing/frequency error. Post processing minutes of data is just fine.. There is a program called rtl_test that just checks how many samples it gets in a certain amount of time. Let it run for a few hours on a PC with a GPS-disciplined PC clock and it'll give you a pretty accurate estimate of the mean sampling clock deviation. The other method is to tune to a signal of known frequency and check what it reads as. There is a program floating around that uses a GSM station for that purpose. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ 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.
Re: [time-nuts] getting accurate timing on RTL-SDR output
jimlux writes: >> A maybe not-so obvious approach would be to use RTL-SDR that have been >> modified for direct sampling (usually via the Q branch) and inject your >> timing pulse there. That would limit the disturbance of the actual >> signal while still relatively easy to extract from the data stream. > > That's where it's being injected.. I'm using the RTL-SDR V.3, which > has the RF input fed right to the Q input. OK, some more details (I did say it was a bit non-obvious :-) on that idea. The R820T tuner in the RTL-SDR v3 only uses the I input of the RTL2832U as it's a low-IF architecture, leaving the Q inputs free and unused in the normal mode of operation, which the direct sampling modification takes advantage of by populating the Q branch with a direct input. The other commonly used tuner, the Elonics E4000, uses both inputs, because it's using a zero IF architecture. Thus it should be possible to switch the RTL dongle to zero IF mode, get the I/Q samples as per normal and you get two perfectly correlated data streams from two different inputs. You can modify the hardware to also have a direct input on the I branch normally used by the tuner. Alternatively, don't modify the hardware and use the tuner to downconvert an RF sync signal to the I branch (you can test if that works by just using it in direct sampling mode with the I branch selected, but I think the tuner might get switched off by the rtlsdr library, so there'd need to be some modifications to the software). http://datasheetcafe.databank.netdna-cdn.com/wp-content/uploads/2015/09/RTL2832U.pdf https://www.reddit.com/r/RTLSDR/comments/1uazsw/rtl2832_datasheet_deep_info/ Also, the RTL-SDR v3 does have a clock input, so you can modify the hardware to use that and make its sampling coherent to a known clock source. That would allow you to align the sampling files only sporadically and then rely on the known relation to the clock as long as no USB frames are getting dropped. https://www.rtl-sdr.com/rtl-sdr-blog-v-3-dongles-user-guide/ No, I haven't done anything of that yet, but what initially got me interested is the idea of correlating DCF77 (through an upconverter) with GPS. Still working on the antenna setup, it might be possible to also receive TDF, MSF and maybe even RBU. I did get as far as buying a GPS timing module with a frequency output that I can use for the external clocking to eventually get coherent sampling. >> Not all of these are created equal. Several manufacturers claim to >> factory calibrate their TCXO to better than 0.5ppm. I have currently >> two RTL-SDR that certainly are within 1ppm. These things get quite hot, >> so it definitely takes some time before they stabilize even if they do >> have a TCXO in them. > > Could well be.. I just turned it on, waited for the beagle to boot, > captured the data, and moved on. My RTL-SDR v3 is still in transit, but I expect your result to indicate that it was still warming up based on what my other RTL based dongles do. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ 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.
Re: [time-nuts] Pulsars, clocks, and time nuts (Jim Palfreyman)
Bill Hawkins writes: > It seems that pulsars are rotating stellar objects that have no reason > to change their rotation, except to decay. The whole point of that exercise was to determine which of the theories that predict what the internal structure of a neutron star looks like is more likely to be correct. Here's a not too long and not too dense (pun intended) writeup: https://arstechnica.com/science/2018/04/neutron-star-glitch-hints-at-superfluid-beneath-its-crust/ > Ruling out causes from the stellar object, You've taken a wrong turn right there. The timing variations that were measured are (most likely) produced by the stellar object. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ 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.
Re: [time-nuts] nuts about position
Tim Lister writes: > It has taken me quite a bit longer that I had hoped but I have finally > published a writeup and howto of collecting raw ublox data, converting > it to RINEX and how to do (or get the NRC experts to do) the > post-processing. It's at a new website I have setup: > https://adventuresinprecision.space/howtos/precise-gps-positions/ > Please let me know any comments or suggestions you have to improve it > or make it more comprehensible and comprehensive. Thanks for taking the time to write that up. Out of curiosity, how far away from the RINEX coordinates is an RMS or median of the original coordinates as recorded by the GPS and how does the convergence curve look like? I'm trying to gauge how long I need to run my timing module in survey mode… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ 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.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Gary E. Miller writes: > Which I always thought was pointless, that only works for a fixed > antenna. Any GPS in a fixed position lab will have a good rooftop > antenna with clear skyview. Except when it doesn't and then the ability to survive on fewer visible/good satellites without going into holdover is most welcome. > Except that requires a post process step, so not useful for real time. No, you can very much use it to inform a consumer of the PPS in realtime about the sub-quantization phase shift and have the PLL take this error refinement into account. > I just looked at the 'U-blox 8 Receiver Description' and it makes no > mention of sawtooh anything. Is that in a different doc? No, it's in there, look for the UBX-TIM series of messages, specifically TOS and TP. However, it talks about offsets of the time pulse, not a sawtooth. But there's a more specific description for series 6 timing receivers, most if not all of which will be applicable to your series 8 module as well: https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_(GPS.G6-X-11007).pdf > I'll also test Surevey-In mode to see how much that helps. _Any_ error in the surveyed position will show up as timing error that also depends on the GPS constellation. I think Lady Heather provides a special plot to map these deviations to the GPS sky tracks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ 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.
Re: [time-nuts] Raw phase data of super-5065
Attila Kinali writes: > Unfortunately, I have no application that can read XPS files available. > Can you send it as something more standard? Okular opens the file without problems. MuPDF should do the same, but I can't test it at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ 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.
