Some IoT Design Considerations, IDE, Sensor I.C's, how to prototype the solution, and some Data Error - "gotchas".

Introduction

In a similar way to my previous paper on IoT technology, I wanted to share my experiences with you. This is regard to a pollution monitoring application that I am working on. This is my own project, and not on behalf of any third party, so I can freely write about it.

This is a much shorter document.

Environmental Monitoring – learning something new?

To monitor all the pollutants, on board an IoT sensor, I needed to find a new suite of I.C’s. Sometimes a change, does us good, but what about the cost in terms of lost I.P. in what you know, and the hassle and effort needed, in learning something new?

My value in the area of IoT is my experience. I don’t pretend to be brilliant, I am not. I am just old, and have done this for a long time.

It can be tough to take on a new “chip-set” and manufacturer, but if I don’t, I’ll stagnate. I have been inspired by this new manufacturer. Their support for developers is excellent. Their development platforms are very cost effective, and (so far) the documentation is accurate, and comprehensive.

Data Errors, or Incorrect Readings

C++. Depending on what IDE you are using, then some compilers will not assign a value to an uninitialized variable. i.e. if you don’t assign values to every variable, then when the program executes, the variable will be set at whatever value is in the memory. So, always assign values to variables at initialization.

Note. I know that Visual Studio handles this problem, but then someone else may use a different compiler, e.g. Eclipse, at a later stage. So, design your software so that it can be managed on any IDE, on any OS.

Logic I.C’s. Most manufacturers will set any readable Pins at a Logic 1, by default. That’s fine, but what happens when a Pin is read? i.e. if you write a logic 0 to a Pin, what happens after the program reads in the level? In many I.C’s, after the cell or Pin is read, the voltage level reverts to the default, i.e. a level 1. That is Ok, if you know about it, but can be a real problem if you do not plan for it. i.e. you may decide that after reading in the level on a pin, or cell, that you write the correct level back to it?

Similar to the above, but worse. You think you have written a logic 1 to a cell/pin, but in fact that never happened. You read the level on the pin, and you read in a level 1. But that was just there, because it was the default level?

Ferroelectric RAM. Some modern I.C’s (which I like a lot), use a NVRAM, made up of Ferroelectric RAM, called FRAM. NVRAM FRAM that is exceptionally fast, and low power, BUT >> it has a read process that destroys the data, after it has been read. So, a little similar to the above two issues, where you need to write the data back into memory, after you have read it.

The Core Application

Are you writing the core application? Or are you working with the core application people? Are they the customer/end-user, or a third-party development firm? The person developing the Sensor can make the core application developer’s life, a lot better. You can open up many more options for the core application people, but the converse is true. If all you are working on is a statement of works, and you don’t have any influence on the overall design, then it’s a sad day. Here’s why you should be working closely with the core application people;

Messaging. How is messaging handled from the sensor to the core application?

Events. How are events handled, by interrupts, or polling, or what?

Storage. Is data to be stored locally at the sensor? If so, how, and in what format, and for how long?

Core Application Unavailable. What does the sensor do, when the core application is unavailable?

Core Language. What language is the core application written in, and does that affect the sensor?

Core IDE. What IDE are the core application people using? Does it help, if you use the same?

Breadboard, Veroboard, or straight to PCB?

I used to take this one step at a time, and do Breadboard, then Veroboard, then PCB. But here’s some issues that are forcing me to change.

There are not always exact pin compatible equivalents of SMT I.C’s that correlate to the traditional full size, socket mounted I.C’s. So, you could test circuits using a Breadboard/Veroboard, but find there are not SMT IC’s available for your PCB. Or they could be available, but there are not ECAD files that allow you to include them into your ECAD design. So, then you have to make custom ECAD files.

It’s also time consuming to make the Veroboards, and depending on how good your soldering is, you may end up wasting a lot of time, in fixing poor soldering joints.

I guess what I am suggesting is, work out what IC’s you want, then see if there are ECAD files available and go straight to PCB. I work with a local PCB firm. I email them the Gerber files, and deliver the parts to them. They take about two weeks to make the PCB’s.

