Old Dot-Matrix Displays Give Up Their Serial Secrets

June 4, 2024 by Dan Maloney 11 Comments

If there’s one thing we like better around here than old, obscure displays, it’s old, obscure displays with no documentation that need a healthy dose of reverse engineering before they can be put to use. These Plessey dot-matrix displays are a perfect example of that.

We’re not sure where [Michael] scored these displays, but they look fantastic. Each 8-pin DIP has two 5×7-matrix, high-visibility LED displays. They bear date codes from the late 80s under the part number, GPD340, but sadly, precious little data about them could be dredged up from the Interwebz. With 70 pixels and only six pins after accounting for power and ground, [Michael] figured there would be a serial protocol involved, but which pins?

He decided to brute-force the process of locating them, using a Pico to sequentially drive every combination while monitoring the current used with a current sensor. This paid off after only a few minutes, revealing that each character of the display has its own clock and data pins. The protocol is simple: pull the clock and data pins high then send 35 bits, which the display sorts out and lights the corresponding pixels. The video below shows a 12-character scrolling display in action.

Plessey made a lot of displays for military hardware, and these chunky little modules certainly have a martial air about them. Given that and the date code, these might have come from a Cold War-era bit of military hardware, like this Howitzer data display which sports another Plessey-made display.

Continue reading “Old Dot-Matrix Displays Give Up Their Serial Secrets” →

MUDLink Is Making UART Data Links More Reliable

May 3, 2024 by Lewin Day 20 Comments

Many of us have used UARTs to spit data from one system or chip to another. Normally, for quick and dirty maker projects, this is good enough. However, you’ll always get the odd dropped transmission or glitch that can throw a spanner in the works if you’re not careful. [Jake Read] decided to work on a system that could use UARTs while being far more reliable. Enter MUDLink.

MUDLink is a library that works with an Arduino’s UART port and stacks on a bit of protocol to clean things up. It uses a packetized method of sending data to ensure that transmissions are received reliably as intended by the sender. Packets are framed using a method called Consistent Overhead Byte Stuffing, which is a nice lightweight way of doing so. The system also uses CRC16-CCITT as an error checking mechanism. There’s also an ack-and-retransmit system for ensuring any dropped transmissions are repeated and received successfully.

If you need reliable UART transmissions without too much overhead, you might want to look at what Jake is doing. It’s a topic we’ve looked at before, too.

Minitel, The 1980s Console Game Platform You Never Had

February 10, 2024 by Jenny List 14 Comments

We’ve made no secret over the years here at Hackaday of our admiration for the Minitel. The ubiquitous CRT terminals which made 1980s France the most connected country in the world never made it to where we grew up, but OH! how we wanted them to! We’ve seen quite a few Minitels repurposed as serial terminals here, but for the time being we think [Louis H] has won the Minitel Internet with his plugin game console cartridges. These have a DIN plug to fit the Minitel serial port, and present themselves as a serial game.

The cartridge itself is an extremely simple affair, a tube which fits over the DIN plug body, containing a slim PCB with an ATmega328 and its supporting components. The games must be programmed such that their gameplay can work over a serial interface, so as an example the first game is a version of 2048.

We applaud both the simplicity and creativity of this project, and we love it that a new 1980s console we never knew we had has been unearthed, without the need for hardware modification. Meanwhile if you’d like to peer inside an Alcatel Telic 1, we can take you there.

Need A Serial Data Plotter? Better Write Your Own

January 29, 2024 by Dave Rowntree 12 Comments

When you’re working with a development team, especially in a supporting capacity, you can often find yourself having to invent tools and support systems that are fairly involved, but don’t add to the system’s functionality. Still, without them, it’d be a dead duck. [Aidan Chandra] was clearly in a similar situation, working with a bunch of postgrads at Stanford, on an exoskeleton project, and needed an accurate data plotter to watch measurements in real-time.

This particular problem has been solved many times over, but [Aidan] laments that many solutions available seem to be too complex, hard to extend, or just have broken dependencies. This happens a lot, and it simply leads to yet another project to get going, before you can do the real work it supports. Based on Python and PyQT5, serial-plotter is a new beginning, with an emphasis on correct data acquisition and real-time data visualization with a little processing thrown in. Think, acquire data, show the raw values as well as the mean value, and RMS noise all on the same windows side-by-side, all of which is easily tweakable with a bit of programming using Numpy and Matplotlib.

