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.

ExpressLRS: Open Source, Low Latency, Long Range RC Protocol

January 19, 2021 by 42 Comments

One of the major choices a newcomer to the RC flying hobby must make is on the RC link protocol. To add the list of choices (or confusion) there is now a new open-source, low latency, and long-range protocol named ExpressLRS.

ExpressLRS’s claim to fame is high packet rates of up to 500 Hz, with plans for 1000 Hz, and latency as low as 5 ms. Long-range testing has pushed it out to 30 km with a flying wing (video below), but this is not unheard of for other protocols. Most modern RC protocols run either in the 2.4 GHz or 915/868 MHz bands, with the latter having a definite advantage in terms of range.

ExpressLRS has options to run on either band, using Semtech SX127x (915/868 MHz) or SX1280 (2.4 GHz) LoRa transceivers, connected to STM32, ESP32, or ESP8285 microcontrollers. The ESP microcontrollers also allow software updates over Wi-Fi.

We’re excited to see an open-source competitor to the proprietary protocols currently dominating the market, but several open-source protocols have come and gone over the years. Hardware availability and compatibility is a deciding factor for a new protocol’s success, and ExpressLRS already has an advantage in this regard. Existing Frsky R9 transmitters and receivers, and Immersion RC Ghost receivers are compatible with the firmware. There are also DIY options available, and the GitHub page claims that several manufacturers are working on official ExpressLRS hardware.

If you’re already into the RC hobby, and you have compatible hardware lying around, be sure to give it a try and give some feedback to the developers! One scenario we would like to see tested is high interference and congested band conditions, like at RC flying events.

All the source code and hardware designs are available on GitHub, and there are active community discussions on Discord. Continue reading “ExpressLRS: Open Source, Low Latency, Long Range RC Protocol” →

M17 Aims To Replace Proprietary Ham Radio Protocols

October 2, 2020 by 115 Comments

While M17 might sound like a new kind of automatic rifle (as actually, it is), we were referring to an open source project to create a ham radio transceiver. Instead of paraphrasing the project’s goals, we’ll simply quote them:

The goal here should be to kick the proprietary protocols off the airwaves, replace DMR, Fusion, D-Star, etc. To do that, it’s not just good enough to be open, it has to be legitimately competitive.

Like some other commercial protocols, M17 uses 4FSK along with error correction. The protocol allows for encryption, streaming, and the encoding of callsigns in messages. There are also provisions for framing IP packets to carry data. The protocol can handle voice and data in a point-to-point or broadcast topology.

Continue reading “M17 Aims To Replace Proprietary Ham Radio Protocols” →

Arduino’s Pluggable Discovery Programs With Any Protocol

May 8, 2019 by 9 Comments

The first Arduino was serial, and over the decade and a half, this has been the default way to upload code to an Arduino board. In 2008, support for in-circuit programmers was added, and later port detection was added. The latest version of the Arduino IDE adds something new: pluggable discovery. Now any protocol is supported by the Arduino IDE.

This feature is the brainchild of [Paul Stoffregen], creator of the Teensy. If you’ve ever used a Teensy, you’ll remember the Teensyduino application used to upload code to the board. The Teensy uses HID protocol instead of serial for uploading. After working to improve the integration between the Teensy and Arduino IDE, [Paul] stated extending the DiscoveryManager. After some discussion with the Arduino developers, this feature was then added to Arduino 1.8.9, released a month or so ago.

There are some issues with Pluggable Discovery, most importantly that it doesn’t yet exist in the Arduino Command Line Interface (yeah, that exists too). If you’re looking to contribute to Open Source, that would be a nice project to pick up.

With the right JSON, and configuration, it is now theoretically possible to extend the Arduino IDE to any sort of protocol. This means (again, theoretically), it’s possible to update the firmware in your DIY MIDI synth over SysEx message, or a parallel port, maybe. Someone is going to upload to an Arduino board over PCIe, eventually.

Transcending The Stack With The Right Network Protocol

April 9, 2019 by 14 Comments

The increase in network-connected devices the past years has been something of a dual-edged sword. While on one hand it’s really nice to have an easy and straight-forward method to have devices talk with each other, this also comes with a whole host of complications, mostly related to reliability and security.

With WiFi, integrating new devices into the network is much trickier than with Ethernet or CAN, and security (e.g. WPA and TLS) isn’t optional any more, because physical access to the network fabric can no longer be restricted. Add to this reliability issues due to interference from nearby competing WiFi networks and other sources of electromagnetic noise, and things get fairly complicated already before considering which top-layer communication protocol one should use. Continue reading “Transcending The Stack With The Right Network Protocol” →