Intro to Electronics Product Design Part 2: Electronic System Architecture

In the first installment of this five-part series, we worked through the process of defining the early requirements for our system: a convenient solar oven. In this second installment, we run through the steps of designing an electronic system architecture, with a heavy focus on the specific design of the solar oven controller. We’ll attempt to meet all the requirements for a test platform that were elaborated on in the previous article.

The design process includes a brief comparison of multiple possible approaches for each of several key functions. This article walks through a preliminary, very brief examination of cost and performance to help select among competing approaches. A guiding principle of the initial design process is easing test and evaluation, and the article discusses subcircuits for evaluation of opposing approaches.

High-Level Architecture

Safety and Temperature Measurement: What We Know How to Do

Let’s tackle the easier part first: safety. To establish the safety of solar-cooked food, we want to know its temperature over the course of its time in the oven. We might have large volumes of food—for example, a big cut of meat—that won’t heat uniformly, so we need to know both the external and internal temperatures.

Some solar cooks cook several different things at once using separate containers in different positions inside a single oven. Containers filled with food at different starting temperatures and in different positions in the oven might be at significantly different temperatures. So our platform should allow users to employ several temperature sensors at the same time.

We need to decide between self-contained temperature sensor modules with their own power sources that have wireless links back to the controller and wired sensors with the electronics inside the controller. The first option makes it easy to avoid problems with access and cords; we don’t have to insert wires through the oven walls or thread them into each of the containers. On the other hand, this option presents a significant cost and technical challenge due to the high end of the operating temperature range, which is well above the operating range of most active electronic components. Also, a multitude of sensors buried inside food presents the risk of the cook forgetting to remove all of them and unprepared diners biting down on a powered, battery-containing module. To avoid these problems, we’ll accept the difficulty of wiring through the oven walls and into each container.

Besides temperature sensing, the controller needs to create a log of each temperature, a running integral of the time spent in the danger zone, and an indicator of whether meat and fish dishes have reached target internal temperatures. Finally, we need our processor to operate the user interface we’ve already defined: a graphic display, a knob or two, an alarm, and some additional input, such as a keypad or touchscreen. Given these requirements, we can summarize the architecture using the diagram below.

Estimating Doneness: What We Have to Find Out How to Do

Some of the easiest, least expensive properties to sense besides temperature are humidity, pressure, and sound (sizzling and popping). Cooks who are determining doneness certainly rely on appearance and scent, but although machine vision could be a powerful tool for determining doneness, it’s too expensive on the processing and software side for this initial set of experiments. We could, however, provide hooks in our test platform for incorporating water vapor sensors and commercially available chemisensors such as those for CO, CO2, and N2, as well as acoustic sensors. To accommodate sensors like these, we’ll make sure we keep several ADC inputs and a few common peripheral buses (SPI, I2C, UART) free so we can attach additional sensors later on.

Narrowing in on Specifics

For our temperature sensors, the probes must operate safely over the entire possible internal oven temperature range defined in the requirements. Some of the sensors may be gas sensors, but most of them will be contact sensors because we need internal food temperatures. They should have response times of a few seconds or faster. They should consume minimal power and cost as little as possible while meeting our other requirements. We’d like a sensitivity and accuracy of 1°C or less over all corner cases. So to start, given all these requirements, we’ll employ three- or four-wire platinum RTDs as our sensors.

After a frustrating search for industrial-grade, food-safe temperature probes with operating ranges up to 750°F among major electronics parts vendor catalogs, it looks like our test platform will have to make do with less-than-ideal temperature probes. Food-safe temperature probes for the top end of the temperature spectrum seem to primarily use kinds of Teflon for cable insulation, which starts to degrade near 500°F. In fact, higher-temperature, food-safe, industrial-grade temperature sensors just don’t seem to be commercially available. And even with these limited temperature ranges, most of the industrial probes were many tens of dollars. Consumer food probes sold as parts of remote digital thermometers had upper temperature ranges similarly well below 700°F.

One shining example of reasonably priced, high-temperature RTD probes stood out: the PT100 RTDs from Adafruit. The Adafruit probes can operate up to over 1000°F. Unfortunately, although the probe itself is foodsafe, the cable is not.

It appears that for the test system, we have to limit the top end of the temperature spectrum for testing to about 500°F/260°C or use non-food-safe probes in initial testing. To avoid damaging probes, we can build in a test feature that provides a notification when a test oven approaches the temperature probe upper limit, so the tester can open the oven and let it cool off a bit instead of damaging the sensor. Two of the three test ovens are unlikely even to approach the upper end of the temperature ranges of even the consumer food-grade sensors, so this shouldn’t be too problematic.

For speedy convergence on high-resolution, reliable sensing, we can start out with a commercial RTD amplifier-digitizer IC, a Maxim Max31865. It’s available in both an evaluation kit from its manufacturer and a less-expensive breakout board from Adafruit. For initial testing, we’ll use the Adafruit breakout board. We need to reserve a slot on a SPI bus on our local microcontroller to talk to the Max31865. If we have three temperature probes, we also need three of these breakout boards and three slave chip-selects on our Maxim SPI bus.

Note: This temperature sensor arrangement is not likely to survive a round of optimization for cost, with probes over $10 each and several dollars each for the amplifier/digitizer ICs, but they’re a good basis for rapid prototyping.

In an advanced test of usability, we’d want our microcontroller to report its findings to a handheld user interface device that might be far away. That link has to be wireless, so we need some sort of radio. Assuming that the solar oven might be quite far from the operator, we don’t want to confine ourselves to the fairly limited-range Bluetooth Smart or ZigBee protocols, but we also don’t want a very expensive radio or a power hog. A final design might have to support multiple kinds of wireless links. For initial testing, we can experiment with Wi-Fi, in spite of its potentially high power consumption.

We also need a display and touchscreen with fairly high quality, of a size that’s not unreasonable to carry around—about the size of a smartphone or smaller. The display and, if included, touchscreen, will probably be the most expensive electronic component of the system, so ultimately, it might receive the most attention for selection of a low-cost but appropriate-quality component. For our test platform, however, we can choose a well-supported, high-quality, low-volume component of relatively high cost.

For the tracking and comparison, we can use a low-cost microcontroller, preferably one that can easily drive our display and that may include one or more wireless protocols. To start our testing, we’ll choose a mid-range processor that stars in an appropriate evaluation kit or prototyping module. We'd like the processor to be in the middle of a family of processors with nice lower-cost, lower-performance siblings at the bottom of the family; we don’t have to start out with the final processor. We can make sure it has sufficient local peripheral buses and an appropriate number of ADC inputs with decent resolution. We need to be able to get it up and running quickly for our initial testing, so we’d like to use a well-supported development platform that meets our goal of free and open-source tools. For the sake of development time, we can use a 32-bit ARM processor.

Our target budget allows us a dollar or two for the processor and another dollar or two for the wireless link in the final system. In our happy times of multiplying open-source hardware sources, we have quite a few options that are similar in support and board cost. One of the options that meets all these requirements is the Adafruit Feather M0 with Wi-Fi, for which an add-on peripheral TFT display of the right size and quality is available. The Feather is particularly convenient, since Adafruit open-source code for operating the Max31865 is already available. We need two Feathers: one to run the sensors and report on status, and the other to run the user interface.

Both of our modules need batteries and power management as well. We can choose a long-lived lithium polymer battery in a fairly large size to start (500 mAh) to accommodate our possible Wi-Fi needs. We can use the regulators on our test boards to start. The Feather comes pre-equipped with a USB connection that can be used to charge the battery.