Low Power, Wide Area Networking and its Advantages in Agriculture 

In the ever-evolving landscape of agriculture in 2024, the integration of Internet of Things (IoT) systems has become a key aspect of a successful operation. When deciding to implement IoT systems into an agricultural project, it is important to consider which networking solution is right for the application. Among the array of options, Low Power, Wide Area Networking (LPWAN) emerges as a frontrunner, offering many advantages that cater specifically to the agricultural space’s diverse needs. 

Longer Range for Rural Environments: 

One standout feature of LPWAN is its impressive range, making it an ideal choice for the expansive and often remote landscapes of gorw sites. With a effective range often spanning from 2 km to up to 20 km, LPWAN excels in providing connectivity even in a long distance environment. This extended reach ensures that agricultural operations covering vast areas can stay connected, facilitating efficient data transmission across fields large and small. 

Enhanced Connectivity in Challenging Terrain: 

IoT for agriculture often needs to be deployed in a diverse range of terrain, from dense forests to vast open fields. LPWAN’s ability to penetrate through obstacles and navigate irregular topographies makes it well-suited for such environments. This adaptability ensures that critical data can be transmitted reliably, even in the face of geographical features that would interfere with other methods of networking, providing farmers with a reliable real-time understanding of their land, often in areas that other technology cannot be effusively deployed. 

Low Power Consumption: 

When operational efficiency is paramount, as is the case with managing labor and natural resources, the low power consumption of LPWAN stands out as a key advantage. Unlike traditional networking solutions that may require frequent battery replacements or significant dedicated energy sources, LPWAN devices boast prolonged battery life, only turning on when transmitting, and only for exactly as long as needed. This directly translates to reduced maintenance efforts and costs, allowing farmers to focus on optimizing their processes without the constant concern of powering or replacing devices. 

Cost-Effectiveness: 

Implementing IoT solutions in agriculture can be a significant investment. LPWAN, with its cost-effective open-source infrastructure, presents an attractive option for farmers looking to enhance their operations without breaking the bank. The extended range of LPWAN also means fewer base stations are required to cover large areas, further contributing to the overall cost efficiency of adopting this technology. 

Diverse Applications: 

The adaptability of LPWAN technology is one of its primary strengths, enabling a range of applications in agriculture. From soil monitoring and crop management to depth sensing and smart irrigation systems, LPWAN provides a versatile platform for implementing a huge set of use cases from a single device. This versatility empowers farmers to tailor their use of LPWAN according to their specific needs, fostering innovation and efficiency across various aspects of agriculture and telemetry. 

As the agricultural industry continues to embrace the era of IoT, Low Power, Wide Area Networking emerges as a compelling choice, offering an extended range, adaptability to challenging terrains, low power consumption, cost-effectiveness, and a versatile platform for diverse applications. In a world where precision and real-time data are paramount, LPWAN stands as a testament to the potential synergy between technology and agriculture, helping usher in a new era of smart and connected farming. Zenseio produces versatile, open-source technology that is designed to allow a maximum level of flexibility while minimizing cost and power consumption. To learn more about how Zenseio can enhance your IoT, visit: https://zenseio.com.  

Key considerations for IoT sensor devices: 2 – Power consumption efficiency

Executive Summary:

• Battery replacement impacts the bottom line
• Power efficiency reduces operating expenses
• Energy harvesting eliminates battery replacement
• Power efficiency enables new energy sources, miniaturizes size, and slashes cost
• Power optimizations is an expert domain

Details:

Many, if not most, of the IoT sensor device deployments are in remote or difficult to access locations without any power grid access, and, thus, are battery operated. This makes replacement of depleted batteries a major cost factor. While the batteries themselves may not be very expensive, the labor to access and replace them can be very high, negatively affecting operating expenses. Therefore, power consumption efficiency is one of key factors behind business case profitability, or, even, feasibility. Anybody intimately familiar with embedded hardware understands that there is no free lunch when it comes to optimizing for low power. There are many conflicting tradeoffs to balance, and it takes considerable effort, skill, and experience to produce an optimal solution – a subject, in itself, covered by scientific publications, academic books, and PhD dissertations.

