An LED bulb with integrated controller chip

Reverse-Engineering A Two-Wire LED Strip Protocol

January 31, 2022 by 19 Comments

Although Christmas may be several weeks behind us, various colorful LED contraptions can nowadays be found in our houses at any time of year. [Tim] got his hands on an LED curtain that came with a remote control that allows the user to set not only the color of the LEDs as a whole but also to run simple animations. But these were not your standard WS2812B strips with data lines: all the LEDs were simply connected in parallel with just two wires, so how was this even possible?

An oscilloscope screenshot showing the data protocol used in an LED string
The LED string protocol is very simple, with one address field and one data field.

[Tim] hooked up his oscilloscope to the LED strings to find out how they worked, detailing the results in a comprehensive blog post. As it turns out, the controller briefly shorts the LED strip’s supply voltage to generate data bits, similar to the way old pulse-dialing phones worked. A tiny chip integrated into each LED picks up these pulses, but retains its internal state thanks to a capacitor that keeps the chip powered when the supply line goes low.

After reverse-engineering the protocol, [Tim] went on to implement a similar design using an ATMega328P as a controller and an ATtiny10 as the LED driver. With just a few lines of code and a 100 nF buffer capacitor across the ATtiny’s power pins, [Tim] was able to turn an LED on and off by sending pulses through the supply lines. Some work still needs to be done to fully implement a protocol as used in the LED strings, but as a proof-of-concept it shows that this kind of power-line communication is possible with standard components.

We’ve seen projects that send signals down a two-wire LED chain before, although as an add-on to a more ordinary LED strip. [Tim] is not the first to reverse-engineer poorly documented LED strip protocols, but probably won’t be the last either.

Reverse Engineering The NeXT Computer Keyboard Protocol

January 26, 2022 by 22 Comments

The NeXT computer was introduced in 1988, with the high-end machine finding favor with universities and financial institutions during its short time in the marketplace. [Spencer Nelson] came across a keyboard from one of these machines, and with little experience, set about figuring out how it worked.

The keyboard features a type of DIN connector and speaks a non-ADB protocol to the machine, but [Spencer] wanted to get it speaking USB for use with modern computers. First attempts at using pre-baked software found online to get the keyboard working proved to be unreliable. [Spencer] suspected that the code, designed to read 50 microsecond pulses from the keyboard, was miscalibrated.

Some analysis with an oscilloscope and logic analyzer allowed [Spencer] to figure out the keyboard was communicating with pulses ever 52.74 microseconds, corresponding to a frequency of 18.960 kHz, sending two 9-bit messages at a time. Disassembling the keyboard confirmed these findings – inside was a 455 kHz clock, with the keyboard sending a signal every 24 ticks producing the 18.960 kHz output.

Reworking the initial code found online to work with the actual pulse widths coming from the keyboard got everything humming along nicely. Now, [Spencer] has a nice vintage keyboard with excellent feel that reliably works with modern hardware. We’d call that a win.

If you need more of a fix, be sure to dive into Keebin’ with Kristina, a regular column all about our favorite tactile input devices!

Raspberry Pi Real-Time HAT

New Part Day: Raspberry Pi HAT For IEEE1588 Precision Time Protocol

August 16, 2021 by 18 Comments

The new Real-Time HAT by InnoRoute adds IEEE1588 PTP support in hardware to a Raspberry Pi 4 nestled beneath. Based around a Xilinx Artix-7 FPGA and a handful of gigabit Ethernet PHY devices, the HAT acts as network-passthrough, adding accurate time-stamps to egress (outgoing) packets and stripping time-stamps from the ingress (incoming) side.

This hardware time-stamping involves re-writing Ethernet packets on-the-fly using specialised network hardware which the Raspberry Pi does not have. Yes, there are software-only 1588 stacks, but they can only get down to 10s of microsecond resolutions, unlike a hardware approach which can get down to 10s of nanoseconds.

1588 is used heavily for applications such as telecoms infrastructure, factory equipment control and anything requiring synchronisation of data-consuming or data-producing devices. CERN makes very heavy use of 1588 for its enormous arrays of sensors and control equipment, for all the LHC experiments. This is the WhiteRabbit System, presumably named after the time-obsessed white rabbit of Alice In Wonderland fame. So, if you have a large installation and a need for precisely controlling when stuff happens across it, this may be just the thing you’re looking for.

IEEE1588 PTP Synchronisation

The PTP client and master device ping a few messages back and forth between themselves, with the network time-stamper recording the precise moment a packet crosses the interface. These time-stamps are recorded with the local clock. This is important. From these measurements, the time-of-flight of the packet and offset of the local clock from the remote clock may be calculated and corrected for. In this way each client node (the hat) in the network will have the same idea of current time, and hence all network packets flowing through the whole network can be synchronised.

The beauty of the system is that the network switches, wiring and all that common infrastructure don’t need to speak 1588 nor have any other special features, they just need to pass along the packets, ideally with a consistent delay.

The Real-Time HAT configures its FPGA via SPI, straight from Raspberry Pi OS, with multiple applications possible, just by a change on the command line. It is possible to upload custom bitstreams, allowing the HAT to be used as a general purpose FPGA dev board should you wish to do so. It even stacks with the official PoE HAT, which makes it even more useful for hanging sensors on the end of a single wire.

Of course, if your needs are somewhat simpler and smaller in scale than a Swiss city, you could just hack a GPS clock source into a Raspberry Pi with a little soldering and call it a day.

Here’s How To Sniff Out An LCD Protocol, But How Do You Look Up The Controller?

July 30, 2021 by 11 Comments

