Lately I have seen several discussions on pin debouncing in the Arduino forum. This made me lookup some of the existing solutions. Although some of them are very sophisticated I found that none of them will be suitable for my DCF77 clock project. The point is that I am going to put The Clock code into a library and then proceed to create a DCF77 alarm clock. Of course this will need pin debouncing. However because I have somewhat unusual timing requirements I want complete control on all interrupts and I do not want to rely on the Arduino’s millis() function. Thus I decided to implement my own debouncer.
In order to make it more accessible I decided to demo it with a simple one dimensional cursor effect.
Click here to read about all the details.
Lately some of my readers complained about troubles with downloading the code to my experiments. In order to fix this I introduced a dedicated download page. There I describe how to easily download any piece of code.
What I actually did is to copy all the code to Github. Thus you can not only download but also contribute if you want to.
Speaking of GIT: some of you might have noticed that some of my projects are relatively large compared to most Arduino projects. One of the secret ingredients is of course version control. If you do not yet use a version control system you might want to learn about one as soon as possible. Version control is for code what accounting is for money. Unless you have version control you will sooner or later lose track of your code changes. If you have version control and something breaks it is usually a lot easier to find out when the issue was introduced. It also is very reassuring to know that there is always “a way back” to latest stable version. Developing without version control is like burning all bridges behind you.
Having said that the question is which version control system to use. If you are developing in a team or a corporate environment this question is usually already solved. If you are alone the choice becomes harder. I settled for GIT for the following reasons:
- It is open source
- It is very easy to setup (git init)
- It is used for the Linux Kernel, thus:
- It will be sufficient for even my largest projects
- It will not go out of business soon
I will not tell you how to use GIT (or any other version control system) because there are lots of excellent (and free) tutorials already out there. If you want to start with GIT here are some resources that I found helpful.
In the past I got some complaints that my Blinkenlight Shield is not 100% Arduino compatible. Of course it is 100% compatible to the “real” Arduino. The issue is that the Arduino family never defined what they assume to be fully compatible. To learn about the nitty gritty details read the full story here. Of course you can avoid all these issues by using a Blinkenlighty in the first place.
Please keep in mind that both the Blinkenlighty and the Blinkenlight Shields are used to fund my site. Actually you can fund my site even without buying any of these products. You just need to follow this link to Amazon and buy whatever you want. Through the affiliate program I will then receive some money for further funding of my experiments.
My efforts with the DCF77 project are finished from a design point of view. However I am now converting it to a resuable library. I also work on the issue of making it available for the newer Arduino Uno models (which have a lousy oscillator). Next month I expect to have the first version ready. So stay tuned
This month I will not focus on improvements of the software side of my DCF77 project. Instead I focused on the hardware. That is I compared different receiver module and antena options. The catchy conclusion is “Bigger is Better”.
In December I started my DCF77 project by enhancing an existing DCF77 library with exponential filtering.
In 2013 I then started “the real thing”. That is a DCF77 clock that applies advanced decoding techniques. This month I am very proud to present the final result. This DCF77 clock can “decode” the signal even under extraordinary amounts of noise. The trick is that it does not really decode the signal but “lock” to it. Once a lock is acquired it can keep the lock even in the presence of increasing noise levels. In case it does lose the lock it can keep time with a local clock. But this is not enough, it can even exploit the local clock information for faster lock reacquisition.
After a lot of search on the internet I am pretty much sure that with regard to noise resilence this is the most advanced open source DCF77 decoder ever
By now my DCF77 project can completely decode the official time signal under really bad conditions. Since bad means “really really bad” I also have to anticipate that there will be prolonged periods without any reasonable signal at all. Thus I should better have a local clock that can keep time while the signal is lost.
However since I have a very sophisticated algorithm there is something in between that I will exploit as well. Remember the phase detection experiment? Of coure it may be possible that the phase can still be detected while although the signal is to noisy to extract any reasonable data. So here is my plan.
1) Extract time data from the signal.
2) As long as the noise is low enough to still decode something sync the local clock to the signal.
3) If the nosie is to high but the phase can still be kept, use the 1s ticks from the official signal to proceed the local clock.
4) If sync is not possible anymore stick to the local clock.
Thing gets somewhat tricky when the phase can be recovered but not yet the complete signal. In order to sort things out I introduced a simple finite state machine.
Have a look at my local clock experiment. It contains all the details plus the source code. By now this should beat any other implementation with regard to noise resilence. But I am not yet done. Wait for the next article on how to push this just one step further. Always along the notion of “anything worth doing is worth overdoing”
After my vacation I finally found the time to extend my DCF77 project to the next stage. The previous version was only able to decode the time and did not properly deal with leap seconds. The new version fixes all these issues. It will decode “everything” and take care of “everything”. That is it properly handles daylight saving and leap seconds. It also determines the date and the weekday.
At first glance it seems that I just added more “decoder boxes” but have a look at the top of the architecture diagram. Now I also require an encoder box. That is my clock can locally synthesize a valid DCF77 code. This was necessary to deal with the messy details of leap seconds. So have a look at my newest version and find out how to do this.
By the way: as far as I know this is the only open DCF77 clock with this level of error correction. If anyone knows another project that goes so far (or further) I would be pleased to learn about it. Please drop me an email or leave a comment on this page.
This month I was on vacation. Therefore the post to this month’s hack is slightly delayed. Nevertheless the people who follow my blog where able to see the content page at the first of the month. So in case you never want to miss my new pages you might want to follow my blog. Just use the “sign me up” button in the sidebar to the right.
As I said I was on vacation. I was travelling to the US and this brought up again the never ending travel adapter issue. My final fix is somewhat unusal. It is hackish in nature but trivial to execute. My first solution was already very satisfactory:
DIY Travel Adapter
But it pales to the final IEC compliant solution. You might find it trivial but I am very proud of it for exactly that reason. Once you know this solution it is as obvious as can be. But if you do not know it you might not even suspect that it exist
After last month’s Lighthouses experiment I am back on track with my DCF77 clock. The Second Decoder is now extended with additinal decoders for decoding time data.
From the architecture point of view this adds just two more boxes.
But don’t be fooled. These two boxes have a quite different construction from the second decoder. The other decoder boxes that are still missing will rely on the same inner workings. All of them will utilize a hamming metric based approach.
The software part of the project is getting closer to its final stage:
- Exponential filtering of the signal
- Phase locked loop / optimal filter for 1Hz phase reconstruction
- Reconstruction of the seconds
Hamming metric based reconstruction of the data
- Dealing with signal loss
Finally my clock can decode the current time . So next month I can take care of the date
With regard to the antenna hardware I finished reading the books:
Das neue Magnetantennenbuch: Selbstbau-Loops für Sende- und Empfangsbetrieb
Außergewöhnliche Empfangsantennen und ihre Anpassung für den Längst- und Kurzwellenbereich
Since this created a desire for more I started to read this one as well:
My summary so far:
- The best amplifier is a better antenna.
- Bigger is better.
- There is more to learn about antennas than you might expect.
My DCF77 project is making good progress. However it will require at least 3 more articles. So I thought I should give it a short break. After all this project drifts a little bit to the signal processing side.
So this month I will focus a little bit more on the Blinkenlight aspects again. The motivation is taken from a question in the German Arduino forum. The question was how to simulate a bunch of light houses / light fires for a nautic map.
One approach would be to encode this in the style of my persistence of vision experiments and reduce the sample rate. However this confuses the actual blink rates and makes the code somewhat hard to adapt to new blink rates.
Thus I implemented a short light houses sketch.
In my opinion the resulting code is pretty nifty. I especially like the fact there there are no explicit loop constructs for the blinking.