Dishwasher Repair Nightmare: Chasing Down 3 Faults

It all started with a vague error code (shown in the image above) on [nophead]’s Bosch SMS88TW01G/01 dishwasher, and it touched off a months-long repair nightmare that even involved a logic analyzer. [nophead] is normally able to handily diagnose and repair electronic appliances, but this time he had no idea what he was in for.

Not many dishwashers require breaking out a logic analyzer and 3D-printed custom adapters, but this one did.

Not only were three separate and unrelated faults at play (one of them misrepresented as a communications error that caused a lot of head-scratching) but to top it all off, the machine is just not very repair-friendly. The Bosch device utilized components which are not easily accessible. In the end [nophead] prevailed, but it truly was a nightmare repair of the highest order. So what went wrong?

One error appears to have been due to a manufacturing problem. While reverse-engineering the electronics in the appliance, [nophead] noticed a surface-mounted transistor that looked crooked. It was loose to the touch and fell into pieces when he attempted to desolder it. This part was responsible for switching an optical sensor, so that was one problem solved.

Another issue was a “communications error”. This actually came down to ground leakage due to a corroded and faulty heater, and to say that it was a pain to access is an understatement. Accessing this part requires the machine to be turned upside down, because the only way to get to it is by removing the base of the dishwasher, which itself requires a bizarre series of awkward and unintuitive steps to remove. Oh, and prior to turning the machine upside down, one has to purge the sump pump, which required a 3D-printed adapter… and the list goes on.

And the E02 error code, the thing that started it all? This was solved early in troubleshooting by changing a resistor value by a tiny amount. [nophead] is perfectly aware that this fix makes no sense, but perhaps it was in fact related to the ground leakage problem caused by the corroded heater. It may return to haunt the future, but in the meantime, the machine seems happy.

It goes to show that even though every fault has a cause and a reason, sometimes they are far from clear or accessible, and the road to repair is just a long slog. Heck, even phones these days can be bricked by accidentally swapping a 1.3 mm screw for a 1.2 mm screw.

Mis-captured signal transitions shown on the screen of the LA104, with problematic parts circled in red.

When Your Logic Analyzer Can’t Tell Good And Bad Signals Apart

[Avian] has picked up a Miniware LA104 – a small battery-powered logic analyzer with builtin protocol decoders. Such analyzers are handy tools for when you quickly need to see what really is happening with a certain signal, and they’re cheap enough to be sacrificial when it comes to risky repairs. Sadly, he stumbled upon a peculiar problem – the analyzer would show the signal glitching every now and then, even at very low bitrates. Even more surprisingly, the glitches didn’t occur in the signal traces when exported and viewed on a laptop.

A Pulseview window showing that the problem is not present in the exported capturesHe dug into the problem, as [Avian] does. Going through the problem-ridden capture files helped him realize that the glitch would always happen when one of the signal edges would be delayed by a few microseconds relative to other signal edges — a regular occurrence when it comes to digital logic. This seems to stem from compression being used by the FPGA-powered “capture samples and send them” part of the analyzer. This bug only relates to the signal as it’s being displayed on the analyzer’s screen, and turned out that while most of this analyzer’s interface is drawn by the STM32 CPU, the trace drawing part specifically was done by the FPGA using a separate LCD interface.

It would appear Miniware didn’t do enough testing, and it’s impossible to distinguish a good signal from a faulty one when using a LA104 – arguably, the primary function of a logic analyzer. In the best of Miniware traditions, going as far as being hostile to open-source firmware at times, the FPGA bistream source code is proprietary. Thus, this bug is not something we can easily fix ourselves, unless Miniware steps up and releases a gateware update. Until then, if you bought a LA104, you can’t rely on the signal it shows on the screen.

When it comes to Miniware problems, we’ve recently covered a Miniware tweezer repair, requiring a redesign of the shell originally held together with copious amount of glue. At times, it feels like there’s something in common between glue-filled unrepairable gadgets and faulty proprietary firmware. If this bug ruins the LA104 for you, hey, at least you can reflash it to work as an electronics interfacing multitool.

Pico Makes Capable Logic Analyzer

