General > General Technical Chat

Cheapest way to get date/time from GPS

<< < (14/15) > >>

nctnico:

--- Quote from: dietert1 on April 19, 2024, 03:37:58 pm ---There is a german paper here: http://cadt.de/dieter/dcf/Praezisionsfrequenzmessungen.pdf
In Figure 12 you can see the 10 ** -11. This doesn't mean there was a determination of time to 10 psec, but the clock speed (in that case the rubidium oscillator) could be calibrated to that precision using DCF77. In my tests i actually saw agreement between a GPS and DCF77 (resp. the disciplined oscillators) at the 2E-12 level. Maybe they are using a GPSDO at the DCF77 station.

--- End quote ---
But as I understand it, that is frequency synchronisation only, not time. For frequency synchronisation, you can use a cell tower or FM radio station as well as these are typically synchronised to a Cesium clock or at least GPS + Rubidium.

dietert1:
But for this thread relativistic corrections don't matter. Also it doesn't matter whether the DCF77 station has a Caesium clock or not. And it doesn't matter if there is a millisecond delay due to atmospheric propagation over 300 km. These arguments were superfluous.
Making a good clock for an embedded system requires a way to synchronize with some other good clock and calibration of the clock frequency in order to get the correct time between synchronizations. Both is important but somehow the second aspect was lost until i wrote about the STM32L476 measurements and calibration.

Regards, Dieter

switchabl:
Calibrating RTC frequency, i.e. compensating clock drift dynamically, can be done for specialized applications. But for most embedded systems, picking a suitable combination of crystal and synchronization interval is sufficient.

In the context of this thread, DCF77 accuracy is certainly a non-issue. The problem really is the lack of global availability and poor reliability of off-the-shelf receivers in the presence of metal objects/structures and EMI.

For metrology applications, time synchronization using DCF77 is only accurate to ~1e-05 s even with PM receivers. This is limited by the low chip rate and the variability of LF propagation conditions. Modern commodity GPS receivers are several orders of magnitude better than that. For frequency transfer, DCF77 can more or less compete with basic GPSDOs. But there are specialized GPS-based systems that perform much better (especially using PPP). TAI, from which UTC itself is derived, is established largely using GPS transfers.

There was a nice article about DCF77 (available in english) from PTB some years ago: https://www.ptb.de/cms/fileadmin/internet/publikationen/ptb_mitteilungen/mitt2009/Heft3/PTB-Mitteilungen_2009_Heft_3_en.pdf

dietert1:

--- Quote from: switchabl on April 20, 2024, 09:54:08 am ---Calibrating RTC frequency, i.e. compensating clock drift dynamically, can be done for specialized applications. But for most embedded systems, picking a suitable combination of crystal and synchronization interval is sufficient.
..

--- End quote ---
No, i think there is a good reason that STM32 MCUs include circuits for calibrating their RTC. As we have seen this may reduce the need for clock synchronization by a factor 100. Not everybody can ignore a factor 100.

Regards, Dieter

switchabl:
I think the main use-case is factory calibration, which is common-ish, particularly for applications where synchronization is not usually available (e.g. battery powered long-term data logger).

Beyond that, I'm sure you can sometimes make a case for dynamically adjusting based on synchronization error as well. Say if synchronization is only possible sporadically or very expensive (in terms of power or otherwise). It's just that for things that regularly use a network connection or cellular modem or GPS anyway, I usually wouldn't bother.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod