A DCF77 Module For You?

In the comments to my DCF77 library Karol Babioch asks for a DCF77 module that comes with my code included. Unfortunately I see absolutely no way to put something like this together and sell it at any reasonable price.

But if you definitely need one you may build it on your own. The Super Filter experiment devliers exactly the necessary code to implement this.

With regard to the library I am planning to push its noise resilence at least two notches further. One notch for even better SNR and another one to deal with signal fading. Ian Castleton provided me with some logs that show how poor the signal is in London. The insights are very interesting. It took about 30 minutes to sync for the first time at 23:30:43 CEST. Then it takes till 23:45:55 to alter between synced and locked. So in total it takes almost 45 minutes to settle to synced. Obviously there is a lot of noise in the signal. Then it stays synced till 14-08-12 2 06:50:00 when it unlocks. It then toggles between lockend and unlocked and arives at 06:50:10 in the state “free”. At 07:19:37 it resyncs. See the details of the log at the end of the article. The point here is that although the signal is very noisy the library easily decodes it. Howevr there is a period of almost an hour where it picks up no reasonable signal at all. Obviously no issue for the clock as it can continue to run on the local crystal. However it is an issue for the frequency auto tune since it requires very lengthy periods where the clock is synced.

This gives me something to ponder about. I am already scratching my head on how to fix this issue. Actually it should be not hard to implement. The real issue is testing this stuff as by now some of the involved time constants are longer than a day.

The log also shows some interesting thing that I did not really think about. As soon as the clock unlocks the convolution bins are of marginal quality at best. It follows that a transition to free is almost unavoidable. Originally I hoped that it might be able to stay in unlocked mode for quite a while. So the original goal at fast recovery of at least the locked state is almost never reached. On the other hand the code is fully tested and performs quite well. One more thing I have to think about. Maybe I should change the conditions for the unlocked -> free and the unlocked -> locked transitions.

Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (2-0:0)(6-0:2)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)0,0,0,255
Clock state: useless
Tick: 347

Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (5802-4:255)(69-13:9)(105-83:3)(96-76:3)(34-26:1)(68-62:0)(56-49:1)(50-43:1)26,5,13,255
Clock state: useless
Tick: 28462

Decoded time: 14-08-11 1 23:30:43 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (5804-12:255)(69-13:9)(105-83:3)(96-76:3)(34-26:1)(73-66:1)(56-49:1)(50-43:1)26,5,13,255
Clock state: synced
Tick: 13

Decoded time: 14-08-11 1 23:31:42 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (5889-12:255)(61-18:8)(112-88:3)(103-81:3)(37-28:1)(73-66:1)(60-52:1)(53-46:1)28,4,14,255
Clock state: synced
Tick: 13

Decoded time: 14-08-11 1 23:31:43 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (5893-30:255)(61-18:8)(112-88:3)(103-81:3)(37-28:1)(77-71:0)(60-52:1)(53-46:1)28,4,14,255
Clock state: locked
Tick: 13

Decoded time: 14-08-11 1 23:31:44 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (5873-12:255)(61-18:8)(112-88:3)(103-81:3)(37-28:1)(77-71:0)(60-52:1)(53-46:1)28,4,14,255
Clock state: locked
Tick: 13

Decoded time: 14-08-11 1 23:34:42 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (5914-6:255)(131-69:8)(133-105:3)(123-95:4)(46-34:2)(85-79:0)(74-63:1)(60-55:1)30,3,15,25
Clock state: locked
Tick: 13

Decoded time: 14-08-11 1 23:34:43 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (5918-22:255)(131-69:8)(133-105:3)(123-95:4)(46-34:2)(91-84:1)(74-63:1)(60-55:1)30,3,15,25
Clock state: synced
Tick: 13

Decoded time: 14-08-11 1 23:36:54 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (5839-0:255)(184-115:9)(147-115:4)(136-106:4)(54-41:2)(103-94:1)(89-75:2)(66-61:1)32,1,17,22
Clock state: synced
Tick: 13