A common enough microcontroller project is to create some form of logic analyzer. In theory, it should be pretty easy: grab some digital inputs, store them, and display them. But, of course, the devil is in the details. First, you want to grab data fast, but you also need to examine the trigger in real time — hard to do in software. You may also need input conditioning circuitry unless you are satisfied with the microcontroller’s input characteristics. Finally, you need a way to dump the data for analysis. [Gusmanb] has tackled all of these problems with a simple analyzer built around the Raspberry Pi Pico.

On the front and back ends, there is an optional board that does fast level conversion. If you don’t mind measuring 3.3 V inputs, you can forego the board. On the output side, there is custom software for displaying the results. What’s really interesting, though, is what is in between.

The simple PCB is completely optional.

The Pico grabs 24 bits of data at 100 MHz and provides edge and pattern triggers. This is impressive because you need to look at the data as you store it and that eats up a few instruction cycles if you try to do it in software, dropping your maximum clock rate. So how does this project manage it?

It uses the Pico’s PIO units are auxiliary dedicated processors that aren’t very powerful, but they are very fast and deterministic. Two PIO instructions are enough to handle the work for simple cases. However, there are two PIOs and each has four separate state machines. It still takes some work, but it is easier than trying to run a CPU at a few gigahertz to get the same effect. The fast trigger mode, in particular, abuses the PIO to get maximum speed and can even work up to 200 MHz with some limitations.

If you want to try it, you can use nothing more than a Pico and a jumper wire as long as you don’t need the level conversion. The project page mentions that custom software avoids using OpenBench software, which we get, but we might have gone for Sigrok drivers to prevent having to reinvent too many wheels. The author mentions that it was easier to roll your own code than conform to a driver protocol and we get that, too. Still, the software looks nice and even has an SPI protocol analyzer. It is all open source, so if you want other protocols before the author gets to them, you could always do it yourself.

If you do want a Pico and Sigrok, we’ve covered a project that does just that. Most of the logic analyzers we use these days we build into our FPGA designs.

A light blue marker with a two-pin header replacing the tip, being pressed against the back of the keypad baord that's removed from the safe

Anyone Can Be The Master Of This Master Lock Safe

[Etienne Sellan] got one of these lovely $5 logic analyzers. As with any shiny new tool, he started looking for things to investigate with it, and his gaze fell on a Sentry Safe (produced by Master Lock). On the surface level, this keypad-equipped safe is designed decently when it comes to privilege separation. You can take the keypad board off and access its backside, but the keypad doesn’t make any decisions, it merely sends the digits to a different board embedded behind the safe’s door. The solenoid-connected board receives the PIN, verifies it, and then controls the solenoid that unlocks the safe.

[Etienne] hooked up a logic analyzer to the communication wire, which turned out to be a UART channel, and logged the keypad communication packets — both for password entry and for password change. Then, he wrote some Arduino code to send the same packets manually, which worked wonders. Bruteforcing wasn’t viable, however, due to rate limitation in the solenoid controller. Something drew his attention from there – if you want to change the password, the keypad requires you enter the factory code, unique to each safe and supplied in the instruction manual. That code entry is a separate kind of packet from the “change password” one.

More after the break…

Continue reading “Anyone Can Be The Master Of This Master Lock Safe”

Photo of the spectrophotometer in question, with a screenshot of the decoding software on the right

Exporting Data From Old Gear Through LCD Sniffing

[Jure Spiler] was at a flea market and got himself a spectrophotometer — a device that measures absorbance and transmittance of light at different wavelengths. This particular model seems to be about 25 years old, and it’s controlled by a built-in keyboard and uses a graphical LCD to display collected data. That might have been acceptable when it was made, but it wasn’t enough for [Jure]. Since he wanted to plot the spectrophotometry data and be able to save it into a CSV file, hacking ensued.

He decided to tap into the the display communication lines. This 128×64 graphical display, PC-1206B, uses a 8-bit interface, so with a 16-channel logic analyzer, he could see the data being sent to the display. He even wrote decoder software – taking CSV files from the logic analyzer and using primitive optical recognition on the decoded pixels to determine the digits being shown, and drawing a nice wavelength to absorbance graph. From there, he set out to make a standalone device sniffing the data bus and creating a stream of data he could send to a computer for storage and processing.

