What to know before launching an IoT device?

Over recent years, the rise in popularity of the Internet of Things (IoT) has led to more and more connected smart devices every day. However, launching an IoT device is not an easy task – it requires careful planning, research, and preparation to ensure a successful deployment.  

To give the best overview of the topic, we partnered up with Krakul - a company with competence in building IoT solutions ranging from urban mobility to space technology. In this blog post, Krakul’s Research & Development Team Lead provided valuable insights into what it takes to successfully launch an IoT device.

The development process

Assuming that the groundwork for your new IoT product is completed, which includes having a use case, market demand, and business-related aspects sorted out, it's time to proceed with the development phase.
‍

‍

‍
The development process itself can be roughly divided into 7 steps:

1. Detailed device specification – the backbone of everything in the development process.
2. Mechanical design – the device must be designed to last, with an optimized Bill of Materials (BOM) cost, robust, and easy to manufacture.  
3. Firmware development – as an essential part of providing connectivity to the device, it needs to be running smoothly (often real-time) and be easily debuggable.  
4. Electronics development – does the device need custom electronics and cost-optimized small form factor Printed Circuit Boards (PCBs)? Even if not, finding the best over-the-shelf components is a job of its own.  
5. Software development – IoT loves the cloud. To get more out of a device, it often relies on back-end magic and great front-end for web, desktop, or mobile apps.  
6. Testing – testing is a crucial step for not only the longevity of the device but also for the company itself.
7. Verification – the final step to ensure that the device complies with the regulations and requirements.
   
   

As the development process is a long journey, and to keep this article concise, we will focus on the two easily overlooked, yet extremely important, aspects.

Firstly, we will be covering the creation of a detailed product specification - really, the base for everything else in the development process, as the document lays the foundation for the next steps for design, firmware, software development, and verification and testing.

The second part of the blog post will be dedicated to device testing, with a thorough testing checklist to follow before launching an IoT product of your own.

Assembling a detailed device specification

When starting out with the specification, one of the biggest questions is: “How realistic are the device requirements?”

To answer this question, you must know the potential constraints.  

Here’s what to keep in mind when it comes to the hardware specification for the IoT device:

• Maximum input signal frequency.  
• GPIO (general purpose I/O – software-controlled input/output pins) usage exceptions, for example, WiFi, Analog to Digital Converters (ADCs), and interruptions when dealing with ESP32 (popular low-cost microcontroller).  
• GPIO input and output voltages.  
• Communication between the microcontroller unit (MCU) and other modules.  
• Power consumption – For example, if the aim is to develop a low-power device, it needs low-power components. Never combine high and low-power components on one PCB.  
• Power supply

The restrictions on the software are based on a variety of key elements:

• Performance of the planned language:
  • For example, interpreted languages like Python or Javascript are slower than compiled languages like C/C++.
    
    
• Does the software run on an operating system or without one on bare metal? There are things to consider with either one:
  • Operating system (e.g., FreeRTOS) - concerns with scheduling; what are the priorities, and potential memory usage (to avoid stack overflow);  
  • Bare metal – potential concerns with the sequence and state machine control; will there be timing conflicts?

When it comes to creating a Bill of Materials (BOM) for an IoT device, selecting the appropriate cellular hardware is a crucial step related to hardware specifications. While there are essential factors to keep in mind listed below, it is vital to consider the component availability and possible replacement options.

Cellular coverage in the destination market - standard Radio Access Technologies (RAT), or NB-IoT / LTE-M

‍

‍

Deciding on a particular cellular technology standard is not easy, especially when considering the full spectrum of radio access technologies (RAT) such as 2G, 3G, 4G, and soon 5G, whereas LTE-M and NB-IoT are low-power wide-area networks (LPWAN) specially designed for the IoT. Although the rollout of NB-IoT and LTE-M has picked up speed worldwide, there are still many things to consider before making the decision.

• Check the RAT or NB-IoT / LTE-M coverage using online, for example, here’s a blog post on the status of NB-IoT and LTE-M coverage and roaming possibilities.  
• Keep in mind that the lists and maps you find online, although most likely frequently updated, can be outdated.
• If there is no mention of NB-IoT and/or LTE-M coverage in the destination market, contact the local network provider for more information, or reach out to 1oT to find the best solution for your use case.

Fallback options

• As the technology of LPWAN networks is still rather young, it’s often needed to provide a fallback option. Understandably, there are drawbacks like a bigger footprint and higher cost of cellular modules for solutions with fallback to 2G/3G technologies. But rolling out a product with only Mobile IoT connectivity is a risky move in the current state of the network deployments.
• As 2G and 3G networks are being shut down over the next few years, consider which fallback technology suits you best, based on the deployment destination. We have done the research and gathered the available information about shutdowns in a blog post.
  
  

Indoor/outdoor device, casing materials

• Hardware must be specified according to the use case. If the device is planned to be used indoors, remember to consider the potential interferences from other wireless devices, potential connection issues due to specific casing materials, or even the perimeter of the building.

Testing the device

Distinguishing between hardware and software problems in an embedded system can be challenging, especially when communicating between modules.  

The rule of thumb for testing is to test the software before designing customized hardware for the product. Most vendors provide evaluation kits for their microprocessors and various submodules, such as sensors and cellular modules. Utilizing evaluation boards during prototyping helps test the software in a controlled environment, which can prevent debugging hardware issues on actual, final hardware.

As testing should take place at various development stages, there’s a checklist to follow to ensure that you have completed all the tests you should. Remember, it is vital to keep a record of test results to prevent repeating the same errors.  

Always bear in mind that testing is more cost-effective than avoiding it. Cutting corners on testing can result in significant expenses, such as when a device appears to function well on an office desk but experiences issues after its launch when it is already in a different continent, for example.
‍

‍

Testing checklist:

1. Feature testing
   1. Do the lights blink as they should?  
   2. Can we maintain an internet connection over long periods?
2. Submodule testing  
   1. Will the device reconnect to the network under various conditions?  
   2. Confirm the communication between components  
   3. Is the communication line connected properly? Consider using a logic analyzer or oscilloscope.
   4. What is the state of the submodule - when is it ready to communicate? This information is usually provided to you on datasheets or as examples.
   5. How to configure and debug the submodule’s features, baud rate, and where to find the communication protocol?
      
3. Subsystem testing
   1. Will the file system remain persistent over power losses and events of network instability?
      
4. System testing
   1. Does the device perform according to our expectations?  
5. Integration testing
   1. Does everything work together as imagined?
   2. Do the components/modules also work separately?
   3. Conduct tests based on user stories
6. Prototype testing
   1. Does the ‘Proof-of-concept’ work?
   2. Are the components chosen valid and working as expected?
7. Product release testing
   1. Conduct long-term tests to ensure your device’s functionality in the future.
8. Power consumption testing for low-power devices  
   1. Does the active and passive mode change work on the microcontroller MCU?
   2. Can the wireless communication module change the power consumption from mA to μA?
   3. Conduct tests on software optimizations, e.g., sleep modes.
9. Internet connection and data testing
   1. Is the Internet signal strong enough? An unstable internet connection can easily cause the system to be unstable, causing data loss and memory corruption in the storage system.
   2. Does the device’s system also work with an unstable internet connection? Conduct a stress test.  
10. Test the IoT device in its destination market before the launch, if possible.
    

Conclusion

All in all, the sudden boom in the IoT market has made launching an IoT device more challenging than ever before. By following the seven stages of the development process discussed in the article and taking the necessary precautions, you can launch a reliable and secure IoT device that meets regulatory requirements and customer expectations.

Need help developing your IoT product?

Krakul is an expert in launching an IoT product from start to finish, while 1oT makes sure your devices stay connected wherever they are deployed, globally.  

For further information on how we could help your particular use case, reach out to us

1oT: sales@1oT.com

Krakul: info@krakul.eu

This article is written in conjunction with Krakul.
Authors: Jaan Kristjan Lepp, R&D Team Lead, and Krista Kippar, Software Engineer.