Arduino to Arduino 2 way RF communication - how to make it quick and reliable?

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.

If I understand it correctly, the scenario is that the cabin sends something and the wing replies? Or can the wing also send data without being requested?

If the first, it sounds like a flaw in the code where the cabin master can send while it is supposed to wait for the reply. Or where the wing slave is too slow with its reply (actually still a flaw in the cabin code that should wait).

A solution could be to have a timeout in the slave; it knows when a message was received, it basically knows how long it has to reply and if it can't do that it will keep quiet. The master can, after a timeout, re-issue the command.

No knowledge of wireless comms, btw.

Question, why use Software Serial in systems that don't seem to be connected to other devices; I'm quite sure that you don't have a PC connected to the wing :wink: Not sure about the cabin.

Question, which serial communication speeds are we talking about?

Hi Sterretje,

The wing also sends data arbitrarily.

Regarding the timeout - the issue is to all cost avoid a simultaneous transmission. For the timeout to work it would have to either be on one side only or synchronized if on two sides otherwise, sooner or later there will still be a clash. My attempt to use a common time stamp was effectively just that.

Regarding SoftwareSerial, the cabin unit talks to a single Android device via USB. The wing unit talks to three other RS232 devices. GNSS unit, inertial and met. unit and camera triggering unit.

I have been using 9600 baud all round.

An inexpensive setup night be to use the WeMOS wifi boards and setup a client/server communication system. Have the client in the cabin and the server on the wing tip. Usually these types of setups can communicate within your one second time frame. Just curious, how are you powering things on the wing tips?

I wonder if nRF24L01+ 2.4GHz transceivers would be suitable. They are cheap and reliable. Have a look at this Simple nRF24L01+ Tutorial.


Hi Zoomkat,

Wing tip power is battery.

first create a simple routine to pass each other a single character alternately

That will rarely work in a noisy environment, except in the context of a packet with decent error checking and/or error correcting codes. At the very least a 16 bit packet CRC is required.

If you want informed help, please give us a usefully detailed description of what data transmission methods you have been attempting to use.

"The wing also sends data arbitrarily."

Is this a time critical transmission? You will need some type of command and control if the two units are communicating randomly to each other. You will need to decide what takes precedent in the communications.

How fast is the wing flying? What will you use for an antenna? What are you using now?


jremington - those units do have error checking built in. Or so they claim. Not quite sure what you mean by data transmission methods. I have only used the 433mhz half duplex APC220 units so far.

zoomkat - command and control is pretty much what I have been trying to achieve. Several of the methods tried I have previously used successfully with stuff like irrigation pump control and interaction with weather and soil moisture data but none of that was time critical and nor was the interaction that frequent.

Paul-KD7HB - it is used on aircraft flying at up to 200knts maximum. Nothing high speed. The antennas are quarter wave whip. Not sure your question is relevant though. I don't think it has anything to do with the environment that it operates in because it is entirely reproducible on the bench in a "perfect" environment.

Guys, I am still very open to suggestions because I am only too well aware of how long you can plug away at a problem and all the while there was a dead simple explanation right under your nose. There is one more thing I want to try which is setting the transmission baud rate either faster or slower than the UART baud rate but I am not too optimistic. What (I suspect) is killing me in this application is the apparent instability of the APC220 at these data rates.

Any further suggestions as to a alternative hardware? Robin2 confirmed that the NRF24L01 is a possibility. Anything else? XBee maybe?

If your 1/4 wave whip is made of springy stainless steel, it is likely to be oscillating wildly at 200 kts. Even whip antennas on automobiles sometime wave wildly about at 50 mph, and above.

Suggest you invest in an antenna made for aircraft use, which is about 3/16 inch stainless steel. See if that has any effect on your communication problem.


Both the cabin and the wingtip units are fully enclosed. Nothing is exposed to the air. But that is not the problem anyway.

jremington - those units do have error checking built in.

Then you should be getting mostly error free transmissions. What ACTUALLY happens? Hint: you should add your own error checking.

The lockups would be a problem with your code, which you did not adequately describe or post.


I set the transmission speed to 19200 baud and left the UART at 9600 and bingo - no more lock ups.

After all this time!

Thanks to all who tried to help. Robin2 and zoomkat - I intend to also try your suggestions (NRF24L01 and WeMos) as well just as soon as courier deliveries are permitted to start again after this awful lockdown.

You may start try with the HC-05 Bluetooth modules. It works very fine at short distances and is very imune to interference. It is very cheap and easy and incorporate it's own CRC . They are also Full Duplex


It's SoftwareSerial that is the problem here! SoftwareSerial is generally crap - it's viable if you're only sending or only receiving, or if when it is to send vs receive is very predictable. Avoid it like the plague - at best, it kind of sucks; at worst it's unusable.

The wingtip units are (hopefully) pro mini's, where the hardware serial pins are unencumbered by an unneeded builtin serial chip (you use an external serial adapter to upload to them) On the uno controlling the whole thing, swap it out for a mega and use the other hardware serial ports.

Rather than spending 10 days faffing about trying to meet software serial's half-duplex requirement in an extremely robust way, you could have ordered $25 of arduino clones on day 1, spent 3-4 days partying until they arrived, and had it up and running in a day, with a solution where it didn't lock up. Your solution is way more robust than any of the proposed RF methods, that wireless serial port thing sounds really good! And, I would also suggest repeating each message (and having receiver be smart enough to discard duplicate commands in rapid succession; that should be much more robust to lost characters if the characters are being dropped by the wireless serial port. As long as the wireless serial ports aren't the thing locking up, you should be fine.