Reverse Engineering and Replacing an Industrial 7-Segment Display – Part 2, Investigation

This is Part 2 of an N-part series. See also [Part 1].

In part one of this series, we began the process of developing a replacement for the LASCAR EM-4-LED 4-digit industrial 7 segment display. To recap: we mined the display’s datasheet for all it we could, then opened up the device to reveal its component parts and continued to dig into their datasheets until we had a reasonably complete view of the device’s functions. With the research phase complete, it’s time to move into in investigation, and we’ll think about how we might begin to probe an unknown device and its connections more specifically.

Author’s Note: The post has been sitting fully written in my drafts since before things locked-down in mid-March, but was lacking a couple of illustrative screenshots/pictures of the signal-capture process. Since the pandemic’s effects are still dragging on, I’m pushing this post out now with a couple of substitute images – they are noted below where applicable.

A refresher – this is the little display we are attempting to replace.

As you move into the phase of actually powering a device up and testing it, there are a few key parameters to keep in mind. Power and signal voltage levels are key – is this a 5V part, perhaps 3.3V, perhaps 12 or 24 or higher for industrial parts? And even if the device has a high or wide-range power voltage, any I/O ports may be more limited. This is why gathering as much data on-paper first is useful: to avoid letting the magic smoke out of the device-under-test before you get all its juicy secrets out.

Other specs worth keeping in mind are:

  • Voltage level of outputs – can you safely probe all external pins with a TTL logic probe? Do you need to start with an oscilloscope to verify voltage ranges? Or even a multimeter?
  • Output clock rates – does your instrumentation have the bandwidth to reveal useful information.
  • Open-collector vs. current-source outputs – if you’re expecting to see some output (for driving LEDs, relays, etc), do you need to supply external power to see if anything is actually happening?

Since we have this info (fairly) confidently in hand, let’s dive into probing our hardware and see what new things we can learn.

Utilizing a Logic Analyzer

One thing that many folks pointed out in the comments of my writeup of useful electronics bench tools was the lack of a logic analyzer on my list. I confess before this project, I had never used one, nor particularly found a need for one. For many years, my primary electrical hobby was amateur radio (indeed, I had a whole separate blog for ham radio pursuits) – which, as a side note, is also a wonderful place to jump into learning about electricity in a very hands on way. Working in the handfuls-of-megahertz with analog signals, a 25MHz analog oscilloscope  was a much more useful tool than something that operated only on digital logic. But for this particular project, while a scope is useful for verifying voltage levels and seeing whether a signal is present or not, the right tool for the job is a logic analyzer.

The old analog oscilloscope that got me through years of Ham Radio adventures

A logic analyzer is a piece of digital test gear that reads the voltage on two or more input connectors and creates a digital representation of the logic-levels of the voltages present over time. So where a digital oscilloscope records and displays analog voltages over time with some degree of precision, a logic analyzer is only interested as to whether the voltage is above or below a threshold, so as to be a logic high or logic low (typically 0v-12v, 0v-5v, 0-3.3v).

For talking to some other nerds and receiving some feedback online, it seems like the standout stars in the relatively-low-cost logic analyzer space are the offerings from Saleae and the Analog Discovery and Digital Discovery from Digilent. All of the above are modules that plug into a computer via USB for their control and display capabilities, so they cannot be used as stand-alone devices in the field. While some mid-to-high-end oscilloscopes also have signal-analysis capabilities built in – these are often listed as “mixed signal” oscilloscopes –  those are a bit beyond my current needs at the moment. And in fact, while the Digilent products have had my eye for awhile, as a place to get my feet wet with signal analyzers for this project, I wanted to verify that this would be a useful tool before I committed my department’s funding to a few-hundred-dollar purchase.

A fancy Rigol scope with logic analyzer functions – note the multipin connector under the display.

I ended up with a $25 8-Channel Sparkfun Logic Analyzer, which handles 3.3V and 5V signals with a sample rate of us to 24 MHz. This nominally means it can handle digital signals up to about 12 MHz, but in practice, something somewhat lower would be a safer choice. Since the LASCAR display we’re working on has a nominal data rate of 500 KHz, this should be plenty for my purposes.

The basic 8-channel logic analyzer from Sparkfun

The Sparkfun Analyzer seems to essentially be a branded version of the many inexpensive logic analyzers floating around Amazon – all of which pretty much will work with the open-source logic analysis software PulseView, which is itself a graphical frontend for the command line program Sigrok. While PulseView doesn’t allow access to all of Sigrok’s many capabilities, its a significantly more approachable way to get started with these devices in my opinion.

Script to compile and install PulseView on Ubuntu · One Transistor

