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 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.

Comments are welcome, at web@pa3fwm.nl.