However, in general, the more computationally powerful the embedded hardware, the more power it will consume or the harder it is to optimize. So, as the starting point, right hardware has to be chosen for a given task. For example, running Linux-based software to make a simple sensor readings with a powerful processor will almost always take significantly more energy than doing the same readings with a power-optimized microcontroller with no Operating System (OS).

The benefit of low power consumption of a device is not only less frequent trips to replace batteries, but also a possibility of getting rid of batteries altogether. It opens a possibility of powering a sensor device by harvesting the available energy from the environment. And, while true that even the whole households can be powered from collected solar or wind energy, the size, cost, maintenance needs of such equipment are huge. Needless to say, the lower the power consumption, the smaller, cheaper, and easier to use the energy harvesters can get. Also, more types of energy harvesting sources become feasible, for instance motion/vibration, thermal, or electromagnetic fields in addition to solar and wind.

Key considerations for IoT sensor devices: 3 – Ease of use

Executive Summary:

• Easy to use or die
• Using off-the-shelf components/boards is mighty hard
• Ease of use needs to be matched to a user’s desire for flexibility
• Ease of use can be provided for by a system based on best proven, popular software frameworks

Details:

Unless a sensor device is easy to configure and use, it will have a very limited traction in practice. The reason is simple – embedded engineers are too expensive to hire by many System Integrators or by most companies that just want to implement IoT applications in their business. At best, they may hire technicians and provide some on-the-job training for them. But, in many cases, the job will be done by non-technical personnel who understands their business process jobs, but not the details of technology. A good analogy is how personal computers are used at companies these days.

Frankly, today’s IoT devices, which encompass a wide range of technologies within a single system from sensors, through power management, through microcontrollers, through wireless/wired communications, to cloud data interfaces and devices life-cycle management, are intimidating even for seasoned embedded computer and communication experts. Defining and putting together such a complex system from individual, off-the-shelf components requires deep and specialized knowledge and skill. Furthermore, writing embedded firmware that logically connects all these components and makes the system perform its tasks in an optimal way is even harder and requires somewhat different skillset. Once the devices are prototyped and considered suitable for real-life deployment, the next step is to productize them. This development stage may dwarf the the other ones in terms of involved cost and the need for uniquely specialized knowledge: design-for-manufacturing, design-for-test, production sourcing and supplier management, logistics – to name just a few considerations. The more stringent the application requirements, such as harsh operating environment in an industrial settings, the more challenging the this stage is.

What’s needed is an industrial grade, configurable hardware platform that progressively balances the ease of use with customization capabilities to match the varying skillsets of different types of users.

With the ready-to-use, hardened hardware modules, pre-integrated firmware framework and the widely popular script programming environment that even schoolchildren and artists can use, the challenge of configuration and programming of a sensor devices is greatly simplified while still providing much flexibility and freedom that is needed. Additionally, a very quick and painless transition can be made from an application prototype to real-life deployment.

Key considerations for IoT sensor devices: 6 – Cost effectiveness

Executive Summary:

• Cost-effectiveness is very important for sensor devices
• In IoT, cost effectiveness is a system-level, not a component-level, optimization
• Full-custom versus semi-custom versus off-the-shelf hardware is an complex application-specific tradeoff to be made

Details:
IoT systems dramatically benefit from localized data collection. The more granular the data localization, the better business decisions can be. Therefore, it is imperative for the IoT sensor devices to be cost effective to enable widespread deployments and to be able to reduce the overall business costs. Due to this desire for larger unit volume deployments, connected sensor devices need to be as as low cost as possible – cost competitive to other commodity devices with similar hardware features and capabilities.