But, more often than not, I still have to start with the traditional Breadboard, Veroboard and then PCB process.

PCB Prototyping

Always design-in monitoring connectors. You may have 200 to 500 pins in an IoT Sensor. I design in several 40-way connectors. I then get some ribbon cables made up, and connect the 40-way connectors to an external Veroboard. I can then monitor what is happening on any pin, on any IC on the target prototype board, regardless of how small the actual circuits on the board are.

This allows me to fault find more easily. It also allows me to monitor what is happening on the PCB as there are changes made due to programming, or any external inputs or outputs.

Make the board many times larger than the final solution. Obviously, you need that for the 40-way connectors. But, a 200mm x 150mm PCB is easier to work on, than something the size of a pea.

Radio?

Whatever frequencies you are operating at, consider and understand how radio works. Design your PCB so that there are not any obstructions in front of, behind or close to the aerial. Think about a ground-plane, and where and how that is placed. Are you using a directional, or shaped aerial, or what? Designing a brilliant Sensor is useless when it cannot communicate via radio, because you put it inside a metal container (or housed the sensor in the leg of a metal support to a machine etc).

Expansion/Change and Power

We expect to be able to upgrade sensors “over the air”. But, no matter what you think of, and plan for, you must consider the cost, risk, and downtime of needing to go and change a sensor, or add something locally. One option to always consider is a daughter-card slot?

Rough Handling

Make the board, and any container, and any cables, able to withstand rough handling. That includes how the connectors are made, and removed. It’s so easy to break a connector to a PCB, by pushing or pulling an external connector too hard.

Selecting the I.C’s.

Think about longevity. What’s the planned life of this IoT Sensor? Plan for spares to be held, and supported.

One problem with new I.C’s, is that the technical manuals will have mistakes in them. New manuals always will have errors. So, new I.C’s bring longevity, but they will mean you need to add more time, to really learn the I.C’s, and document yourself how they operate.

The more complex and powerful I.C’s will have far more weaknesses, in terms of attack vectors for hackers. So, while we all want the most powerful I.C’s, (yes choose them) but carefully investigate all those wonderful features, and find out which could be used by a hacker.

Select the I.C’s with the most Memory, Storage, Timers, Interrupts etc. Even if the I.C’s cost 50% more, that cost difference is insignificant when you just added additional capability to the core application, that the end-user/third party developers could never have imagined possible.

Security

As you may know, I invented and patented an IoT security solution. It can be added to any IoT solution. It does not change any existing processes, or technology. It can use inputs from existing security solutions, to make determinations on potential threats. My IoT security solution uses A.I. and Logic Circuits, and is impervious to traditional hackers.

I design security taking into account that any encryption can be broken given time, and all networks and applications can be hacked. In addition people make mistakes.

My security solution is not perfect. But it starts from where yours finishes. So, whatever you have now, my IoT security solution is another layer of defence.

Mike Mckean, the Author

I began working on this type of technology in the mid 1980’s. At the end of this paper you can review a list with url links, to some of my other recent technical publications, which include a range of associated compute technologies.

My email is; [email protected]

Other Publications

·        A very technical paper on NAND Flash technology.

See https://www.dhirubhai.net/pulse/nand-flash-technical-paper-mike-mckean

·        There are several others on my Linkedin, but this IoT and the above NAND Flash paper are the most detailed.

My Linkedin https://uk.linkedin.com/in/mike-mckean-991a7743

Other Publications. These are much shorter;

·        Brief Technical Description of what an API is;

https://www.dhirubhai.net/post/edit/brief-technical-description-what-api-mike-mckean

·        Ransomware through the Counterfeit Firmware, back-door;

https://www.dhirubhai.net/pulse/ransomware-topical-what-boring-old-firmware-mike-mckean

·        Firmware;

https://www.dhirubhai.net/pulse/firmware-technical-description-mike-mckean

·        Snapshots (Storage);

https://www.dhirubhai.net/pulse/short-explanation-snapshots-mike-mckean

·        Cost cutting in IT. Don’t do it;

https://www.dhirubhai.net/pulse/dont-cut-costs-mike-mckean