Swiss_Army_Debug_Helper.ino missing 'unlocked' cases

[nameoftherose]

In the switch (DCF77_Clock::get_clock_state()) { statements on lines 780 and 806 case Clock::unlocked: Serial.println(F("unlocked")); break; is missing.

[udoklein]

Thanks for pointing it out. I will fix it during the weekend or next week.

[udoklein]

Fixed it: https://github.com/udoklein/dcf77/commit/0a06d2daa7c033bcac710224b27f9649fa03a77b

Thanks again for finding this one.

[nameoftherose]

free is forgotten too ... I would rather use DCF77_Clock::get_clock_state() != Clock::useless instead of now.month.val > 0 in line 811 but that is subjective.

[udoklein]

By now I am thinking about not checking anything at all but dumping everything no matter what the state. I will fix the "free" issue. Thanks for pointing this out.

[udoklein]

The missing "free" label is added by now: https://github.com/udoklein/dcf77/releases/tag/v3.2.7

[nameoftherose]

Will you be so kind to have a look on a recent log? Since June 20 clock does not sync. Thank you

[udoklein]

Do you have a recent log for me? I am currently moving into a new flat. That is I would need to dig out the DCF77 stuff out of my boxes that are already packed. If you have a current log I can analyze it. Otherwise I will take 2-3 months till I have everything in place again.

[nameoftherose]

I attach a recent log, file dcf20190622.0.txt is timestamped, while in dcf20190622.txt timestamps are removed. The log starts after reset. Just make a visual assesement if you have any time. Thank you. dcf20190622.zip

[udoklein]

According to the log your library version is

[2019-06-22 21:03:20.801] Compiled:              Wed Dec  5 18:26:27 2018
[2019-06-22 21:03:20.802] Architecture:          AVR
[2019-06-22 21:03:20.802] Compiler Version:      4.9.2
[2019-06-22 21:03:20.802] DCF77 Library Version: 3.1.5

The most up to date version is 3.3.3

In addition the log shows

[2019-06-22 21:03:20.832] EE Precision:    0.0625 ppm
[2019-06-22 21:03:20.833] EE Freq. Adjust: -100.0000 ppm
[2019-06-22 21:03:20.833] Freq. Adjust:    -100.0000 ppm

Maximum accuracy at "exactly" 100 ppm?! This looks suspicious. I would assume there is something wrong with the tuning.

I would also assume that the change that v3.3.0 introduced might fix your problem. I suggest to upgrade to v3.3.3 and see if the problem persists. If not so, send a new log.

Sorry for not digging deeper but right now I am very limited with my time.

[nameoftherose]

Thank you very much for your advice. I think this all is caused by the very limited time that the signal exists due to the long day duration and perhaps increased noise. The embarassing thing is the commercial clock syncs. I have also seen 100ppm frequency adjustment, means the tuning algorithm has saturated. I will look into all this again.

[udoklein]

Yeah, but this is no suprise. The commercial clock uses a different noise model. Most commercial clocks are optimized for a situation where there is a window of some minutes without any noise. That is if they receive a reasonable signal for 3-4 minutes they will sync.

My clock is optimized for a signal that is always noisy. Hence it uses a statistical approach. If the signal is bad for hours and then clean for 4 minutes and then bad for hours it will not sync.

For the "commercial" setup a decoder is pretty trivial. Depending on your noise situation the commercial clock approach can be better.

[nameoftherose]

Thank you for focusing me to the 100ppm frequency adjustment, by zeroing the EEPROM the Clock synced quite easily. The Clock has been operating for almost 2 years now, it is consistently outperforming the commercial clock. This was the first serious incident. Your point that "if they receive a reasonable signal for 3-4 minutes they will sync" is valid but on the other hand they are looking for a signal only 4min every hour, while the algorithm is examining the signal continuously and can also extract information in the presence of noise. I try to avoid changing over to version 3.3.3 because frequency tuning has been eliminated and I like that feature. (But if you think it useful to have v3.3.3 logs from my location i will provide them) I will try to modify the tuning algorithm so that it resets when it reaches maximum value. I am also thinking to buy another bigger antenna. Thank you again.

[nameoftherose]

A typo in the project title, it is resilient not resilent.

[udoklein]

Because this is different from the original issue I created a new issue instead of reopening the old one. https://github.com/udoklein/dcf77/issues/40