Seems that my Super Filter is more useful than I expected when I created it. Actually I only created it because it was so easy. Well, unfortunately it fell short of the expectations some people had about it. Special thanks to Uli Beyenbach for pointing my nose to it.
I decided that I will not only fix the issues but extend its functionality. Now it will live up even to those expectations that I did not intend to cater.
You will find the new Super Filter 2 here.
In case you wonder why my blog entries are somewhat short lately: the time is used up by the next release of the DCF77 library. Wait and see 🙂
Blinkenlight 
Hi,
I’m certainly impressed by your library, making a donation absolutely worthwhile to stimulate the good work
There’s one thing that’s missing, and that’s good structured documentation.
For example, I figured out how to put the crystal’s frequency fault into the code (using DCF77_1_Khz_Generator::adjust(-28369);), this works fine, a few minutes and the first DCF time is received.
For what I understand from your blog, the frequency adjustment has been automated into the library. When I take your latest code (the swiss army knife version, that should completely depend upon the library, right?) and compile it (windows 8.1, Arduino 1.6.4) will it tune the frequency adjustment (it’s 28 kHz) itself ? How long will it take do so on average ? It has been running for quite a while now, but nothing changes in the serial output. Since I’m on windows, I cannot just disconnect and reconnect the Arduino board since this reset the whole thing , so I have to stay connected with my laptop to monitor any progress.
confirmed_precision ?? adjustment, deviation, elapsed
0 Hz .- , 0 Hz, 0 ticks, 85 min, 34329 cs mod 60000
8244/100~0/600
Thanks !
Well, this project is basically driven by my intend to learn about signal processing. So documentation is not the very highest priority on my list. There is already a lot in my blog. But I get your point. However “good” documentation is subjective. What exactly would you expect from the documentation?
With regard to donations: they are always welcome, the higher the better 🙂
With regard to the tuning. Yes and no. The library can auto tune for crystals. The maximum supported tuning range is assumed to be +/- 30 000 Hz. However in practice I think this is not reasonable. The point is that a crystal oszillator is usually within +/- 200 ppm, otherwise it has already some kind of manufacturing defect. Your oszillator deviates by more than 1000 ppm which probably indicates an Arduino Uno which has a resonator. You may tune it manually of course but as soon as temperature changes come into the equation it will fail. Actually this is what might happen: you tune it manually. It locks successfully to the signal and runs a week or so at reasonable constant temperature. Then it decides to narrow down the bandwidth by a factor of 10 and persist this to the EEPROM. Then after some hours it loses the lock because of the poor stability of the resonator and will never or seldom relock.
Or with other words: get an Arduino (clone) with a crystal and it will successfully and reliably auto tune. Otherwise your are relying on luck.
The library is designed under the assumption that the clock source has an offset of +/- 100 ppm and short term stability (tau = 1h) of better than 2 ppm. Consider this the SOA, everything outside the SOA may or may not work and if it works it may be unreliable. Notice that these specs are trivial to meet with a crystal in a living room but significantly harder to meet with a resonator.
Hi, both arduino boards I own do have a crystal, not a resonator. one board is from the arduino starterkit, the kit with a lot a components, a book, a breadboard and so on. One wold expect it to be fairly good if it’s origional, however, it seems not. Can always try to replace the crystal with another one of course, maybe that helps.
Well, my impression is that Arduino is overpriced compared to the quality they deliver. You basically pay for the brand. ISome of the clones offer comparable or significantly better quality for the same price or less. In particular some clones still have a crystal instead of a resonator.
Hi,
I’ve been playing with the Filter a few days now. It works great as far as I can see at this moment!
There is one strange behavior, and I think I read it as a remark from another fan of your library on this blog earlier in time.
When the filter has gone into a stable sync, and the status reaches “5”, I introduce some noise to the antenna (by turning on the powersupply of my laptop 😦 .
The filter switches to status 4, the indicator on pin 3 remains permanently lit (at least until the disturbance is taking too long, it will start 1-off / 3-on )
I would expect the synthesized output on pin 6 to continue sending out clean bit paterns, however it does not: it starts sending malformed bits, too long, too short, too many – it seems to copy the garbage from the antenna. That’s not the expected behavior when referring to this info on the github site “synhesized: as long as the receiver clock is at least “free” provide synthesized output. Otherwise pass the signal as it is”
If by any change you are able to look into this ?
Btw – not until this afternoon I realized my arduino’s are not on a crystal – the clearly visible crystal on the board belongs to the USB interfacing IC, the resonator on the 328 is so small, you can hardly see it Now searching for boards with TWO crystals
Just to be sure that we are on the same page. You refer to https://github.com/udoklein/dcf77/blob/master/examples/Superfilter/Superfilter.ino, in particular to this version: https://github.com/udoklein/dcf77/blob/b27881213953877220a62be468b37f939f42d49d/examples/Superfilter/Superfilter.ino. Correct?
Would you please use this version: https://github.com/udoklein/dcf77/blob/debug_helper_for_superfilter_issue/examples/Superfilter/Superfilter.ino and capture its serial output into a file? Then reproduce the issue. The debug output would help me a lot to figure out what is going on and to fix this issue.
With regard to the Arduino I am unaware of any with two crystals. You have to go for some “outdate” clone that still has a crystal. The point is that the Uno design just sucks. Go for copy of an older Arduino design.
Hi, Thanks for looking into it.
Seems the debug code you supplied needs some editing before i could compile it, things like this (line 80): digitalWrite(dcf77_second_pulse_pin, ms_counter = DCF77_Clock::locked); // JB changed Clock into DCF77_Clock
and line 83: tick == DCF77::long_tick ? ms_counter < 200: // JB removed Internal::
and so on, i compared the line to the 1.1.0 version and made changes accordingly when error during compilation occurred.
the zipped debugfile can be found here : https://csf.sharefile.com/d-sb1321406755427ea
I observed the erroneous output, my first conclusion is it occurs right after the start of a minute, so it's in the meteo bits ?
I looked into the logs but did not find out what is going on. I have prepare a ***very*** special debug helper. This will NOT compile on your system. However if you tell me which pin settings you used I would compile one for your Arduino. Then you could upload it and provide me with the logs of this helper. Hopefully this would then shed some light on this issue.
Hmm, I downloaded it again from github and it compiles. Strange. Anyway thanks a lot for providing the trace. I will not manage to resolve this today but I will look into it during the week.
It’s appreciated !
Hi, i only changed the status from pin 3 to 13 ( the onboard LED. Furthermore, i use a non-inverted DCF signal.
OK, can you upload https://gist.github.com/udoklein/26fa7cf84e3f18852d5d with avrdude? To find the proper parameter to avrdude, just set your IDE to “upload verbose” and upload something. This will show the parameters in the console output. Copy those and use them to upload the file. Then please capture the output of this and send it to me again.
Hi,
I ran your .hex code and create a debug output and a mp4 movie.
At 19:27:45 I turned on the disturbance
at 19:28:45 I turned it off
at 19:29:45 I turned it on
at 19:30:45 I turned it off
In the video you can see an LCD showing a clock synced by your Superfilter.
The white led on the left is the clock pulse from pin 6, the amber led in the right below is the “signal quality” led. Tx is blinking.
Notice when I turn on the disturbance (which is, in this case, the SMPS from my notebook), the first 15 seconds of the timecode are messed up. You can see this looking at the white led, blinking very irregular. It starts blinking “normal” again at 15+ seconds after the full minute.
Files at:
https://csf.sharefile.com/d-s2f0ec9170e446739
https://csf.sharefile.com/d-s275e6884ead434e8
Thanks a lot for adding the video. This finally solves the mystery. To understand what’s going lets look into the piece where the final output is computed (
const uint8_t synthesized_signal = ...)Now lets look into the DCF77 encoder in particular in function
DCF77::tick_t get_current_signal(const DCF77::time_data_t &now). During seconds 1-14 it will output undefined. This is because these are the seconds that carry meteo data. Since meteo data can not be derived from the time I can not compute them and output undefined. Hence during these seconds the meteo signal is just passed through. So if the input is erratic seconds 1-14 will be erratic as well. This is a feature. Of course I could synthesize them to a default. This would make up the output to appear smoother but would prevent anyone from decoding the meteo signal after the filter. For clocks that do not evaluate the meteo part it should make no difference as they will ignore the meteo bits anyway.Conclusion everything works as designed. In particular the filter synthesizes the time data and leaves the meteo data alone. Probably I need better documentation as you already pointed out. I will put this on my list. May take some time though.
–> You filter setup works as it should.
Thanks a lot for adding the video 🙂
P.S. How does the library / the filter perform for you? Especially under typical noise conditions?
As an afterthought: if you want to default the meteo signal just change the synthesized signal to
const uint8_t synthesized_signal =
tick == Internal::DCF77::long_tick ? ms_counter < 200:
tick == Internal::DCF77::short_tick ? ms_counter < 100:
0
Hi, thanks, I’m glad the video showed what I meant 😉
I have changed the code with your afterthought in mind : this should give my DCF decoder a clean signal when the antenna-signal goes crazy. There is no need for the meteo data, I cannot decode it anyway (who can ?), however, the algorithm I use likes to have to complete sequence of bits. (it’s Thijs Elenbaas’s).
Following your last hint, it would leave out the sync puls (which is NO pulse) and the meteo bits. However it give me an idea on how your code works, so I changed it to :
tick == DCF77::long_tick ? ms_counter < 200:
tick == DCF77::short_tick ? ms_counter < 100:
tick == DCF77::sync_mark ? 0: ms_counter <100;
maybe you can add something like this as a settable option , so users can decide at compilation time whether they need the meteo data or not ?
BTW I replaced the resonator with a true crystal. Now it runs and autotunes like a charm!
Good point. I will add this. With regard to the meteod ata: if you use the filter in front of a commercial clock you might want this. To my knowledge there exist no legal open source decoders for meteo data. The reason is not that this would be hard. It is actually trivial since the key and the algorithm were leaked. I could easily implement this for Arduino. The issue is that publishing it would be just asking for trouble. I suspect there are quite some people out there who can and will decode meteo data but do not publish this fact.
Have a look at this https://github.com/udoklein/dcf77/commit/b71a98d621541fd7857895f409e557235d4da2e9 and tell me if this is how you would expect it. I opted for sending 1 instead of 0 for unknown data because 1 is never used as a sync mark. This would probably be the best for receivers that are unaware of the meteo data.
Hi,
There’s another funny thing i just discovered. I hooked up a 7 segment display that shows the state the filter is in (synced, locked, etc …) so i can see the quality wthout a serial console.
It starts at 0 , goes 1, goes 0, goes 5, goes 4, goes 5, And then …. The output both serial and bitwise says it’s 17-07-2097 !
This shows the change-over from 4 to 5:
Decoded time: 15-06-15 1 22:20:58 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 1 (6367-0:255)(178-70:15)(245-187:8)(249-233:2)(168-165:0)(251-228:3)(251-230:2)(211-219:1)4,21,21,0
Decoded time: 15-06-15 1 22:20:59 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 1 (6377-10:255)(178-70:15)(245-187:8)(249-233:2)(168-165:0)(251-228:3)(251-230:2)(211-219:1)4,21,21,0
Decoded time: 97-07-17 1 16:20:59 CET *L
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (6347-0:255)(178-70:15)(245-187:8)(249-233:2)(168-165:0)(251-228:3)(251-230:2)(214-219:2)4,21,21,0
Decoded time: 97-07-17 1 16:21:00 CET *L
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (6349-0:255)(178-70:15)(245-187:8)(249-233:2)(168-165:0)(251-228:3)(251-230:2)(214-219:2)4,21,21,0
Decoded time: 97-07-17 1 16:21:01 CET *L
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (6351-0:255)(178-70:15)(245-187:8)(249-233:2)(168-165:0)(251-228:3)(251-230:2)(214-219:2)4,21,21,0
The code is the latest version with the meteo addition (which I had to change to output all Zero’s instead of all One’s, otherwise my DCF receiver software wouldn’t accept it, must be a bug)
Thanks for putting efforts into testing my library.
Just out of curiosity: can you use the swiss army debug helper to record maybe 60 minutes of this signal such that I can analyze the real cause?
My suspicion is as follows:
The signal seems to be really crappy with a bias towards “high”. Now the decoder is basically some kind of random walk mechanism. Whenever it is “far enough” in the “good” area it will switch to sync. Obviously in your case the threshhold for “far enough” is not really “far enough”. With other words we need to increase the threshhold. You may wonder why I did not increase it in the first place. Well, the additional safety margin will increase the time to acquire a sync and it also increases the time for resync.
However on the other hand the phase lock seems very good, so the signal is not that bad. Except for leap seconds (next one due June 30, 2015 at 23:59:60 UTC) a lock is good enough to keep accurate timing.
My suggestion is to increase your threshhold as in the following library branch: https://github.com/udoklein/dcf77/tree/defensive_sync_test
Can you give this a try and see if you are still able to reproduce the issue? If not I could make this an option in the .h file.
Hi, I was able to generate 2 logfiles which I will make available to you. I think the logfile that comes from the .hex code you sent me last week, shows the data that you need for your investigation ? Borh recordings were made with a clean signal, reception is pretty good in the place I live.
the output from the .hex code : https://csf.sharefile.com/d-sd6a717c82354ba5b
the output from the filter : https://csf.sharefile.com/d-s7f51920522e4cc3b
both files show the strange time and date appear after about an hour when the filter changes from locked to synced.
I have not been able yet to generate a output from the Swiss army knive debugger.
Thanks for providing the logs. I will look into them and try to figure out what is going on. Due to the long time constants / long round trip time for analysis this may take some time though. It might be necessary that I provide you another dedicated debug helper if I can not reproduce the issue here. But as I said this may take some time.
Thanks !
So far I am not able to reproduce the issue. But your logs raise some suspicion. Can you create another log with the help of this version of the debug helper: https://gist.github.com/udoklein/714cfdbe2f8b4efe43fd Please flash it and once it stats put it into mode “Dm”. That is send Dm through the serial monitor to it. Then log the next two hours or whatever it takes to reproduce the issue. If it does NOT show up, just log 2-3 hours.
Thanks! I will start the logging right away. Strange enough, at this moment , i cann’t reproduce it either… I’ll post the logs later on!
the log file is at https://csf.sharefile.com/d-scf9e2a4aabc4b6db
The issue does not show up .. I noticed the value at p(…) keeps growings to a much higher value as before. What does it indicate ?
We have two issues here:
1) By accident I was linking vs. my development branch instead of the published branch. That is both debug helpers use different libraries.
2) The first debug helper used a flawed unpublished library which resulted in wrong crystal tuning. This in turn would explain the observed behaviour.
3) The latest debug helper uses the newest unpublished library of the development branch which does not show this behaviour.
4) Your original version is a different from both.
I suggest to retest what happens if you recompile your stuff. If this can be reproduced we have two routes to solve this issue:
a) I issue another debug helper with the old library.
b) You wait till you get hold of the newest library. I will publish it probably in two months. If you want to you can get an unofficial version as a beta tester.
With regard to the bigger numbers: this indicates that the library tuned to your crystal better than 8 ppm. Hence it decided it can narrow the bandwidth by a factor of ten (and increase the noise tolerance accordingly). This indicates that it was running fine for an extended period of time. This is considered good 🙂
Hi Udo,
I have recompiled the filter with the latest download of the library, and have not been able to reproduce the issue anymore last week, so that’s good !
Another question appeared however: the bits for CEST and CET seems to be both high at some given time: in the code I can see your code handles different cases for the CEST bit for good and bad reception, however I cannot figure out how this is applies when the filter is generating synthesized output.
The DCF decoder I use scans for parity errors in the date and time of course, and it also checks of the CEST and CET bits are of opposite value , if not it generates a parity error. For now, I have disabled this check to be able to receive time.
Hi JJ,
thanks for the donation 🙂 With regard to the summertime issue: I am investigating it. May take some days though.
Great that it basically works. And thanks for the donation.
I had a quick look into the code. I have to admit that I do not fully understand why it fails. However the latest release https://github.com/udoklein/dcf77/releases should fix it. However it is to late tonight to test it. Maybe you can try it and provide me some feedback.
-Udo
Hi, I applied the latest fix for the summertime bit, so far so good, no errors until now 🙂
Hi Udo.
I am having problems getting the Super filter to work.
I am building a DCF77 Analyzer Clock and have added your Super Filter as a switchable option so I can compare results.
I have an inverted DCF77 receiver and have set the Super Filter as the code below.
_______________________________________
const uint8_t dcf77_analog_samples = false;
const uint8_t dcf77_analog_sample_pin = 5;
const uint8_t dcf77_sample_pin = 19; // A5
const uint8_t dcf77_inverted_samples = 0;
#if defined(__AVR__)
#define ledpin(led) (led)
#else
#define ledpin(led) (led<14? led: led+(54-14))
#endif
const uint8_t dcf77_monitor_pin = ledpin(18); // A4
const bool provide_filtered_output = true;
const uint8_t dcf77_filtered_pin = ledpin(5);// was 12
const uint8_t dcf77_inverted_filtered_pin = ledpin(4);// was 11
const uint8_t dcf77_filter_diff_pin = ledpin(2);// was 7
const bool provide_semi_synthesized_output = false;
const uint8_t dcf77_semi_synthesized_pin = ledpin(16);
const uint8_t dcf77_inverted_semi_synthesized_pin = ledpin(15);
const uint8_t dcf77_semi_synthesized_diff_pin = ledpin(14);
const bool provide_synthesized_output = false;
const uint8_t dcf77_synthesized_pin = ledpin(4);// was 6
const uint8_t dcf77_inverted_synthesized_pin = ledpin(5);// was 5
const uint8_t dcf77_synthesized_diff_pin = ledpin(2);// was 4
const uint8_t dcf77_second_pulse_pin = ledpin(10);
const uint8_t dcf77_signal_good_indicator_pin = ledpin(3); //was 13
_____________________________________________________
When the Superfilter has not synchronized (and the un synthesized signal is output) the signal output is inverted. When it has synchronized the signal in non inverted and works fine until the unsynthesized Meteo data is output then again the signal errors and won't get past the 0 bit mark.
If I switch back to the non filtered signal from my receiver it all works fine.
Is there a problem with the filter working with inverted signals?
I have tried super filter 2 with library release 2 and Superfilter 3 with library release 3 with the same results.
Is there a way of inverting or not inverting the non synthesized signal so the synthesized and un synthesized signals match?
Regards.
Brett.
I will look into the superfilter over the weekend or next week. Might be some mistake on my side.
Thanks for pointing it out to me.
Hmm, by now I have to confess that I do not fully understand the issue.
1) What exactly do you mean be “signal output”? Which output pin are you looking at?
2) What exactly do you mean by “until the unsythesized Meteo data is output … and won’t get past the 0 bit mark”. In particular the second part of the sentence is unclear to me.
3) Would it be possible for you to send me some logs of both the input and the synthesized output to see how it fails?
1.I am looking at the output from your Super filter. I have tried the
const uint8_t dcf77_filtered_pin and the const uint8_t dcf77_synthesized_pin
My clock shows the Period (should be 1 second or 2 second) at the end of minute and also the Pulse width (should be 100ms and 200ms).
When the Superfilter has not synchronized (and the un synthesized signal is output) the signal output is inverted ie 100ms is 900ms and 200ms is 800ms. When it has synchronized the signal in non inverted and I get 100ms and 200ms pulses.
If I select the inverted synthesized pins I get the opposite of the above ie when the super filter is not in sync I get normal pulses and when in sync the pulses are inverted.
I notice from comments where the superfilter works people are using non inverted DCF77 receivers. Could this be a problem with the Superfilter on inverted DCF77 receivers where the inversion is not applied to both synthesized and non synthesized outputs?
2. Once in sync and I am getting correct pulses from the super filter all is fine until we get to bit 0 the “Meteo Data” that is not synthesized and should follow the input signal. Then the Time period goes up sometimes to 2 or 3 seconds as if it’s not getting any pulses at all this is followed by some good and some bad pulses.
In all cases when I switch to the non filtered output direct from my DCF77 receiver I get correct pulses.
3.I will try and get a log of the inputs and outputs.
I need the logs. The superfilter outputs everything that I need through the serial interface. Just capture it and sent it to me.
Udo have emailed log.
Let me know if you don’t receive it as I had trouble finding your email address.
Not sure if it is correct.
Oliver123, if you have an inverted receiver, why didn’t you change this:
const uint8_t dcf77_inverted_samples = 0;
Hi JJ van den Berg.
I presumed 0 = inverted
The superfilter synchronized with this set to 0 and when I have used the DCF77 library in other clocks with the same receiver it is always set to 0. I presumed this was correct?
My problem is when the superfilter changes from not synchronized to synchronized the output signal is inverted – 100ms becomes 900ms and 200ms becomes 800ms.
Do you think changing to const uint8_t dcf77_inverted_samples = 1; would solve this?
in this case this is the rule:
if your receiver outputs 5V with 100 or 200 ms “lows” it is inverted
if your receiver outputs 0V with 100 or 200ms “high” it is not inverted
set the bit accordingly. I just tested with an inverted receiver,your issue did not occur.
I have not measured it but the datasheet says it’s an inverted output http://www.pvelectronics.co.uk/rftime/SYM-RFT-XX.pdf
I will try and get a measurement.
it’s inverted wit respect to the AM modultated signal, for the filter logic, it’s NOT inverted.
https://en.wikipedia.org/wiki/DCF77
Have just measured it with an LED the short pulse is +ve so you are correct it is non inverted.
That means const uint8_t dcf77_inverted_samples = 0; is correct for my setup.
Still does not explain why the signal changes when the superfilter switches from synthesized to unsynthesized.
Maybe it’s the library/code I am using in my DCF anaylizer. It works 100% fine with an unfiltered signal via the receiver or superfilter. Once the superfilter synchronizes the pulses width changes from 100ms to 900ms etc.
I have tried changing
const uint8_t dcf77_inverted_samples = 0;
to
const uint8_t dcf77_inverted_samples = 1;
and the superfilter does not synchronize .
tell us: does your signal go high or low to indicate a pulse. Did you check and measure ?
OK I had better go back to basics. Just in case I am miss-understanding the superfilter
This is my understanding of the superfilter.
I use this code to setup
——————————————————-
const uint8_t dcf77_analog_samples = false;
const uint8_t dcf77_analog_sample_pin = 5;
const uint8_t dcf77_sample_pin = 19; // A5
const uint8_t dcf77_inverted_samples = 0;
#if defined(__AVR__)
#define ledpin(led) (led)
#else
#define ledpin(led) (led<14? led: led+(54-14))
#endif
const uint8_t dcf77_monitor_pin = ledpin(18); // A4
const bool provide_filtered_output = false;
const uint8_t dcf77_filtered_pin = ledpin(5);// was 12
const uint8_t dcf77_inverted_filtered_pin = ledpin(4);// was 11
const uint8_t dcf77_filter_diff_pin = ledpin(2);// was 7
const bool provide_semi_synthesized_output = false;
const uint8_t dcf77_semi_synthesized_pin = ledpin(16);
const uint8_t dcf77_inverted_semi_synthesized_pin = ledpin(15);
const uint8_t dcf77_semi_synthesized_diff_pin = ledpin(14);
const bool provide_synthesized_output = true;
const uint8_t dcf77_synthesized_pin = ledpin(4);// was 6
const uint8_t dcf77_inverted_synthesized_pin = ledpin(5);// was 5
const uint8_t dcf77_synthesized_diff_pin = ledpin(2);// was 4
const uint8_t dcf77_second_pulse_pin = ledpin(10);
const uint8_t dcf77_signal_good_indicator_pin = ledpin(3); //was 13
——————————————————————————–
My signal from my receiver goes in on pin 19 (A5)
I have disable filtered and semi_synthesized output
synthesized output comes out of pin 4 into my clock using another non Udo DCF77 library
while it is synchronizing the output from pin 4 is unfiltered
once synchronized the output from pin 4 is filtered and synthesized. Any noise is ignored as the superfilter synthesizes the output.
This is except when the meteo data is received. As this is licensed and encrypted so the superfilter just passes it through as is.
Does this seem correct?
I have checked the output from the superfilter with an LED and it looks fine.
It must be the way I am reading the output from my analyzer.
I will investigate further………………………………………………..
OK, I will wait till I hear about the outcome of your investigation.
OK, I will wait till I hear about the outcome of your investigation.
Hi Udo.
Have completed my DCF77 Analyzer Clock, it’s based on a design by Erik de Ruiter. https://github.com/deruiter/DCF77-Analyzer-Clock
The clock uses an Arduino to decode and display the DCF77 time code and display time & date etc. It has a 2nd Arduino loaded with your Super Filter and a hard wired switch so I can turn the Super Filter on and off.
I have given up trying to switch inputs with software via a remote control and have used the spare output to remotely reset the Superfilter instead. Separate remote reset of the main Arduino is also possible via remote.
Full details of the clock can be seen here http://home.btconnect.com/brettoliver1/DCF77_Analyzer_Clock/DCF77_Analyzer_Clock.htm
Thanks again for another superb piece of software!
Hi Brett,
another very nice clock from you. I am glad that you are satisfied with my software 🙂
Cheers, Udo
Hello Udo,
I have build the DCF77 Analyzer from mr de Ruiter. All works fine. But as you already mentioned in your logs, I use the Arduine Uno r3, have a nice signal without interferences, but no LOCK !!!
Which “arduino” compatible board do you suggest to use ? (it must have I crystal instead of a resonator. Or is there a mod to replace the resonator on my arduino board ?
Greetings André
I suggest of course my own board 🙂 There is of course the possibilitys to replace the resonator. You may want to look in a current github discussion for my libray: https://github.com/udoklein/dcf77/issues/18. Search for the comment by Brett Oliver. While you are there you may also want to “star” my library such that you get notifications for each update / bugfix / new release.
I have replaced resonators for crystals on several boards, and it works. You need some serious soldering skills though, otherwise it’s a no go.
If you recognize one crystal on your board – its from the usb interface. Only if you recognize 2 crystals for sure, you can assume the 328 is running on a crystal as well. When in doubt, show us a picture.
Please note the filter takes at least 5 to 10 minutes or so to stabilize, so be a little patient.
hello jj
how can i sent in a picture ?
I have a button for including images. But then again I am a registered wordpress user. Maybe you need to register in order to include images.
Soldering skills – yes. But serious soldering skills? This is about replacing a single through the hole part by another part + 2 crystalls. I would rate this beginner level. If you do not feel confident you can just as well replace the resonator with a prepackaged 5V 16 MHz crystal oscillator. This would most probably even work without desoldering the resonator in the first place. Just be sure to connect the oscillators output to pin XTAL1.
Hello jj,
looks like my reply’s are not stored in this blog.
Want to sent a picture. how do i do that ?
They are stored. As a measure to prevent spam everything here requires my approval. Since you never posted before you had to wait till I approved your request.
Hello Udo,
I have ordered your board, it will arrive today.
I have modified my arduino uno with a cristal and 2 caps. After 5 min a hard LOCK !!!! So that works. But I have a question,
When I made my DCF77 receiver on breadboard, I had a lock with my original Arduino. After I made my DCF77 analyzer (erik de ruiter) there was no lock anymore. How can it be happend that I had a lock with the original arduino ? Luck ?
Greetings
André
If you are talking about an original uno (has a resonator instead of a crystal) then this was pure chance. I would say bad luck.
Hello Udo,
My dcf77 signal decoding display is finished.(erik de ruiter) all works fine. your super filter sketch does the job !!!
I noticed something :
the databits coming in the weather section 1-14, when high a pulse width 199-201, but when low, 118-125.
the rest of the following bits 15-58, when high a pulse width again 199-201, low are 99-101 .
Is there an explanation why the first 14 bits, when low, have a longer pulse width ?
greetings,
André
Yes. The other bits are usually synthesized. However there is no means for me to synthesize the weather section. Hence I just copy them 1:1 from input to output.
Hi Udo is there a way of getting the Superfilter to pass all 1s for the Meteo Data instead of just passing the data through? I seem to remember reading about it but can’t find the info anymore.
The library synthesizes the signal here:
https://github.com/udoklein/dcf77/blob/54e9812abc804f5e72e25fd1ff972db73b582109/dcf77.cpp#L1011
I suggest to NOT modify the library but to path the superfilter instead. Here: https://github.com/udoklein/dcf77/blob/54e9812abc804f5e72e25fd1ff972db73b582109/examples/Superfilter/Superfilter.ino#L233
That is add some if statement to check for the meteotime seconds and then just output a 1 instead of the synthesized signal.
Reason: if you patch the library any upgrade will break your code.
Hi Udo.
Thanks for the rapid reply.
I have modified the superfilter as suggested and all works perfectly.
After the line “tick = now.get_current_signal();”
I have added-
//Brett always output 1 for Meteo Data
//Serial.print(“Get current signal “);
// Serial.println(now.get_current_signal());
if (now.second >= 1 && now.second <= 14)
{
tick = 3;// show 1 while seconds are 1 to 14
// Serial.print("now.second ");
// Serial.println(now.second);
}