How to verify a good packet

[Ringo42]

I have a system with 2 18F452's. If I connect them via rs232 they work great, but if I connect them via XBee radio modules that work just like a 232 cable, then occasionally I get a lockup on the receiver so I'm assuming I'm getting some bad data and not handling it correctly. On the transmitter side I'm doing a printf, so it might look something like
printf("pwm 1:47 2:-76\r");

what is the easiest way to make sure I'm getting good data. I know I could check each little parameter, but there must be an easier way. I know the theory behind CRC's but have never implemented it. Is this the correct thing to do to a string like this? If so how hard is it to do? It needs to be fast too of course.

Thanks
Ringo
_________________
Ringo Davis

[PCM programmer]

Add a checksum byte to the end of the packet.

For ASCII packets, you can use the NMEA checksum. Do a google
search for this:

[rnielsen]

Look up 'API mode' in your XBEE module documentation. API mode requires the use of a simple checksum to ensure proper data transmission between modules. It took me a while to understand all of the fields, in the data stream, and what was needed for each field but that should help you eliminate any errors between the modules.

Ronald

[Ringo42]

I read it, but I didn't really get it.
Do you put it in API mode by using x-ctu?
Once you do that then do you just configure your data according to what it wants and do a putC or printf like normal?

Do you have any code you can share?

Thanks
Ringo
_________________
Ringo Davis

[rnielsen]

X-ctu is the easiest way to configure your XBEE. Set AP = 1. If you're only using two modules, as if to replace a serial cable, each one needs to have AP = 1. Each module will need to be set to a unique address(use 16-bit addressing) since API mode uses addressing.

If you'll look at the section that talks about TX (Transmit) Request: 16-bit address, you'll notice it shows how a 'frame' should be formatted. A frame is a group of data that has been properly formatted that is sent to another module.

You have a Start Delimiter, Length, Frame Data and Checksum. The start delimiter(byte 1) is always 0x7E. The length(bytes 2 & 3) is how many bytes you are going to send in the frame data. Lastly, you have the checksum. Length is always two bytes so if you're only sending six bytes of 'frame data' then length will be 0x0006.

API Identifier(byte 4) tells the XBEE what action you will be taking. 0x01 indicates that you will be transmitting data using a 16-bit address that corresponds to another XBEE with that same 16-bit address (remember, I said that each module needs to have it's own unique address).

Frame ID(byte 5) should just be 0 which makes things easier. Destination Address(bytes 6 & 7) is the destination address of the XBEE you want to talk to. Options(byte 8) should be 0. RF Data(bytes 9 - n) is the actual data you want to have come out of the destination XBEE.

Now that you have all of this information formatted you need to calculate the checksum for the packet. Take all of the bytes from the 'frame data' and add them together. Take the two LSB from the total and subtract it from 0xFF. This is the value for checksum.

Take all of this data and simply do a printf() out of the PIC into the DIN pin of the XBEE. If it has been formatted properly and all of the numbers add up the receiving XBEE should strip all of the special formatting characters and spit out only the RF Data that you wanted to send.

Here is an example of a properly formatted frame:

Say you want to simply send a single character. We're going to send the character '1' to an XBEE that has the address of 0x0001(16-bit addressing). These are the bytes that you would send:

0x73 0x00 0x06 0x01 0x00 0x00 0x01 0x00 0x31 0xCC.

We're transmitting six bytes in the Frame Data. Add it up and it totals 0x33. Subtract that from 0xFF and you get the checksum of 0xCC. The only thing that will come out of the DOUT pin of the receiving XBEE will the the character '1'.

Clear as mud?

Hope that clears up a little bit.

Ronald

[Ringo42]

That makes alot of sense. I did not catch that all that came out was the data, I thought the data was still packetized and had to be extracted. So I only have to change my TX code, not my RX code (just the rx module settings).
I'll give it a shot. Thanks for the help.
_________________
Ringo Davis