New timecode on Poland's 225 kHz signal

[phase plot] Since late 2023, Poland's longwave broadcast transmitter on 225 kHz additionally sends a time code as phase modulation. Many other longwave transmitters have been doing this for years, like the longwave broadcasters BBC on 198 kHz and France on 162 kHz (see also here and here), and dedicated transmitters MSF on 60 kHz and DCF77 on 77.5 kHz.

Still, it's surprising to see such a service start in 2023, when there are so may other ways to receive time information, and many longwave transmitters are being shut down. (However, looking in old recordings, it turns out that the phase modulation of this carrier with "Enea lighting control" messages has been going on for at least 8 years; only the time code is a recent addition.)

Documentation of the data format can be found at https://e-czas.gum.gov.pl/e-czas-radio/; only in Polish, but Google translate does a good job of translating it to English. Using this, I've implemented a simple decoder to go with my WebSDR at http://websdr.ewi.utwente.nl:8901/tdf/poland225.html.

While implementing this, I ran into a couple of unclarities, errors and omissions in the published specification ("version 1.0"), as documented here.
(Note: this list is not meant as criticism, but to help other potential implementers, and perhaps the authors of the specification to improve it.)

Errors/unclarities/omissions:

The bits of the timecode are transmitted with the most-significant bit first, while the specification suggests the opposite. The UTC offset is in fact transmitted least-significant first (as documented), suggesting that this was the intention.
The encoded time is UTC; the specification doesn't say this explicitly, only that the also transmitted offset must be added to obtain local (Polish) time.
The scrambling value, given as 0x0A47554D2B, is to be interpreted as a 37 bit number, and EXORed, most-significant bit first, with bits S0...SK1.
The number of seconds since 01 January 2000, as transmitted, excludes any leapseconds in that interval.
Details of the error-detection CRC are not given, making implementation impossible (which polynomial? which initialization? which bits? before or after scrambling? etc.).
Same for details of the error-correction Reed-Solomon code.

Some further remarks:

What is the point of the three bits '101' before the actual timecode? The documentation ~~points out~~seems to suggest that the 25th bit, which is one of these, is the actual moment of which the time is encoded, but there's no need to actually transmit a specific bit value at that moment.
There are "only" 30 bits for the timevalue, which will overflow in the year 2102.
What's the point of the scrambling? Scrambling can be used to reduce the DC component, but then it must be pseudo-random, not deterministic as here.
The modulation format has a substantial DC component; a format with much less or no DC component may make demodulation a bit simpler and is very advantageous in case the transmitter is also used as a frequency reference (its carrier seems to be spot-on, so perhaps it is already tied to an atomic reference?).
It's odd that the Reed-Solomon code doesn't cover one of the data bits; presumably a code on GF(2⁴) is used, which would allow for 15 blocks of 4 bits, so this one bit was too much.
Is Reed-Solomon really a good choice for this? It's a powerful code, but the decoding algorithm is rather complicated, which is not easy to implement on a low-powered microcontroller.
One wonders what all those "lighting control" messages are for...

Update October 2024

Wojciech Kaczmarski, SP5WWP, and Grzegorz Kaczmarek, SP6HFE, have puzzled out the CRC and Reed-Solomon codes, as detailed in code in their github repositories: https://github.com/sp5wwp/e-Czas and https://github.com/sp6hfe/e-CzasPL Unexpectedly, the CRC is calculated over the scrambled data bits, rather than over the actual databits.

Update November 2024

Two more observations:

The transmitted timestamps are quite imprecise. The start of the message (first synchronization bit) is varying between 150 and 200 ms after the start of the time represented by the message. This starting time seems to vary according to a rather irregular sawtooth, advancing to 200 ms over a number of minutes, and then jumping back to about 150 ms. Such errors may be acceptable for a wall clock, but not for e.g. an NTP server. [see below]
For reference, as also notably missing from the specification: the modulation is a straight-forward phase modulation, with a 1 bit represented by the "normal" carrier phase and a 0 bit by the phase being retarded by 45 degrees. The phase slewing seems to be linear in time.

Update September 2026

Measuring now, the timestamps do seem to be much more accurate than earlier. The graph shows the measured offset over the last year or so, with NTP as reference. The received timestamps are between 10 and 25 ms late at my location, of which about 3 ms is due to the distance (propagation).

A very clear slope is visible: the clock seems to be running 5.5 · 10^-10 slow. Also, this slope is quite stable, apart from what looks like a step-wise correction in May 2026. The Allan deviation is about 2 · 10^-9 at tau=10⁶ s, with a slope of still almost -1, suggesting most of the random fluctuation is due to propagation effects rather than the clock source. Thus, it looks like the clock is more stable than would be expected from a quartz oscillator. So it seems as if the transmitter does use an atomic clock for reference, but which is running slightly slow; perhaps a rubidium?

Comments are welcome, at web@pa3fwm.nl.