Improving Quality

As you might have noticed I now have merged Gavin’s MSF code into my development branch at Github. So far I did not put it into the master branch as part of a release. The point is that I still did not test it. The same holds true for the contributions of Aido.

Before I merge this stuff into master I want to be sure it works. Hence I ask everyone who wants to contribute please give me some feedback to one or both of the following questions:

  1. Does the MSF Code work for you?
  2. Does the (DCF77) Code work with an Arduino Leonardo?

I also improved the documentation quite a lot.

But the most work went into setting up unit tests for my library. As it turns out I introduced some subtle issues into my code while refactoring. Now I uncover and fix them one by one. Continue reading here to learn about the details.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to Improving Quality

  1. paxyinrs says:

    Keep a great job !
    Project works great with Crystal Mini Pro and do not work because of drift at Ceramic Nano.
    I have just combined Swiss Army Debug Helper with MB Emulator so I can with option “Dn” switch to NTP mode (MB Emulator). That way, with Scope and Debug I first find best position, with lowest noise level then I switch to MB emulation. In future, I will probably add some hardware switch for moving form one mode to another.

  2. Emmanouil A. Neonakis says:

    Great Work.
    I am thinking of using the once per second output as a time base for measuring network frequency.
    Is it in your opinion accurate and stable enough for such a use? In particular how much is the period variation?
    Thank you.

    • In principle yes. The details are somewhat involved though. Once the signal is locked to DCF77 it will stay “exactly” in sync with DCF77. However there is a quantization error of +/- 1ms. Also you have a crystal frequency deviation. Lets say for the sake of example your crystal is running at 16 MHz -50 ppm. Then your second ticks will be ~ 1.00005 s appart. Also every 20 seconds you will get a second tick that is only 0.99895 seconds long (equivalent to a phase glitch of pi/20 with regard to mains frequency). Once the clock is running for a several days it will autotune to this deviation and persist this to flash memory. Afterwards all manufacturing related deviations will be gone. Thus the crystal deviation will be soleley due to againg and temperature deviations. If your are monitoring mains frequency the device will be probably running all the time. Thus due to automatic retuning you will be left with the deviations due to temperature. Or with other words maybe +/-2 ppm. Thus you will get the 1ms jump every 100 seconds. It will nevery be more than 2 ms out of phase. That is the deviations do NOT sum they will always even out to keep in phase with DCF77.

      Since it phase locks to DCF77 (like swissgrid does) this should be sufficient if you know what you are doing.

      With other words: if your algorithms account for this behaviour then it is OK, otherwise not. If you use it for a project I would be happy to learn about the details 🙂 In particular I like to learn about the results.

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s