[Jure] stumbled into a roadblock, however, when he tried to use an Arduino for this task. Even using a sped-up GPIO library (as opposed to notoriously inefficient digitalRead), he couldn’t get a readout frequency higher than 80 KHz – with the required IO readout rate deemed as 1 MHz, something else would be called for. We do wonder if something like RP2040 with its PIO machinery would be better for making such captures.

At that point, however, he found out that there’s undocumented serial output on one of the pins of the spectrophotometer’s expansion port, and is currently investigating that, having shelved the LCD sniffing direction. Nevertheless, this serves as yet another example for us, for those times when an LCD connection is all that we can make use of.

We’ve seen hackers sniff LCD interfaces to get data from reflow ovens, take screenshots from Game Boys and even equip them with HDMI and VGA ports afterwards. With a skill like this, you can even give a new life to a vintage calculator with a decayed display! Got an LCD-equipped device but unsure about which specific controller it uses? We’ve talked about that!

Continue reading “Exporting Data From Old Gear Through LCD Sniffing”

Screenshot of Pulseview showing capture and decode of some digital channels

Need A Logic Analyzer? Use Your Pico!

There’s a slew of hardware hacker problems that a logic analyzer is in a perfect position to solve. Whether you’re trying to understand why an SPI LCD screen doesn’t initialize, what’s up with your I2C bus, or determine the speed of an UART connection, you’ll really want to have a logic analyzer on hand. People have been using a Pi Pico as a logic analyzer in a pinch, and now [pico-coder] has shared a sigrok driver that adds proper support for a Pico to beloved tools like Pulseview.

The specs offered are impressive. Compared to the $10 “Saleae” clone analyzers we are so used to, this thing boasts 21 digital channels with up to 120 MHz capture speed, 3 ADC channels at up to 500 KHz, and hardware-based triggers. The GitHub repository linked above stores the driver files out-of-tree, but provides build instructions together with an easily flash-able uf2 firmware. It’s likely that you’ll soon see this driver in a stock Pulseview installation, however, given the submitter-friendly attitude we’ve witnessed on the sigrok mailing list. However, if you need a logic analyzer ASAP, you should follow the caringly offered quickstart guide.

We’ve covered Pulseview being used in combination with cheap accessible analyzers before — a must-watch if you need to get yourself up to speed on the value they provide to a hobbyist. If an oscilloscope is what you need and a smartphone is what you have, perhaps you’ll enjoy the Scoppy firmware for the Pico.

We thank [mip] for sharing this with us!

Logic Meter Aims To Make Hobby Electronics Troubleshooting Easier

The basic test instrument suite — a bench power supply, a good multimeter and perhaps an oscilloscope — is extremely flexible, but not exactly “plug and play” when it comes to diagnosing problems with some common hardware setups. A problem with a servo driver, for example, might be easy enough to sort of with a scope, but setting everything up to see what’s going on with the PWM signal takes some time.

There’s got to be a better way to diagnose hobby electronics woes, and if [Bob Alexander] has his way, his “Logic Meter”, or something very close to it, will be the next must-have bench tool. The Logic Meter combines some of the functionality of an oscilloscope and a logic analyzer into a handy instrument that’s as easy to use as a multimeter. The Logic Meter’s probes connect to logic-level signals in a circuit and can be set up to capture or send serial data, either directly to or from a UART or via an SPI bus connection. There are also functions for testing servos and similar devices with a configurable PWM output. [Bob] rounds out the functionality with a GPS simulator and a simple logic analyzer, plus some utility functions.

The beauty part of the Logic Meter is that [Bob] has left where it goes next largely up to the community. He’s got a GitHub repo with details on the PIC32-based hardware, and the video below makes it clear that this is just a jumping-off point to further work that he hopes results in a commercial version of the Logic Meter. That’s a refreshing attitude, and we hope it pays off; from the look of a few of [Bob]’s retrocomputing makeovers, something like the Logic Meter could come in pretty handy.

Continue reading “Logic Meter Aims To Make Hobby Electronics Troubleshooting Easier”