This month I setup ntpd on my Linux Box. The idea was to connect a GPS and my DCF77 clock as a backup. My naive assumption was that the GPS would outperform my DCF77 clock easily. However as it turned out it is the other way round. Although the GPS must have a significantly better internal clock my clock outperforms it easily in any relevant aspect: less jitter, better precision and excellent performance during heavy rain / obstructed sky view.
Then there were quite some people that got very excited about my library. For example Brett Oliver – creator of very cool DCF77 clocks – wants to use this library for one of his next clocks. As I already noticed on my DCF77 library page this seemed to be a compiler issue. Some of my readers noticed this as well. Thanks to a comment by Werner Gaulke and the work of Andy Brown the issue is solved. It definitely is a compiler issue and Andy has detailed instructions on how to fix this for Windows. I assume that this works for other OSes as well. For Ubuntu I never had this issue because my compiler was not bundled with Arduino. Thus I always enjoyed a better compiler.
The proper solution to this mess would be of course to convince the Arduino team to replace the ~5 year old compiler by an up to date version.
Finally I separated my DCF77 decoder into a library. The dcf77 library will give your projects the same extraordinary noise resilence as the clock.
It also comes with several examples.
There is one issue with my library though. With Arduino 1.0 the library is fine. However with Arduino 1.0.1 and higher the compiler bloats the code. The size issue is anoying but not really critical. However it also slows down the code which in turn makes clock synchronization impossible.
If anyone knows that changed and how to fix it I would be very grateful.
Since I published my advanced DCF77 clock I recieved quite some questions on what will be next. There are two things that I am after right now.
I noticed that some people find it difficult to properly run my clock. On the other side I find it difficult to help them without reasonable troubleshooting and analysis tools. So the first thing is the analysis tool DCF77 scope for troubleshooting my clock setup.
The next thing will be a library. I am going to isolate the hard work of my clock experiments into a standalone library such that everyone can leverage to create better DCF77 clocks. So stay tuned for the next months :)
For this new year I wanted to create a video at least as cool as last year’s VU meter experiment. (Check out the video!)
However I did not manage to get this done. As it turned out some broken USB power supply prevented me from proper execution.
My fix resulted in the USB Voltage Monitor Experiment. Now I have some very simply means to check if USB voltage is good or bad. Check out the article after the link.
In case someone notices: yes, the charger doctor would have detected the issue as well. However I always notice the display flicker and blink. Thus I usually keep it disconnected. My solution will only blink if there is something fishy with the USB voltage.
So happy new year everyone and check your USB voltage if your peripherals start to behave strange :)
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” ;)