You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 16, 2019. It is now read-only.
Love your library, I only had a slight problem with it. The situation is as follows:
Mesh network of 104 nodes, 88 are always on, reset will power off during daytime. The system is always powered and will send messages to the nodes on request.
After about 4 to 5 days, the libxbee returns error -22 (XBEE_ENOFREEFRAMEID).
At this moment this is my theory:
When a message is sent to a node a frameID is used (max frameID's is 255) when the message is sent the frame is locked (busy) when the message is received (ACK is received by sender) the frame is unlocked (free). Because there are nodes on the network that turn on and off, the 16 bit address of those nodes can change (unlikely according to Digi, but it is possible). I think that when a node is switched off and changes it's 16 bit address, the system tries to send the message (locking the frame) and the message is never returned, the frame is then still locked. Then my system tries again without the 16 bit address (64 bit address only) and the message is sent successfully (new frameID), the last frameID is still locked. If this happens ofter (with 104 nodes in a network it happens fairly quickly) all frameID's are locked and the error -22 is returned.
My solution is to clear all frames that are set to busy every time I start sending messages (every 150 seconds) with this, there is a chance of removing a frame that was in use, but that frame will have been in use for 150 seconds, therefor I think it is not that bad of clearing the frames.
The solution is crude to say the least, but my lack of knowledge of the way the library handles frameID's causes me to resort to a less desired solution.
What do you think of this problem, is there anything I did wrong?
Greetings,
Junky
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hey Attie,
Love your library, I only had a slight problem with it. The situation is as follows:
Mesh network of 104 nodes, 88 are always on, reset will power off during daytime. The system is always powered and will send messages to the nodes on request.
After about 4 to 5 days, the libxbee returns error -22 (XBEE_ENOFREEFRAMEID).
At this moment this is my theory:
When a message is sent to a node a frameID is used (max frameID's is 255) when the message is sent the frame is locked (busy) when the message is received (ACK is received by sender) the frame is unlocked (free). Because there are nodes on the network that turn on and off, the 16 bit address of those nodes can change (unlikely according to Digi, but it is possible). I think that when a node is switched off and changes it's 16 bit address, the system tries to send the message (locking the frame) and the message is never returned, the frame is then still locked. Then my system tries again without the 16 bit address (64 bit address only) and the message is sent successfully (new frameID), the last frameID is still locked. If this happens ofter (with 104 nodes in a network it happens fairly quickly) all frameID's are locked and the error -22 is returned.
My solution is to clear all frames that are set to busy every time I start sending messages (every 150 seconds) with this, there is a chance of removing a frame that was in use, but that frame will have been in use for 150 seconds, therefor I think it is not that bad of clearing the frames.
The solution is crude to say the least, but my lack of knowledge of the way the library handles frameID's causes me to resort to a less desired solution.
What do you think of this problem, is there anything I did wrong?
Greetings,
Junky
The text was updated successfully, but these errors were encountered: