Power consumption and production testing Qoitech Otii and pytest


Fully automated test system benefits are best recognized in catching potential device problems during development as well as ensuring every device manufactured is flawless at the exit of the production line. Particularly for smaller batches of 100–1000 devices, the cost of development and test system setup has traditionally proven to be a limiting factor. Not having them in place introduces a high risk that we are not willing to afford. We have invested a lot of thought into our design process to minimize this extra cost. This way even the early trials are spared experiencing bugs in operation and can focus on other aspects that product owners should pay attention to.

The test bench

The test bench is set up to enable the following key features:

  • Measure power consumption per firmware function (or a set of them), for example measuring the analog channel, LoRaWAN transmission, BLE transmission, LED blink and others
  • Automatically provision device firmware and parameters with a set-up that fully disconnects the programmer to avoid any current leakage
  • Actuate and detect device inputs and outputs, for example, detect an LED blink, create an analog pulse on the input etc.
  • Connect via LoRaWAN or BLE and validate correct operation and settings.
Test setup

The software

The key to a fast test procedure is the use of Otii Enterprise (or Otii Automation Toolbox), which provides a TCP-server for simple Otii control using a JSON-based API. Main program is a Python script which uses the unittest module and a custom wrapper around Otii TCP Client for Python. Basic features include firmware upgrade and power analysis. Depending on the project these are extended with BLE connectivity and I/O capabilities to interface with the device.

Test configuration

Test configuration is specified in JSON which makes it most universal and available for the user to readily changed. This is best observed in the Lion tracker use-case as shown below, which is configured to operate as a state-machine solution. With an UART print of state transitions, one can easily mark the time when these transitions happen, as well as the power consumption in-between. Then by defining the boundaries for these transitions, we can evaluate the correct operation.

  • "from" is the message where measuring begins, matches text
  • "to" is the message where measuring ends, matches text
  • "avg_limit_low" is the lowest amount of energy (in μWh) that can be used up in the specified duration (on average).
  • "avg_limit_high" is the highest amount of energy (in μWh) that can be used up in the specified duration (on average).
  • "timeout" is the highest amount of time (in ms) allowed between messages. If timeout is 0, the limit is infinite.
enum state_e{
"from": "fsm(0",
"to": "fsm(0",
"avg_limit_low": 0,
"avg_limit_high": 0.1,
"timeout": 0
"from": "fsm(3",
"to": "fsm(4",
"avg_limit_low": 100,
"avg_limit_high": 170,
"timeout": 8

Test results

The test progress can be monitored using Otii Enterprise (or Otii Automation Toolbox) software. We can observe power consumption as well as state parameters throughout the test procedure.

  • GPS IC not soldered correctly
  • Short-circuit in step-down converter
  • LoRaWAN RF problem as the transmission failed



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Institute IRNAS

Institute IRNAS


We are applying today’s knowledge to create systems for an open future.