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.
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.
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.
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.