A word from our Head of Product Engineering...
Brava is an inspiring place to work. It is a community where brilliance, inventiveness and attention to detail are held in the highest regard. It's a place where persistence, in the face of great challenges, is truly rewarded.
In this post, I'll tell the story of one of our biggest challenges encountered during development. If this sounds like the kind of problem and the type of solution-oriented collaborative teamwork you're looking for, please take a look at the available positions on our Software: Device & Technology team!
Understand when the solution really needs complexity
In general, good engineers keep designs as simple as possible. Great engineers are able to make designs even simpler, smaller, use fewer or cheaper parts, or less code and memory. Once in a while, however, there's a problem that no elegant reduction of complexity can address. When one of these comes along it's sometimes necessary to "spend complexity" on solving it. Two years into my tenure at Brava we encountered one of these problems with our power control system.
We noticed this problem by operating a Brava Oven prototype in a routine manner with a power-monitoring device that measures the operating current, voltage and other details at the power cable. The Oven is designed to make the power levels delivered to food highly consistent for every use, independent of the available voltage at the outlet (which in North America can vary by -5% to +5% of nominal.) Unfortunately, the variation in performance of this test was about 15%, and it was consistently off the mark every time. The Oven had been carefully tested and verified at the Brava HQ in Redwood City, CA, and was now being operated in Texas. In both locations the utility voltage was noted and checked - both were within specification. We decided to ship the Oven back to California and duplicate the circumstances in our lab with the aid of a variac (a device that transforms AC voltage.) Surprisingly, the Oven did not show the ~15% variation. Moreover, attempting to duplicate the environment more closely (in-wall wiring resistance, ambient temperature and so on) did not reveal the variation either. We were perplexed - what could it be?
This problem bothered us significantly, but it didn't prevent our normal product- and feature-development work, so a dedicated team continued to investigate it. We sent a different Brava Oven to Texas. We sent other Ovens to other places. Soon, we discovered there was another location, in Arizona, that showed the same type of problem but with a different consistent deviation. After that, the team found some places in California that showed similar consistent performance offsets. What could be going on?
At Brava, we have a high level of cross-functional integration between engineering teams. Mechanical engineers use oscilloscopes and write code. Software and electrical engineers fabricate brackets and optical test articles. To tackle this particular problem we gathered all three disciplines to build a portable power measurement device which could *safely* capture AC waveforms on an oscilloscope, then transfer the waveform data to a PC and process it in MATLAB. With these measurements, we began to see the problem right away - the shape of the AC wave of utility power looked totally different in these various locations! Though we knew at design-time that utility waveforms would not be perfect sine waves, we underestimated just how far it could stray and how much it could vary at different locations in the country. Moreover, we realized that we are very lucky to have very close to a pure sine wave at Brava HQ, so we did not come across this issues in development.
Up to the time we discovered this issue, the Brava Oven only measured the peak amplitude of the AC waveform. We determined that we would need the electronics to sample more than just the peak. Perhaps if we could classify the wave into a few categories, such as "pure", "third-harmonic distorted", "fifth-harmonic" and so on, then we could adjust the time components of recipes accordingly. This would be the simplest solution we could get away with. Unfortunately, our culinary development team reminded us, the chemistry of cooking doesn't tolerate arbitrary trade-offs of time and power, not even +/-15%.
If that wouldn't work, we should look at the next lowest-complexity possible solution. How about classifying the waveform - as above - and keep time components the same but adjust the heater power to counteract deviations? Unfortunately, the control scheme we use, combined with the inherent physics of our Pure Light CookingTM heaters, meant that such a solution would be excessively difficult to generalize. We confirmed this with simulation in MATLAB.
What's the next-simplest solution that has a chance of succeeding? Our benchmark implementation, in MATLAB, used the discrete calculus approach of integrating the captured voltage and current waveforms to compute the real power signal. Would we have to do the same in production hardware? The thought alone was worrisome, as our real-time control hardware wasn't designed to handle this workload. It had neither the CPU nor memory resources, and even if we upgraded the microcontroller, it ran on a special low-standby power supply which didn't have the capacity to supply more current to a more powerful chip.
Our Finest Hour
Soon we realized that we had exhausted all simpler possibilities, so we had to take the plunge and put the calculus on the chip. We adhered to the principle of picking the simplest and most elegant implementation, and the team put in a huge effort to find a solution that would meet both the product objectives and consume the least additional (re)engineering time. I'm delighted to say that the "strike team" assigned to the problem devised something that would run on existing hardware with only one component value altered. Their solution not only makes performance consistent across all expected waveforms but also builds a comprehensive power measurement system into the product which we can use to ensure the problem is solved for good.
I'm extremely proud to say that this is not the only time the engineering teams at Brava have delivered amazing, unlikely solutions to daunting problems. Check back for more stories of grand challenges and brave solutions from Brava engineering!
Article Written By: Kuy Mainwaring, Head of Product Engineering at Brava