DoMSnif - Dot Matrix LCD Sniffer Bluetooth Adapter

Wow! The project won the best documentation prize for the Connected World Contest!

Things have been a bit busy, so no experimentation has been allowed on the LCD at this stage, but I hope to have working hardware sources soon.

While this project has set out to offer a solution for the LCD display, the oven itself has met a different fate. It was decided to modify the hardware completely and give it a more useful set of features. You can see the work on this over here - https://hackaday.io/project/167324-brtro-420-better-blazin-mod

This new project is using the SAMC21 5V tolerant ARM MCU as well, so the working getting Arduino up and running on that will feed back into this project.

So just poking around the various microcontroller options out there, it seems there's a few "newish" 5V capable ARM chipsets in the wild.

This would mean we can do away with the level conversion and interface directly with the LCD. One of these options is the ATSAMC21J18A a 5-Volt 32-Bit ARM Cortex M0+.

This SAMC variant further simplifies the DoMSnif which would just require some buffering for the UART TX pin:

So after mulling over a few options, it looks like it's best to do the decoding on a dedicated microcontroller and send a decoded LCD frame buffer periodically to a Bluetooth controller, which can then send this data to a client at its own leisure.

This solution means that there is no interruption to the high priority interrupts required to capture all the LCD instructions (which happens on the NRF52 when Bluetooth is operational). If you miss any of these instructions coming in, the decoded image can become corrupt, as each instruction either tells it which column/page to write in or which pixels to write.

The sending of data over a UART connection from the decoding chipset to another Bluetooth controller will not interfere with this, as it will send bytes "when it can" between LCD instructions. This transmission happens as a simple start sequence, then sequentially reading out each display byte and finally a CRC check. This is then buffered by the Bluetooth controller and sent to a client periodically. This framebuffer is essentially the bitmap of the image, so the client doesn't require anything fancy to decode it.

For the prototype it's still using the Feather for the Bluetooth comms, but it now also has as a Teensy for the dedicated LCD decoding:

The final version will consist of a much more simplified board containing an NRF52 chipset for Bluetooth, a SAMD21 for the LCD decoding, some level converters and a power supply. Something along the lines of this:

The code is "mostly" working on the prototype, but it still requires some testing. There was some issues building BLE support into the Visual Studio demo application so the data could be visualised. But that for the most part is working now with the help of the Universal Windows Platform, Windows.Devices.Bluetooth classes:

After some testing, the nRF52832 on the Feather module being used is not going to work well for this project alone.

The data is fed into the LCD approximately every 14us:

However the critical radio sections of the nRF52832 can take much much longer than this:

These Bluetooth critical sections have the highest priority on the nRF52832 (otherwise they wouldn't work), so several LCD data events can occur before the LCD data ready interrupt is actually triggered (aliasing/skipping data).

So now to find another method of gathering the LCD data...

Whipping together a quick prototype adapter board for the NRF52 Feather was pretty simple. The main thing to note was level conversion between the 5V LCD signal lines and the 3.3V pins of the feather which in this case was achieved through some resistor dividers. The 5V line is connected to the VBUS (5V) input of the Feather to power the board from the LCD cable.

A smaller, more streamlined board will be created later. But now there's software to write!

There's very few visualisation tools out there to translate the binary KS0108 LCD data to an actual visual output and none offered the ability to import or display a dataset from any source. So I guess we have to make one.

Fortunately the KS0108 has a pretty simple layout:

A KS0108 based 128x64 pixel LCD module consists of two controllers, each with 8 pages and each page consisting of 64 column bytes. So we can structure the code very similarly:

Combine this with a little GUI magic and we get a nice little tool to import data from a CSV file and output it to a window in realtime:

Now, we have the base code for decoding the KS0107/8 module, we can now start porting it to an NRF52 board.

If you can hear audio, then it can be recorded by another analog source, rendering DRM ineffective.

The same can be said about any device. If you can see the data you want, then you can record it. Well fortunately we don't have to go quite Neanderthal on such devices with a camera setup. Instead, we can sniff the display data directly.

Adding an additional 20 pin header to the ribbon cable of the LCD connection (or creating a pass through board), gives us direct access to the digital data being sent to the LCD display. While there was no markings on the LCD board to determine its interface, by looking at the signalling it was found to be a KS0107/8 based device used in most hardware devices.

So what do you do with this data?

Working with the BRTRO-420 reflow oven, it looked like it might be possible to interface with the controller using an inbuilt serial connection to possibly get temperature read outs.

Reverse engineering the serial connection got the following:

Unfortunately trying to interface with this yielded no results. Looking further into the CY96F613 microcontroller datasheets then lead to the fact that this connection is purely used for serial firmware updates. So that was a dead end, apart from recreating the firmware which would effectively brick the machine until it was finished and working.

So where to next? Well the temperature data was sitting right in your face on the front of the machine, it's just a little tricky to get to...