At one time or another, we’ve all suffered through working with a piece of equipment that didn’t feature a way to export its data to another device. Whether it was just too old to offer such niceties, or the manufacturer locked the capability behind some upgrade, the pain of staring at digits ticking over on a glowing LCD display and wishing there was a practical way to scrape what our eyes were seeing is well known to hackers.
That was precisely the inspiration for DoMSnif, the dot matrix LCD sniffer that [Blecky] has been working on. Originally the project started as a way to record the temperature of his BRTRO-420 reflow oven, but realizing that such a device could have widespread appeal to other hardware hackers, he’s rightfully decided to enter it into the 2019 Hackaday Prize. If perfected, it could be an excellent way to bolt data capture capabilities to your older devices.
The first phase of this project was figuring out how to capture and parse the signals going into the device’s KS0108 LCD. Getting the data was certainly easy enough, he just had to hook a logic analyzer up between the display and the main board of the device. Of course, figuring out what it all means is a different story.
After running the oven for a bit with the analyzer recording, [Blecky] had more than enough data to get started on decoding it. Luckily, the layout of this fairly common 128×64 pixel display is well documented and easy enough to understand. With a little work, he was able to create a tool that would import the captured data and display it on a virtual LCD.
Unfortunately, the Bluetooth part is where things get tricky. Ultimately, [Blecky] wants to ditch the logic analyzer and use a Adafruit Feather nRF52 Bluefruit to capture the signals going to the LCD and pipe them to a waiting device over Bluetooth. But his testing has found that the nRF52’s radio is simply too slow. The display is receiving data every 14us, but it takes the radio at least 50us to send a packet.
[Blecky] is looking at ways around this problem, and we’re confident he’ll crack it. The solution could be in buffering and compressing the data before sending it out, though you’d lose the ability to monitor the display in real-time. Even if he has to abandon the Bluetooth aspect entirely and make the device wired, we still think there would be a market for an easy to use hardware and software solution for scraping LCD data.
Compressing data sbouldnt affect realtime use.
It does if you don’t have a powerful enough CPU to do it on the fly.
Simple delta encoding to only send the changes compared to the previous frame should in most cases be fast enough (unless the entire screen changes every frame)
To clarify to someone else who like me misunderstood the problem: it’s not lack of transmission bandwidth.
It’s that the nRF52 is a single-core device and is held up for at least 50us when the BLE stack periodically communicates with the connected central device and is unable to sample the data bus during that time.
This is correct JR :)
So, it’s a digital frame grabber then.
Surely that Feather has enough RAM to inhale a whole frame. The radio only has to send diffs in real time, or it could even do image interpretation itself.
I did something similar to grab numeric values from the screen of an instrument that I couldn’t void the warranty on, but exposed its VGA signal for an external monitor: I captured the analog video signal into a VGA frame grabber, and ran a cross-correlation on predefined patches of the screen with a library of pre-stored images of numbers. It spat out the half-dozen numeric values frame-by-frame in real time on a 25 MHz ‘486 (hey – it was 1992…)
The Feather should be able to do this much more easily on the digital data, since you don’t need to do a full cross-correlation: the image isn’t going to be wandering around in the frame grabber memory from day to day like it does with an analog signal. A simple pattern match will work fine.
I came here to make a similar suggestion to Paul’s.
It’s not quite the radio being too slow, it’s that the Bluetooth software context on the Feather runs with the highest priority interrupt for several tens of us (blocking all other interrupts), so you end up missing LCD instructions that stream in.
I’ve got a temporary fix and that’s to just use a Teensy to do the instruction decoding and the Feather to send the LCD data. But I’d like a more elegant solution down the track.
Surely the data he wants to record is the oven temperatrue right now, now the whole data on the LCD display. Then he can log it to file and plot it as a graph or otherwise note down key features. Wouldn’t the designer be better off trying to add a wire directly to the device’s temp sensor and just read that off, then send that data to their logger? Extracting numbers from full images just to plot them yourself later seems a very inelegant solution.
I could do this, but it was more an exercise in decoding standard LCDs. This could have a multitude of different purposes for other industrial equipment that cannot be easily modified.
one frame every 14µs – one transmission every 50µs
-> 50 / 14 = 3,5 -> Round up to 4 = just transmit every 4th frame and ignore the rest, this is not a high framerate application
It’s not quite the radio/MCU being too slow, it’s that the Bluetooth software context on the NRF52 runs with the highest priority interrupt for several tens of us (blocking all other interrupts), so you end up missing LCD instructions that stream in. These instructions are effectively random, so you cannot predict when they arrive. If the Bluetooth device is connected, it runs 50us high priority interrupts at different intervals during the connection, so you end up missing lots of data.
Each instruction is a register setting (change address/write display bytes mostly), so if you miss any of those you get a corrupted display image.
The core on the NRF52 is there more or less to run the Bluetooth functions and there’s a bit of extra processing power to do low priority tasks. So it’s a bit misleading, as it’s not a dedicated processing core.
*Each instruction is a register setting every 14us or so
Just did something quite similar
https://youtu.be/5ymh3p8gKiQ
Sending one frame per second should be real-time enough for most tasks.
Can you please make this into sigrok protocol decoder plugin?