Pulseview can capture samples and decode them visually for you.

Sparkfun has already written up a great Getting Started with Sigrok, Pulseview, and the Logic Analyzer tutorial, so I won’t try to duplicate their work here. Suffice to say, after getting the software installed, you attach the ground probe on the analyzer to a ground point on the circuit you’re probing, and attach one or more signal probes to the signal lines you’re like to test. After configuring the sample rate at which you want to capture data points and how many points to capture, you “run” the analyzer, which then then a few seconds to minutes capturing the number of points you selected. After capture, you can select one of a number of “decoders” that attempt to turn the individual high-or-low, one-or-zero datapoints into a structured view of what data contained therein. For example, if you’re probing what you think is a serial UART stream, the UART decoder will give you a view of the data as ASCII characters being transmitted over the UART, which is much easier than looking at pure sample points.

Here’s a look at the data and power lines going to the existing LASCAR display:

(Getting this picture has been pre-empted by a global pandemic! A picture will be here when I can get back in the building someday.)

What a nice set of labels! The presence of the clock and data lines matches with our expectations, since last time we spotted a shift-register built into the brains of the EM-32 display. The shift register will “clock in” or take in one bit of data from the data line each time it transitions, either from low-to-high or high-to-low. So we should expect to see these lines changing in alternation – first, the data line will go low or high to establish the next bit of data, then the clock line will be pulled low or high to tell the shift register to take-in this bit of data.

Or at least, that’s what I would expect, given the schematics of the EM-32 that we were looking at last time. Probing the signals will hopefully allow us to confirm this. So, let’s hook up a the signal analyzer’s ground to the GND wire and channels 1 and 2 of the analyzer to the CLOCK and DATA lines, here’s what we capture:

This is a substitute image of a different capture – the actual image is inaccessible due to pandemic conditions. But the capture would look much like this.

The first thing we note is that the data rate here is nowhere near the 500KHz rate that the datasheet says we can tolerate – we’re seeing about 40 bits of data at a rate of roughly 1KHz, in bursts about 10 times a second. So we can turn our data capture rate waaaay down from its maximum 24 MHz. Which is great. Applying the SPI decoder to this data (which has a similar clock-and-data-lines structure to what we expect) allows us to see a view of the individual 1’s and 0’s that make up the stream of bits coming from the PLC.

This is a substitute image of a different capture – the actual image is inaccessible due to pandemic conditions. But the capture would look much like this.

Comparing this bitstream with the timing diagram we saw last time, we thankfully see things lining up pretty well – we can see the initial clock pulse and start data bit, which tells the display to begin expecting data, following by 35 bits of data more. The PLC then pauses for approximately 100ms before sending more data.

The two major takeaways from our logic-analyzer work are:

  • The bitstream coming from the PLC is as-expected given what we learned from the datasheet, and
  • Its datarate is at most 1KHz, in bursts about 10 times a second.

This will help us develop our testing solution – knowing that we have reasonable data rates means that we don’t need to throw anything particularly fancy at this problems in term of hardware.

Reverse Engineering and Replacing an Industrial 7-Segment Display – Part 1, Research

Building one-off hardware is one part inventing, one part dissecting, one part scrounging. When we try to hit that magic mixture of good, fast, and cheap, so often we must rely on prebuilt modules – if we’re trying to build a widget that gets us from zero to 100, it may only be financially/temporarily/technologically reasonable if someone already makes a module that gets us from 0 to 80. Utilizing economies of scale of already-developed parts can bring a one-off project from the realm of fantasy into feasibility.  Often, the solution is to develop a chain of off-the-shelf components that can fulfill the end goal.

But all components have a service life, and a manufacturing lifetime. And when your part goes out of production and then your spares-bin runs dry, sometimes keeping your machine running requires some deeper problem solving. When you work in the public-facing technology sphere (theatre, museum work, retail displays, etc), a lot of the solutions are literally one-of-a-kind, even if they’re constructed from commercial parts.

I recently had the need to replace a very specific module in some equipment. While it didn’t end up being the most high-tech/high speed/highfalutin bit of technology, it presents a good opportunity to talk through how one can approach an unknown part, come to understand its workings, and develop a replacement. So in this N-part series, we’ll look at the process of researching, developing, and implementing a custom one-off solution to a failed part in a unique piece of gear.

The Lascar EM32-4-LED is a four-digit seven-segment panel mount LED display meant for general-purpose data display. Its small digit size (.39″ tall), machined aluminum housing, small footprint (32.5mm diameter punchout) and NEMA 4X/IP67 made it a compact choice for anyone needing to display a single value with 4 digits of precision. It also had the ability to drive four external LEDs, for additional status or process indicators.

