The Puft management firmware is written to utilise all aspects of the custom hardware, designed to control aftermarket air suspension assemblies, implementing functionalities to ensure the smoothest interactions between the user, the Puft Mobile Application, and the vehicle itself.
The firmware is implemented in C and object-oriented C++ atop FreeRTOS, utilising both the Arduino and ESP-IDF frameworks for increased code readability and maintainability; with integration of the GoogleTest and GoogleMock frameworks for unit testing and test driven development.
Before development could begin, it was necessary to construct a list of high-level requirements for the minimum viable product. Due to the length of this requirement list not all will be discussed here, however a subset is as follows:
In order to implement the firmware with as much flexibility as possible, a basic implementation architecture was devised. This outlined that firmware ‘modules’ are to be split between both of the Espressif ESP32-S3’s cores utilising FreeRTOS’s tasks. One running regardless of the system’s current state, the other running the necessary modules dependent upon the system’s current state. This allows communications channels to remain functional, even if current interactions on the parallel core are potentially blocking.
Currently connected devices are determined by two things: a confirmed hardware connection, and a completed Puft proprietary handshake process. Only when a device successfully passes both criteria is deemed authenticated and able to interact fully with the system.
Commands generated by the user via any of the three possible communication channels: Bluetooth, UART, or RF, are decoded, determined to be valid, and then added to an internal queue. This serves the purpose of serialising the commands, as the system acts upon them in the order they’re received, eliminating potential race conditions. It also allows all of the currently connected devices to receive return values generated by one method of user input, synchronising the interfaces.
System configuration is gathered from the flash on a cold-boot and stored in RAM. From then on during regular operation configuration values are fetched from their place in memory as they are requested either by various modules in the system, or by the user. When the same configuration values are requested to be updated, the new values are written both to the current value in RAM and updated in flash with automatic wear-levelling. This ensures that if for any reason there is a failure with the non-volatile storage used for the configuration, the updated value can be used until a hard reboot occurs.
The implementation of automatic adjustment to preset pressures required monitoring and smoothing of the values from the ADC, taking readings at varying update rates depending upon whether the system currently has solenoids in operation inflating or deflating the air bags. This ensures the most up-to=date reading possible for accurate adjustment, but also ensures that the displayed pressures are stable during regular driving conditions.
However, due to rapid spikes in the pressures measured for corners of the vehicle that have their respective solenoids activated, it was not possible to use the readings directly to determine if a preset had been attained, even with the additional smoothing, as the settled values were significantly lower than the target. This resulted in ‘valve pulsing’ and an increased period of adjustment while the system alternates between over-inflation and under-inflation. The aforementioned spikes are also not consistent across vehicles and cannot be eliminated by a simple offset value due to the variation in components across install’s. For example, some vehicles may use 10mm air line and single bellow air bags, whereas others may use 6mm air line and double bellow air bags.
Combatting this was particularly challenging as ensuring the quick and accurate adjustment to target pressures when the user selects a configured preset is a central feature of the product. To ensure this requirement was met, it was necessary to create a method through which any vehicle’s unique characteristics could be captured and used during the adjustment calculations.
After many inflation and deflation cycles of a development vehicle’s suspension were undertaken, correlations between the data’s characteristics began to appear. Testing of these correlations confirmed their accuracy, and from there a full calibration procedure was built that exercises each interconnected variable of the suspension, records the outcomes, and builds a vehicle profile. A full calibration of the system can take up to 15 minutes and results in rapid, accurate adjustment directly to the target pressures, and can pre-determine through the use of the current system pressures whether a target pressure is attainable before adjusting.
The development of the firmware remains ongoing, with updates pushed as features are added through the various channels defined by the Puft OTA Web Server.