New Mainboard, New Features (V2.0)
Car Computer + HUDOver the course of 2021 I have reliably been using the "first" proto board and firmware for the car computer (A.K.A. the S.B.O.S - A.K.A. Shit Box OS). It's proven to be surprisingly reliable, with quite a few kilometers (3000km+ since July 21') and hours of use. I say quite a few, because there is no way to really know since saving odometer readings was a manual process, one I forget to perform regularly.
Hardware Changes (V2.0)
This round of updates revolved around major hardware changes to the system. Most of the software changes I wanted to make were reliant on a few key additions to the main PCB. To add these, and improve the reliability of the system, I decided it was time for version 2.0 of the PCB. Version 1.3(ish) was never meant to be a long term solution. It has been added to over the last few months in ways that could only be described as janky (see figure 1). This board used standard DuPont connections, which are non-locking, and with vibration can loose a solid connection or even come loose. I was starting to experience some missed i2C commands which were triggering accidental joystick communications and turning on the roof mounted lights, not okay at all.
So what has changed? I have added 3 key new features to the main board. First is a higher quality PCB, second is a real-time clock module, and third are JST style locking connectors to remedy the unreliable Dupont connections.
Bigger, Better PCB
Real Time Clock Module
Why?
Up until now, I have pulled time data from my GPS module. While this is very accurate, it is only available once the GPS locks a few satellites. This means on start up there is no accurate time, which is pretty annoying. It also means I can't use the time to trigger functions, or to use in data logging applications. Having a constant reliable source of time will be a big advantage.
How?
I have added a DS3132 real time clock module to the main PCB, which communicates with the ESP32 via i2C serial communication. Simple enough to add in hardware, it caused me some headaches in the software side due to an i2C address conflict with the MPU501 gyroscope and accelerometer package. This was fixed with a small hardware patch on the MPU module by adding a jumper from positive to the AD terminal which changes the i2C address of the chip. Without this feature I would have had to find a different hardware solution for either the RTC or Gyro module since this address is baked into the chip.
JST Connectors
Why?
Previously all my data lines were connected with Dupont connections. These are meant more for development on the bench rather than real work use. They don't lock which is important to keep a tight connection in automotive applications like this. Akin to the Dupont connections, JST connectors require crimping. I spent a few hours in the truck cutting the old connectors off, stripping the tiny 28AWG wires, and adding the new crimps. I may redo some of these connections to add some better strain relief to the cables as currently I feel they could be a bit better.
Voltage Divider, Screw Terminal
I snuck in a voltage divider on the underside of the board. I wanted to read the input voltage, so I simply tapped in to the input side of the buck converter (the little board seen above the resistors), which steps the voltage down from the 12-14V from the vehicle, to a nice steady 5V. The EPS32 doesn't read analog signals perfectly linear, so it's not really an accurate representation of the voltage without some good math. I'm using this mainly to autosave any preferences in the code and non-volatile values like overall run time, and the odometer feature.
I also added a screw terminal for use with ferrule crimps, a nice clean and secure way to attached power. Previously a barrel connector was used.
Software Developments
Voltage Sensing + Autosave
Vehicle Voltage Sensing (VVS) is a real milestone because it involved creating a new proto board with a voltage divider on the power supply, allowing me to add autosave functionality on power off. This is key to logging GPS odometer readings because they are stored in non-volatile storage (which can only endure X amount of reads and writes, essentially killing the boards long term storage ability in no time at all). I need non-volatile storage so I can store the odometer value when there is no power to the ESP32 chip which runs the system. By having it save only when the board looses power from the vehicle, I can program it to save once per use on power off.
Time + Logging +Triggers
After VVS and autosaving code, I developed another feature I've been wanting for many months; a real time clock (or RTC for short). This is another hardware and firmware upgrade. Up until now, I've been using UTC time supplied by the GPS module. This is fine once the system is up and running with a solid lock on a few satellites, but it's not so great if you just want to know the time all the time, or when you power your vehicle on in a parking garage (like I do everyday). The RTC module has an onboard button cell battery which allows it to keep time in a low power state. Once powered up the SBOS mainboard reads from the RTC via I2C serial communication and boom, accurate time, all the time. But isn't GPS supplied time more accurate? Yes. So I wrote a few lines of code which updates the RTC with the time from the GPS once per on cycle. Once the GPS establishes time link, it updates the RTC once and then leaves it be the remainder of the on-cycle.
Display Dimming Control
Now for the final big feature I'm actually quite proud of. Display Dimming Control (DDC). This may seem trivial and boring, but I assure you reader, it is not. I use a white OLED display with an SSD1306 chip driving it. These displays are ubiquitous in the world of hobby electronics and Arduino specifically (Mine is a 2.5 inch rather than the standard 0.96 inch, however it uses the same driver, the 1306). If you know anything about these displays, you will know they are not easy to dim, specifically when you are using the U8G2 display library for it. I scoured forums for hours trying to find how to do this, since it is not directly supported in the library, and even then I had to use trial and error to find the right combination of values to do this. It requires you to use registers to write directly to the SSD1306, to modify the brightness, and the pre-charge variables. With a combination of the two, I can get the display MUCH darker, making night driving a more pleasurable, less squinty experience. To be fair to the OLED, because it has no backlight, the glare was reasonable for most lighting conditions, only getting bad on long drives on DARK highways.
Now that I have all these new acronyms (VVS, RTC, DDC), S.B.O.S. is that much closer to what I had envisioned so long ago. These feature allow me to implement all sorts of new time based tools, like a run time counter using the RTC, which saves it's value on power off with the new VVS ability. I can also set auto-on headlights at sunset, and dim the display after dusk and before twilight.