Nevertheless, unlike many other simpler types of products, IoT is a complex system solution. To truly achieve cost effectiveness, the whole system cost has to be optimized – focusing on cost optimization of a single component may not result in the lowest overall system cost over the product’s intended lifespan.

For example, for some applications, field maintenance operational expenses (opex) may dwarf the capital expenditures (capex) for the cost of sensor devices, especially if those “things” are installed in very remote locations. Ultra low power solutions that reduce the time between battery replacements or that are self-powered by harvesting energy from their environment are proven methods of drastically reducing opex at minor increase to capex.

In some IoT applications, better quality and variety of sensors in a sensor device may allow to reduce the number of deployed sensor devices, thanks to their increased range and sensor fusion capabilities. Alternately, a device that can better compress or reduce the transmitted data, may have a huge impact on the reduction of wireless data usage and connectivity costs (for instance for satellite and cellular) or to enable switch to more cost effective methods of wireless communication (for example switching from cellular to LPWAN).

Another important tradeoff is how the sensor devices are designed and produced. This ranges from full-custom design through semi-custom design to using off-the-shelf components. The chosen approach should depend mainly on the nature of the application, specifically how many identical sensor devices are needed and if there are any special requirements to meet, for example a physical form factor, a unique type of sensor used, or operating conditions vastly different from those found in typical deployment environments.

Developing a fully custom-designed sensor device for a specific IoT application may not be a cost effective solution if the unit volume is low or even mid-size. The NRE (Non-Recurring Engineering) costs are typically very high for such custom high-tech products, and have long development and compliance certification lead times, especially those containing RF circuits. Any potential cost savings from optimizing the component BOM (Bill Of Materials) are dwarfed by the incurred NRE costs. Oftentimes, a more cost effective way is to use a multipurpose hardware platform which is amortized among many users and only to pay for any required minor customizations required to make such solution suitable for a given application.

Although the product selection process is a complex tradeoff between cost and benefits, here are some general rules of thumb:

• For large deployments, more than 20,000 of identical units, or for specific form-factor implementation, full custom design may likely be the right choice
• For fast time-to-market or small to medium unit deployments, it should be more beneficial to use pre-qualified off-the-shelf components if they are available. Appropriately configured modular hardware platform with off-the-shelf modules, slashes time-to-market without overpaying for the features not needed.
• For unique IoT application requirements where off-the-shelf components don’t exist, consider a full-custom solution, but not before investigating a semi-custom solution based on multipurpose, modular hardware platform – where only a specialized module needs to be developed with other subcomponents being off-the-shelf. Many times, such chassis-based, semi-custom solution will be a more cost effective than full-custom solution as the bulk of hardware platform cost is amortized among many other users.

In any case, good understanding of the requirements for the overall business IoT application and the underlying technologies – not just sole focus on selecting the lowest cost components – is the primary factor that will determine financial success or failure in the IoT-powered business.

Bottom line: versatile, high quality, and capable IoT sensor devices are the most cost effective components for majority of IoT applications.

What is the anatomy of IoT sensor devices?

Executive Summary:

• IoT Sensors include three fundamental functions: sensing, communication, and power supply, as well as additional functions: processing/system management and user interface
• IoT application is determined by the types of sensors, cloud connectivity, power sources, and (optionally) user interface used in an IoT sensor device
• It is possible to realize a variety of IoT applications with a single IoT sensor hardware platform by employing appropriate functional modularity and interface abstractions
• An application processor and well defined interfaces help abstract functions for versatility and ease of use

Details:

There three fundamental functions that any IoT sensor must include:

1. sensing the required physical conditions
2. transmitting the sensed data
3. being energized

Communication may be wired or wireless, direct or indirect – as long as sensor data somehow gets from the a sensor to public or private cloud service. Sensors may be internal to the IoT sensor device itself or external (perhaps embedded in another piece of equipment). If a sensor is external, IoT sensor must provide an appropriate interface to it. Energy sources may be internal (eg. batteries), external (eg. power mains), or hybrid (eg. external energy harvester source with internal rechargeable battery).

