Hello friends! I've been working with Xbees for five years now, and still learning all the time. Thanks in advance for your advice!
The issue I'm having is that I need my packets to be as fresh as possible. If a any are lost or corrupted, I don't want a retry. Once in a while, I do get a few lost packets. That's not a problem in itself, but when I start to get them back again, I'm pretty sure I'm getting some retries first, followed by a perpetually late packet train. I believe I can tell because I have milisecond timestamps on these packets, and what I'm seeing is that after a dropout, my timestamps can all lag behind the true time by up to like around 100ms.
Some background - I'm using the Xbee3 and the 802.15.4 protocol because I've found it plays well with 2.4G RC control links in my working environment, which I have to coexist with. I've found that 802.15.4 onboard my drones gives me the fastest downlink and best range from the air to my receiving Xbees on the ground. I have not gone with transparent mode because I saw better throughput numbers in XCTU with 802.15.4, and because it's so much easier to do AT commands and to grab the packet contents on the receiving end.
My application involves sending position and orientation data from drones in real time, as rapidly as I can. I'm using Teensy boards on both ends and sending from 60-100 full packets per second, per craft, and I'm using channel differentiation and 16bit addressing to send the packets from the craft to their own individual receiving Xbees on the ground. Each craft/receiver combo has it's own channel, and the craft all have a certain 16bit address. My reasoning is that this way the airborne units are not wasting time receiving packets from other craft, and that the 16bit addresses can serve as craft identifier numbers, which will need to be set in the field by end users.
What I know about 802.15.4 is that it has three retries built-in. I have yet to find a way to turn those off, after realizing the retries parameter is only for *additional* retries. What I would like to know is how the receiving buffer is working, or what it might have to do with this issue. I believe it must be a factor though, because I can't think of any other way the data would remain stale after the packets come back. I'm imagining that the first packets to come back are retries, and then after that the fresh packets are just going into the back of the buffer to wait their turn until they're "received". But there's a lot I don't know about this, and I may be way off base.
My position and orientation data has to be real time and true-to-life. What I really just need is to be able to drop all retries, keep any buffers current, and just only receive packets that I know are totally fresh. Is there a way to do this with the 802.15.4 protocol? Or am I going to need to change my whole approach?
Thanks for your time and expertise!