Now, when I go to the Digi International website, and see what they say about DigiMesh, it says:
DigiMesh is a proprietary wireless mesh networking topology developed by Digi’s RF engineering experts which allows for time synchronized sleeping nodes and low-power operation. One unique aspect of DigiMesh, compared to other protocols like ZigBee® or Z-Wave, is that all devices on a DigiMesh network are the same device type. No complex architecture is required to define different nodes on a network as end-nodes, routers, coordinators, border routers, etc. Every device is the same, and capable of routing, sleeping for power optimization, and communicating via a mesh network.
Thus, it says that the nodes can be sleeping, and they can wake up at specific times to perform the routing of packets within the mesh.
However, according to @bashkar, on this thread:
The NCD nodes only do routing if we turn off the sleep mode, and exhaust the batteries in no time at all. That is not how DigiMesh operates, and that is not the idea that is sold to us on the NCD.io website. It says that we can both have a mesh network, and to have autonomies measured in years.
Which is it? Do we have true Digimesh? Or we just have a dumb XBee board sending raw packets to a gateway that is always on?
This is exactly the problem I am having with my setup. I purchased several sensors and fully expected a MESH NETWORK as described on the product page. But of course, that isn’t happening. I am losing way too many transmissions by the sensors even though they usually reach the gateway. In searching the forums I found the thread you referred to and then this one which explains exactly what is going on. False advertising for sure.
Thank you Tony, I can very well understand your frustration.
In the end, I managed to solve the problem, but it was a ver complex process, that took a couple of hundred hours of engineering time, and making changes to the board that would void your warranty.
Basically, what NCD did was to create a system where the XBee is always asleep, and the Atmel MCU wakes up at certain intervals to make a reading, then it wakes up the XBee, sends the reading, and it goes right back to sleep. Thus, it is never awake to retransmit the messages from other nodes.
When I confronted NCD with this limitation, their proposed solution was to change the XBee from its current sleep mode (only wakes up when the SLEEP_RQ line is activated) to sleep mode 0, which basically means always awake. Because the XBee consumes close to 45 mA when awake, that means that the batteries would only last a few days, if that, not the 10 years.
So, our solution was to change the XBee to sleep mode 8 (Synchronized sleep), where the gateway acts as sleeping coordinator. In this way, the XBee boards in the network are almost always asleep, but they all wake up in a coordinated fashion at pre-arranged intervals. When they wake up, they all wake up the Atmel MCU (rather than the other way around, but this entails altering the node’s hardware connections, thus voiding the warranty), the Atmel makes the reading, sends it via the XBee, and because they all happen to be awake at the same time, they relay the messages between them, in a real mesh. Once the messages are all sent, both the Atmel and XBee go back to sleep. The whole process takes less than one second. Of course, this also entails rewriting the firmware on the Atmel, which was quite a laborious task, which requires a lot of reverse engineering to find out how the whole circuitry works. So, in the end, it is possible to solve the problem, and NCD could do it themselves, far easily than we could, as they have all the knowledge of their board. We had to do it, because we had promised our customer this system, and we had relied on NCD’s specifications to promise that. But it cost us quite a bit of money to develop the solution.
Thanks for the detailed reply, Malaquias.
Unfortunately, in my case, your solution would probably not be of much help? The system I built uses NCD’s water detect sensors to alert residents when flooding occurs in any of multiple buildings on the property. Were I to go your route, I suspect that alerts would only go out when the XBee decides to wake up instead of the other way around. Do you concur?
We are looking at costs of running electrical service to the sensor locations but in the interim we will be forced to buy the USB modem to use as a repeater in a central location to help mitigate the signal losses. We hate to send more money to NCD but at this point we don’t see much choice. Very frustrating indeed and NCD should update the way they describe these units.
the sync sleep modes goes out of window when you have hundreds devices in a building.
also it doesn’t work in the devices which are INT based for example water detect. it sends data when it detects a change. so sync mode again wont works ( its just common sense)
some sensors like vibration sensors sends over 20KB of data. if we keep all sensor on while one sends data it will drain the battery in all units in no time.
sensors can still work as mesh routers if you use external power and disable sleep mode. ncd manufactures over 100 kinds of sensors and the entire eco system has to follow a fix structure.
the repeaters are the easiest and most efficient way to build mesh network.
I see your point. It depends on what is your acceptable delay in sending out the alert. If you were ok with a five-minute delay, and you programmed the nodes to wake up every five minutes, you would probably still get 3-5 years of autonomy, and you would have an acceptable delay. Of course, if you needed a maximum delay of 1 minute, the autonomy would decrease correspondingly. The Atmel would still wake-up as a result of the humidity alarm, and it would record the occurrence. When, a couple of minutes later, the XBee would wake up, it would send the information. But I would have to know more about your specific setup.
As I explained to @Bhaskar before, if I happened to have electricity near the places where I want to put my sensors, I wouldn’t have any use for NCD’s nodes. I would simply put an MCU attached to a LTE modem, and send the data straight to the cloud. The point of having a battery-operated node that has mesh capabilities is, of course, to use it at challenging locations, such as rural fields or urban infrastructure where it would be impossible or too expensive to bring electric power in.
The only reason I even looked at NCD was because they claimed in the literature that they performed a mesh network and their batteries lasted 10 years. No qualifications, no buts. If I needed electricity to power my mesh nodes, why would I need a mesh in the first place, when LTE coverage is ubiquitous.
Now, for the technical part. It is not true that the sync sleep goes out of window. The Digi-Mesh is quite robust and the Sync node sends sync information to the nodes in every wake window, thus bringing them all back in sync. In my city, 10 thousand water meters are in sync with a sync sleep mode, and their batteries last for over 5 years. Of course INT based devices would be more challenging, as the information would only follow in the next sync window, but such is the compromise. You know that in embedded sensors, speed pays a penalty in terms of consumption and vice-versa. But at least we would be given a choice. Instead, NCD did not even bring the SLEEP_ON line to the Atmel, which would have made our life a lot easier. With that small change and a little technical support, system integrators would have an easier choice, and the NCD nodes would be a lot more versatile and valuable.
To be completely fair, I also have to say that the mechanical design of the nodes is very good, and the engineering is top-notch. So, it is all the more disappointing that this crucial feature was forgotten. I also understand the argument that NCD needs to use the same architecture for all nodes. But this would not, in any way, sacrifice the present working of the network. We still use the NCD MQTT gateway, and it can still receive the same messages from any other NCD node. But a few very simple changes and a technical note, whose details I would be glad to discuss with NCD, would make a huge difference for system integrators who, like us, chose NCD because they needed a quick solution for a problem that the advertising promised to solve.
Bhaskar, I completely understand the reasoning behind it all. The only thing I wish NCD had been more transparent about how this works in the description of the products, as malaquias has already said. NCD should clearly state on the product page that to actually use the mesh network feature requires powered sensors and/or repeaters.
I am using the Edge gateway, is it possible to disable sleep mode wirelessly with that?
It would be especially useful if the ability to turn sleep mode on and off be added to the “Wireless Device” node in node-red. I think the current minimum SLEEP duration is a few minutes? Perhaps setting this to -1 could send the “never sleep” command to the sensor during a config?
Thanks, as malaquias said, other than this issue I am very happy with the units. They seem very well built.
@tonysunnybrook, it is always possible to turn the sleep mode on and off on all XBee boards remotely, using Digi’s XCTU software. The main problem is that this affects only the XBee board. The Atmel MCU has its own thing, and it follows different wake-sleep schedules. Thus, you need to modify the hardware a bit, and to put a new firmware, so that the XBee can wake-up the Atmel, rather than the other way around.
If I understand correctly, I would only need to disable sleep mode of the XBee board and wouldn’t need to change firmware. I only want to have the radios form the DigiMesh network on the units that get plugged in.
Will the XCTU software run on the NCD Edge computer in order to accomplish this?
Oh, ok. If you maintain the battery nodes just as they are, and you include other plugged nodes between the battery nodes and the gateway, then it should work.
But, from what I understand, you do not need to disable the sleep on the plugged nodes. Those are already always awake.
