Most of us come to realise at a relatively early age that the world isn’t always fair, just ask the average 4 year-old. The same can be said for perfection; some of us learn that the quest for perfection is perhaps more important and far more realistic than achieving it. In short, we learn the importance of compromise.

Given that we have to make compromises as a matter of course, it seems unreasonable to accept that datasheets only provide figures under ‘typical’ conditions, or in other words, ideal. This may be fine for comparison purposes, but not if you are responsible for a design that needs to operate within a strict and limited power budget.

In a real-world (not ideal) scenario, many integrated devices operate in ways that vary significantly from those advertised. Generally, engineers can accept this and design accordingly, but in our pursuit of perfection in a more connected world, we are now looking to develop devices that can operate at the edge of the network for several years powered only by a single primary cell.

Many engineers will have experienced the effect of leaving an unused input on a logic device floating, and how tying it high or low with a pull-up/pull-down resistor can have a dramatic and positive impact on power consumption. This kind of oversight is easily rectified but if the design uses a device that can experience significant and legitimate variations in power consumption it becomes a lot more challenging to design accordingly.

The case in point today is wireless connectivity, which is now becoming a must-have in IoT endpoints. RF activity is a major power-drain under the best conditions but when those conditions become more challenging the device in question may be expected to compensate; this is particularly true in cellular and LPWAN technologies. Those conditions are almost entirely incidental, meaning it depends on where the endpoint is located, the level of any other RF activity in the proximity and the link budget with respect to the receiving device. In this case, it is easy to see that ‘ideal conditions’ as they relate to the datasheet may be hard to achieve.

Without the luxury of a full anechoic chamber, RF signal generator, spectrum analyser and RF power meters, not to mention plenty of time and patience, it would be difficult to characterise an RF SOC for every operating condition, so it is little wonder that manufacturers have to fall back on typical figures. But for engineers working in the IoT it becomes necessary to bridge this gap between datasheet and design.

While it may be academically interesting to fully profile an RF SOC in the way described above, in reality it isn’t necessary. What engineers really need is a small number of reference points about which to base their design. Knowing that your endpoint may only achieve the figures published in the datasheet for 20% of the time is more valuable than trying to design to an unachievable power budget. Compromise is, after all, an important discipline in design and engineering.

Using Otii and Arc to profile the power drawn by a design under various but largely controlled conditions can give developers a much better insight into how their design will perform in the real world. Perhaps more importantly, the ability to profile a design under different simulated battery power levels can be even more revealing. Electronic devices that draw current in surges, which includes an RF transceiver, need to operate consistently and compensate for any instability in supply voltage that the surges may cause. While this may have a small impact on the instantaneous performance, it could have a larger impact on the average power consumed, the way the battery performs and, ultimately, the lifetime of the device.

The IoT is an amazingly diverse application space that is dominated by low power solutions. Endpoints will be expected to operate maintenance-free for many tens of thousands of hours. Indeed, entire business models will depend on it. Delivering that reliability based solely on the figures published in datasheets may seem reasonable in theory, but real-world scenarios vividly illustrate the compromises involved. Designing to worst-case conditions may be a safer path to follow but in a commercial landscape it provides little in the way of a competitive advantage. Engineers may be used to compromise and we may live in an imperfect world, but that is no reason to develop without all the data available. Datasheets offer a good starting point but empirical measurement provides developers with the real-world information they need to really meet that power budget.