IoT Platform Strategy

IoT Practical Limitations

The best opportunity for using microcontrollers to measure sensor data at 1 kHz requires that only moderate duration bursts are recorded and then sent buffered to a cloud based server for post-processing. Continuous secure transmission of sensor data by wireless / wired / fiber cable to a cloud server is limited to a sample interval of 1000 ms or 1.0 Hz. Continuous measurement of sensor data sampled faster than 1 sec / 1 Hz will require local processing at the microcontroller level (if the data processing is simple), or a full PC with data analysis software, and then transmission of the analysis results to a cloud based server (e.g. Edge Computing / Computational Storage technologies).

Sample Rate

Most IoT microcontrollers can achieve a sample rate of 1 kHz for a single channel. This is sufficiently fast enough for nearly all mechanical systems with events in the 100 Hz range (many less than 30 Hz). The 1 kHz sample rate is required to avoid aliasing issues associated with 100 Hz signals.

On ATmega based boards (Arduino UNO, Nano, Mini, Mega), it takes about 100 microseconds (0.0001 s) to read an analog input, so the maximum reading rate is about 10,000 times a second (10 kHz). You can boost that to as high as 77 kHz using a special ADC free running mode, but with restrictions on the other resources on the microcontroller. A good strategy is to limit sampling to every 1 ms or 1 kHz per channel.

Particle Gen 3 devices can read an analog input as fast as 10 microseconds or 100 kHz. Faster analog input reading is possible with special DMA techniques.

Sensor To ADC Connections

You can extend the range between a sensor and a microcontroller in an industrial environment using a 4-20 mA connection (12 m / 39 ft via 18 AWG wire). However, considering the low cost of a microcontroller, it makes more sense to put a microcontroller directly at the sensor and then send the data from the sensor location to another location via a wired or wireless connection.

Data Communications

Packaging Sensor Data

You can perform a resonable level of pre-processing of the sensor data right at the microcontroller (maximum, mininum, average, etc.) prior to sending the data. You may also decide to limit how often a value is transmitted based on how much it has changed since the last transmission. Any data message can easily include a UTC based date/time stamp, and even the GPS location can be added where relevent without too much cost or complexity. Some level of encryption of the message is also possible with most IoT microcontrollers. An unencrypted signed floating point value with six significant digits and a RFC3339 date/time stamp consumes 31 bytes (Ex. "20200216T150644Z;+6.534755E+06").

Comparison of Data Communication Methods

Connection	Type	Distance & Rate Limit	Node Limit
4-20 mA analog only	wired	18 AWG 12 m / 39 ft	1
RS485	wired	100 kbs @ 1200 m 35 mbs @ 12 m bps = m * 10^8	32
CAN bus	wired	250 kbit/s (J1939) 250 m / 820 ft	30
Ethernet	wired	10 Mbps minimum 35 m (single cable)
WiFi	wireless	~ 2.4 GHz 46 m / 115 ft indoor 140 m / 459 ft outdoor
Cellular	wireless	255 bytes every 250 sec (low $)
LoRa [1]	wireless	19.2 kbps 1000 m / 3281 ft outdoor	1 Tx to many (~1000) Rx
Bluetooth (BT & BLE)	wireless	10 m / 33 ft 2 Mbps BT; 1 Mbps BLE	1 to many

[1] LoRa RFM95 @ 900 MHz (Americas) configured with 1 kHz transmission rate (of messages less than 252 bytes) and RHReliableDatagram (messages are acknowledged by the recipient, and unacknowledged messages are retransmitted until acknowledged or the retries are exhausted). RFM9x series of LoRa are limited to a message packet of 252 bytes (limited by the radio's internal buffer).

WiFi Data Transmission

WiFi seems at first to be a great solution when available, but any change to the SSID or authentication credentials over time can cause the device to require an update of the application code in order to achieve connection to the WiFi network. The WiFi credentials can be managed manually (see Get new ESP8266 WiFi credentials via local Access Point)

Cellular Data Transmission

Transmitting IoT data over a cellular network can resolve many connectivity issues, especially in remote data collection scenarios. It is common for transmitting devices to be able to receive firmware updates over-the-air, making long term management very simple.

The major challenge with sending data over a cellular connection is the data transmission rate. The data transmission rate includes the size of the data, and how frequently the data needs to be sent. Although you can tether your laptop to your cell phone and under 4G or better achieve a reasonable internet connection, IoT connections are generally more challenging. The best strategy is to strive to a IoT message size of 255 bytes or less sent no more frequently than every 250 sec or 10541 messages per month. This keeps the monthly data usage below 3.0 MB per month. You can do occasional bursts of say 4 messages in one second, provided it is followed by a corresponding recovery period. Higher data transmission rates and usage per month are possible, but you get into excessive costs, and you also begin to experience limitations on the receiving end at a transmission rate of 2,500,000 messages per month or one message every 1.0 second (the general limit is 10,000,000 messages per month or one every 0.22 seconds).

The first and most simple method to manage transmission rates is to only send data from the IoT device when the value has changed significantly, or if a specified duration since the last transmission has elapsed. This is fairly simple to implement in the IoT device code, and depending on the data, can provide significant savings.

Some data services such as Blynk that provide the capability of sending data from and IoT device to a custom Blynk app on your phone, limit the transmission rate to every 60 seconds per channel, or 4392 messages per month. If that IoT device sends the data through Particle's Cloud, then the rate needs to be limited to every 90 seconds in order to keep the data usage below 3.0 MB/month.

Keep An Eye Out For

NI's Edge Storage and Data Transfer Service (DTaaS) claim a storage capacity of 200+TB and data throughput of greater than 6GB/s.