Hello, Geoff.
Thanks for letting us know about your new library. I have added it to the Wixel Apps post and I think it will be useful to other Wixel users.
In your library, I noticed several comments about various problems the library has. One of the most worrying ones to me is that the radioMultiTxDataBlocking function has a chance to discard a received packet even though the library has already sent an acknowledgment packet to the sender.
If I were trying to write a reliable multi-Wixel radio library, I think I would not store the TX packets in a circular buffer. The idea of the TX circular buffer used in radio_queue and radio_link is that you have several packets queued up to be sent, and they must be sent in a particular order, and you know exactly which packet you are going to send next. Instead of using a circular buffer, I would probably have some number of independent packet slots. Having 10 slots seems like a good default. Each slot can either be empty or hold a packet that I am trying to send. To ensure correct ordering of the packets and to help make sure that I don’t use up all the slots, I would avoid acquiring a new slot for a packet if there is already another slot trying to send a packet to the same receiver.
For the RX unicast packets, using slots could also help. It would allow the library to be in a state where it’s not ready to receive packets from a particular sender, and it won’t acknowledge packets from that sender, but it is ready to receive packets from other senders. Received broadcast packets should probably go in a circular buffer though.
–David