Nearly all IoT & IIoT sensors have a internal sampling rate, and an interval when the sensor data is transmitted to the cloud. It is common for the transmitted interval to be in minutes, although for a premium (especially cellular), you can get this interval down to a second. It is frequently the situation where the value that is transmitted is the sensor value at that instant, not the maximum or minimum value since the last transmission. For very slow changing conditions such as temperature and humidity, this is not a problem (unless the transmission interval is in hours). But for anything involving a change in state (switch on/off), a proximity sensor, vibration sensor (accelerometer), tilt/inclination, etc. then an important event can and is likely completely missed between tranmission intervals.
Just because a sensor has an internal sampling rate of 1 kHz (1000 samples per second) for example, doesn't mean that you are achieving continuous monitoring, unless the microcontroller managing the sensor data and the data transmitted is looking for the event you are interest in. If your sample rate is 1 kHz, but your transmission interval is 5 minutes, you could be completely missing what happened in all but the last second of that five minute interval.
Nearly all mechanical systems have events less than 100 Hz, and many less than 30 Hz. From a sampling perspective, that means sample rates of 1 kHz or 300 Hz, respectively. The exception to this is some impact/vibration events, where events occur in a few kHz range and 10x higher sample rates are required. Nearly all microcontrollers can sample a sensor input at 1 kHz, and the more popular faster units can easily sample at 10 kHz without any special A/D tricks.
Some sensor signals experience short duration bursts of high amplitude activity, and then the remaininig time is low amplitude. These types of events can be monitored with a level crossing algorithm that looks for the occurance of when the input signal exceeds a predetermined threshold, triggering an event handling routine.
The most simple event handling routine would continue to record the data for the signal that exceeded the threshold, and then stop recording when the monitored signal falls below the threshold. Unfortunately this can easily capture too much data to be transmitted by traditional IoT systems. A modification of this method would to also record the data for all other sensor inputs that may be relevent to what is being monitored. But this exacerbates the data size problem.
A more data size minded event handling routine would locally buffer the signal monitored, and then after the signal falls below the threshold, post process the buffered data, identify the peak value, and then transmit that value (possibly along with the values of any other relevent samples at the time of that peak). In order to post process the data as described, it would either be necessary to stop monitoring the signal of interest in order to do the processing (risking that another event is missed), or performing the post processing task as a parallel process / multitasking. Most IoT microcontrollers do not have multiple execution capabilities (they perform sequential execution of the instructions). The time required to post-process the data and transmit it would be fairly short, so it may be an acceptable compromise.
In the case of vibration data, it may be more useful to perform a frequency analysis (FFT) and root mean square (RMS) calculation on the buffered event, and report only those results. The FFT will identify the dominant frequency of vibration, and the RMS tells you about the energy content of the vibration profile. These calculations can be performed with a microcontroller. Note that the FFT works well when a finite number of dominant frequency compoents exist. When this is not the case, then a power spectral density (PSD) analysis needs to be performed to characterize the random vibration.
WARNING: It may be tempting to simply monitor the signal after the event handling is started, and assume that a peak has occurred as soon as the next value measured is less than the prior value. All signals will have noise and other influences that will cause local minimum values in the signal. The only way to truly capture the peak for an event is to first have a start and end point for the event, and then to scan the event data.
I am amazed at how often a company offers hundreds of battery powered wireless IoT sensors, and gateways to transmit that data to the cloud, but no Global Positioning System (GPS) hardware. Recording the latitude/longitude position of a stationary object is not normally useful, but anything being transported or moving certainly benefits from the recording of positional information. Good quality GPS units are easily found for $20 or less. They also provide the date/time from the GPS signal in UTC. The latitude and longitude values in decimal degrees format, only need three decimal places to achieve a location accuracy of 111 meters at the equator. That's a small data packet.
Frequently users of high end data acquisition systems forget to set the internal clock of the device to Coordinated Universal Time (UTC) and document that fact. Why UTC? Well, if the unit under test is configured for the local time where testing is configured, and then transported to a location across a time zone, and the configuration is not carefully recorded, it may be unclear later what the date/time values represent. Note that the GPS UTC time signal is not a very accurate source for the date/time value, and should only be used perhaps to sort out an ambiguous setting for a device real time clock (RTC). Always include RTC date/time stamp with the IoT data transmitted. Don't rely on the cellular transmission date/time information, or when the data is imported by the cloud service. Those activities can be delayed depending on connectivity, etc.
A 50 kHz sample rate will capture 5 kHz vibration/impact events. 50 kHz requires a really fast microcontroller and/or special A/D sampling techniques because 10 kHz is the easier limit.
Use level-crossing to determine when an event of interest starts and ends. Record the signal sampled at 50 kHz and store locally for detailed analysis later when the data can be physically downloaded (not wirelessly). Calculate a time-at-level histogram from the data and add this to a running cumulative profile stored locally. Calculate the peak value from the event and transmit that value. Resume level-crossing monitoring.
At the end of the transportation event, you will have detailed event information, along with a duty cycle that can be derived from the cumulative time-at-level histogram data.
Measure +/- tilt in three axes, plus ambient temperature and humidity. Capture the peak value for tilt and humidity, and the maximum & minimum for temperature since the last transmission, and then transmit those values.
GPS position information is frequently missing from these IoT devices. Which is ridiculous, considering that the hardware costs about $20, and the data payload is only 17 bytes per transmission (unencrypted) when four decimal places are included (accuracy to 1.11 meters at the equator).
A real time clock (RTC) set to Coordinated Universal Time (UTC) costs only a few dollars for the hardware, but tells you precisely when the event was recorded.
A 50 kHz sample rate will capture 5 kHz vibration/impact events. 50 kHz requires a really fast microcontroller and/or special A/D sampling techniques because 10 kHz is the easier limit.
Use level-crossing to determine when an event of interest starts and ends. Record the signal sampled at 50 kHz. When the event is over, post-process and perform a frequency analysis (FFT) and calculate the root mean square (RMS). Transmit the dominant frequency of vibration data and the RMS value. Resume level-crossing monitoring.
The FFT will identify the dominant frequency of the vibration, and the RMS tells you about the energy content of the vibration profile (how damaging it is).
Measure ambient temperature and humidity. Capture the peak value for humidity, and the maximum & minimum for temperature since the last transmission, and then transmit those values.
GPS position information is frequently missing from these IoT devices. Which is ridiculous, considering that the hardware costs about $20, and the data payload is only 17 bytes per transmission (unencrypted) when four decimal places are included (accuracy to 1.11 meters at the equator).
A real time clock (RTC) set to Coordinated Universal Time (UTC) costs only a few dollars for the hardware, but tells you precisely when the event was recorded.
Do you need help developing or customizing a IoT product for your needs? Send me an email requesting a free one hour phone / web share consultation.
The information presented on this website is for the author's use only. Use of this information by anyone other than the author is offered as guidelines and non-professional advice only. No liability is assumed by the author or this web site.
Sitemap | Copyright © 2014 - 2024 Mechatronic Solutions LLC
Web site by www.MechatronicSolutionsLLC.com | | 7.5730 ms