7

I am planning to use the BNO055 Absolute Orientation Sensor for collecting the accelerometer, magnetometer and gyroscopic measurements for an application. As of now I want the data to be sent at a rate of 10 Hz to a data collecting entity (Pi or BeagleBone with wireless technology).

The setup can be:

  • 3 such IoT Things
  • 1 central collection Thing
  • Star Topology with collection point at center

From what my experience says, 802.11 WLAN seems the only optimal option as opposed to 802.15.4 ZigBee and/or Bluetooth LE(4.0). The reason being the large sets of data that BNO055 would generate and send at a very quick rate (~ 0.1 sec). I am just making a simple prototype and hence I would rather use simple UDP to send the data out.

I am currently focusing on the range factor since the placement will be within a boat's hull and that also implies there will be considerable data loss due to metallic surfaces. But I can take the liberty of running the nodes on full power (connected with power supplies or high Li-ION batteries)

Questions:

  1. Is WLAN the right choice of wireless technology for the application? If not, which other technology should I give it a try?

  2. What can be the obstacles that can occur for such a low-latency (10 Hz) type of IoT application that I can avoid or take notice of?

  • 1
    802.11 will surely provide you ample data rate. Is range a consideration here? Also do you know how much data your sensors will be sending each cycle? – sob Jun 18 '17 at 13:36
  • 1
    Are the edge things battery powered? – Helmar Jun 18 '17 at 14:03
  • @Helmar , I guess you are asking as using WiFi on battery powered devices will drain them quite fast? – sob Jun 18 '17 at 14:19
  • I am currently focusing on the range factor since the placement will be within a boat's hull and that also implies there will be considerable data loss due to metallic surfaces. But I can take the liberty of running the nodes on full power (connected with power supplies or high Li-ION batteries) – Shan-Desai Jun 18 '17 at 15:41
  • 1
    @Shan-Desai I edited your question to include these information. It's always preferable to have all information in the question. Feel free to edit in a form more to your liking. – Helmar Jun 18 '17 at 16:10
7

Latency vs Rate

a low-latency (10 Hz) type of IoT application

This is a conceptual error. Latency and Rate are largely independent. You could have a system which recorded thousands of readings per second, stored them on an SD card, and once a month someone visits the remote site, extracts the card, and mails it to you - that system would have a high rate but also extremely latency. Or you could have a system which reported readings within a few microseconds of when they are taken, but only took one reading per hour.

So the first thing you will need to do is to clarify your requirement - do you need to take a lot of data, or do you need to get it while it is still very current, or both?

A 10 Hz update rate is relatively workable for most digital transmissions schemes, except for those where there is a regulatory limit on the number of transmissions per period of time, or those which have such a low data rate (either because they are narrowband for link efficiency, or because they are crude) that they just can't move the amount of data you want to send quickly enough.

Latency vs. Reliability and Complexity

As the actual propagation time in small areas requires exotic circuitry to even measure, for local radio systems the time taken to move a message is basically the length of time to encode it - unless system design aspects add more. A system which needs to do a lot of "contemplating" of a message could add delay, though with decent software that is likely to be slight. One which requires a number of back-and-forth cycles of "discussion" per message necessarily increases the time by the number of cycles and any turnaround time of the link or protocol.

But the most likely source of delay is a Reliability Layer - if a message is missing or arrives corrupted, what should the system do? If it tries again, that almost invariably means adding delay, while if it just drops the message and moves on that may mean gaps.

For your kind of application, what may work well is an unreliable scheme, but one where each packet includes not only a current measurement, but repeats of a few previous ones (or for a counting application, a running total). And those don't necessarily need to be the most immediately recent measurements - depending on patterns of interference, the best scheme could easily end up being something like current, previous, next previous, 5th previous, 13th previous, or whatever, so that the packets that do get through tend to have a high chance of also including the data which did not.

Practical Systems

Many off-the-shelf 2.4 GHz systems would probably work fine in your example, if there are reasonable sight lines or leakage paths between the components.

  • nRF24L01 - style 2.4 GHz digital radios would easily handle the data rate, and are readily used to make fairly low latency channel hopping systems - for example, these and their competitors are used to interactively fly many inexpensive consumer drones.

  • BTLE has modes with state complexity which could be problematic, however the advertising mode is simple enough and can be run at the kind of repetition rates you are seeking. Custom receivers built around embedded boards as your propose should be able to keep up and give you the full details of each packet. There is also some cross compatibility with smartphones, however in that case the host operating system may give you only a small minority of the traffic, and may not consistently inform you when the packet contents change.

  • there are of course many other choices

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.