Custom hardware designed to interface with the necessary components to control aftermarket air suspension fitted to modified vehicles, controlled by the Puft Mobile Application via Bluetooth Low Energy, BLE.
The schematic design and PCB layout has been continuously evolving through multiple years of development. Beginning its life as a carrier board for an Android Nano sporting an Atmel ATMEGA328P before settling into a fully custom, dual-board PCB design utilising an Espressif ESP32-S3.
As a minimum viable product, it was necessary for the hardware to undertake the following:
Although these basic hardware requirements result in a fully usable product, they didn’t go far enough to establish Puft as unique in the marketplace. To combat this, the following additional requirements became paramount before the hardware was satisfactory to be released:
As aforementioned, the Espressif ESP32-S3 was chosen as a suitable microcontroller to implement around due to its adequate amount of available GPIOs, built-in wireless technologies for both BLE and WiFi, and ability to perform OTA updates integrated into Espressif’s ESP-IDF development framework. The remaining wireless communication, 2.4GHz RF, was selected to be implemented via an additional Nordic Semiconductor nRF24L-series wireless radio, interfaced to the ESP via SPI.
The choice of microcontroller did come with drawbacks however. Despite the adequate number of built-in analog-to-digital converters, ADCs, to connect 5 pressure sensors. The ESP’s ADCs are non-linear in nature, resulting in complex calibration procedures to be completed on each device, and even then the compensated linearity is not guaranteed to be accurate. To mitigate this, an external 12-bit SPI ADC and supporting components were selected to provide stable, accurate, and linear readings as a solid base for the core functionality of the product.
Two power regulation circuits were implemented. One buck converter to step the variable 11-14V input from the vehicle down to 5V and mitigate any potential spikes during engine cranking, feeding both the external ADC and pressure sensors, and one 5V to 3.3V low-dropout regulator with supporting smoothing capacitors to supply the ESP32-S3, nRF24L, and various other supporting components throughout the board. Battery voltage monitoring was achieved via clamping diodes and voltage dividers.
As the 12V rail used to supply both the solenoids and the compressor relay is available to the management, it was possible to implement low-side switching by directly interfacing the ESP32’s GPIOs with suitably rated N-channel MOSFETs. Supported by current limiting, and pull-down resistors, and a flyback diode to eliminate any sudden voltage spikes due to the inductive load.
12V from the vehicle’s ignition and the user customisable input are converted to 3.3V before being fed into the ESP32 via two N-channel MOSFETs. The use of two MOSFETs allows the logic level HIGH/LOW to directly reflect that of the input, and allows the ESP32 to be woken from sleep via one or both inputs as the ESP32 only supports wake from multiple sources on ‘all low’ or ‘any high’.
User customisable outputs are direct 3.3V GPIO from the ESP32. This implementation was chosen to provide as much versatility as possible, allowing the outputs to become basic GPIO, I2C, or UART as necessary to interface with supporting products.
LEDs are WS2812B, with their ground plane being switched by another N-channel MOSFET to ensure minimal power usage while the ESP32 is in sleep mode.
Considering the management’s intended installation location, in show builds where the management is intended to be visible and worked into a larger display, and hidden install’s where the management will be tucked away behind various trims, the optimal size for the enclosure was determined to be 100mm by 60mm. With this measurement in mind, and wanting to leave clearance inside the enclosure itself, the size constraints of the PCB worked out to be 88mm by 48mm. With components shared across two stackable PCB’s, and the pressure sensors contained within their own separate enclosure, there was plenty of area to fit everything onto 2-layer PCBs.
Board bring-up was a relatively straightforward process due to the ‘breadboard’ prototype’s and the iterative nature of the schematics and PCBs evolution. The test firmware written to exercise hardware functionality ensures any issues are found rapidly, intentionally, and are reproducible. Only finding a single dry solder joint on a pulldown resistor to be the source of a minor solenoid control issue, identified via the use of an oscilloscope to check logic levels were as expected by the debug output of the firmware.
The end result was an easily serviceable, fully featured product platform containing enough hardware so as to not constrain future firmware expansion into unique functionality, setting the product apart from similar products on the market.