Let's Make Robots!

Error Correction - how can i do it

As part of my "Depron Project", i have made a XBee pro RF transmitter and receiver interface.

(it works very well, however my application will test it to its limits i guess......)

I would like the data to be 100% true. (else my 400gramme areoplane will just be a dot on the horizon - if you know what i mean)

My Question :- I have heard of error correction codes and would like to know what is the best way or method to follow ?.

My system is Arduino based ie Atmega328s.

My data string is so :-

EDIT :- 125,25,255,10,55,1,0 (ie 5 channels values 0-255 , plus two digitals at the end).

now i sent the equivalent character down the line ie. instead of

90,89,88,87,86,1,0 i send just ZYXWV10      (reduction of 18 characters (worst case 23 best case 13)  to constant 7 characters)

Thanks in advance.........

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

There are two basic ways that an XBEE can be used in localization.

  1. triangulation
  2. signal strength analysis

Trianglation is accomplished with a directional antenna mounted on a servo. swing the antenna around until you get the strongest signal. Do that to at least 2 other xbees at know locations and apply a little math. could use an antenna array but that adds cost and complexity. a directional antenna could be something as simple as putting an xbee in a metal can, grounding the can to the xbee and pointing the open end in the direction you want.

signal strength analysis. Given a number of xbees at known locations, examine the signal strength and deduce the location based on the relative signal strengths. You can calibrate this by putting xbees in the corners of a grid and sampling the signal along the edges of the grid and extrapolating that. Requires some tuning but only costs four xbees for the grid and one on the robot. There are a number of papers done on the subject.

Thats brill......... i am new to xbees and have not really delved into the signal strength possibilities, this is good news.

Part of my previous job was finding stuck "ON" UHF radioTranmsitter telemetry outstation posts , so i am familiar with directional  "Yagi-s", but all the triangulation data was done by hand and compass and 30-40km trips between measurment nodes.

It would be interesting as to how big an area the xbees could survey....and resolution.

My XBees have the surface mount antennas,  - but i am interested in experimenting with 2.4Ghz antennas.

 

From memory the Xbee's do have buit in error checking. This should not be a problem. As TheGrue mentioned, loosing data due to extreme range would be the primary concern and his counter method should be well suited for detecting missing packets.

When you consider that data from your joysticks are being sent many times per second, the lost of the odd packet should not be of great concern as the servo's would not get much time to respond before a new correct packet is received.

 

XBee Series 1 have buffers and error correction routines to make sure you get out what you put in. XBee Series 2 adds features ZigBee protocol of which I am not familiar.

For a UAV I would be less concerned about data correction with an XBee than data arrival. I would think that CRC Checksum is overkill to verify the data integraty. But you may not receive packets on the ege of your range. I would implement a count. Basically in the packet that this is packet 1 of 1000, 2 of 1000 and so forth. So if the UAV misses packets it can transmit a request for the missing packet and if does not receive one than you create code to make the UAV return to base or until it reacquires connection.

The XBee pros have a design range of 1.5Km line of site, i plan to be in range < 200meters (my current fly zone is one football pitch only)

I will only be sending small packets of data circa 8 bytes max, thats why i was hope_ing that error correction would be somehow easy.

As for full blown UAV i have no plans with this model (needs a more for-giving plane) , however relaying inflight GPS data or video back to my hacked Tx unit would be possible with the Xbees 8-)

Here is a good article on the use of XBee's. It is a 3-node network with 1 robot, one wireless remote, and 1 base unit displaying telemetry. Check out the article here. I is base on a different microcontroller but it is a good basis on the XBee communication routinges.

Are you transmitting values as text? That seems wasteful. I don't know about xbees or arduinos, but I suspect you get to choose how to send values.

What do you mean by "two digitals at the end". Are those two binary values (booleans)? Those could be consolidated in one byte, with room for six more bits to spare.

Checksums can be anything. The simple addition of al values may be a bit overkill. Six bytes could go as high as 3036 which requires two bytes to transmit. The leanest trick is the good old parity bit. Take the checksum and determine if it's odd or even. Transmit that as a single bit: 1 for odd, 0 for even.

The mathematically designed method is often called a "Cyclic Redundancy Check" or CRC. A CRC will always return a checksum of a given length (say 8 bits), regardless of the input: from nothing to a gazillion gigabytes. If your transmitter can calculate a short CRC swift enough AND your receiver can do the same, you can use these for comparison.

Mind you: this will not correct anything! You will just detect potential errors.

My previous code transmitted characters, (for the servo positions and two digitals)

So worst case:- 255,255,255,255,255,1,1  would be transmited .

now i sent the equivalent character down the line ie. instead of

90,89,88,87,86,1,0 i send just ZYXWV10      (18 to 7)  i call that a win..... :-)

and yes as you mentioned i could also save 1 character by compacting up the digitals into one character.

wait a mo worst case would be 23 characters - to constant 7 characters - an even better win than i thought......

Sending data as characters is a huge waste unless you actually want the data to turn up as characters at the other end, for an LCD display or something.

A value from 0-255 takes up one byte, and every ASCII character takes up a byte. If you send the number 255 you transmit one byte, but if you send the string "255" then you have to send 3 bytes.

If you just send the raw values then you don't have to waste time converting from numbers to characters and back again.