IoT tips and tricks - 1

As I wrote in a previous article, one of the distinctive features of IoT projects is that they require integration of technical blocks originating from three different domains: electronics, communications and software. And inside these three domains, various different subdomains are usually involved: analog and digital electronics, wireless communication modules, protocol stacks, embedded software, user interfaces, database management, analytics, geospatial data, etc.

Therefore, when developing a new system, it's almost impossible to only rely on technical blocks developed in-house, or that you have been already using for a long period: you have to integrate some new components provided externally. And usually you'll discover that provided documentation does not say everything about components characteristics and behaviour.

There are several ways to reduce risk and shorten development time despite these discrepancies between specifications and reality. Among them, I usually rely on these three ones at least:

• for every component that I don't know yet, I run dedicated tests to ascertain how the component reacts
• when it is used in a wrong way (for instance, for a communication module: badly formatted commands, request for a connection to a non existing remote server, etc.)
• when it is overloaded (for instance, still for a communication module: transmission of messages at highest throughput possible, while it is receiving messages at highest throughput possible)
• I keep associated test environments for the whole project duration, so that in case of trouble with the system being developed, I can use those environments as references.
• at software level, I first implement handling of abnormal system conditions (for instance: buffering data when connectivity is lost, reseting GNSS receiver when it is frozen, etc.) Hardware architecture must be designed to support this of course (for instance: the device microcontroller has to be able to control the reset pin of the GNSS receiver).

Adhering to these recommendations slows down the start of the project, but it allows to eliminate so many problems that would otherwise have appeared before the end of the project or, even worse, in the field, that the overall balance is very positive.

By the way, the above recommendations can be applied to components developped in-house as well, of course. And to software-only projects.