Path: Home => AVR-EN => Applications => DCF77 signal analysis
DCF signal analysis display AVR applications

Signal analysis with ATtiny24
Hardware, Operation, Use and Software for the signal analysis

Analyzing DCF77 signals with ATtiny24

  1. Properties
  2. Hardware
  3. Operation
  4. Software

1 Properties of DCF77 signal measuring device

This page complete in one PDF (16 pages, 310 kB) here.

1.1 Purpose

Analyzes DCF77 receiver modules for their signal duration.

1.2 Functioning

The hardware properties are:

1.3 Operates with different voltages

  1. If your LCD requires 5V and your DCF77 receiver module allows operation with +5V, you can use it un-modified.
  2. If your LCD requires 3.3V and your receiver module works at 3.3V, you can also use it unmodified.
  3. If your LCD requires 5V and your module only allows operation with up to 3.3V, use the described modified hardware.

1.4 Simple hardware

The hardware is based on a ATtiny24-LCD module, as described here. The receiver module and a key (to reset the counter) can be plugged into the Bread6 interface of the module with a 6-pin parallel cable and plug. Only the software described here is needed.

Page top Properties Hardware Operation Software

2 Hardware

2.1 5V version

Schematic for the 5V version This is the whole schematic for the 5V version. If both, the LCD and the receiver module, work at 3.3V, you can also use this.

Testing of the hardware is simple: just check your connections.

A 5V receiver module connected This shows such a 5V receiver module, as attached to the ATtiny-LCD-module.

2.2 The 5V/3.3V version

Schematic for 3.3V modules The alternative, if your LCD has 5V and your receiver module allows only 3.3V, is this.

The operating voltage is reduced by a resistor of 180Ω and a Zener diode of 3.3V. Zener noise is suppressed by the 100µF electrolytic capacitor as DCF77 receiver modules are very sensitive for noise on the operating voltage.

The output pin of the module delivers either a rectangle signal or has an open collector. In the first case the 3.3V voltage swing has to be translated to 5V by use of an NPN transistor (BC547 or equivalent). As receiver modules do not generate lots of current, a high resistor of 100k produces enough base current to drive the 47k collector resistor and produces a stable input voltage for the ATtiny24.

In the second case, if your module has an open collector output only, you'll have to provide enough current on the 3.3V level to drive the base of the transistor high if the open collector is inactive. That is done with the 1M resistor. In that case you'll have to close the jumper. All receiver modules that I have tested operate correct with the 1M, make sure you have that closed in case your module is of the open collector type.

Testing of the hardware is also simple, but not as simple as in the previous version. Of course, your connections shall be ok, too. If the LCD does not count any signals, try closing the jumper. That should resolve most potential errors.

If not, remove the receiver module and the jumper and connect the signal input with GND. The output, the collector of the transistor, shall now show a voltage near to 5V. Then tie the signal input to the +3.3V (on the cathode of the Zener diode, e.g.). Now the output shall be close to zero Volt.

5V/3.3V interface This is such an interface. On the three- and four-pin female plug-ins different receiver modules can be tested. The connection to the ATtiny24-lcd-module are wired, all components are mounted on a small PCB.

Page top Properties Hardware Operation Software

3 Operation

3.1 Selecting the tolerance value

The main parameter to select is how accurate the receiver's signal shall be. This is defined by the constant cDcfTol. This is the tolerance in percent that the signals can have to be correct.

Avoid too narrow tolerances below 6 percent and too large tolerances beyond 33 percent. This unavoidably results in errors because, e.g., the recognition of a pause has an average duration of 850 ms, but can be as well be 800 (or slightly shorter) or 900 (or slightly longer). If you receive many P errors, that might be a hint for a too small tolerance.

Also, avoid too large tolerances. If you are above 33%, the accepted areas would overlap. When assembling, those overlaps are recognized, you'll get an error message and no hex code is generated.

20% is a good margin, and a good receiver shall operate with that with no errors.

3.2 Display of counts

LCD display of counter values The software works as follows:
  1. Each signal change on the DCF input restarts the TC1 counter, which is clocked by 1 MHz and prescaled by 1,024 (frequency = 976.6 Hz, time per tick = 1.024 ms).
  2. The length of each pulse duration is compared with constants that are derived from the settings of the times in the Adjustable constants section of the software. There, a logical zero transmitted by DCF77, is set to last 100 ms, a logical one to 200 ms. The pause that follows a logical zero or a logical one, until the beginning of the next second, is set to 850 ms, but can be either 800 or 900 ms depending from the bit that was sent. Another signal duration is the length of a missing second pulse (the 60th second is omitted by DCF77). That results in a pause between 1,800 and 1,900 ms.
  3. The analysis of the pulse duration can have the following results:
    1. Shorter than the Spurious signal duration: very short signal (shorter than 10 ms), this count is the first number in line 2 of the LCD below Sp,
    2. Longer than the spurious signal duration, but Shorter than the time necessary at least (100 ms minus tolerance) for a zero, this count is below the <0 in line 2 of the LCD,
    3. A correct zero signal, below 0 in line 2,
    4. The same for ones: either too short for a one <1 or a correct 1.
    5. Further results are listed in lines 3 and 4 of the LCD: the pause duration (<P and P), the minute change duration (<M and M) and if the signal duration exceeds the maximum (>M).
  4. If counts reach 10,000 or higher, 9999 is displayed, but the counter is 16 bit wide and can count 65,535 pulses.
  5. Use the key to copy all counters to EEPROM, clear all counters and to restart counting.
In the example no spurious signals and shorter than zero or ones had happened, but one pause was too short and two minute change signals were too short.

As a pause is always associated with each received one and zero (and follows those), the number of pauses should be equivalent to the sum of both. This is approximately the case in the example.

3.3 Downloading and calculating signal averages

The software not only counts the number of signal duration categories and displays this live on the LCD but also adds the real measured signal duration to a 32-bit adder for each category in the SRAM buffer. As this information does not fit onto the small LCD, it is only held in SRAM.

Every time that the key is pressed, the content of this SRAM buffer, consisting of
  1. two ASCII characters for the category (the same as displayed on the LCD headers in line 1 and 3),
  2. two bytes for the counter (up to 65,535 events),
  3. four bytes for the adder (up to a sum of 4.29 millions),
are written to the EEPROM and can be downloaded from there. The generated EEPROM content e.g. looks like this:

The downloaded hex file with EEPROM data That is rather cryptic, and we need a tool to convert this into a more meaningful format. For this I wrote the Pascal program "dcfsigana_eep2csv". Its source code is here and compiles with any Pascal compiler (tested with Free Pascal Compiler, FPC). If you are afraid of installing or not allowed to install FPC (admins sometimes are hypercritical) or if FPC is not available for your operating system (which rarely can be true), you can download the already compiled Windows-64-bit executable from here.

This software eats an Intel hex format file, by default named "eep.hex" (select h from the menu, or then input any other name), tests it by counting the lines and checking whether it only consists of colons as first characters on the lines and of hexadecimal numbers (select a from the menu) and if successfully tested, converts it to a CSV encoded file. Each line of the file is the content of one out of ten of the above SRAM buffer structure. The ASCII characters are enclosed into ", the numbers are separated by tab characters (ASCII-9). The CSV file can be imported with OpenOffice (do not try Excel, it cannot handle CSV files conveniently). Make sure that you tick the tabulator as a separator (if not already marked).

Select the decoded raw data, copy it to the clipboard and paste it to the "rawdata" sheet of the OpenOffice spreadsheet here. The results are used on the sheet "measuring" to calculate average pulse durations in milliseconds and to compare those with the ideal duration.

With this tool you'll see how long your receiver module's signals really are, why zeroes, ones, pauses and minutes fit or fit not into the decoder's math. You'll also see how long spurious signals on the input line really last.

With that you should be able to do identify any kind of problem that your module shows.

Page top Properties Hardware Operation Software

4 Software


The assembler source code is available for download here and needs the LCD include to assemble correct.

The source can be viewed in the browser here.

Please note that the previously published, which was first used by me in creating this software, had a serious bug: it cleared the lower part of the output port A, by that initiating key PCINTs constantly. After identifying and correcting the bug, the key interrupts work fine. So make sure you use the latest, as linked above, and not an older version.

Page top Properties Hardware Operation Software

4.2 How the software works

4.2.1 Time measurements

Time measurement in performed with TC1. This timer is clocked by the 1 MHz system clock with a prescaler of 1,024. Timer ticks are therefore roughly 1 ms long (more exact: 1.024 ms).

Each interrupt on the DCF77 pin reads the current timer count and clears it thereafter.

TC0 is not used and free for other uses.

4.2.2 DCF duration classification

The times for each DCF77 signal category is given in the software as a constant (names starting with t) in milliseconds. Those are converted into timer values using the controller's clock, its prescaler value and the tolerance for which those times shall be included into the categories.

The times and counter values can be best viewed in the OpenOffice spreadsheet here, but can also be read as symbols (with a c instead of the t) from gavrasm's symbol list, if assembling is done with the -s option active.

Those constants are all included in a table that is used by the software to identify the signal category.

4.2.3 Reading results from EEPROM

Following any key event,
  1. all category strings, counters and adders are copied from SRAM to EEPROM,
  2. the routine waits 100 ms until the key has been released (with debouncing),
  3. clears all counters and adders and restarts.
The EEPROM can be read and its content can be viewed by assistance of the above described software and can be imported to a spreadsheet, for which the OpenOffice spreadsheet here can be used.

Praise, error reports, scolding and spam please via the comment page to me.

©2019 by