However, looking closer into an IoT sensor, there are other important functions it contains. Aside from the simplest forms of implementation, it needs some processing capability to manage the overall device operation. How and where the processing function is done depends on implementation choices, typically driven by cost and ease-of-use considerations. For instance, as some wireless radios need sophisticated processing, they may have more than enough horsepower to also provide application processing for a sensor reading and formatting. In such a case, the system management function may be combined with the connectivity function, but, potentially, at the expense of ease of reuse of the sensor processing paired with a different type of radio communication device.

Additionally, in some applications, an interactive user interface (UI) may be needed to configure or control the device operation. An UI may be as simple as an LED and a push button or as complex as touch-screen display or a GUI application on a paired smartphone. As many IoT sensors have to be fully autonomous devices, UI capability is added only whenever it is needed.

IoT application applicability is determined by the types of sensors, cloud connectivity, power sources, and (optionally) user interface used in an IoT sensor device.

For example, a Smart Agriculture IoT application used to optimize quality and yield of wine grapes may need soil moisture, temperature, and relative humidity sensors to monitor localized conditions around vines. IoT sensors for agriculture being out in large fields, need long range wireless communication to a gateway connected to internet. The sensor devices need to be powered from a harvested energy source, such as abundant solar power as there is no power grid in the field. There is no need for any UI. A suitable IoT sensor would then have the following hardware configuration:

• Sensors: soil moisture, temperature, and relative humidity
• Wireless radio: LPWA (low power wide area), such as LoRaWAN
• Power Supply: self-powered from harvested solar energy with a rechargeable Li-Po battery to provide energy even during cloudy days
• UI: none

Let’s look at another example. The IoT application is to monitor for water leaks at a school building, to warn of water damage from burst pipes during unoccupied hours (weekends and nights) before the damage to the building is extensive. The sensor is sensing for water moisture conditions (alternately it may monitor the flow of water in main supply pipe). Since the school building has adequate Wi-Fi coverage throughout, Wi-Fi radio connectivity is appropriate and low cost. There is power outlet in every bathroom, so the sensor device can be powered from an external power supply unit. UI is needed to configure wi-fi credentials during the deployment and to locate a deployed device via audible sound. A suitable IoT sensor would then have the following hardware configuration:

• Sensors: moisture sensor (electric conductivity)
• Wireless radio: Wi-Fi 802.11n
• Power Supply: 5 Vdc from external power supply unit
• UI: Wi-Fi Direct paired to a smartphone (for Wi-Fi credentials configuration) and piezo buzzer (for audible localization)

These two examples illustrate that while the details of the implementation are very different, the fundamental IoT device structure is the same. This means that a single sensor device hardware platform could be devised for seemingly different IoT applications with appropriate level of abstraction of interfaces for sensors, radio, power supply, and UI within the sensor device. Such abstraction can be achieved by employing modularity where different types of sensor iot, communication channels, and power supplies are implemented as interchangeable modules with well defined, common interfaces. A separate application processor in the chassis that connects the modules together provides firmware level of abstraction, that speeds up development time by reusing common firmware components and IDE despite variations in populated modules.

Thus, with enough insight into the anatomy of IoT sensor devices, a versatile, easy to reuse, and cost effective hardware platform that implements a great variety of IoT applications can be realized.

Key considerations for IoT sensor devices: 5 – Industrial deployment readiness

Executive Summary:

• Hardware prototypes are far from deployment-ready
• IoT sensor productization is an often overlooked, complex, specialized task that drastically impacts time-to-market and cost
• “Hardware is hard” is not a cliché, especially for highly reliable industrial applications

Details:

As mentioned above, there is a significant challenge going from a well working application prototype to a product ready for real-life field deployments in terms of the required level of effort, specialized skillset, as well as development time and cost. What might work well in climate-controlled lab environment may behave erratically or unreliably under stressed environmental conditions where an industrial device is expected to operate reliably over the course of many years.