Decoded time: 14-08-11 1 23:36:55 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (5841-14:255)(184-115:9)(147-115:4)(136-106:4)(54-41:2)(103-94:1)(89-75:2)(68-62:0)32,1,17,22
Clock state: locked
Tick: 13

Decoded time: 14-08-11 1 23:45:54 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (5748-0:255)(171-22:20)(207-161:6)(194-152:5)(77-57:3)(149-135:1)(120-101:3)(90-88:0)44,4,26,20
Clock state: locked
Tick: 13

Decoded time: 14-08-11 1 23:45:55 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (5770-6:255)(171-22:20)(207-161:6)(194-152:5)(77-57:3)(149-135:1)(120-101:3)(94-88:1)44,4,26,20
Clock state: synced
Tick: 14

Decoded time: 14-08-12 2 06:49:59 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (16-0:2)(180-25:21)(248-12:33)(249-19:32)(252-2:35)(252-13:33)(252-6:34)(252-11:33)64,50,50,8
Clock state: synced
Tick: 14

Decoded time: 14-08-12 2 06:50:00 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (14-0:1)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,8
Clock state: unlocked
Tick: 13

Decoded time: 14-08-12 2 06:50:04 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (23-0:2)(6-6:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: unlocked
Tick: 10

Decoded time: 14-08-12 2 06:50:05 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (51-0:6)(6-6:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: locked
Tick: 11

Decoded time: 14-08-12 2 06:50:06 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (23-0:2)(6-6:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: locked
Tick: 12

Decoded time: 14-08-12 2 06:50:07 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (4-0:1)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: unlocked
Tick: 10

Decoded time: 14-08-12 2 06:50:08 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (21-0:2)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: locked
Tick: 12

Decoded time: 14-08-12 2 06:50:09 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: unlocked
Tick: 10

Decoded time: 14-08-12 2 06:50:10 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 0 (0-0:0)(6-0:2)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)(0-0:0)64,50,50,10
Clock state: free
Tick: 10

Decoded time: 14-08-12 2 07:19:37 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 1 (4086-0:255)(157-0:22)(108-84:3)(79-67:1)(38-25:2)(77-66:1)(64-51:2)(50-43:1)90,64,64,39
Clock state: free
Tick: 11

Decoded time: 14-08-12 2 07:19:37 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 2 (4079-0:254)(157-0:22)(108-84:3)(86-72:2)(38-25:2)(77-66:1)(64-51:2)(50-43:1)90,64,64,39
Clock state: synced
Tick: 13

Decoded time: 14-08-12 2 09:07:31 CEST ..
Quality (p,s,m,h,wd,d,m,y,st,tz,ls,pm): 14 (4612-0:255)(183-0:25)(252-58:27)(254-40:30)(254-135:16)(253-154:13)(255-134:17)(252-156:13)16,8,8,43
Clock state: synced
Tick: 14
[\code]

Posted in Uncategorized | Leave a comment

Soccer Championship vs. my Blog

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.

Posted in Uncategorized | Leave a comment

Automatic Tuning

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.

Frequency_Control

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

Posted in Uncategorized | Leave a comment

Working with Brett Oliver

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.

Posted in Uncategorized | 5 Comments

DCF77 Library planned for some Really Cool Clock

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.

Posted in Uncategorized | Leave a comment

DCF77 vs. GPS

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.

Posted in Uncategorized | Leave a comment

The dcf77 Library

Finally I separated my DCF77 decoder into a library. The dcf77 library will give your projects the same extraordinary noise resilence as the clock.

The_Clock_Library_Architecture

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.

Posted in Uncategorized | 13 Comments

DCF77 Next Steps

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

Posted in Uncategorized | Leave a comment

Happy New Year 2014

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

Posted in Uncategorized | Leave a comment

Debouncing

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.

Debounce Test

Debounce Test

Click here to read about all the details.

Posted in Uncategorized | Leave a comment