I just picked up the MakerFocus DSTIKE board and most of it seems straight forward however I have two questions:

1. The Clock option - Can't seem to set or change the clock it always reads 25:165. Does this require a separate clock chip or circuit?

2. After scan and under the select sub-menu there is an option 'Names' which always shows '0' . What exactly is names and how is it populated?

Thanks!

From childhood, I've been fascinated by electronics. Back then, I was building random projects without fully understanding the underlying science, tinkering with small cars, phones, amplifiers, and even attempting to build drones. It was just pure, chaotic fun.

Down the line, I somehow landed a job in software. I totally forgot about hardware for a while because I found a new kind of joy in building code.

Then, a couple of months ago, I bought a small TV ultra-desk clock simply because it looked cool. It sat on my desk for weeks, and it never really clicked that I could customize or hack it. Eventually, I started scrolling through YouTube videos to figure out how to write custom firmware and flash the device. But every tutorial seemed to require a mountain bunch of wiring and usb to ttl which I didn’t had, so I set it aside.

Everything changed when I stumbled upon a project ClawdMeter that bridged the gap between my childhood passion and my day job. I realized I could use Claude to debug and write code, turning what seemed impossible into a reality. I managed to hack through the limitations, build a custom firmware, and successfully deploy it without opening it just via OTA.

Suddenly, all that childhood joy came rushing back. I went ahead and bought a bunch of hardware esp-32, sensors like TOF , Ultrasonic, and more and started building things like 3D scanners, ultrasonic scanners, and web-controlled displays. All the time I’ve spent working in software, combined with the power of these AI tools, is finally coming together and making the process so much easier. I'm fully hooked on building hardware again.

Here is the project that finally started it all click: Glimmer

I made this device back when I was in college, to cheat obviously, but never actually used it for cheating. It has an ESP-M2 module which is an ESP8285. Which acts as an Acces Point and a websocket server, to control the calculator. The calculator is a Casio fx-82MS. And it’s not controlling it over UART or something, it actually simulates physical button presses by connecting the exposed pads of the calculator. To simulate these connections I’ve used two 74HC4051 chips and a SN74LVC1G3157. The board is powered a 14500 li-ion battery and a HX4000B voltage regulator. I also used a DW01A for battery protection and a TLV70012DCKR voltage regulator for powering the calculator itself. It also has a BMX055 for a cool reason. I’ll be creating a GitHub repo in a few days, just wanted to share here before.

Update: added link to source code

This is a rather long post. It documents my journey on a project that raised a lot of eyebrows. As is usually the case for me, the question of how is much more interesting than the question of why. This post gives a very detailed answer to the question of how. Let's go!

----

I have a 21 year-old Miele washing machine. I used to connect to the Internet using a modem when this fellow first left the Miele factory floor. As a weekend project I decided to put an ESP into that. How hard can that be?

The device has a 3-digit 7-segment display and a bunch of status LED's

So I figured, how hard can it be to add an ESP on top that reads out the current state of the device and posts it over MQTT? Just wire the LED's to some GPIO's and read out the voltage across each LED, amirite?

The first step was to disassemble the washing machine (as most people are known to do on weekends) and meet the incumbent MCU.

On the board we see a custom Miele chippie, a couple of other chips and all the SMT LED's that light up the front panel.

Let's see if we can even tell whether a LED is lit just by measuring the voltage across it. Uh oh, the measurement across a lit LED showed 0.17V. What?... my initial plan did not survive first contact with reality.

Let's try to figure out how the LED's on this board work. Tracing the fat PCB traces that lead away from the LED's on the right side, we arrive at one of the other chips - a Motorola MC14489, year of manufacture '99. A multi-character LED display driver. A-ha! It appears that the board uses an MC14489 to multiplex the output to the LED's. Neat! That explains the low voltage measured earlier.

There is in fact a second MC14489 on the board which apparently drives the 7-segment display. So one chip to drive the display and a second chip to drive the ~24 status LED's. I call the chips "left" and "right" from here on, or L and R.

Reading the datasheet, we see that the MC14489 is programmed over SPI. The chip has two registers, an 8-bit control register and a 24-bit display register. If you shift in an 8-bit packet, it writes it to the control register. If the packet is 24-bit long, then it goes into the display register. So instead of passing a register address as part of the packet, the length of the packet is itself the address. Neat! This addressing mode is so revolutionary that Motorola patented it and trademarked it as BitGrabber(tm). Wow! Google bought Motorola just to get a hold of this one patent, guys! /s

At this point we already have a plan B brewing. What if... listen... what if we tap the SPI lines and read out the MC14489 state? From that we could then derive the state of the entire panel!

Each chip has a CLOCK, DATA and /ENABLE pin. Let's see, where's the best place to solder in some modding wire? Also, we need to figure out how we're going to power our ESP board. Actually, which board are we even going to use?

Poking around the board with the continuity tester, we figure out the following: the two chips share common DATA and CLOCK lines and have separate /ENABLE lines.

While the washing machine is powered we determine that the chips are sipping on 5V.

