Menu
The area of IoT Wireless Sensor Networks has seen a ton of progress over the past 5 years, so it is not a surprise that there are more than a few technologies that are potential solutions for an IoT network deployment. Unfortunately, as is with all things in life there is no perfect solution, each tech-stack comes with its own advantages over the rest in certain scenarios and has shortcomings in some areas of application.
IoT gained its popularity in the context of smart home/building/city applications as they are more mainstream and bring more exposure to the general public. In this space it would seem LoRaWAN® is quickly becoming the go-to standard. Residential building automation, smart parking, waste management, etc., most new deployments of such type are utilizing some type of LoRaWAN® deployment whether a public or private network is utilized like Helium, The Things Network, Actility, etc. That is not to say that there are no other solutions like NB-IoT for example, but we are going to keep the Cellular side of the story outside of this discussion as it operates in a licensed spectrum, requires a subscription and is not open, which is a bit of a disadvantage in my opinion.
If we shift the focus to more specialized applications in the Industrial and Agricultural sectors things are not so straightforward. Depending on the specifics of the use-case scenarios LoRaWAN® might not be the best choice and technologies like DigiMesh (based on ZigBee) come into play as a better solution.
The rest of the article will compare the above two (this specific pair has been chosen as they are very similar in application, although different in implementation, and would present a very good base of comparison as far as the general traits of the two types of execution are concerned) and see what advantages one has over the other in what specific scenarios. In the end you should have sufficient knowledge to select the appropriate one depending on your specific application requirements.
Let us start with a condensed comparison of the main differences between DigiMesh and LoRaWAN®
DigiMesh is built on top of the same physical layer as ZigBee Mesh, with the notable difference that it has a single node type, making the network completely homogeneous. This allows for a very simplified network operation and quick deployment. This also allows the nodes to be battery-powered, whereas with ZigBee some need mains power (coordinators and routers).
In addition, DigiMesh has improved range and larger max payload size (256 bytes vs 80 bytes) over ZigBee, which is perhaps its biggest advantage over other IoT solutions, especially when compared to LoRaWAN®. Like LoRaWAN® it also works in the 800MHz, 900MHz and 2.4GHz bands (LoRaWAN® is still new in this portion of the spectrum so performance is yet to be figured out).
You can think of DigiMesh as a version of ZigBee that is specifically designed for IIoT applications to better fit the specific requirements one would have when deploying such sensor networks.
Let’s look at the minimum characteristics of DigiMesh so we can later compare them with LoRaWAN® and see where the advantages of each are.
DigiMesh is a proprietary wireless networking protocol developed by Digi International, a company known for its contributions to wireless communication solutions that also offers ZigBee and LoRaWAN®.
At its core, DigiMesh is designed around a mesh topology. Unlike simple point-to-point connections or the star topology used in some other networks (LoRaWAN®), a mesh network interconnects devices, allowing data to take multiple possible paths from source to destination. This interconnection ensures redundancy, making it harder for the network to fail if one node goes down, as it self-heals by finding an alternate device to transmit through and complete the chain.
DigiMesh often operates on the 2.4 GHz frequency band, which is globally accessible. However, it can also work on sub-GHz frequencies (800/900MHz), which might provide better range but with potential regulatory restrictions based on the region.
Given its inherent redundancy and adaptability, DigiMesh is often preferred in scenarios where reliability is crucial. This includes IoT applications, home automation, industrial automation, and environmental monitoring where nodes might be placed in difficult terrains or obstructed environments.
As it is considered a low to mid-range wireless technology it is suitable for denser scenarios limited to a building or a plot (factory, store house, greenhouse, etc.) rather than larger ones that span over a whole town or a neighborhood (start city applications like monitoring parking spaces, garbage bins, etc.)
This is a protocol stack tailor made for IoT scenarios, more specifically cases where relatively infrequent small packets of data are transmitted by the end-devices. It has great range, low latency and is easy on battery consumption as the devices strive to keep their time on air short and power consumption low.
Similar to DigiMesh it also mainly works in the Sub-GHz bands of 800/900MHz (region dependent), where it has recently received a specification update to include the 2.4GHz band (global availability).
LoRaWAN® stands for Long Range Wide Area Network. It is a protocol designed for low power, long-range communications and is built on top of the LoRa® (Long Range) modulation technique. It is an open standard with a rich ecosystem of manufacturers and service providers.
LoRaWAN® operates using a star topology. Sensor devices (end-nodes) communicate directly with gateway devices in a star formation. These gateways then relay the information to a centralized network server, called a LoRaWAN® Network Server (LNS) that incorporate all required protocol mechanics to authenticate nodes, de-duplicates packets, decrypt the data, decode and parse the payload, etc.
LoRaWAN® operates in the sub-GHz frequency bands, which vary based on region (like EU868 MHz in Europe and US915 MHz in the US). LoRa® modulation is the underlying technology, providing the long range (best in class RF penetration in my opinion) and low power consumption features of LoRaWAN®.
Due to its design for long range and low power operation, LoRaWAN® is particularly suited for scenarios where devices need to send infrequent bursts of data over long distances. Common applications include smart cities, agriculture, supply chain and logistics, metering, and other areas where device autonomy and wide coverage are key.
It is less suited for scenarios where data integrity is crucial, and large data payloads have to be delivered, like monitoring multiple parameters at the same time or measuring complex processes like vibrations that require a lot of sensor data. It is for this reason that it has not seen as wide an adoption in IIoT as it has seen in more mainstream applications like Smart Cities.
A side-by-side comparison between DigiMesh and LoRaWAN® is presented in the table below. This is a good reference if you quickly want to refresh your knowledge on the difference between the two.
| DigiMesh | LoRaWAN® | |
|---|---|---|
| Type | Proprietary, developed by Digi® | Open, maintained by the LoRa Alliance® |
| Topology | Full Mesh | Star |
| Frequency / Modulation | 800MHz, 900MHz and 2.4GHz | 800MHz, 900MHz and 2.4GHz |
| Key Features | Self-healing, Peer-to-Peer, Adaptive Routing, Simplified provisioning (all devices are the same type) | Long-range, Long-battery Life, Interference resistant, huge ecosystem of vendors and solution providers |
| Disadvantages | Limited to the same manufacturer (no interoperability) | Limited payload size and time on air dependent on local regulations |
| Main Use-cases | Suitable for high-reliability scenarios | Suitable for low-reliability scenarios (cost-efficient) |
Let us look into two example use-case scenarios, one for each technology. These illustrate very well how for a particular deployment one technology is better suited than the other and also give you insides on the range of applications each fits best in.
An example would be the predictive maintenance / vibration analysis use case where we focus on reliability, frequent transmission and the ability to carry a large payload in order to provide sufficient data for a detailed frequency domain analysis.
Good quality Vibration sensors line what NCD offers that are 3-axial, have a built-in temperature probe and/or current monitor output a lot of data. They send metrics on acceleration, velocity and displacement with a high sample rate. They also have a built in FFT analysis so you can check the main distortion components, or the option to send the full/raw time domain data (very large packet) to do an off-site vibrational analysis in detail.
DigiMesh is more suitable when device to device communication is dominant and sending data to the Internet is relatively rare, very suitable for on-premise deployments as opposed to cloud centric ones like LoRaWAN® (does not require an LNS).
A big disadvantage is that the standard is not open and there is no device interoperability between vendors, however this on the other hand allows for a simpler network setup as all devices are essentially the same type and vendor.
Very suitable for broadcast intensive applications like ModBus, as a matter of fact this is the go-to Solution for upgrading ModBus installation that used to run on wires.
In the end these types of sensors are simply too complex and output too much data to be used with an IoT technology that is optimized for short dwell time and small packet size like LoRaWAN®. DigiMesh is realistically speaking one of the only viable options to for such data-heavy IIoT applications (Wi-Fi could handle the payload, but it lacks range, security and the battery life).
A LoRaWAN® network where end-devices do not communicate directly to each other is more suitable for devices that communicate infrequently (with smaller payload sizes) and devices are not very densely located one to another. There is now LoRaWAN® Relay feature in the specifications, however a gateway is still needed (which is still a single point of failure), unlike with Mesh networks.
On the advantages side, LoRaWAN® does benefit from less network delays (less hops) and less jitter (delay variation) compared to a mesh network like DigiMesh. The simplicity of the end-devices also leads to reduced per-device cost.
An example would be a temperature and humidity monitor that transmits data relatively infrequently, with a payload optimized for minimizing size in order to provide the best battery life and device cost efficiency.
This type of network deployment is a bit more complex than DigiMesh, however, it still has advantages (for example unlike NB-IoT it requires no service level agreement with the provider). A disadvantage is the need of network planning for coverage and capacity (Spreading Factor), similar to cellular networks (although it is a lot more straightforward and time efficient) Another one potential shortcoming is the fact that Gateways are a single point of failure and add to the cost as they are more complex and require more powerful hardware, together with the fact that the LNS needs to be maintained either on premise or via a 3rd party, which DigiMesh does not require.
A good example use case scenario for LoRaWAN® would be temperature and humidity monitoring in a facility or an office. These measurements do not need to be performed in real time as it is unlikely that the temperature or humidity rise very abruptly. Furthermore, the sensor sends just a set of simple values, keeping the payload very small. The measurements can be done relatively infrequently once an hour or two to monitor overall conditions. Additionally, not a lot of these devices are required one per room/space is generally sufficient to obtain a good enough picture of the environment for the entire building. Thus, the network need not be dense (compared to the DigiMesh scenario where we can have multiple sensors on a single device/piece of equipment with multiple devices/pieces of equipment in the same space being monitored, think several sensors on a gearbox/motor where there are many of those over the factory floor).
This example scenario is very well fitted for LoRaWAN®, as the number of devices is relatively low, they do not require a high data reliability (a few missed temperature readings a day are not a major issue), and costs can be kept to a minimum with deploying just a few nodes in key places.
In general, you would want to go with a standard protocol for interoperability reasons and to avoid vendor lock (this does not apply to NCD devices as they are platform agnostic). This is a sound strategy and I would recommend it. However, taking into account specific requirements some use-cases are better suited for proprietary solutions like DigiMesh, for example the case of the Vibration Analysis sensor that simply needs more bandwidth.
On the other hand, a network of temp and humidity sensors that are not working in a dense network or in an industrial environment is more suited to a LoRaWAN® deployment. This choice will keep costs low, device longevity high and would still provide valuable data, although not as detailed, secure or scalable as in the DigiMesh case. In this particular scenario LoRaWAN® would be the better overall choice.
Take this into account when selecting your sensor technology and network type. They all have their advantages, DigiMesh being better suited for industrial environment applications where data integrity, reliability, bandwidth and node density are important. Go with LoRaWAN® if you want to have a cost-efficient deployment with a very long battery life, but you can forgo large data packets, frequent transmission and cost overhead for redundancy.