The largest site has 200+ but most are sleeping nodes, so they don't actually contribute to the Mesh.
The general Mesh service is provided by 20'ish radios that are powered 24/7 in a defined layout (final location adjusted during install).
For sensor nodes that have power available anyway (VFD's, AMR, etc), I'll leave the radio on so they also work as mesh routers. It's not uncommon for a Network Scan to show radios with 8-12 links to other XBee's due to the range of 900 Mhz. The minimum I want is 3 links per radio for the dedicated mesh backhaul in an Industrial Environment.
1 Like
@RWB, After seeing your clip of the datasheet, It got me wondering how I dreamed up 256. I looked through my old notes to find the 256 device limit.
That's actually due to the fact that my Gateway Code tracks the Node ID #'s in (1) byte in the API frame, or "payload" from all sensor nodes.
So for any device past this 255 limit (not there yet), I have to flag it with another dedicated byte in the Payload Frame for the next group of 255 Nodes (I don't use Node #0).
So I was wrong when I mentioned 256 was the hard limit imposed by the DigiMesh, it's not 
A wise man once said: "The Code on your Particle Gateway is 99% of a DigiMesh Network."
J/K
@hwestbrook, Yes, I've been very pleased with S3B DigiMesh 900 w/ Particle Gateway for revenue producing projects. It's not something I would want to tackle for small projects (pretty large learning curve), but I was forced to use Sub-Ghz for one particular Industrial Project a few years ago.
I plan on using Gen3 for "normal" sites that aren't very large or complicated RF environments....... In fact, seeing the recent posts on the ranges with RC.26, I'm about ready to start un-boxing my Xenons.
1 Like
Just to be clear, you’ve deployed a network of XBee S3Bs with one Electron base and > 50 S3Bs nodes that was reliable and didn’t require much maintenance?
If so, maybe I should look at the XBee again… we are evaluating adding wireless sensors to our product and I’ve been looking at LoRA.
I’d be interested to know also if you are shipping this to people who setup themselves or if you do it for them.
That makes sense.
It seems that in a setup where you just publishing data at different times that you could put more than 128 nodes on the same wireless network and still get the message to the Gateway node without any problems. Kinda depends on what your needing to accomplish as far as how many nodes can always be on a 24/7 vs a lot of sleeping nodes that just wake up and check in.
That’s becoming very clear to me now 
It seems to be a set it and forget it type of thing.
The Photon code I’m running has been running for multiple days processing 12 messages per second and has had zero lockup’s or issues that needed to be dealt with.
The radios connect and join the network super quick and then they are online and ready send and receive data until power is lost or it’s taken out of range of all other nodes.
Save yourself the headache and just stick with the 900 MHz Digimesh radios. They provide a superior overall system expecially when you factor in the free Digi XCTU software that you can use with the radios to allow wireless programming and firmware updates of any node on the network along with other features. You don’t get that with LoRA.
That’s exactly what he is doing successfuly 
Would love to see you join the party here!
Yes, I can confirm >50 S3B XBee's constantly online in (1) Network all sending data to (1) Particle Electron is no problem at all. The only network maintenance required is when folks unplug Mesh router(s).
For a large system using an Electron, I would perform all the setup in my office, including the Backend so those clients don't touch anything. It can be a turn-key working system shipped in a box, once the Electron is plugged in on-site. But normally, I'd ship minus the Electron. The customer would purchase/setup the Electron/Photon and then flash the specific code for their Gateway. I actually Generate that in MS Excel due to the specific Backend "endpoints" required for each sensor node. The Gateway code gets hairy.
I looked at LoRa also, and saw @RWB make a lot of progress with them on this forum.
But no FCC certification was a no-go for me. Well, I couldn't find Certified modules that were cost competitive.
1 Like
@Rftop On your battery power XBee 900 nodes, how much time do you give the XBee radio to connect to the local Mesh network before you send the payload out?
I’m assuming you have some delay before sending out data and have tested this delay in your trial sessions.
I normally use NCD.io products for the Battery Nodes, except for Direct I/O sampling with the XBees.
I’m wondering if you add a delay on a XBee 900 radio 
when it wakes up to give it time to connect to the mesh network or not.
Based on our previous conversations, I thought you were going to maintain battery power on your end nodes, for 2-way comms.
There are a lot of variables here depending on the Sleep Mode used if you're building a sleeping network.
If you install the Mesh Routers (powered 24/7) with proper coverage, you can wake a battery powered node in Pin Sleep and "almost" immediately send your Payload with the DL of your Gateway. The Pin Sleep XBee doesn't need to "connect" to the DigiMesh in the traditional sense that we normally think. Wake the Pin Sleep XBee as soon as your MCU wakes. By the time the MCU has done anything meaningful, you can transmit and put them both back to sleep.
I'm not sure if this helps you, since your Gateway cant wake the sleeping node if it's using Pin Sleep.
But a Synchronous Sleep Network on a fairly short cycle would work.
All of your mains powered Routers would be configured with synchronous sleep support mode.
That is correct but during my testing of turning on nodes that are sending payloads and waiting on a gateway reply I’m seeing it take a few seconds before a publish actually is responded to as received by the gateway radio.
The node test code starts sending payloads every half a second as soon as the main loop starts running.
I see each payload send event on the serial monitor on my laptop and it usually takes about 5-6 publish events before the Gateway sends a received response which is around 2.5-3 seconds after it sends out the first message. This is while the gateway is receiving 2 messages per second from 2 other nodes.
I just started adding a 10 second delay on nodes before sending a payload when they are first powered on assuming that the XBee radios need a few seconds to join the Digimesh network before successfully sending out a payload.
Once it successfully sends a payload it’s rock solid from then on out.
The radios have been running 24/7 for almost a week now running the test code along with each node having a color 240x240 pixel LCD display updating a send, reply, and ACK indicators every loop and there have been zero issues with anything.
There have been No code or Photon lockup’s over all this time where the gateway is processing 12 messages per second and the nodes are processing 4 messages per second. It’s a very reliable combo.
That makes sense and is helpful.
I’m planning on using 24/7 powered nodes but I have been wondering if the XBee could wake an Photon that is sleeping when it receives a new message addressed specifically to it via pulling one of its Pins high which could wake a Photon instantly to read the incoming data without missing anything.
That's likely caused by something else, not the node's XBee.
With a XBee configured for Pin Sleep, Write a Photon script that wakes the XBee and sends the API frame a few (ms) later and puts the Xbee back to sleep. You can use a loop that increases/decreases the delay time, so you'll know exactly how quick a XBee can power up and successfully transmit. Don't use any form of Acknowledgement on the gateway for the test, just watch for a successfully received API frame that includes the (ms) used by the Photon.
You can have the Gateway send a Remote I/O Command in the API frame to the node (drive a Pin High/Low to wake MCU), then send your actual API payload to the node immediately after the remote I/O Command.
The XBee has serial buffers. You could probably even do that all in 1 API frame, idk.
1 Like
Good idea.
If / when I run this test I’ll report my findings.
I have another question.
How long are the wire antennas that Digi attaches to the XBee 900 radios with wire antennas?
All my 900 modules have the screw on antenna connectors that I can remove and replace with wire antennas like I used with the 900mhz Lora radios with great success.
The XBees use stranded wire right? Any guess to what AWG the wire is?
I do not want to add external antennas to the nodes due to their enclosure not having room for them, nor do they really need external antennas for the ranges were working with. The gateways will use the external antennas.
1/4 wavelength ~ 3"
The wire antennas work very well inside enclosures.
Idk the wire gauge, it's tiny. It is stranded. It's soldered on the bottom side of the radio.
1 Like
Thanks for the picture, I was wondering where they were soldering the wire to.
3 inch is what I used on the LoRa radios also.
What kind of distances have you been able to achieve with the wire antenna?
In the suburban city I have seen up to 1 mile range with the antennas being 5 feet above ground level.
I saw pretty much the same results using a 3 inch wire antenna vs the rubber ducky antennas.
It all depends on your location. Essentially, it works until a significant obstruction.
Height above ground plays a significant role also. Higher = larger Fresnel zone.
Hello,
Nice work. I am experimenting with an agricultural - hobby application that needs multiple nodes spaced about 1km. Electrons worked, but the latency is cell messaging was not suitable. Mesh has less latency, I just ordered a handful of Xbee PRO radios.
Would you be willing to share your code ?
Also, can you point me to the Xbee library that you used? I was not sure if the Xbee library on particle is peekay123’s
Cheers,
1 Like
Here is the library I am using and got started with:
Here is a book that complements the library: