Super Filter Reloaded

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 🙂

This entry was posted in Uncategorized. Bookmark the permalink.

66 Responses to Super Filter Reloaded

  1. JJ van den Berg says:

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

      • JJ van den Berg says:

        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.

  2. JJ van den Berg says:


    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 

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

  4. JJ van den Berg says:

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

      • JJ van den Berg says:

        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:

        • 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:

  5. JJ van den Berg says:

    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.

  6. JJ van den Berg says:


    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)

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

    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.

  8. JJ van den Berg says:

    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 :
    the output from the filter :

    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.

  9. JJ van den Berg says:

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

      • JJ van den Berg says:

        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!

      • JJ van den Berg says:

        the log file is at
        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 🙂

      • JJ van den Berg says:

        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.

      • JJ van den Berg says:

        Hi, I applied the latest fix for the summertime bit, so far so good, no errors until now 🙂

  10. oliverb123 says:

    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)
    #define ledpin(led) (led<14? led: led+(54-14))

    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?


    • 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?

  11. oliverb123 says:

    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.

  12. JJ van den Berg says:

    Oliver123, if you have an inverted receiver, why didn’t you change this:

    const uint8_t dcf77_inverted_samples = 0;

  13. oliverb123 says:

    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?

    • jj vd berg says:

      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.

      • oliverb123 says:

        I have not measured it but the datasheet says it’s an inverted output

        I will try and get a measurement.

        • jj vd berg says:

          it’s inverted wit respect to the AM modultated signal, for the filter logic, it’s NOT inverted.

          • oliverb123 says:

            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.

    • oliverb123 says:

      I have tried changing
      const uint8_t dcf77_inverted_samples = 0;
      const uint8_t dcf77_inverted_samples = 1;
      and the superfilter does not synchronize .

  14. oliverb123 says:

    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)
    #define ledpin(led) (led<14? led: led+(54-14))

    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?

  15. oliverb123 says:

    Hi Udo.
    Have completed my DCF77 Analyzer Clock, it’s based on a design by Erik de Ruiter.

    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

    Thanks again for another superb piece of software!

  16. andré says:

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

    • jj vd berg says:

      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.

      • andre says:

        hello jj

        how can i sent in a picture ?

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

  17. andré says:

    Hello jj,

    looks like my reply’s are not stored in this blog.

    Want to sent a picture. how do i do that ?

  18. andre says:

    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 ?



  19. andre says:

    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 ?



  20. oliverb123 says:

    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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.