XBee Pro s2b sending route record indicators

Question

XBee Pro s2b sending route record indicators from API routers after encryption turned on. This then causes random problems in routing whereby messages are not returned to end points.

Not happening when EE is turned off.
Using latest firmware on S2Bs(Pro) and S2C (Xbee) end points.
stack profile is 0

Has anyone else come across this?

Answer 1

Yes, it is a function within the new Ember stacks. The module is not using source routing, it is just outputting a source rout packet that can be ignored.

Comments

The problem is that it appears to be creating 1 way routes.
Our end points are able to send a frame via an intermediate router node to the coordinator which we can see arriving however the end point never receives the coordinator's response. Usually accompanied by Network NACKs.  End nodes connected directly to coordinator communicate normally.

---

Check the address in yiour packet being sent back. Make sure that you are not using the Broadcast address and you are using the address of the node that you want the data to go to.  Also make sure that the parent node has the proper ST and SP times set. Also make sure you do not send more than one packet for any parent/child per wake cycle as the parent can only store up to either 2 packets or 100 bytes in their buffers.

---

Thanks mate. I appreciate the help.
Unfortunately its not quite that simple. We  are using pin sleep on the sensor end and are attempting a link test at commissioning or after hard reset. we send 40 packets with 1 byte payload at 1.2 sec apart to a linux processor at the coordinator end. it loops them back and we calculate losses. the packets reach the coordinator and are looped back using the 64 bit address of the node. We have found this to be reliable when the node connects directly to coordinator, if it goes via an intermediate route node we usually don't receive the response, instead getting network NAKs.   tried using explicit addressing with the loop back cluster iD and have had same result.
The sleep pin remains active and radio remains on for this whole process so it is unlikely to be a sleep setting.
Pulling our hair out :-)

---

Are you able to have two way communications if you use cyclic sleep mode and ajust the SP and ST time on the parent router to match the SP and ST time of the end device?

Are you able to have two way communications if you disable encryption using your current settings?

---

Haven't tested by going to cyclic sleep.


We have found that the problem is occurring when the coordinator is being hit with route record indicators > 2 per second. It starts when an end device tries to access coordinator via intermediate router. When this route record indicator storm is not occurring the system works perfectly. Now trying to track down root cause and conditions causing route record indicators.
There are only 2 routers on this particular network!

Have ordered some S2C TH modules for coordinator and routers to see if it is a firmware problem between S2C Xbee end devices  and s2b.

we have found the best results so far running zigbee Reg stack on end devices although haven't found any documentation on difference between Zigbee Reg and zigbee stacks on s2c.


UPDATE: Finally got it going after disabling encryption + numerous pieces of tuning
80+ hours into this and finally closer to answer  :-)
Next Step: make it work with encryption

---

The short answer is the name and the actual firmware version. That is the difference between them.