Input Devices

I designed a small board in KiCad to connect the DCF77 component to a XIAO RP2040 for experimentation. Since there was no footprint for the DCF77, I used a 4-pin socket and added a rectangle to it to make it obvious which side the board was sticking out.

I soldered stacking pins to the component itself to connect to the socket.

Using the dsiggi/micropython-dcf77 library, I attempted to get a reading with the following script.

from machine import Pin
from time import sleep_ms
from dcf77 import dcf77

# turn component on
Pin(3, Pin.OUT).value(0)

# start scanning
dcf = dcf77(Pin(4))
dcf.debug(True)
dcf.start()

current_dt = None
while True:
    dt = dcf.get_DateTime()
    if dt != current_dt:
        current_dt = dt
        print(dt)
    sleep_ms(100)

The output indicated issues with pulse widths, which were mostly too long (it should be around 100 or 200 millisecond).

$ curl https://codeberg.org/dsiggi/micropython-dcf77/raw/branch/main/dcf77.py > dcf77.py
$ mpremote cp dcf77.py :dcf77.py
cp dcf77.py :dcf77.py
$ mpremote run dcf77-test1.py
DCF77:  Start decoding
[0, 0, 0, 0, 0, 0, 0, 0]
DCF77:  Wrong pulse width 1588636 - Start new scanning for tick 59
DCF77:  Wrong pulse width 1005 - Start new scanning for tick 59
DCF77:  Wrong pulse width 758 - Start new scanning for tick 59
DCF77:  Detected '1'
DCF77:  Wrong pulse width 15 - Start new scanning for tick 59
DCF77:  Wrong pulse width 811 - Start new scanning for tick 59
DCF77:  Wrong pulse width 979 - Start new scanning for tick 59
DCF77:  Found Tick 59
DCF77:  Wrong pulse width 1937 - Start new scanning for tick 59
DCF77:  Wrong pulse width 816 - Start new scanning for tick 59
DCF77:  Wrong pulse width 36 - Start new scanning for tick 59
DCF77:  Wrong pulse width 9 - Start new scanning for tick 59
DCF77:  Wrong pulse width 802 - Start new scanning for tick 59

It was probably measuring the time the signal was high instead of low. The library allows setting the detection set to inverted with dcf.inverted = True, so I tried that.

from machine import Pin
from time import sleep_ms
from dcf77 import dcf77

# turn component on
Pin(3, Pin.OUT).value(0)

# start scanning
dcf = dcf77(Pin(4))
dcf.inverted = True
dcf.debug(True)
dcf.start()

current_dt = None
while True:
    dt = dcf.get_DateTime()
    if dt != current_dt:
        current_dt = dt
        print(dt)
    sleep_ms(100)

This looked better because now it actually "Detected" bits!

$ mpremote run dcf77-test2.py
DCF77:  Start decoding
[0, 0, 0, 0, 0, 0, 0, 0]
DCF77:  Detected '0'
DCF77:  Detected '1'
DCF77:  Wrong pulse width 137 - Start new scanning for tick 59
DCF77:  Wrong pulse width 49 - Start new scanning for tick 59
DCF77:  Detected '0'
DCF77:  Wrong pulse width 13 - Start new scanning for tick 59
DCF77:  Detected '0'
DCF77:  Detected '0'
DCF77:  Signal timeout - Start new scanning for tick 59
DCF77:  Wrong pulse width 133 - Start new scanning for tick 59
DCF77:  Found Tick 59
DCF77:  Wrong pulse width 5 - Start new scanning for tick 59

Unfortunately, after running for an hour, it never received a full minute of bits, so it never produced a proper reading. I connected a a logic analyzer to observe the signal.

It was clearly visible that there was noise on the line. I was running this on my office desk, surrounded by running electrons, so I moved to the top floor of our house to see if that would help. There, the errors disappeared, and I had finally received a reading!

...
DCF77:  Detected '0'
DCF77:  Detected '0'
DCF77:  Detected '1'
DCF77:  Detected '0'
DCF77:  Last Transmission: [0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0, 1, 0, 0, 1]
[2026, 3, 21, 5, 20, 35, 0, 0]
DCF77:  Detected '0'
...

