Remember
Register
Home
/
Support
/
Support Forum
/
XBee Pro s2b sending route record indicators
Digi Forum
All Activity
Q&A
Questions
Hot!
Unanswered
Tags
Categories
Users
Ask a Question
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.
All categories
Digi Remote Manager
(387)
Python
(1,016)
RF Solutions and XBee
(8,439)
Device Cloud-enabled RF Gateways
(97)
XBee3
(482)
IEEE 802.11 (Wi-Fi)
(267)
IEEE 802.15.4
(1,646)
ZigBee PRO Featureset (and legacy ZNet 2.5)
(1,490)
ZNet 2.5
(86)
ZigBee Smart Energy Profile 1.1
(111)
DigiMesh Proprietary Mesh Networking
(785)
Multipoint Proprietary
(197)
XLR PRO
(17)
XStream
(40)
XTend
(137)
XCite
(4)
XPress
(8)
Miscellaneous Hardware and Software
(515)
XBee Programmable Development
(778)
XBee Cellular
(120)
MicroPython
(66)
Digi TransPort
(789)
Digi Connect Cellular
(447)
DAL
(5)
Embedded Devices
(4,170)
Google Coral
(2)
Rabbit
(3,200)
Console Servers
(354)
Modbus and Industrial Automation
(246)
Realport
(603)
Serial Servers
(837)
Satellite Modules
(25)
USB
(1,273)
Serial Cards
(715)
ConnectPort Display
(58)
Feedback/Wish List
(93)
Other/Legacy
(377)
XBee Pro s2b sending route record indicators
0
votes
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?
xbee
route
record
indicator
asked
Aug 11, 2015
in
ZigBee PRO Featureset (and legacy ZNet 2.5)
by
alanp
New to the Community
(
33
points)
Please
log in
or
register
to add a comment.
Please
log in
or
register
to answer this question.
1 Answer
0
votes
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.
answered
Aug 11, 2015
by
mvut
Veteran of the Digi Community
(
15,223
points)
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.
Please
log in
or
register
to add a comment.
...