I have a problem that has been driving me nuts for about 10 days now.
The application is in an airborne environment where I need to pass messages and data to and from a sensor package mounted on an aircraft wing tip and a host environment in the aircraft cabin. Aviation regulations do not permit cables to be run without extensive and time consuming approvals so it has to be a wireless connection. And a fairly positive one at that. The typical cockpit environment is a digital soup of VHF, HF, radar, Loran, GNSS and what all else.
The nature of the communication is that the cabin unit sends certain instructions to the wing unit, the wing unit reacts and sends back confirmation messages and some data. The instructions can be single characters. The data packages need not be longer than 32 characters at the most. Timing is random and can be as frequent as a single second or as intermittent as several minutes. There is no way to predict when an instruction or data will be received, however, once received, the unit has to react and return a confirmation quite quickly. Certainly within 100ms for the complete loop.
To date I have been using a Nano on the wing and a Uno in the cabin and APC220 units as the link between them using SoftwareSerial. For the most part it works fine but now and again all communication locks up. After some trouble shooting on the bench it became apparent that the lockup occurs when both sides try to send a message simultaneously. It hardly ever happens when there are gaps of a three or more seconds but becomes increasingly common as one approaches single seconds.
So I figured that would be easy to fix with an Ack/Nack type of handshaking embedded in the start and end of messages. To implement it I thought to first create a simple routine to pass each other a single character alternately and then expand on that. And there went about 100 hours of effort! I have tried everything that I can think of and then some. Delays of different lengths in different places, listen() and stopListening() statements, serial ends, buffer flushes and empties and more besides. I have tried saturating one end with multiple repeated messages until acknowledged and even tried getting a time stamp from one Arduino to synchronise time on the other and then allocating odd and even 100ms time slots for transmission.
Everything worked. Nothing works reliably. Sooner or later there is always a missed message or a lock up.
I have come to the very reluctant conclusion that the APC220 is not up to the job. Apart from the handshaking issue, I also suspect they are in some way unstable. I have noticed several times that you can run the exact same code and an hour after behaving in one way they behave completely differently. This is very sad because at this stage I have quite a few of them and a lot of invested effort.
Anyway, for those brave people who have taken the trouble to read this far, I have two requests.
One. If anyone has some reliable and reasonably quick 2 way communication code on the APC220 that they would be willing to share I would greatly appreciate a look at it. I think I have covered all bases but might easily be missing something obvious.
Two. Would appreciate recommendations or suggestions for what devices to use instead of the APC220 units. I have a hunch it needs to be a true duplex link but wondered about the NRF24L01 units, which I understand are half duplex but talk about setting up separate pipelines for transmit and receive.