Lascar Electronics EM32-4 LED

A piece of equipment I’ve been working on recently had just such a LASCAR display installed a few years back to serve as a timer. I”m going to have to be a little vague about the specifics of the equipment itself, but since this post is focused on technical process and not the piece itself, I think I can safely share enough details for the following to make sense:

The piece is an interactive object that triggers some actions and servos, demonstrates a physical phenomenon, and then takes about 25 seconds to cool back down before can be used again. The user is presented with a green illuminated button to activate the system – when the system is in active or cooling down, the illuminated button turns red. But because it’s not entirely clear from the action of the device alone when it will be cool enough for use, a countdown timer (two digits) is displayed on the EM32 display, counting the number of seconds until we’re good to run again.

Sadly, this particular EM32 display died shortly after LASCAR decided the product hit its End of Life. What’s more, I’m currently without the ability to modify the programming of the PLC that’s driving the whole shebang. In order to maintain the functionality of the piece, it became necessary to build a device that would ingest the existing signals being sent by the PLC, interpret them, and drive a newly crafted 7-segment display of some kind.

The ‘datasheet’ for the EM32-4 is a paltry 2 pages long. Presumably there was additional documentation provided to those who were using the device, but since it’s now EOL, that documentation seems to be unobtanium. But the existing pair of pages does contain some useful information.

We’ll start at the very beginning (a very good place to start): the opening prose paragraph:

This is where we find a high-level overview of the part, it’s intended purpose, and (sometimes) explanations of the differences between any variants of the part. Say, for example, a given part is made in a standard and a mil-spec version, or a normal and a slew-rate limited version, a manufacturer will often encompass them in a single datasheet. It’s important to identify specifically what part you have, so you can characterize it accurately. 

In our case, the EM32-4 is unique enough that there are no major variants. The paragraph mostly tells us what we already know – it’s a 4-digit, 3 decimal point display in a metal bezel. But it does call out the “optional external LEDs.” While it’s unclear at this point exactly what this means, it’s useful to make note of these surprises early on, as they’ll often explain a what-the-heck-is-that moment late in the datasheet.

Moving on then to the next useful block in just about any datasheet; the electrical specifications. This is where you’ll find input-voltage ranges for power and signals, output voltages and timing, and other device-specific characteristics (transistor beta and voltage spreads, op-amp gain and slew rate, power ratings, etc). If I was doing a Double Dare Physical Challenge and had to utilize a part with only one table of its datasheet available, I’d take the electrical specs chart 9 out of 10 times.

In our case, there’s only 6 lines, but 6 important lines they are. We learn that this is a 5V part, but can run at up to 9V so we can’t assume we’ll have 5V power available. Nominal power  usage is ~20mA, so the power available on existing supply lines may be limited. The operating and storage temperature ranges are typical. VLED is a a bit confusing – does this refer to the display itself, in which case we have no real purpose for this voltage? Or perhaps it refers to the voltage available for the external LEDs. 

The final line is promising – that the typical clock input frequency is 500KHz. This is the first we’ve seen any information about how this device receives communication from a controller. But now we know it’s some kind of clocked input (perhaps sometime like SPI?), and that its possible frequency is not unreasonable from something we might interpret with off-the-shelf hardware. Not that 500KHz is a stroll in the park, but it’s not in the many-megahertz range, say.

The last really useful part of the datasheet is the Functional Block Diagram. This block shows a symbolic representation of what’s happening inside the device, as an aid to the user in visualizing what’s happening on the interior and how we need to interface with it. You really only see this with integrated circuits or other modules (the functional bock diagram of a transistor would be… just a transistor).

To highlight the purpose of the block diagram, let’s do a quick comparison between two drawings on another part: the venerable 555 Timer IC. Its datasheet sports both a schematic diagram and a functional diagram; here are the two side-by-side:

This demonstrates pretty clearly the distinct purposes of the schematic diagram versus the functional one. The functional diagram is there to give users a high-level understanding of how the device functions, where inputs and outputs attach, and what the essential parts of the device are. The schematic diagram is there for those who need to really drill into exactly how the chip is built, because of some precise technical reason. When I’m driving a car, I need to know whether the transmission is manual or automatic, two-wheel vs four wheel, and so on – a functional understanding is enough. A mechanic needs a schematic showing the various linkages and gears of my transmission to diagnose and repair issues; holding that level of information in my head all the time would get in the way of the business of driving around.

With that diversion hopefully making clear the purpose of the functional block diagram, let’s check out the one for the EM32-4.

