Accuracy

[cmwik]

We have a Technoline WS 6830 that we brought with us when we moved to America. Of course there is no DCF-77 signal here, but thanks to your amazing project we managed to build a tiny transmitter with a Raspberry Pi 2 Model B rev 1.1, and after much trial and error we got the clock to pick up the signal successfully.

The clock on the Pi is synced with systemd-timesyncd and the system time is correct. However the WS 6830 clock is 8 seconds slow.

Does anyone have any ideas why this could be, or how we could try to debug the issue?

[hzeller]

This is peculiar.

With the option -v, you can tell txtempus to print out the current time it transmits, maybe that helps narrowing down what is happening.

Maybe there is a systematic thing broken with the clock ? Did it work correctly when it received actual DCF-77 ?

[cmwik]

Thanks for the quick reply!

I set up a camera and put the txtempus -v output in the frame along with the clock and an iPhone running Atomic Clock. Pressed the sync button on the back of the WS 6830 and waited for it to complete the cycle. And boom, clock is now in sync again. Nice, but annoying too.

I am wondering if it could be something like:

• The txtempus process starts before systemd-timesyncd has a chance to sync the clock, and it continues to broadcast the wrong time? I have it set to start at boot automatically on the Pi.
• Maybe the hardware clock in the Pi drifts over a few days, and causes it to get out of sync?

Unlike in your example, we don't have it set to start the process 2x day, it just runs continuously. Could it be that we just need to restart the process periodically?

[hzeller]

The hardware clock in the Pi is probably not to be trusted, so make sure you have your systemd set up to run an ntp client and keep the time in sync using that (if not already).

I need to double-check that txtempus behaves nicely if the external system time is modified that it picks it up correctly while it is running.

(in my case, I run the Pi with NTP time sync, and only at night a 2 min before before 2 am and 3am start txtempus for 10min or so using cron, because these are the two hours when my watch attempts to sync the time. That also means that txtempus does not run most of the time and certainly not at boot time when the system time still might be somewhat off)

[seamusdemora]

The hardware clock in the Pi is probably not to be trusted, so make sure you have your systemd set up to run an ntp client and keep the time in sync using that (if not already).

Definitely don't trust the RPi built-in clock! And systemd-timesyncd works well enough for most purposes , but last I checked it used SNTP instead of NTP. You can check RPi time using timedatectl.

(sorry for buttin' in :)

[cmwik]

Butting in welcome Seamus :-)

There definitely seems to be an issue with txtempus maintaining sync with the system clock. In the attached video, the white text is the output of txtempus -v, the green is tty-clock -s showing the time on the Pi, and the weather station on the right shows the radio symbol above the colon indicating it has synced with the DCF-77 signal. This is about 48 hours after starting txtempus and syncing the clock, and as you can see it's already > 1 second out.

The solution may just be to restart txtempus a couple times a day with a cron job and that will keep it accurate enough for our needs. I'll have a read through the source code but it's been 20 years since I wrote any C code, doubt I'll be able to make sense of it...

https://github.com/user-attachments/assets/e2af0739-250a-4ac6-ab02-a2e0a8132d31

[hzeller]

For more closely getting the system time, I'd not use tty-clock (you don't know what UI lag it creates), but instead date to print out the current system time. So to update that frequently, something like this would work, so you see the right time with a lag of at most 100ms-ish:

watch -n 0.1 date

txtempus internally uses the clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME...) call to wait exactly to the next tick it needs, so that is the system time, including all NTP adjustments. Note, that txtempus -v updates after all modulations have been sent, which is either 100ms or 200ms after the full second for DCF77 (just updated it, so if you git pull it will output the log exactly on the second).

There should be no difference in keeping txtempus running or restarting it multiple times a day (though I am wondering why you would run it all day in the first place: Clocks usually only synchronize around 2 and 3am, but don't extract time during the day as the radio band is more noisy during that time, and they only really need to check once a day, ideally at the time daylight saving shifts happen. So I'd probably avoid running a pirate sender all day)

Do you have confirmed that you have ntpd running, which keeps track of ntp time and tweaks the system clock constantly ?

What are the outputs if you run the following commands, that talk to your local ntpd and extract some stats

ntpstat
ntpq -np

[hzeller]

Also, don't use systemd-timesyncd, which is just a crude regular sync without clock discipline.

Use a proper ntpd to get clock discipline and the most accurate time with drift compensation (on my Pi system time is typically within 10-20ms of actual world time).

[seamusdemora]

Yeah... "crude" - but it kinda' goes along with some of the other things in systemd :)

[cmwik]

I've learned to not hate systemd, grudgingly, but took both of your advise and ran apt install ntp which removed systemd-timesyncd automatically and enabled the ntp service. ntpq -np now confirms my clock is in sync (0.000s delay, 0.002s jitter)

I've also switched txtempus to run daily at 1am for 180 minutes. I'm not exactly sure when the clock will try to sync, the manual does not say, but I would assume around 2am since that's when summer time starts/ends in CET. We will see over the coming days if it stays more accurately in sync or loses the signal!

Thanks for your suggestions and thanks again for open sourcing such an awesome utility.