IoT considerations — Wireless and Battery

Next in the series of things to consider when starting on an IoT project is wireless technology and battery power.

If you missed the previous articles, the overview with links to all the other content is here.

Wireless technologies — core to your design

Regardless of what you’re doing, there is a very high chance that you will need to do something wireless as part of your project.

Whether it involves connecting to Wifi/3G/LTE/4G to gain access to the internet, using Bluetooth to talk to an app on a smartphone, or using a longer range low power radio or mesh network to communicate with one or more remote sensors, you will need to consider how this is going to work and how to do it.

Connecting to the internet

Even where the answer seems obvious it is not as straightforward as it seems. For example — Wifi/3G/LTE/4G. Do you buy a couple of radio modules and put them on your board? What about antennas? Where does the 3G sim card go? Does it affect your enclosure designs? Do you need external antennas? What connector type — RP-SMA? N? BNC? TNC? U.FL?

Suddenly, your simple design gets a little more complex, and even before you think about talking to other devices, radio networks are already a significant consideration in your electronics design.

Of course, you could decide that the provision of network access is done entirely via ethernet, and move the problem of internet outside your core device, but depending on your device and application this may or may not be acceptable.

Connecting to other devices

Unless you’re doing something very specific, you’ll want to use a freely-available unlicenced radio spectrum for your communications with other devices.

Different regions have different standards, available spectrums and transmission powers — for example in Europe, 433MHz is available for use, but it is not in the US. In the US, 900MHz may be used freely, but this is not permissable in the EU.

However, the 2.4GHz band is free to use worldwide (it’s designated as an industrial, scientific and medical (ISM) radio band), and so many radio technologies target this unlicensed spectrum — Wifi, Bluetooth, Zigbee, 6LoWPAN, Thread, others. This means there are plenty of options to choose from which have international approval.

Short range — Bluetooth

If your gadget is going to connect directly to a smartphone, then you’ll probably want to use Bluetooth. Most devices such as phones and tablets support it, and it’s widely used. It has good throughput and is mature.

The primary disadvantage is range. Typical consumer type devices will have a range of 10 meters or less (33 feet). It’s also designed for directly connecting two devices together, so isn’t really suitable for more complex topologies.

It’s also quite power hungry, although Bluetooth LE (low energy) has made progress here, and is widely used in devices such as fitness trackers, blood pressure monitors etc.

IP network

Could you use an IP network such as wifi to gather sensor data? Of course — if everything is connected to wifi, you could find them on the network and interrogate them.

But what happens if the wifi is flaky, or down? How would you configure each individual device with the correct Wifi SSID and security credentials? What if there’s no wifi where you want to deploy? Do you create your own? Range is then an issue.

Depending on your application, if you only have a couple of devices, this could work ok. But if you have many devices, it will not be scalable as deployment will be hard.

Medium to long range — Low Power Sensor Networks

A better way of talking with many other devices in a location is using a low power sensor network.

This is generally defined by the IEEE standard 802.15.4, which is a standard which specifies the physical and addressing layers of a low power wireless personal area network.

On top of this standard, there are several technologies which take the basic layers of 802.15.4 and add their specific implementation on top of it. Examples are Zigbee, 6LoWPAN, Thread, MyWi, Wireless MBus. Other technologies exist which use other physical and addressing layers — common examples are EnOcean, KNX RF, etc. Regardless, the concepts are generally similar.

Transmission Power and range

802.15.4 allowable transmission power varies with jurisdiction, but you have to consider the worst case legislation when designing your system.

For example — in the US, the FCC specify 100mW/MHz as being the max allowable transmission power of 802.15.4 devices. In Europe, the maximum allowed transmission power of these types of devices is 10mW/MHz of spectrum used.

So, if you want to use this radio technology in Europe, you will need to consider the lower power value as your baseline. [note — I’m simplifying a little — but if you want to read up on spread spectrum, DSSS, FHSS, and multiplexing, please feel free!]

This has the effect of halving the potential distance of outdoor line of sight radio transmission, but it has a greater effect on indoor transmissions.

In practice, it means your non-line of sight range is limited to somewhere in the region of 40–60 metres (130 — 200 feet), as the already weaker signal will attenuate as it passes through a few walls, windows and obstacles such as people and furniture. But be careful — this is just a guideline — more obstacles will lessen the range further (particularly metal obstacles) — so you can’t always rely on those figures.

Point to point vs mesh

A point to point link is where two radios communicate with each other directly. So — If your maximum point to point range is limited to ~60 metres, what happens if your application needs to communicate over longer distances?

Assuming device A is 40 metres from device B, and device C is a further 40 metres from device B, then device C is out of range of device A. So how can we pass data from device C to device A?

Answer — we ask the device in the middle to pass the message on for us. This is called a mesh network. The reason it’s called mesh is as when you visualise the connections between the devices it looks like a mesh. [note — the Lattice part of Lattice Research is because it is a synonym of mesh]

