Category Archive : Electronics

I like to repair broken electronics. I buy (or just collect) broken TVs, subwoofers, amplifiers, and the occasional power tool. I repair and sell them. Or throw it away if the item is (economically) beyond repair. It is a nice way to spend my time, especially since I now have more of that for obvious reasons. So when a friend told me a while ago his (rather expensive) subwoofer stopped working, I volunteered to take a look at it.

It looked like a straightforward problem. The unit gave no sign of life whatsoever and it had a blown fuse. Blown fuses are typically the result of a malfunction, rather than the cause. This fuse was not just blown, it was completely black, indicating something was shorting out.

After opening the unit up, it didn’t take me very long to diagnose the problem. The Switched-Mode Power Supply (SMPS) had a faulty rectifier diode in the secondary circuit which, in turn, led to the early demise of another diode and two MOSFETs. Both MOSFETS were shorted internally, explaining why the fuse was black. I ordered the parts on eBay (the local electronics shop was closed due to COVID, or at least I thought it was) and put the subwoofer aside for now.

When the parts arrived, I was confident the subwoofer would soon be in working order again. I was wrong. After replacing both diodes, MOSFETs, and the fuse I slowly turned up the voltage using my variac until the magic smoke escaped. What happened?

One of the capacitors in the secondary circuit nearly exploded. The good news was the SMPS was apparently working again, but why did the capacitor die? Apart from old age and/or bad quality, there are really only two reasons for an electrolytic capacitor to blow: Too much voltage or reversed polarity. My muli meter indicated the latter.

I had no schematic of the SMPS, nor could I find it online. So I had to reverse engineer it. Luckily the secondary part (where the problem obviously was) was simple. Basically, just the secondary winding of the transformer (the center of it connected to ground) and a full bridge rectifier made up out of two double ultra-fast recovery diodes in a TO-220 casing.

At this point, it was apparent to me both diodes should be different. But both had the same type number printed on them (MUR1620CT) and both had the same symbol printed just above the leads. Two diodes with their cathodes towards the middle pin of the TO-220 casing. That must be incorrect. But how is that possible? Before it died, the unit had worked for quite some years.

I was confuzzled. The power supply unit couldn’t have worked when both double diodes had their cathodes connected to the center pin. One of them should have the anodes in the middle. I decided to put the ones I took out under the microscope again and take another look.

That’s when I found out one was a MUR1620CT, the other one was a MUR1620CTA. When I first looked at the diodes to identify them, I totally missed the last A on the second one. The type number was the same, the symbol below the type number was the same (two diodes with their cathodes connected in the middle), so I figured both diodes were the same. They weren’t. According to the datasheet, the ‘A’ indicates the anodes are connected to the center pin, not the cathodes. That made a lot of sense.

I ordered some parts again and I’m quite sure the problem will be solved after replacing the diode and the electrolytic capacitor.

So, lesson learned: Do not trust schematic symbols printed on components.

This is what a proper MUR1620CT / MUR1620CTA pair looks like. Note the different symbols on the CTA version:

I have been looking for a good way to measure the amount of propane left in the tank in my RV. It turns out the manufacturer of the tank sells a gauge that can be easily fitted to the tank by replacing the old, non-electric one. How the sensor works is beyond the scope of this blog, what’s important is that the sensor has a variable resistance: 0 Ohms means the tank is empty, 90 Ohms means the tank is full (at 80%).

Of course, the manufacturer sells a display as well, but I wanted to connect the tank level sensor to my already existing ESP32-based logger. So I needed a way to measure resistance with a microcontroller. The most common and easy way is by pulling up an analog input of the controller and connecting the sensor between the analog input and ground, like this:

R2 is the sensor. It has a value between 0 Ohms and 90 Ohms. In order to be able to use the full range of the ESP32’s Analog to Digital Converter (ADC), Ohm’s law dictates that R1 should be 46 Ohms. We need 3.3V over R2 if it is at its maximum value of 90 Ohms. Therefore we need a current of 3.3/90 = 36.7mA. The voltage over R1 should be 1.7V (5V – 3.3V), so the value for R1 needs to be 1.7/0.0366 = 46 Ohms.

This solution is easy and cheap, but it has the disadvantage that the voltage at the analog input pin of the ESP32 (and thus the measured value in the software) is not linear to the value of R2 and therefore not linear to the amount of propane left in the tank.

This is due to the fact that if R2’s resistance changes, the current flowing through both resistors changes as well. This becomes clear if you look at the table below:

Tank levelResistanceVoltage% of voltage
0%0 Ohms0V0%
25%22.5 Ohms1.648%
50%45 Ohms2.472%
75%67.5 Ohms2.988%
100%90 Ohms3.3V100%
Output voltages of the voltage divider network at different tank levels.

As you can see, the behavior is not linear at all. Of course, this could be fixed in the software running on the ESP32, but the non-linearity makes the readings on one end of the range less accurate than on the other end.

Since the problem lies in the fact that a change in the resistance of R2 does also influence the current flowing through the circuit, I decided to solve this issue by using a constant current source. Building one is easier than you might think. Take a look at this circuit:

Measuring resistance with the help of a constant current source.

For now, just forget about C1, C2, and D1. I will get back to those later. U1 is a standard voltage regulator. It regulates it’s output voltage to a constant 5V, regardless of the output current or input voltage. This means that the voltage across R1 will always be 5V. R1 has a fixed value, therefore the current through R1 will be constant as well. Since R1 and R2 are in series, this also results in a constant current through R2.

To calculate the value for R1 we use Ohm’s law again. We still need the 36.7mA current through R2 to get 3.3V at full scale. 36.7mA at 5V means 5/0.0367 = 136 ohms. I’d use the next higher available value because in practice the current will be a little bit higher due to U1’s own power consumption.

With the current through R2 now being constant, the voltage at the input of the ESP32 will be linear to the resistance of R2 and thus linear to the propane level in the tank.

So what’s up with C1, C2 and D1?

First the capacitors C1 and C2. They keep U1 from oscillating. D1 is added as a safety measure. Because of the voltage drop between the input and the output of U1, the supply voltage needs to be higher than 5V. I use 12V in this example, but anything between 7V and 40V is fine. If R2 is for some reason disconnected, this would cause a voltage of around 9V on the input pin of the ESP32, which will probably destroy it.

If you would like to learn more and fiddle around with Ohm’s law and voltage divider networks, take a look at this page.

A few weeks ago, I was browsing on one of those Chinese websites (I’m not mentioning names) when I came across some parking sensors. A set of 4 sensors, controller, display unit and a hole saw to make the necessary holes in the rear bumper would set me back only €15. The ’99 Volvo I bought for the Carbage run didn’t have any parking sensors and I was curious about this set, so I decided to order it.

A few weeks later, the package arrived and I installed it. The hardest part was to find a suitable route for the sensor cables. The rear bumper is filled with this foamy material, which makes it hard to get the cables through. Once that was done, I hooked up the controller to the reverse light wires. In that way, the sensors are only active when the car is in reverse. I put the display unit on the dash (I have yet to find a suitable place for it) and that was basically it. It just worked. So this is going to be a short post about €15 well spent 🙂

Since we’re carbage running as team Fred & Wilma, I figured we needed a soundboard. You know, Fred screaming “Wilmaaaa!”, the distinctive sound of Fred driving off in his car, Wilma laughing, etc. And some of these sounds should be played automatically, for instance when disengaging the handbrake.

I experimented with playing audio directly trough one of the ESP32’s DACs, but for some reason, I could not get the sound quality up to an acceptable level. If you want to take a shot at it: be my guest. You will find some pointers here. I choose a different solution: An external audio decoder board based on the UDA1334A chip. It takes data via I2S and can be bought from Aliexpress, eBay, Banggood, etc.


Here are the most important features:

  • Voltage regulator, so the board can be powered directly from the car battery (with reverse polarity protection).
  • Two 12V tolerant digital inputs. These can be used to trigger the playback of a sound if the lights are switched on, the handbrake is disengaged etc.
  • An analog input. This can be used to connect multiple switches. If every one of these switches has a resistor in series, the software can tell which one is pushed by reading the value of the analog input.
  • A relay. This may come in handy to power on an external amplifier or to switch on some light effects whenever a sound is being played.
  • Audio output, of course. In stereo.
  • ESP8266 MCU. Since the audio decoding is now done by a dedicated chip, there is no need to use the ESP32. The ESP8266 is fast enough. The NodeMCU boards have 4MB of flash memory. 1MB will be used for the software, the rest is available for audio samples.

I have a working proof of concept, I am still working on the software. Currently, the software plays only .WAV files and I would like it to handle .MP3 as well. After all, 3MB of SPIFFS is not a lot if you are using uncompressed audio files.

Carbage run soundboard PCB (back)

