Category Archive : Electronics

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)

Software:

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:

PCB design
PCB design 3D model

Todo’s:

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.

Links:

The schematics and PCB design can be found in the download section.
The code is on GitHub.
The portal can be found at https://camperlogger.tarthorst.net/.

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