Robust Radio Communication Protocol

Hello-

I am currently programming a quadcopter and I need to improve my Radio Communication. I am currently using two 60mW Xbees as a link between two arduinos.

I am wondering are there any standard ways to program the transmitting Arduino and receiving arduino so that they form a robust link, that can detect and tolerate errors in the radio link? Ive looked around but I cant figure out how to do it. Ive thought about using a checksum but im not sure how to do it.

-Nick

XBee's are robust.

I don't have an XBee and I don't know if @wwbrown means that they have behind-the-scenes arrangments to ensure high reliability of transmission and reception.

In general I think there are two significant risks with wireless comms - a complete failure to send or receive or a garbled message.

It should be relatively easy to write code that works like a "dead man's handle" on a train. If nothing is received for X seconds / millisecs (whatever) assume that comms has failed.

There are a few things you can do to avoid garbled messages. You can include a byte that represents the total number of bytes in the message, or you could ensure that messages all have a standard length. You can include some form of checksum in the message. There is a lot of intense mathematical study in this field and you wil have to judge for yourself how complex you want to be. Suppose there are 7 bytes in a message. A simple arrangement is to XOR all 7 of the bytes in the message and store the resulting byte as an 8th byte. The receiving code uses the exact same algorithm and expects to get an answer that is identical to the 8th byte.

...R

Well my main goals are two have a robust two way communication, that sends packets each way 50 to 100 times a second, and have it be robust enough to handle errors.

That being said, im not exactly sure how to implement a checksum, and not sure exactly how to correctly do a packet system (is one byte off limits and only used as a start byte, how is a packet defined start to end?)

-Nick

Xbees by default do packet error checking. How have you set them up, and what problems are you having?

Ok i think im phrasing my issue slightly misleading.

Its not that im having errors and need a robust protocol to handle them, but I would like the protocol to not fall apart on the off chance i do get a dropped byte or error.

My main question is how to a packet system with starting it and ending it. I want a fixed number of bytes in a two way communication, I just don't know what the standard method is for using packets in radio communication.

What i am confused about, and correct me if im wrong, but whatever defines the start of the packet cannot be used in the packet itself...

-Nick

Xbees also handle the packet construction, transparent to the user. Read about the options here GitHub - andrewrapp/xbee-arduino: Arduino library for communicating with XBee radios in API mode Again, how have you set them up, and what problems are you having?

Well the current set up I have is sending a start byte, followed by a few (but always the same number of) data bytes. They are continually written. The receiver reads data until it sees the start byte and then reads the data, and i never use the start byte in the data.

I looked at the ling jremington posted and i saw some timeout delays, which makes me worry that it cant send packets at 50 to 100 Hz.

-Nick

You should be using API mode, which takes care of packet construction, error checking and "handshaking" packet retransmission until reception is successful. Lots and lots of info in the internet on how to do that. This is the best you can do -- nothing that you try by "rolling your own" will work better.

Radio communications are inherently unreliable and as the environment becomes noisier, or the receiver begins to go out of range of the transmitter, the packet transmission rate will go down because of retries. Eventually, transmissions will fail, as when your cell phone goes out of range of the towers.

I see that the xbee API is the more reliable and probably "correct" way to do it but my biggest concern is can the process be done fast (many times per second), and can it be done in the background e.g. the arduino can say "send this data" or "look for data" and do other stuff while the data is actually sending/receiving? Is that possible? Because if it is not I need a better way.

-Nick

Under good radio transmission conditions, packet transmission between Xbees is very fast and in the background. Only you can tell us whether the speed fits your requirements, so try it out.

Well before I try it out i want to know if the rate is even in the ball park of what I need. Is the packet speed (for about 10 bytes) on the order of 1's 10's or 100's of Hz. I just need a ballpark within an order of magnitude, then I can do all the code to get specific. I don't want to put in all the work to get a packet sent every 3 seconds.

-Nick

If I recall correctly, the raw data rate of the Xbee is about 250k bits/sec, which considering overhead probably works out to about 25000 actual data bits/second. That would correspond to roughly 300 ten byte packets/second under ideal conditions. But, conditions are very rarely ideal.

Well I know that the xbee can handle the data i am sending through, but my primary concern is will the API mode decrease the speed of the connection. I have gotten it working without API before, however I want to use API mode if it dosent significantly inhibit data speed.

-Nick