In this IoT 201 tutorial we discuss testing IoT devices, and how to test the RF and power management efficiency of your final IoT device design. ARTIK modules speed the time-to-market of your IoT products by pre-integrating much of the design, but you still need to pay attention to some hard hardware facts. We handle the design and regulatory details of the radios, but providing a good connection between the module connector and the air is your job. Our engineers obsess over power efficiency of the modules, but if you want the best battery life possible you need to do your part, too.
Let’s start with the radio. The compliance certification that all ARTIK modules pass measures conducted RF signals at the output connection for the ARTIK module. Using sophisticated (and expensive) testing gear and testing chambers, certified testing labs measure the power and quality of the RF waveform conducted to the PCB pad to which the antenna connects.
But what you really care about is radiated power: the power you radiate during transmission and your ability to capture radiated power and conduct it to the receiver pins on the ARTIK module. Efficient conversion of conducted to radiated power and vice versa requires good impedance matching between the transceiver (ARTIK module) and antenna. Both should be 50 ohm loads with no discontinuities between them.
RF problems can arise from poor quality antennas, cheap materials at connection points, and flaws in the design or manufacturing of the PCB and assembly. Regardless of the source of flaws, the symptom will be power that is reflected between the ARTIK module and antenna, rather than efficiently transferred between radiated power and conducted signal at the proper ARTIK pad. Problems can of course also stem from an improperly designed custom antenna, but since that requires a new round of regulatory certifications we’ll assume such issues are caught during the certification process.
The good news is you don’t need an anechoic chamber to detect problems in your design. The frequency of the reflected (lost) power depends largely on the distance between discontinuities, making it possible to see with a spectrum analyzer or mixed-domain oscilloscope. Start by analyzing the signal on an ARTIK developer board at the RF connection. Power up the module and run some code that transmits a large block of data, then capture the frequency components of the signal. You should see frequency components at the center points of the carrier frequencies with some spread about those frequencies due to modulation. You should not see much power outside the transmission channel.
Now run the same test on your design. Look for conducted power in frequencies you didn’t see on the ARTIK developer board. If you’re still at the hand-built / breadboard phase it’s normal to see some loss because connections aren’t great, but if you’re looking at early manufacturing parts, any power outside of the main channels indicates one or more problems you need to fix before release.
Battery life matters whether you’re building an IoT sensor based on an ARTIK 020 or a solar-powered hub using an ARTIK 710. Consumers hate changing batteries and the cost of battery servicing can destroy otherwise promising ROI calculations for commercial and industrial customers. While average power consumed over time is the driving calculation, there’s nothing “average” about the instantaneous power of a sleepy IoT node. The ratio of peak power (typically during RF transmission) to the power consumed during sleep can easily exceed 105. To improve battery life you need to control the magnitude, duration, and frequency of your data bursts while zealously quashing every nanoamp of power consumed during sleep mode.
You need to measure the magnitude and duration of power pulses if you want to optimize battery life in a sleepy IoT device. The instrument(s) will see three distinct phases:
- Sleep mode power depends mainly on the power consumed by the ARTIK module itself plus any loss through your power supply. You’ll need to measure current with precision in the sub-microamp range for an ARTIK 020 or 030.
- Data acquisition power depends on the sensor(s) you’re using plus the power the ARTIK module requires to digitize the signal. If it’s an analog input, expect currents in the milliamp range plus any signal conditioning your sensor requires. The duration of power pulses associated with data acquisition are generally on the order of milliseconds.
- Data transmission is the biggest consumer of power. You can’t do much about the peak power (tens of milliamps) but you sure can minimize duration. Look at your data payload and see if there’s anything you don’t need to transmit, or at least don’t need to transmit every time. Also consider the protocol you’re using to connect. There’s a big difference in power consumed per byte transmitted between Bluetooth® Low Energy (BLE), Wi-Fi®, ZigBee®, and Thread.
In addition to minimizing the duty cycle of your transmission bursts, look for any power consumed that you can’t account for. Check out the following screen shot from a Keithley 7 1/2-digit graphical sampling digital multimeter (DMM) of two transmission cycles of a sleepy IoT device. (Note: this is for illustration purposes only and is not the actual power consumed by an ARTIK module.) In the image you can clearly see all three expected power phases, plus something unexpected. After the first captured data bursts there is a period of about 700 ms where the device draws about 2 ma of current. There’s an opportunity to reduce power.
Testing key parameters of IoT designs should continue through the product lifecycle, including:
- During design and early prototyping, as discussed in the main tutorial.
- During production rollout, suppliers and manufacturing processes can change, and a testing plan should be in place to insure the changes don’t adversely impact performance. In fact RF performance should increase as manufacturing processes improve.
- During production, the automated testing system should monitor performance.
- Value engineering needs a testing hurdle to insure the switch to cheaper suppliers and processes don’t cause performance problems.
If you want to dig deeper into testing IoT devices, check out the Electronic Design article Practical Approaches to IoT Test Challenges.
About the author: Kevin Sharp has been an engineer since long before he got his engineering degree, and has extensive experience in data acquisition and control networks in industrial, retail, and supply chain environments. He’s currently a freelance writer based in Tucson, Arizona.
Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, and do not necessarily reflect the views of Samsung. All Samsung names and trademarks are the property of Samsung Electronics Co., Ltd. or its subsidiaries in the United States and other countries. Other names and brands may be claimed as the property of others.
Please read these legal terms carefully before using this blog.