IoT thoughts — Physical Issues and Embedded Environment

I’m writing a series on why getting started on an Internet of Things project can be complex, and what considerations can make your project go more smoothly. The original article with links to all the content is here.

Today I’ll be discussing hardware, and touching on the embedded environment.

Hardware

The hardware you’ll need for your application will vary depending on what you’re doing, but unless you’re hooking your software into some third party systems or buying off the shelf components, you will need some hardware.

Sensing things (Temperatures, Switches, Pressure, Occupancy, Wind Speed, Rainfall, Humidity, Air Quality, Heartbeat, Perspiration, etc etc) and actuating things (Turning on equipment, actuating proportional devices) are the two primary requirements in most applications.

Electronically, these things are generally well known and common circuits exist for doing many of these things. In fact, many sensors can be bought off the shelf.

But — if you want to do it at a competitive cost or do something non-standard (say a device which measures heartbeat AND humidity at the same time) then you will need to roll your own hardware.

There’s plenty of big vendors vying for market share in the IoT. Intel, Microsoft, Arm, Samsung, Qualcomm, QT, and many others are making big bets on the future of IoT, and offering hardware/software platforms for developers to get started. So, a good approach might be to hire some embedded developers and electronics engineers and jump right in — if budget were not an issue.

Unfortunately a lot of these platforms come with a high engineering cost - the cost of acquiring the knowledge and people to implement the solutions can be prohibitive.

Rapid Prototyping

However there are plenty of products targeting the “hobbyist” market, which are very accessible for anyone with even the smallest exposure to electronics. These can be a better starting point for doing some simple proofs of concept before moving on to a more comprehensively engineered design. They let you mock it up and learn some things before you jump in to the design head first.

The Intel Galileo board can run either windows or linux and has a good share of IO available to interact with outside circuits, or as an extension the outside world, and starts at about $70. The Raspberry pi is about half the price and is hugely accessible as long as you are comfortable working in linux — however it does have less IO. In the middle, the beaglebone black is just as accessible as the Raspberry PI but has a huge amount of IO.

Going simpler still, a good starting point could be an arduino. Very low cost, with varying levels of IO and simple to program, it’s a great starting point for prototyping some simple concepts. They are so low cost that most people will just buy another one if and when they break it.

The above devices fall into two categories. Microprocessor based devices such as the Raspberry Pi can be thought of as a mini computer. They run an operating system which can be configured and programmed in a way similar to a desktop pc. These are relatively easy to connect to the cloud as you can easily use ethernet or an external wifi module to get internet access.

Microcontrollers are simpler devices, which are programmed by flashing some code (generally C code) onto the chip. An example is the arduino. When it powers on, the code that is loaded runs until it is powered off. The code will be simple, with a lot of recurring loops. The simplest example would be a piece of code which toggles an output every few seconds, causing a LED to flash. Microcontroller based products are generally simpler devices which consume less power — and as a result have the potential to be battery powered. However, their simplicity makes it much more difficult to get them directly cloud connected.

There’s plenty of tutorials on getting started with microprocessor type devices (e.g. Rasbperry PI) or microcontrollers (e.g. Arduino) so I won’t go into any more detail on them.

From prototype to engineering

Of course, it’s a long road from a few simple mockups using these types of devices to a properly engineered, full fledged product. But they can make it easy to prototype a concept quickly and then get into the real development faster. For someone non expert in electronics , you will still need to hire in or contract out for the right knowledge to design and implement a robust solution. This could involve paying someone knowledgeable a lot of money — or hiring a couple of smart recent graduates — or outsourcing the entire project to an electronic engineering company.

It is essential to find someone good however — you will legally need to demonstrate compliance with local electronic regulations, EMC emissions testing etc. In Europe, these are the EN standards dealing with low voltage devices, radio emissions etc, and these are dealt with by CE testing. In the US, similar standards exist from the FCC and others, and UL testing can verify operation.

Even if your products can be demonstrated to comply with the standards, that does not mean they will operate flawlessly in the real world. Hooking up some wires and testing your device on the bench does not equate to deploying it in a location with noisy electrical equipment, industrial plant, or locations with a bad earth. Electromagnetic Interference from outside can cause major effects on your microprocessor or microcontroller — making them think a switch is on when it is not, or vice versa, or in extreme cases crashing the device. If your application falls anywhere between “kinda important” to “critical” then this can be a big problem. So again, it’s important to have some professional advice here.

Once you have decided what route you’re going with the hardware you’ll have to think about the environment too.

Embedded Environment

Your embedded device(s) will need to run control logic, connect to cloud, provide local data storage, possibly run a touchscreen or interface, have robust watchdog functionality to prevent unexpected lockups, and make sure everything is running correctly. Should you target Android, Windows or Embedded Linux (or others)?

Embedded Linux

Embedded Linux has been widely used for many years, and is the go to environment of choice for many devices. It’s very easy to customise, lightweight and generally very stable. A lot of knowledge exists out there of this environment and it is well understood. Any code that can run on desktop linux can similarly run on embedded linux, giving you a wide range of options for language.

Android

Next up is Google’s Android operating system, as it at least shares some common roots with Linux. It uses the Linux kernel as its’ foundation, so the environment, while very different from Linux itself, will seem somewhat familiar to Linux developers. Android has been very successful in phones and tablets, with limited success in embedded applications — primarily in automotive applications. It features a good looking strong UI, which is an advantage over traditional embedded Linux. But it is more closed, less well understood as an embedded platform, and has limited language support — primarily an android flavour of Java — with some C/C++ extensions. Android is worth considering if you’ll be running a touch screen though.

Windows IoT

Microsoft have been working hard to converge their many platforms and to give a more cohesive IoT platform. Windows CE gave way to Windows Embedded Compact and the new kid on the block, Windows 10 IoT Code, looks like it will eventually take over the mantle from Windows Embedded Compact. Windows IoT Core is a good fit for developers most familiar with the Visual Studio and Azure, and Windows. Services such as Azure IoT hub also offer bolt on services which may make it easier to implement the cloud services later.

Others

There are other options out there — but less widely supported. In no particular order — Sailfish, Firefox OS, RISC, QT for Device Creation, etc etc. So it’s worth doing a little of your own investigation to see if there’s a better fit for you.

Other thoughts

So — you’ve chosen a hardware platform and an environment. What else is important?

Will you have a single device or multiple devices networked together in the real world? For example, if you want to gather data from a remote sensor, you’ll probably need to do something wireless. You may also want to do something battery powered — this brings its’ own set of challenges.

Next time out, I’ll discuss wireless technologies and low power considerations.

Update — part 3 is now available. Part 3 — Wireless and Battery.

—

Des Flynn is CTO of Lattice Research, who help companies to design, build, deploy, operate and service innovative and cost-effective IoT control systems to meet their customer’s needs. More information at www.lattice.ie