This month I expected that my blog will see very low page hits. Actually every summer in the last two years page hits were low. And this summer there were also world soccer championships. Something that I expected to drive down numbers even lower.
Do not worry – Germany won the Championships – so I am not going to complain :)
However for some reasons that I do not understand the contrary happened. I got significantly increased hit rates – which of course I like a lot. Seems more people are getting interested in my stuff.
Most notably I got very increased hit rates from Italy. Also the Power Grid Monitor was drawing a lot of attention. More than the all time favourite experiment LED Camera. If anyone could explain the sudden rise of attention from Italy and the increased interest in the Power Grid Monitor I would be very pleased to learn about this.
Also I got a lot of feedback for my DCF project. Ian Castleton from Great Britain found some issue with my 1 kHz generator for the DCF77 library. I was setting up timer 2 with some undefined mode which worked anyway by pure chance. Now I am using only officialy documented timer modes. Of course the github repository is already up to date. What I learned from Ian is that DCF77 is pretty popular in GB but they have to deal with really poor signal quality due to the large distance to DCF77. Just like Brett Oliver he also found that my library deals with this issue very well. He even sent me some logs of the signals he received. He gets a really crappy signal but still not even close to the limits for my library. Ian also solved my long standing question at Stackoverflow. He hinted me to the document Performance Analysis and
Receiver Architectures of DCF77 Radio-Controlled Clocks by Peter Engeler. Without knowing that I was searching for such an article for a long time he provided me with exactly what I wanted. A big thank you to Ian for this.
The highlight for this month was that a colleague got hold of a 3D printer. Of course I immediately designed some enclosures for my Blinkenlighty. I am very pleased with the results.
As promised last month my library now got some more update that exceeds the functionality of The Clock significantly.
It now supports “autotune”. That is the crystal frequency compensation will not require manual optimization anymore. The improved library will auto tune the adjustment. Even better it will retune automatically as long as the library keeps in sync with DCF77.
I went even one step further. It even supports persistency for the tuned adjustments. Once the frequnecy is tuned the adjustment will persisted to EEPROM and reloaded from there at the next power cycle.
If you wonder if I applied wear leveling – the answer is no. I computed that on average the library will persist less than once per day. So it would wear out EEPORM after 100 000 days or more than 300 years of continous operation. In my opinion this is something not worry about :)
Last month I implmeneted the first extension to my library to help Brett Oliver with his new clock.
I struggled quite a bit with the decision if crystal frequency compensation will go into my library or not. After all the goal of this library is maximum noise resilence. Finally I came to the conclusion that a signal outage is some kind of noise. Thus handling it as good as possible is congruent to my goals for this library. Consequently I implemented this.
The next step is to add some autotune feature for the frequency adjustment. Although this is not to hard to implement it takes long to test it. This is not because it is hard – it is because the involved time constants are in the range of days. Thus I just can not test the autotune feature overnight.
Stay tuned for the next release of the library as it will support autotune to 1 Hz or 1/16 ppm.
Last month Brett Oliver contacted me. He already constructed some really cool DCF77 synced clocks. Since Brett is located in Great Britain he faces some challenges though.
The biggest challenge is that his current setup gets slightly out of sync every once in a while. This is of course due to noise / issues with the DCF77 sync. Since my dcf77 library is specifically designed to address this issue he is planning to deploy my library. Current test results are very promising. According to him his PC monitor creates loads of noise but my library still keeps perfect sync. As it seems it meets its design goals :)
The second challenge is that he is in a different timezone. When I developed the library it did not occur to me that anyone would want to use it outside the CET zone. But since its decoding capabilities are so good I think this is very reasonable. However at this time I do not want to put timezone handling into the library. So I added a timezone conversion example to the simple clock.
Finally he is also concerned about maintenance outages of DCF77. Although I am not very concerned about them I think he has valid point. The issue is that Arduino (even with a crystal) makes a lousy timekeeper. The typical drift of an Arduino (with crystal) is in the order of magnitude of 30 ppm or more than 1 second per day.
There are several ways to fix this. The most obvious one is to add an RTC. Something that I already planned before. However after digging into ntpd I ponder about a software solution. The idea will be to use the DCF77 signal to infer the drift of the crystal and then compensate for it. This should bring the drift down to 1-2 ppm or less than 0.2 seconds per day. This in turn would get rid of a dedicated RTC and make the whole circuit much simpler.
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.