Until the washing machine started its spin cycle…

It's a bit disappointing that this component is so sensitive to noise. However, looking at all the "Wrong pulse" messages and the analyzer output, I believe this could be fixed in the dcf77 library by ignoring all the shifts shorter than 50ms. The bit encoding includes three parity bits and two bits that always have the same value so after evening out the wave, it's still possible to validate the reading.

Later, I found an Arduino library that avoids these "squeaks" as describe above: DCF77.cpp line 99

I created a very simple board with two pads, one for each pin. To make KiCad to accept this, I added net labels for TX and RX for the pins I intended to use. In the PCB editor, I created two pads on the F.Cu layer, and assigned them to these net labels. Then, they were easy to wire up.

The result is very basic!

In the embedded programming week, we used a QPAD XIAO, and I experimented with some PIO assembly. I skipped that for this week because software can be a dangerous rabbit hole. Instead, I'll use some basic MicroPython.

from machine import Pin, ADC
from time import sleep_ms

rx = ADC(Pin(26, Pin.IN))
tx = Pin(0, Pin.OUT)

def probe():
    result = 0
    for i in range(10):
        tx.value(1)
        high = rx.read_u16()
        sleep_ms(50)
        tx.value(0)
        low = rx.read_u16()
        result = result + (high - low)
    return result

while True:
    print(probe())

The values are all over the place. I'll need to try again with a resistor at some point, to see if I can get more stable values. It's promising nonetheless!

I couldn't find a footprint for it in the KiCad library. It has 5 pins spaced like thos on a XIAO (2.54mm), so I used a horizontal 6-pin female header from the fablib to connect it.

I hoked it up as follows:

I had some trouble milling this board. In my first attempt half of the trace areas were only scratched instead of all the way through the copper layer (see figure 12). The bed screw on the right was too tight, causing the bed to wrap.

On the second attempt, all the trace areas were just scratched. Henk fixed this by z-leveling with some pressure on the bed, allowing the milling bit to stick out of the collet a bit further.

I wrote the code below to observe the pins behavior.

from machine import Pin

clk = Pin(6, Pin.IN)
dt = Pin(7, Pin.IN)
sw = Pin(0, Pin.IN, Pin.PULL_UP)

current_value = [clk.value(), dt.value(), sw.value()]
while True:
    new_value = [clk.value(), dt.value(), sw.value()]
    if new_value != current_value:
        print(new_value)

    current_value = new_value

Note: I used the internal pull-up resistor on the sw because otherwise, it doesn't detect the knob presses. Without the pull-up, it does jitters when I touch it, so I guess: extra points for a touch sensor!

Turning it clockwise, I observed the following bursts per click:

[0, 1, 1]
[0, 0, 1]
[1, 0, 1]
[1, 1, 1]

Turning counter-clockwise:

[1, 0, 1]
[0, 0, 1]
[0, 1, 1]
[1, 1, 1]

And pressing the knob changes the last value to 0.

The changes in values above correspond to the description of Incremental Encoders on Wikipedia, but in the opposite direction.

To detect the direction, I can assume:

• Clockwise: when clk goes from low to high and the dt is low.
• Counter-Clockwise: when clk goes from low to high and the dt is high.

from machine import Pin

clk = Pin(6, Pin.IN)
dt = Pin(7, Pin.IN)
sw = Pin(0, Pin.IN, Pin.PULL_UP)

direction = 0
current_count = count = 0
current_value = [clk.value(), dt.value(), sw.value()]
while True:
    new_value = [clk.value(), dt.value(), sw.value()]

    if new_value != current_value:
        if new_value[0] != current_value[0] and new_value[0] == 1:
            direction = dt.value()

            if direction == 0:
                count = count + 1
                print("clockwise", count)
            else:
                count = count - 1
                print("counter-clockwise", count)

        if new_value[2] == 0: # button pressed?
            count = 0
            print("button", count)

        current_count = count
        current_value = new_value

Note: The above code is for testing purposes only. It's a very busy loop that continuously polls the pin values. This approach is not suitable for production and would likely require debouncing code.