A mesh network has some limitations, but not too many.

One — if we exceed the maximum number of devices our radio technology can address, then we can can’t extend it any further without doing something complex.

Two — each hop increases latency and decreases throughput. Make your network too large and it may slow to below the speeds your application needs.

Three — If a hop in the middle powers off, you will lose communications with the rest of the devices on the branch.

So — are these real issues? Not for most applications. Most low power mesh radio technologies support thousands of devices, so ultimate range should not be an issue.

Throughput depends on the application, but most applications don’t need frequent data transmission — for example, the temperature at a remote point of a building is unlikely to change very much for minutes at a time. I’ll discuss this more shortly.

For the third point, as long as we make sure every hop can see at least two other devices between it and the other end of the network, there will always be a backup route.

So, a mesh network overcomes the limitations of point to point connections, and ensures a more robust network. But let’s look a little closer at the throughput issue.

Throughput

A major limitation of low power wireless networks is one of throughput — the amount of data you can pass through it over time. While 802.11ac Wifi offers up to 1.3Gb per second transmission speeds, low power wireless networks can achieve much less — it depends on technology, but Zigbee is in the order of 250Kbps. This makes modern wifi 6,800 faster than a typical low power wireless network.

To make matters worse, the actual throughput is even lower than the transmission speed. The transmission speed is the theoretical value, and expect the adressing and routing aspects of the radio stack to consume a big chunk of the available throughput too. Expect to see about 100Kbps maximum under best case scenarios.

What if there’s multiple hops? The intermediate devices will need to decode the data, figure out where it’s going, re-transmit it, and there’s also more scope for noise causing retries. So expect your throughput to be more like 30Kbps in this case.

What if you want to encrypt the data (and you probably will) — in this case every hop along the way will also need to decrypt the data before checking it, and re-encrypt it before sending it on. So expect 15kbps instead.

But these technologies are not equal — Wifi needs to be able to transfer 4K HD video — while your low power network is passing limited statuses.

In fact, even if you only achieve 15kbps, you could still transfer nearly 300 words of actual text per second. It doesn’t sound like a lot, but if all you’re looking for is some temperature, humidity or other readings or commands, it is plenty. You can always minimise traffic on the network by simply sending the traffic less frequently.

What about Prototyping wireless?

Building your own wireless designs is not an insignificant project, even if you use a reference design or some pre-designed modules.

But, if you are so inclined, you can dip your toes in the water by buying some hobbyist friendly modules. Check sparkfun or adafruit — you can buy wifi, bluetooth or 802.15.4 modules to let you start prototyping.

This may not get you all the way to where you want to go — but it will let you learn a little more about the technologies if you’d prefer not to hire an RF engineer right away.

Battery Power

If you want to do something which is easily deployed, you will need to think about using battery powered devices.

For example, the Lattice Framework has a specific node type which is a temperature sensor used for sensing the temperature in an area of a building. It comes in a neat sensor case and runs on two AA batteries. It can be affixed to a wall in less than a minute — whereas if it needed a power supply it could take an hour or more.

But doing something like this brings its’ own challenges. Did you decide to use wifi or bluetooth (non-LE) to communicate with your remote sensors? Well, then you’re out of luck, as these devices will consume vast amounts of power and will not be suited to battery operation.

But — if you chose Bluetooth LE or a low power radio network, then your radio technology will (more than likely) have the ability to communicate with devices which can go into ultra low-power sleep modes.

Take for example, a device which on average consumes 100mA of current at a supply voltage of 3V.

Two AA batteries in series could supply the 3V, but if they can only deliver 2000mAh before being drained, then [using a *very* simplistic calculation of 2000mAh / 100mA per hour= 20h] , they would offer a battery lifetime of less than a day.

If you wanted to achieve a battery lifetime of a year, you would need to reduce the current usage to an average of .228mA (or 228uA). If you wanted to achieve two years, it would be 114uA.

These are quite low levels — the only way to do this would be to optimise your code to minimise the wake time, and put the device to sleep for as much as possible. Putting the device to sleep is effectively telling all the peripherals attached to the microcontroller to turn off, then telling the microcontroller to go to “sleep” for a pre-determined duration.

Of course, your electronics design here will be essential as all circuits will have some sort of a “quiescent” current, e.g. the current they consume when not doing anything — for example via resistors turning electricity into heat, or ICs using a small amount of current to stay in a ready state.

So — professional advice is definitely needed here — preferably from a good engineer who has done it before, and preferably with the exact microcontroller type you’re tagetting.

Conclusions

Wireless can be tricky — and battery powered devices have their own problems. Make sure you take time to think the issues through before you plan on talking to other devices, especially if they need to be battery powered.

Next time out, let’s move away from the hardware for a bit — I’ll take a look at the Topology of the rest of the system and the Data Model.

Update — Part 4 is now available: Topology, Data Model and Languages

—

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