Moreover, the chips' data, power and ground nets are all helpfully exposed on test pads nearby.

Let's bodge in some 30 AWG modding wire next,

We'll need a board with at least 4 safe GPIO's, a 3.3V voltage regulator and a level shifter. A lot of the GPIO pins on an ESP8266 must be either high or low when the ESP8266 first boots, otherwise the boot fails. There are only a couple of safe GPIO's that may be in any state during boot.

All of the above means that the ESP-01 is disqualified. It has no safe pins. Our next option in the ESP8266 line-up is a D1 mini, which has 4+ safe GPIO pins and also has a voltage regulator.

The question is, can a ESP8266 even reliably read out the ongoing SPI communication? I mean, it surely can, right? The ESP8266EX CPU runs at 80MHz by default and the SPI clock rate is surely much, much lower than that. Heck, even an attiny running at 8MHz could do probably do it! Even bees do it!

Let's see. The ESP8266 can work as an SPI slave. Can we tap that? It turns out, no, not really. When working as an SPI slave, it follows its own higher-level protocol, expecting address-data word pairs to be clocked in. After reading the docs and a lot of example code on the net, I still couldn't find a way to make it emulate BitGrabber(tm). So, bit-banging it is.

I have a Home Assistant setup at home, so our BitGrabber emulator has to be able to work from within an ESPHome firmware. I implemented a custom C++ ESPHome component that emulates the hallowed BitGrabber(tm). It uses external interrupts on designated CLK and /EN pins to respond to level changes on the SPI bus. The idea is to simply read out the DATA pin state from inside a CLK interrupt when the /EN pin is low. When the /EN pin goes high, we latch in the control register on 8 bits received, the display register on 24 bits received, otherwise we drop the update. Separate template text sensors read out the captured state registers and turn them into useful status reports.

To help out with development, I programmed an Arduino to act as a dummy SPI master. It would just shiftOut() consecutive numbers on the SPI bus every second. This allowed me to test and debug my SPI sniffer before wiring the ESP to the real thing.

I programmed the Arduino to shiftOut() 0, 1, 2, 3, 4, 5, 6... on the SPI bus every second. I could see the correct bit pattern appearing on my Rigol oscilloscope. Yet, in the ESP logs I saw 0, 0, 1, 1, 2, 2, 3, 3. It appears that the last bit wasn't getting shifted in on the ESP side. Thinking that there was an interrupt getting lost, I debugged and debugged and debugged the interrupt handlers to no avail. I was stumped for quite a while.

Then it hit me. The ESP8266 took so long to dispatch the CLK interrupt handler, that by the time my code sampled the DATA pin, the Arduino had already shifted in the *next* DATA bit. It turns out that external interrupts on the ESP8266 are reeeeeally slow. Like, 80+ cycles slow. Cranking the ESP clock rate to 160MHz and dialing down the SPI clock rate to 100kHz gave the ESP just enough time to clock in the DATA bits before they disappear with about 99.5% success. So, occasionally it still dropped some bits.

Pathetic. The clock is roaring at 160MHz and the MCU is barely able to respond to a 100kHz external interrupt event rate? The ESP8266 is not a great MCU. Is it even an MCU at all?

OK, so if the SPI clock rate on the Miele is <= 100kHz, we're good to go. Otherwise we'll need to go up to an ESP32. Guess what - the Miele clock rate turned out to be about 97kHz, as reported by the Rigol. So, we're bang-on! We can expect a couple of lost packets, but we can live with that. The Miele MCU seems to output the washing machine state on the SPI bus many times per second. We can live with a little bit of packet loss.

With the SPI sniffer ready, we can now test it with the real thing. I soldered some DuPont connectors to the bodge wires, and prepped everything on a breadboard. I put a chinesium 4-channel level shifter between the D1 mini and the SPI bus.

I crossed my fingers, powered up the Miele... and hooray! It worked! I could see the SPI bus chatter appear in the board's MQTT log topic.

I could see the digits displayed on the 7-segment display literally appear in the display register of the left chip in hexadecimal. So decoding the "time remaining" was really easy. The right chip is responsible for all other LED's. I ran two cycles and spent about 2 hours recording which bits in the R display register correspond to which LED's on the front panel. And after some fiddling with template text sensors I finally got this shown on my Home Assistant dashboard:

Here's the complete firmware source code.

With the prototype finished, I soldered it onto a stripboard

And strapped it with a cable tie to the mains wires (what could go wrong) under the hood:

And we're done! Full disclosure: the project took 4 weekends, not just one.

Total BoM:

• D1 mini - 2 EUR

• Level shifter - 1 EUR

• Wire - ~50 cents

• Stripboard - ~50 cents

Stats for nerds:

• # shocks from a live wire - 1

• # lost screws - 5

• # remaining screws that I can afford to lose before the thing becomes unassembleable - 0

....

But can it load the laundry over WiFi? Can it then hang it out to dry over WiFi?

Listen.... what was the point of this project? It was to learn, to hack and to have fun while doing it. In that respect the project was a success and that's all that matters.

Thank you all for your time!