There’s some really good info here! Let’s start with the external connections:

  • We could have guessed V+ and 0V are supply voltage and ground, but this confirms it.
  • The 35-bit shift register is intriguing, and illuminates the purpose of the D (Data) and Ck (Clock) terminals. There’s also an Ē (enable) pin for the data line which is active low (indicated by the bar over the pin name, for “not”). 
  • Since we don’t have direct control over the latches or buffer layer of the shift register, it seems that data will be shown as soon as its clocked in.
    • There’s a weird hanging inverter on the left side of the diagram attached to the output buffers, as if there was some kind of external buffer control possible at some point. How odd.
  • It seems that the  VL pin is on the downstream side from the voltage regulator, so it probably puts out the 3 volts listed under electrical specifications above.
    • This probably means that L1 thru L4 are open-collector outputs, so we have a sense of how we might use the part to drive the external LEDs.
  • Finally, there’s a Reset pin for soft-resetting the data displayed – this would be useful if the end product was configured so the displayed retained power when the controller turned off – the controller could simply reset the display (or many displays in parallel) to ensure that no data was present for a fresh start.

One of the starting placing for replacing this display was the possibility that there might be some driver circuitry driving a generic 7-segment display. If the display itself was still good, perhaps we can simply replace the driver and have a visually identical display. Those hopes were dashed, however, when I opened up the EM32-4 LED to find…

An OEM 4-LED – the power behind the throne – it’s the same product, right down to the block diagram, but in a DIP-style package. The EM32-4, it turns out, is the OEM-4 with a nice aluminum case and terminal blocks. And the back of the OEM-4 is epoxy-blobbed together, so even if we were to break into the thing, there’s a good chance everything is wirebonded all the way to nowhere and back. Reusing the display on this thing is a non-starter.

All is not in vain, however – the OEM-4’s datasheet is a whopping four pages to the EM32’s paltry two. The first two pages are essentially identical (which makes sense, since one is the other in a very real way), but the two additional pages in the OEM-4’s datasheet have four additional juicy diagrams. Starting with a timing diagram:

We can now see in much more detail that, yes indeed, the display is based around an internal shift register architecture, with bits being clocked in and held in the device. We can see that there’s a start bit (“1”) and the 35 data bits we saw in the EM32’s datasheet, so we’ll need to clock 36 physical bits into the device, whereupon it will automatically load the data (presumably into the data latches and output buffer). Then in 30 ns it will automatically reset and be ready The clock timing, which is listed as 500 Khz nominal, can in theory be pushed to 2 MHz if the 500 ns cycle time (250 ns + 250 ns) can be believed. (Not that we’re hoping it’s that high). We can also get some detail about the external reset signals and the data input timing.

Remember, all this sleuthing is with a goal –  not of driving an EM32, but of creating a display controller which takes the place of an EM32 in a specific installation. Any details we can deduce from the datasheets will help us narrow down where we begin with our investigation of the controller itself.

The “applications” diagram gives us a few pointers – not all are useful to our goal, but are interesting nonetheless. As we guessed before, the LED1 through LED4 pins are open collector drivers – but unlike our guess, we actually need to provide the +3 volts for that control from an external regulator, not from the VLED pin. And the typical current should be 2.5mA per LED, so there’s aren’t high-current drivers in any sense. We can also see that the OEM-4 module has an option for external brightness control via a 50kΩ potentiometer, but we don’t have the ability to access those pins on the EM32 unit.

There’s also a sneaky note at the bottom of the diagram that there is a ‘special version’ OEM-4 LED with a built-in 3V regulator and brightness control. I wonder which version we have?

At first blush the circuit diagram appears to tell us what we already know – there’s a shift-register LED driver inside this thing that’s taking clocked data in and driving LEDs on the downstream side. But there are actually two key things to note here – while I had assumed the VLED pin was only for the external LED’s, it’s actually the anode connection for all the segments of the display! This means that connecting it isn’t optional for driving external LEDs, it’s mandatory if we want the OEM-4 to work. Looking back at the block diagram from the EM32, we can understand the purpose of the built-in regulator shown there.

The EM32’s built-in 3V regulator on the EM32.

The second key thing we learn from the circuit diagram is which bits control which segments. But it’s made even more clear in the final diagram from the OEM-4 datasheet: the serial data input sequence:

Now we don’t have to try to deducing the bit-order from what we think the data stream is displaying, we can build that data into our programming from the beginning. Thank goodness, since I’d never actually seen this display in action before I undertook the task to replace it!

This is about as deep as the research rabbit-hole goes, it seems. We’ve found the datasheet for the EM32 module itself, the OEM-4 module inside it, and the PS035 inside that.

In the next post, we’ll start probing the signals coming from the controller, building a version of the display in software, and testing some theories about how the display operates.