Oftentimes, productization aspect is an afterthought, despite being one of the most important factors deciding between a product’s success or failure. Without relevant experience to rely on, many customers fall into a trap of thinking that having their secret sauce firmware ported into an IC vendor’s evaluation board (EVM) is all it takes to create a product ready for deployment. What they don’t realize is that even though the EVMs they use often high quality and sometimes low cost, IC manufactures won’t sell them in any quantities larger than a few units to a single end customer and frequently have legal restrictions in fine print that these EVM’s are only for IC evaluation and product development, forbidden to be used as actual products. Another widely popular prototyping platform are Arduinos. While Arduinos have no legal restrictions as above, they are not reliable industrial grade products designed for industrial environments nor optimized for low power consumption. These solutions are great starting points on a long and arduous road to real industrial product development that may cost upwards of $100K and many months to finish-line. In particular, use of RF circuits, which are required for wireless communication, adds major productization complexity, schedule delays, as well as additional high development and regulatory compliance costs. There is a saying in the industry that “hardware is hard” – these are some of the reasons.

This is typically what prototyping looks like – far from production readiness

2G/3G Sunset

Our friends at Multitech remind us about impending 2G/3G sunset with the US carriers.

Replacing the cellular-based sensor infrastructure takes time and good planning. Don’t be caught off-guard.

LoRa is a proven, low-cost alternative to LTE, especially for Smart Ag applications. Zenseio has had LoRa sensor solutions deployed on fields for the last year, and customers are happy to dramatically reduce their recurring connectivity costs.

If interested, drop us a line.

IoT Hacking for a Greater Good and Profit

• by Roman Staszewski
• February 1, 2017

What will happen when you lock a bunch of hackers, entrepreneurs, and mentors into a room for two full weekends, give them powerful tools, dangle a valuable prize, and ask them to come up with an idea for an industrial IoT product? This was an experiment masterminded by my dear friend from college days, Tahir Hussain, who heads a tech accelerator – Collide Village in the Dallas metroplex. And, it was executed just recently.

On a fall afternoon last year, Tahir told me about his hackathon idea and asked me to provide mentorship as well as to sponsor Zenseio IoT hardware for the event. He was lining up the leading IoT companies as partners and successful local businessmen/entrepreneurs as mentors. It sounded like an interesting idea, so I jumped on it without hesitation.

The time commitment for everyone involved was significant. Participants, mentors, and organizers had to sacrifice their two full weekends. This attracted only the most driven, hardcore participants and filtered out just the curious ones. Still, over 120 participants signed up at the “Collidathon” and great majority survived to the finish line.

Lots of ideas flowed freely, and teams quickly formed around the most promising ones. The ideas were rough diamonds in disguise that needed to be shaped, polished, and validated.

Participants eagerly started working on business plans and prototypes. The IoT tools that were available for prototyping were Zenseio IoT devices, STMicroelectronics dev kits, Intel Edison dev kit, Senet LoRaWAN network, Microsoft Azure Analytics, and Ericsson Blockchain.

I was happy to see that the majority of teams picked Zenseio LoRa devices and it all went went very smoothly. In no time, everyone signed up for Senet account, configured Zenseio devices, and was streaming live sensor data to the cloud – Microsoft Azure or myDevices Cayenne. Many teams went way beyond expectations and started modifying hardware and firmware to add their own custom sensors.

What has traditionally been hard about hardware was actually the easiest step here. This afforded the aspiring entrepreneurs more time to focus on the core product concepts, business and application development. As some applications were using GPS for localization or asset tracking, they were able to immediately run outdoor pilots and to remotely collect reliable data with the Zenseio devices, without dangling wires as typical with Arduino and other prototyping dev kits.

