After realizing the Particle mesh would not fit the needs of one larger project I want to move forward with I decided Digi’s XBee Digimesh 900MHz Radios are a better fit due to increased 1 mile urban range, a stable platform with 10 million units sold, and from what I read can handle at least 128 nodes per network, and there is good windows software for easy setup and troubleshooting.
These are more expensive radios but they are different and they have all the certifications behind them unlike a lot of LORA radios.
There is a ported Particle XBee library in the library already that’s been downloaded 1,800 times so I’m hoping it works well.
I have all 4 radios programmed to be on the same Digimesh network and this was super easy. Now my next step is to use the Particle XBee library to get a Photon to communicate with the XBee 900 HP you see pictured.
I plan on communicating using the API Data Fame method that is included in the library since its the most flexible.
I’m probably going to need some help some so I figured I would just share this here in case somebody else finds its useful for their own needs.
My goal is basically setup an advanced pager like network where alerts and message data can be broadcast to all nodes when needed on the Digimesh radio network that still works without the need for WiFi or Cellular.
I want to use the Photon and Electron for their stability to allow the Digimesh network to access and push data to then web when needed.
I wanted to ask if any body else on here has worked with this equipment combo along with the Xbee library to community in API Mode? Please share your experience if you have.
I built and operate a large DigiMesh Network at an Industrial Site using XBee Pro 900HP’s with a mix of Particle hardware, NCD.io hardware, and homemade hardware. I’m forced to stay sub-GHz at several of my Industrial Clients.
I agree, you definitely want to use API mode, but you’ll need to make an important decision early on.
Your Particle Gateway will need to either :
Keep Track of the nodes by XBee Serial Number
Use Node ID #'s and sensor type #'s.
The benefit of #1 is you can do a lot of things at end nodes with ONLY the XBee radio’s direct I/O sampling (no MCU required) and 2xAA batteries.
The benefit of #2 is that it allows you to define a clear API Frame structure for unlimited “types” of future nodes/sensors. But each node will need an MCU to generate your API frame. #2 allows for unlimited customization.
You can do both at the same time with your Gateway, but the Code gets a little more complicated.
I also use the Particle Library: XBee (0.0.10) on my Electron Gateways.
They can each push anywhere from 5,000 publishes to 20,000 publishes per day, depending on load.
The range on the XBee 900 HP is amazing. You can easily have over 256 devices for the same DigiMesh Network, since most will be sleeping.
I’m still excited about Particle’s Gen3 right now and I’m testing just like everybody else. I still plan on using Gen3 for smaller sites once the sleep modes are incorporated.
It’s REALLY nice to have somebody to talk with about this who has experience using this exact equipment combo and is actively managing it on a large scale!
Method #2 makes the most sense considering I will have a Photon/Electron Connected to each XBee radio to display information on a LCD display, kinda like a pager. I will be able to update each node over WiFi or cellular which I like.
Can’t you update the actual Xbee HP 900’s wirelessly using the XCTU software with one of the XBee radios connected to the PC to provide the wireless link to the MESH?
I’ve used the XCTU software to discover other nodes connected to the network which is pretty cool to see. Seems like in API mode you have full control over the XBee radios wirelessly just as if they were plugged into your PC.
You saying you can have a network of around 256+ nodes is really nice to hear because I think that would cover 95% of my planned needs.
Tell me more about what how the nodes are setup and what they are actually doing if you can.
Are they all running off AA batteries?
What is the max distance you have seen and are currently using?
Does Digimesh handle waiting to send data if the other nodes are talking?
And does the library code handle presenting data if it’s not acknowledged as received by the receiver?
And have you looked at or tried any of the newer Xbee3 radios with Bluetooth setup?
Short Version:
XCTU is really only used to setup the Mesh Network.
Only the sleeping nodes are 2xAA powered. Large Coverage areas require 24/7 powered mesh “routers”
Like any RF, the range is extremely dependent on the environment. 900 MHz handles concrete well, nothing likes steel.
The XBee radios automatically handle the retries if needed to reach the Particle Gateway.
The examples in the XBee library show you how to handle acknowledgement from the sensor nodes to ensure the Particle Gateway received the message. Good documentation in the Library.
I’ve looked at XBee3, but no sub-GHz radios are offered in XBee3. I cant use 2.4 in a couple of my projects, thus the reason for using the 900HP XBee’s in the first place.
Found a good use for the 3 Argons and LED’s that come with them
I have got 4 of the XBee Pro 900 HP Digimesh radios setup in a mesh network now using @peekay123 's ported XBee library.
Had some initial trouble getting the TX and RX examples working due to Serial needing to be Serial1 for the XBee Module. Many thanks to @Rftop for catching that little issue.
The flashing LED’s are a sign that the data sent to the XBee + Photon was successfully received and acknowledged. D7 Flashes if there is a error in or if the data sent is not received which triggers another transmission.
Using multiple nodes in a MESH network and you can cover some pretty large areas without the need to rely on cellular or Wifi access points which are not always 100% online and operational.
I’m needing a radio network that works independent of Wifi & Cellular although they will be connected to the web and cellular via the Particle Photon & Electron to push data out to the web when it is available.
I was able to do a quick range test with one of the XBee Pro 900 HP radios awhile back and I got a pretty impressive .77 miles with just putting one transmitter in the front window and then drove out and ran the range test app in Digi’s X-CTU software which is really nice, its been updated. I’m sure I could have gotten more range but I didn’t have time to go any further.
Pretty cool stuff and the XBee Library is full of MESH features I’m really liking.
I have been working on testing the speed of the XBee Digimesh Network using the 900 MHz 200Kbs radios.
I’m using a modified library for XBee called “Simple Zigbee” , which I really like, but it did take a couple days to wrap my head around all the functions that are available and built in.
In the video below you can see the serial output from 4 XBee 900 radios connected to Particle Photons. The serial baud rates of the XBee radios and the Photons are 56,700.
Each of the 3 nodes are sending a message out 2 times a second. It’s sending 3 separate one byte values along with other data like the radios serial number and send Ack on receipt flag.
When the Gateway receives these messages from the 3 nodes it instantly sends back a message that the mapessage was received successfuly so you know there is no need to resend it.
The Gateway then adds up the 3 separate numbers we sent it and sends a return message to the specific sender with the total so we can compare and validate that returned number against what we actually sent it.
The Receiving node receives this message from the Gateway and sends back an acknowledgement so the Gateway knows it was received and there is no need to send it again.
So in total we have 2 Tx & 2 RX events happening per second per radio node.
The Gateway is processing 6 TX & 6 RX events, 12 total per second with zero problems and its been doing this for 24 hours straight now.
The video below shows the Serial Data flying around which is satisfying to see for some reason.
Good Job !
Now the fun stuff: Place a node (sender) out of range of your Gateway and let a XBee only (no Photon req’d) route the packets to the Gateway over the Mesh. No setup required.
You can cover the sender with a Metal Mixing Bowl and turn down the power if you have to.
It’s actually hard to perform range testing with these things
I’ve never hit the Mesh limits during Stress Testing. We’re talking about a network rated at 25,000 bytes per second. A typical message, with API Overhead is 60-70 bytes.
Based on your numbers of 25,000 bytes per second of network capacity / 70 bytes per message = 357 messages per second assuming the processor can keep up with that amount of traffic.
It does give me a good feeling about sending a broadcast out to all radios asking for a quick “I’m Alive Reply Back” with a network of 100+ nodes.
I was wondering how quickly I could get replies from all nodes without causing any traffic issues.
Do you know if the XBee MESH waits to send it’s message until the channel is clear and nobody else is currently transmitting? That was an option that the LORA RFM95 Radiohead library had in it.
You have a few different options that I know of. The Most common is the ND (Network Discovery) command.
When a device receives the network discovery command, it waits a random time before sending its
own response. The maximum time delay is set on the ND sender with the NT command. The ND
originator includes its NT setting in the transmission to provide a delay window for all devices in the
network. Large networks may need to increase NT to improve network discovery reliability. The
default NT value is 0x82 (13 seconds).
Depending on how you track/store your Nodes in the Gateway Code, instead you can use the FN (Find Neighbor) command issued to each specific Node (loop through your list 1 at a time) to build a "map" (array) of the network topology with RSSI for all Mesh Links periodically.
The Code on your Particle Gateway is 99% of a DigiMesh Network. The Mesh is almost a set-and-forget situation with sub-GHz. I don't think that will be the case if you move to XBee3 on 2.4 GHz (for large sites). Then physical layout becomes much more crucial and less forgiving due to range limitation and noise on the spectrum, in my experience. For Small Sites, I plan to use Gen3 once the kinks are worked out. The hardware is cheaper and Gen3 will have several benefits over XBee3 (again, just personal opinions).
That might be the way to go! I’ll have to give that a shot. It’s basically what the XCTU software does when you trigger a wireless network discovery.
These radios are super cool and reliable. I woke up today to find everything still chugging along at 12 messages per second.
The XBee3 would only be good for shorter range projects but I am interested in their small size, low power consumption, Bluetooth programmability, micropython programmability, and low $15 cost. I will hold my judgement on these until I actually test them.
The Particle Xenons will be hard to beat once they are running smoothly.
@RWB Great post! In the XCTU throughput tests what kind of speeds are you getting on the 200Kbps model @Rftop & @RWB ? I would hope it’d be ~200Kbps no?
I've honestly never checked. As with any RF environment, there are many variables.
You would never see 200Kbps across the Mesh in reality, maybe point-to-point.
