Open udoklein opened 9 years ago
aido
commented
9 years ago Hi Udo,
Yes, this is a shortcoming of the MSF signal. But I think leap second can be handled using the fact that the last 8 A bits of a minute are always 011111110.
The MSF page on wikipedia states:
https://en.wikipedia.org/wiki/Time_from_NPL#Shortcomings_of_the_current_signal_format
udoklein
commented
9 years ago Yes and no. A naive decoder would do this. In the presence of noise things are more tricky. Probably the best bet would be to check if a leap second is at least theoretically possible (only 4 times a year anyway). Then create a redundant sync mark binner with 1s offset. If this acquires a better lock ditch the old binner instance. The issue is that this costs an additional 60 bytes of memory plus the CPU cycles to compute it. But of course this might be the best solution. With regard to the 1s offset the question would be if the offset should be +1s or -1s. This could be inferred from the DUT. Because UTC and GMT will be synced when the offset gets to close to 1s. Thus the sign of DUT will tell if a leap second is inserted or removed. A less sophisiticated approach would be to assume that the leap second gets always inserted. As the earth slows down on average this also seems a good guess.
Still the 60 Bytes for this are anoying me.
Another option would be to discard the sync mark bins 4 times a year at the potential leap seconds. Then the clock would resync. Probably this would be the most pragmatic option. With low noise it would resync within some minutes. With lots of noise it would not detect the leap seconds not to fast anyway. So the impact would be minimized. What do you think?
Seems that MSF does not provide a leap second advance warning. This will make leap second handling somewhat more tricky compared to DCF77. On the other hand the decoder can recover from this. So this is also not the highest priority --> can go into the backlog.