At the end, the rough ideas were turned into actionable business plans and demonstrated with the functional full end-to-end prototypes. It was amazing to see what was accomplished in such a short time. And, the IoT applications that were championed strived to make the world a better place. Some examples using Zenseio devices:

• Using environmental sensors to learn about daily patterns of elderly folks living alone and to provide immediate notification to caregivers in case of unexpected events or emergencies
• Turn the trash in “smart” commercial dumpsters into monetized “gold”, using sensors and blockchain
• Gamify recycling and proper trash disposal into “smart” bins to make the planet greener
• Provide easy localization guidance for emergency responders to quickly find victims in case of emergency

The Collidathon turned out to be a success. While it was a close race, three teams won cash and an invitation to the Collide Village incubation program, totaling $20K.

For me, personally, I gained a few friends and valuable connections, and I was glad to see that Zenseio devices made very easy and quick for entrepreneurs to prototype and pilot their IoT ideas. There is nothing more inspiring than a complex IoT ecosystem of products and participants working harmoniously to address human challenges and striving to make the world a better place.

And, by the way, for fun, we also celebrated the Chinese New Year of Rooster on Saturday night at the annual “Different Approaches” party hosted by Mike and Quyen Courtney, featuring a live rooster 🙂

Tags:HACKATHON

IoT Security and 100 Million of Volkswagens

Researchers just published a startling discovery we’d never want to read about. It turns out that 100 Million Volkswagen vehicles sold since 1995 can be relatively easily hacked to open doors wirelessly without having the key.

It turns out 100 million vehicles used only a handful of private shared keys. Once a single private key is breached, millions of vehicles are compromised. The way cryptography based on Pre-Shared Key (PSK) works is that two devices (a vehicle and a key fob, in this case) share a secure private key that was programmed at a factory or at a dealership. This private cryptographic key, along with a rolling code are used for encrypted wireless transmission of authenticated commands to open/close doors.

With enough compute power, pretty much any secure communication can be cracked with brute force attack. But, in many cases, this may not be practical. The older VW Remote Keyless Entry (RKE) systems were trivial to crack, but the latest schemes ones are more robust. However, another, easier attack, is to snoop the memories of vehicle’s electronics for the private keys. This is what happened here. The secret keys were not so securely stored, and they were read out from the vehicle microcontrollers by people skilled at this. Normally, only one vehicle would be compromised (and only after hackers broke into the vehicle’s interior, in the first place). But, whether by ignorance, laziness, or mindless “cost-cutting”, 100 millions of vehicles and their key fobs were programmed with just a few common secret keys used worldwide over decades. So, once one vehicle got hacked, millions of others were compromised. Oops, another of Volkswagen’s expensive screwups. (To be fair, VW is not the only large corporation to suffer from such a security breach, but this one has been the most spectacular so far.)

IoT Security

So, how does this relate to security of IoT connected devices and sensors? Think of Volkswagens as IoT devices. Similar cryptography schemes are used to secure the communications between sensors and cloud services. While older obsolete cryptographic algorithms offer little protection to eavesdropping or spoofing, more advanced algorithms, such as AES-CCM are considered state-of-art for resource-constrained devices.

They use secret Pre-Shared Key along with another piece of information, called Initialization Vector (IV) are used for authentication and encryption of the information being transmitted. The IV is additionally incremented with a monotonic counter, so that the transmissions with the same payload data, always generate different encrypted messages. If there is enough secret key and IV bit length and randomness, this scheme can be very effective in resisting brute force hacking and spoofing attacks, especially for low-cost IoT devices that use low-power, long-range wireless communication.

But, these state-of-art cryptographic algorithms are only as good as the secrecy of the private keys, the design of the security system, and deployment methodologies being followed. Just like your credit cards are secure as long as you are careful whom you hand them to and how well you protect your wallet.