Nothing feels better than getting a salvaged component to do your bidding. But in the land of electronic displays, the process can quickly become a quagmire. For more complex displays, the secret incantation necessary just to get the things to turn on can be a non-starter. Today’s exercise targets a much simpler character display and has the added benefit of being able to sniff the data from a functioning radio unit.

When [Amen] upgraded his DAB radio he eyed the 16×2 character display for salvage. With three traces between the display and the controller it didn’t take long to trace out the two data lines using an oscilloscope. Turing on the scope’s decoding function verified his hunch that it was using I2C, and gave him plenty of data to work from. This included a device address, initialization string, and that each character was drawn on screen using two bytes on the data bus.

He says that some searching turned up the most likely hardware: a Winstar WO1602I-TFH- AT derived from an ST7032 controller. What we’re wondering is if there is a good resource for searching this kind of info? Our go-to is the LCD display and controller reference we covered here back in March. It’s a great resource, but turns up bupkis on this particular display. Are we relegated to using DuckDuckGo for initialization strings and hoping someone’s published a driver or a logic dump of these parts in the past, or is there a better way to go about this? Let us know in the comments!

Understanding Custom Signal Protocols With Old Nintendos

July 2, 2021 by 5 Comments

For retro gaming, there’s really no substitute for original hardware. As it ages, though, a lot of us need to find something passable since antique hardware won’t last forever. If a console isn’t working properly an emulator can get us some of the way there, but using an original controller is still preferred even when using emulators. To that end, [All Parts Combined] shows us how to build custom interfaces between original Nintendo controllers and a PC.

The build starts by mapping out the controller behavior. Buttons on a SNES controller don’t correspond directly to pins, rather a clock latches all of the button presses at a particular moment all at once during each timing event and sends that information to the console. To implement this protocol an Adafruit Trinket is used, and a thorough explanation of the code is given in the video linked below. From there it was a simple matter of building the device itself, for which [All Parts Combined] scavenged controller ports from broken Super Nintendos and housed everything into a tidy box where it can be attached via USB to his PC.

While it might seem like a lot of work to get a custom Nintendo controller interface running just because he had lost his Mega Man cartridge, this build goes a long way to understanding a custom controller protocol. Plus, there’s a lot more utility here than just playing Mega Man; a method like this could easily be used to interface other controllers as well. We’ve even seen the reverse process where USB devices were made to work on a Nintendo 64.

Continue reading “Understanding Custom Signal Protocols With Old Nintendos” →

Decoding The PS/2 Keyboard Protocol Using Good Old Fashioned Hardware

March 11, 2021 by 29 Comments

1987 was a glorious year.  It brought us the PS/2 keyboard standard that’s still present on many a motherboard back panel to this day. (It also marked the North America/Europe release of The Legend of Zelda but that’s another article.) Up until this point, peripherals were using DIN-5 and DE-9 (often mistakenly called DB9 and common for mice at the time) connectors or — gasp — non-standard proprietary connectors. So what was this new hotness all about? [Ben Eater] walks us through the PS/2 hall of fame by reverse-engineering the protocol.

The PS/2 connector in all its glory

This is a clocked data protocol, so a waveform is generated on the data pin for each key pressed that can be compared to the clock pin to establish the timing of each pulse. Every key sends a unique set of encoded pulses and voila, the whims of the user can quickly and easily be decoded by the machine.

This is where [Ben’s] dive really shines, we know he’s a breadboarding ninja so he reaches for some DIP chips. A shift register is an easy way to build up a parallel PS/2 interface for breaking out each data packet. There are a few quirks along the way, like the need to invert the clock signal so the shift register triggers on the correct edge. He also uses the propagation delay of a couple inverter gates to fire the 595 shift register’s latch pin slightly late, avoiding a race condition. A second 595 stores the output for display by a set of LEDs.

Beyond simply decoding the signal, [Ben] goes into how the packets are formatted. You don’t just get the key code, but you get normal serial interface error detection; start/stop bits and a parity bit as well. He even drills down into extended keys that send more than one packet, and a key-up action packet that’s sent by this particular keyboard.

This is the perfect low-level demo of how the protocol functions. On the practicality side, it feels a bit strange to be breaking out the serial to parallel when it would be very easy to monitor the two signal lines and decode them with a microcontroller. You might want to switch it up a bit, stick with the clock and data pins, but connect them to a Raspberry Pi using just a few passive components.

Continue reading “Decoding The PS/2 Keyboard Protocol Using Good Old Fashioned Hardware” →

Reverse Engineering USB Protocols On A Function Generator

February 9, 2021 by 21 Comments

When working with test equipment such as oscilloscopes and function generators, it can be useful to take a screen capture. Historically this was done with Polaroid cameras that were bolted in place, but these days it can be done over a simple USB connection. [Majenko] didn’t like the Windows-only software that shipped with their Tenma 72-14110 function generator, however, and set about reverse engineering the USB protocol to create their own.

The hack was pulled off by running the original software in a Windows VM, while running Wireshark in the host Linux OS to capture the USB traffic. Once enough data had been captured, [Majenko] set about figuring out how the function generator formatted the screen data when sending it to the PC. Based on the fact that the data changed in length depending on what was on the display, it was surmised that the data was not raw, but compressed somehow. A hunch suggested it was probably some form of Run-Length Encoding, and this proved to be correct. With a little more digging and experimentation, [Majenko] was able to put together some code that netted a clear image from the device.

It’s a useful guide for reverse engineering image data, one that could prove useful if you’re tackling a similar problem on other hardware. We’ve seen some great reverse engineering efforts over the years, on everything from old video hardware to the Sega Saturn. If you’ve been diving deep into the secrets of software or hardware yourself, be sure to drop us a line.