One particularly important point to highlight is that of the handling of time-stamping. [Aidan] needed to ensure samples were logged together with a local MCU timestamp so that when displayed and possibly later post-processed, it was possible to accurately determine when a particular value or event occurred. With the amount of buffering, data loss and multiple-thread shenanigans, it is easy to forget that the data might get to the application in a non-deterministic way, and just relying on local CPU time is not so useful.

If you need to visualize data transported over the serial port, we have seen many projects to help. Like the highly configurable Serial Studio, for one. If your needs are a bit more complex, especially with multiple data transport methods, then a Supercon 2022 talk by [Alex Whittemore] might be a jolly good place to start.

Finally! A Typeface For Hardware People

December 4, 2023 by Jenny List 11 Comments

When it comes to novelty typefaces there is no shortage of weird and wonderful fonts to be found when you have finally tired of Comic Sans. Everything from bananas forming letters to Wild West saloon lettering can be yours, plus of course our favourite, the embossed Dymo label. But there’s a new kid on the novelty typeface block, and for us it sweeps all before it.

Scopin’ Sans is as its creator [Guy Dupont] calls it “A typeface for hardware people”, and its party trick is that it doesn’t produce letters. Instead it forms an oscilloscope trace that displays what it would look like as serial data. Instantly your text jumps straight to 1337, and you win the internet.

We have shamefacedly to admit that we don’t know binary ASCII by sight, so we’ll have to take his word for it. But for the curious there’s a demo from which you can amuse yourself creating traces, and if you can’t recognize serial ASCII then the chances are few of the people around you can either. We take our hats off to [Guy], and it’s something we’re sure we’ll use at some point to delight and confuse our friends. It’s not the first font we’ve brought you, here are some more if you come from the bitmap era.

Four jumper wires with white heatshrink on them, labelled VCC, SCL, SDA and GND

Three Pitfalls In I2C Everyone Wishes Weren’t There

July 3, 2023 by Maya Posch 95 Comments

The best part of I2C is that it is a bus that is available just about anywhere, covering a vast ecosystem of devices that offer it as a hardware-defined interface, while being uncomplicated enough that it can also be implemented purely in software on plain GPIO pins. Despite this popularity, I2C is one of those famous informal standards that feature a couple of popular implementations, while leaving many of the details such as exact timing, bus capacitance and other tedious details to the poor sod doing the product development. Thus it is that we end up with articles such as a recent one on the tongue-twisting [pair of pared pears] blog, covering issues found while implementing an I2C slave.

As with any shared bus, whether multi-master or not, figuring out when the bus is clear is a fun topic, yet one which can cause endless headaches. One issue here comes from a feature that the SMBus version of I2C calls quick read/write. This allows for the rapid transfer of some data. Still, depending on the data returned by the slave, it may appear to the master that nothing is happening yet, since SDA is being held low by the slave until the stop condition, essentially locking the bus.

Where things get even more exciting comes generally in the form of what logic analyzers love to traumatically call a ‘spurious start/stop condition’. This refers to the behavior of SDA and SCL, with SDA going low before SCL indicating an error. This can occur due to a hold time that’s too low, causing other devices on the bus to miss the transition. Here SMBus defines a transition time of 300 ns, while I2C calls for 0 seconds, but it’s now suggested to delay calling a start/stop condition until a delay of 300 ns has passed. Essentially, it would seem that implementing a hold time is the way forward until evidence to the contrary appears.

The third pitfall pertains to the higher-speed modes of I2C, including Fast-Mode (FM) and Fast-Mode Plus (FM+). Backward compatibility with these higher speed versions is absent to spotty. Although FM+ (introduced by NXP in 2007) is supposed to be backward compatible with slower speeds, effectively the timing requirement differences between the FM+ and FM standards are too large to compensate for. At least in the current versions of the standards, but one of the joys of I2C is that there’s always another new set of revisions to look forward to.

Interlaken Want To Connect All The Chips

April 17, 2023 by Al Williams 11 Comments

One of the problems with designing things on a chip is finding a good way to talk to the outside world. You may not design chips yourself, but you care because you want to connect your circuits — including other chips — to the chips in question. While I2C and SPI are common solutions, today’s circuits are looking for more bandwidth and higher speeds, and that’s where Interlaken comes in. [Comcores] has an interesting post on the technology that blends the best of SPI 4.2 and XAUI.

The interface is serial, as you might expect. It can provide both high-bandwidth and low-latency multi-channel communications. Interlaken was developed by Cisco and Cortina Systems in 2006 and has since been adopted by other industry-leading companies. Its latest generation supports speeds as high as 1.2 Tbps.

Continue reading “Interlaken Want To Connect All The Chips” →