IoT security is a rightfully serious vulnerability today because, many times, it is designed and deployed by people who don’t understand the interplay of the technology nuances and the application’s  business risks. When cost pressures inevitably show up (these are supposed to be low cost devices, after all), wrong compromises are made. While there were many security breaches similar to the Volkswagen’s, and a few were as well publicized, my feeling is that the majority received little press and many more are the “ticking time-bombs” still waiting to happen.

Zenseio’s IoT device platform offers strong built-in security features. The private keys are uniquely and randomly generated for each device and stored in secure hardware crypto vault. After being written once, private keys can never be read back. Our devices will also prevent revealing of internal secrets through physical hacking or reverse-engineering, such as probing for voltage, temperature, frequency, light, or electromagnetic field signatures. Even if one of the devices is cracked with brute force cryptanalysis, others are unaffected. Additionally, as each device uses unique internal secrets for authentication of messages, spoofing attacks are also prevented.

Not every IoT application needs this high level of security. In fact, most applications are better served by less stringent key management schemes, but still using the state-of-art cryptography algorithms (which we support out-of-box) as they are easier to use and maintain. However, if your application needs ironclad security, we have built-in hardware features to deliver a hacker-resistant solution.

Sources:

IoT Epoch Time Disaster? Only Time Will Tell

Ever heard of the “epoch time”? I’m not talking here about  history periods or geology. Epoch time is simply a standardized time and date reference used in UNIX and many other computers. It defines time, measured in seconds, starting from January 1, 1970 epoch. This is based on an arbitrary, somewhat historical epoch, but, what matters is that it is a commonly followed standard.

Why is this important and what does it have to do with IoT? Many IoT sensor devices have to keep track of time, so when they collectdata readings from sensors, they time-stamp them. IoT devices may collect sensor data for hours, days or weeks before sending them to the Cloud for Big Data analytics. Time-stamping helps to precisely know when the data was measured, not when it was received by a Cloud server. This is very important if the data analytics is to be correct and accurate.

Many IoT devices use what is called Real Time Clock (RTC, for short) to keep track of time. It’s a very low power electronic circuit that counts pulses from an internal clock generator. These pulse counts are converted to seconds and, then, the seconds are counted. What is the count referenced to? A convenient epoch (and, sometimes, the only one possible) is the time of the device power up. But then, the time reference would vary greatly from one device to another. If one device was powered up a month ago and another one yesterday, they  would be both showing different timestamps for the data measured at the same time, say an hour ago. Exacerbating the problem, this time-stamp reference could never be relied upon in absolute terms since the devices could be powered up at arbitrary time. It’s only good for relative time-stamps.

So, this is where the epoch time can be helpful. It’s the standard that all Cloud servers already use. There are standard software libraries written to convert human readable time to epoch time. These libraries have been ported even to IoT devices and utilized to support the epoch time reference (provided they have a communication downlink to synchronize the time reference from the Cloud server, in the first place).

Looks peachy – so, what’s the problem? Well, the IoT devices are very resource constrained because of their low power and low cost requirements. They typically use 32-bit counters for keeping the epoch time. A 32-bit signed counter can hold up to 2^32 values. That is 2,147,483,647 seconds. A quick calculation shows that this seconds counter will overflow sometime on 19 January 2038 – about 21 years from now. For industrial IoT devices this is definitely within their active deployment lifespan. But until the time rolls around, few will worry about these device limitations.

What will happen is that the sensor data time-stamps suddenly wrap around to start from January 1, 1970. Remember “Y2K bug” deja-vu, anyone? Perhaps the Big Data analytics AI algorithms may get very confused about this and draw wrong decisions and cause massive damage. Or perhaps, the AI may be smart enough to figure out what’s wrong and readjust the timestamps without a hiccup. Only time will tell.

But, why risk it? There are solutions that can be used today, that make this epoch time overflow a non-issue.

At Zenseio, we specialize in robust, industrial IoT sensor devices. In our hardware platform, we pay attention to details big and small, so our customers don’t have to worry about them. We are quality freaks.