A few notes on the PCB design:

  • The NodeMCU dev board appears to be available in two variants. One has a square FTDI chip, the other one has a rectangular one. The footprint used in the design is for the smaller ones with the square FTID chip. The larger one will fit (and the connections are all in the same place), but the electrolytic capacitor is in the way. If you mount the NodeMCU board first, you can mount the capacitor a little bit to the side. As you can see in the picture above, that is what I did, because I didn’t realize the footprint I used was for a differend NodeMCU board than the one I had.
  • I used a cheap UDA1334A breakout board I got off eBay. It seems to be the same as Adafruit’s “UDA1334 I2S DAC”. The only difference I noticed is the color of the PCB. Both versions should work.
  • I used the breakout board rather than the chip itself (and some discrete components) in my PCB design to make it easier to assemble.


A couple of years ago I bought a coach and converted it into an RV. After the first season, I parked it and hooked up a battery charger to keep the batteries charged during winter. When the winter was over, I found out that the charger blew a fuse and my batteries were dead. I decided to add some monitoring. I bought a Victron BMV 702 battery monitor (which has both a display and a serial connection), hooked it up to an ESP32 microcontroller and started fiddling around with it. Soon the project exploded. I hooked up a couple of DS18b20 temperature sensors, my Victron MPPT solar charge controller (which has a serial connection as well) and a cheap GPS module I bought off eBay.

Hardware specs:

ESP32 dev board (NodeMCU-32S)
  • ESP32 microcontroller (with built-in WiFi)
  • USB connection for programming/debugging
  • Power input (5V)
  • 2 Optically isolated serial inputs (for Victron VE.bus)
  • 1 Non-isolated serial input (for GPS receiver)
  • “1-wire” I/O (for Dallas DS18B20 temperature sensors)
  • 3 General purpose I/O’s (can be used as digital input or output, analog input, PWM output, RS232. I2C etc)
  • 2 Onboard relays (dry contact outputs)


The software is written in C++ using the Arduino IDE.

Current software features :

  • Reading and parsing of VE.bus messages from a Victron BMV series battery monitor.
  • Reading and parsing of VE.bus messages from a Victron MPPT solar charge controller.
  • Reading various temperatures (inside, outside, hot water, etc.) using up to 10 Dallas DS18B20 1Wire temperature sensors.
  • Reading and parsing of NMEA data from a GPS receiver.
  • GPS location upload supports both GeoHash and Lat/Lon.
  • Reading a resistive tank level sensor.
  • Measurements can be uploaded to a server using http(s) GET.
  • Measurements can be written directly to Influxdb. Both http and https are supported.
  • Switching on the 24V to 12V DC/DC converter to charge the 12V battery if the 24V battery voltage is above a certain level. Switching of if the voltage drops below a certain level. The DC/DC converter is switched by one of the two onboard relays. 24V battery voltage measurements are read from the Victron BMV battery monitor.
  • Data upload is encrypted (HTTPS).
  • Over-the-air software updates (OTA). New software images are automatically downloaded on a seperate partition of the flash memory and verified. If verification is successfull, the ESP32 automatically boots the new image. Both upgrades and downgrades are supported.
  • Most settings (WiFi SSID and password, Influxdb hostname, username/password, what measurements to write etc) are configurable through the web interface.
  • Settings are stored on a separate partition of the SPI Flash File System (SPIFFS) and are therefore not lost after a software upgrade.
  • Measurement collection runs in a separate background task.
  • All measurements can be downloaded directly from the web interface in JSON format.
  • A portal is available for those who do not want to set up their own server for software updates etc. When using the portal for management, data can still be written to your own Influxdb instance.


PCB design
PCB design 3D model


None of the items on my todo list require any hardware updates. Luckily the ESP32 is flexible enough to facilitate all the things I thought of after I had the PCBs produced. Until now, at least 🙂 This is mainly because of the built-in matrix switch which allows you to assign any function (like UART RX, UART TX, digital in, digital out, analog in, PWM out) to any IO pin.

  • Add an extra temperature sensor to measure the temperature of the water heater. No extra I/O’s needed, extra sensors can be connected parallel to the existing ones since every DS18B20 sensor has a unique address.
  • Make the resistive tank sensor configurable.
  • Finish the portal.
  • Tweak the “12V charger on/off” criteria.


The schematics and PCB design can be found in the download section.
The code is on GitHub.
The portal can be found at

The live telemetry page of my bus can be found here.
I visualize the data using Grafana.