Two Hardware Lessons from the Front Line: PID Loops and Bootloading

About a year ago, we began collaborating with Pura Scents to make their connected fragrance dispenser a reality. Their team had ironed out a concept that people loved, and during a successful Kickstarter campaign, paired it with an aesthetic that sold well. However, they needed next some outside help to bring their connected device to life.

Among the firmware, software, and fleet management aspects were two specific product features with technical intrigue that struck me as worth sharing, firmware/hardware-level features that anyone working within a hardware startup can appreciate. 

Control systems for targeting and maintaining temperature (or speed, or anything)

Imagine driving a car with cruise control. How annoying would it be if your car accelerates a bit beyond the target cruise speed then coasts for a moment or two before physics rears its ugly head and your car drops below the desired speed again? This, of course, necessitates another bump in acceleration and thus the cycle repeats. Accelerate, coast, accelerate, coast. That would be annoying and also terribly inefficient.

A better solution is to maintain effort. This, more or less, is what you’ll find written among the first few pages of a process engineers playbook for this situation: proportional–integral–derivative (PID) control.

Instead of turning a heater on whenever the temperature for a fragrance dipped below its optimal burn temperature, we integrated and tuned a PID loop to gradually do that for us. What that actually looks like in practice is a bit of math to determine exactly how much effort to ask from the heater in order to get the temperature back to where it needs to be. However, this approach has one huge negative: it costs more. How?

For PID loops to work, they need to have a reliable feedback mechanism. For heaters, that might look like a custom ceramic heating element that incorporates a thermistor with a wiring harness or pigtail terminating with a JST or similar tag connector. These components add to the bill of materials (BOM) and increases assembly and QA cost. But is the extra cost necessary?

For Pura, we could just as easily map a heater’s level of effort with a temperature to target and maintain an ideal temperature for each fragrance. This meant we wouldn’t need to include any feedback mechanisms in the device. Pura explored the benefits of both approaches (to PID or not to PID) and ultimately decided the performance gain wasn’t there… it didn’t contribute to a fundamentally better product and would cost consumers more.

Lesson: PID loops can be designed and tuned to adjust systems from one state to another. However, their benefits may come at a cost, and those benefits may be easily replicated through some wit.

Bootloading for liquid level sensors

Product engineers are incorporating self-capacitance buttons into an increasing number of products. From my perspective, the uptick is justified because they solve two major problems: 1)They are affordable and 2) do very well in water or dust ingress-prone environments. They  are also relatively straightforward circuits with detection areas that can be etched onto PCBs (and optionally controlled with dedicated SOCs that abstract many software-level complexities). Perhaps best of all is their flexibility. Capsense sensors can do far more than just detect the presence of a finger. They can also detect the presence of liquid.

Pura wanted a way to approximate the amount of liquid remaining in either of their two fragrance vials at any time. Like your finger, fragrance oil also has a capacitance. This creates a straightforward path to design a circuit providing some granular amount of liquid-level detail. So, instead of worrying about how the product might change over time, or in what extremes it would need to operate, Pura focused on designing firmware that was both flexible and completely upgradable.

Because the Pura device was connected to the internet, we had the ability to write firmware that was remotely upgradable. For consumers, this enables Pura to continually improve their existing products over time. However, the peripheral chips do not directly have connectivity, but may likely require an upgrade in the future. While it would have been cheap and easy to ship devices with “one and done” capsense sensors that were forever locked into their firmware ways, Pura decided to invest early in a bootloader that enabled their capsense chips to be forever upgradable. And, this investment has already paid dividends. During an initial beta period users helping to improve the device were provided with remote capsense updates to improve fragrance level-readings which, in turned, informed changes to the mobile app.

Lesson: Peripheral devices need bootloaders too. Save yourself from future regret and invest early in compatibility. Never expect a first solution to be the best solution a year from now.