Ensuring correct data send over RF.

Gerhard · Joined: 30 Aug 2007 Posts: 144 Location: South Africa

I need to send data over a RF using a CC1000 and at the moment I am sending a preamble before i sent the actual data. The code for sending is as follows

libor · Joined: 14 Dec 2004 Posts: 288 Location: Hungary

Solutions range from a simple checksum of a data packet, thru the more robust various CRC algorythms (8, 16, 32 bits) with or without error correcting option.
I simple ckecksum with resending (as the error correction) would be the right method for you I think.

Gerhard · Joined: 30 Aug 2007 Posts: 144 Location: South Africa

Thanks.
Can you please give me some guidance as to do this. A reference to an example or some starting point program would be nice.

libor · Joined: 14 Dec 2004 Posts: 288 Location: Hungary

First, you need to design your own standard packet structure. I see you're sending just one byte as the payload to one recipient (no addressing is needed)
So something like [preamble, data, crc] will do. For more data bytes I would have suggested a CRC-8 solution applied on your datat packet like this one here CRC-8.

But for just one byte of payload this would be an overkill, I think You can simply send you byte 3 times. [peramble, data1, data2, data3] and compare the 3 bytes upon arrival. If they match, use the data as valid.

I suggested 3 times repeating and not 2. because you can also make you error-correcting solution in the receiver if you wish. If all three bytes do not match, but any two are the same (majority-voting) you can discard the minority (presumably wrong byte) and use the majority value as valid (in the wireless RF world we need to adapt to the errors, and not trying to eliminate them)

Gerhard · Joined: 30 Aug 2007 Posts: 144 Location: South Africa

At the moment I sent a preamble which = 1byte then my data package which is also 1 byte. On the recieving side i start reading the byte as the CRX_BUFFCOUNT is bigger than 1. After that value is set to temp, i compare it to the preamble then I save the next value, in a if loop to temp aswell. How would i be able to adress say 4 data packages(preamble,data1,data2,data3) if on every set of datapackages that is sent if im am doing it with just preamble and data1 as follows?

libor · Joined: 14 Dec 2004 Posts: 288 Location: Hungary

Lets send the data byte 3 times:

newguy · Joined: 24 Jun 2004 Posts: 1903

Gerhard,

See this post in the code library. It has a link to the original post here in the discussion group.

http://www.ccsinfo.com/forum/viewtopic.php?t=23953

Gerhard · Joined: 30 Aug 2007 Posts: 144 Location: South Africa

Thanks you.
Does the comand get_CC1000 only reads the 8 bits that are in the buffer before it actually copys that value into temp 1 and then reads the next 8 bits and copy's that bit in the next temp2 or does the buffer set itself to 0 and then redo the whole reading setup. How does the pic know that 8bits have been read and it should copy the next 8 bits into the next varable??

Gerhard · Joined: 30 Aug 2007 Posts: 144 Location: South Africa

I Can't seem to find the correct solution.
How is the adressing done in the getCC1000 comand. If the preamble is read the first data package gets read and after that the second but how does the pic know that it is in fact reading the complete 8bits of data1 then of data 2 and not some mix between the first data package and the last??

libor · Joined: 14 Dec 2004 Posts: 288 Location: Hungary

Gerhard · Joined: 30 Aug 2007 Posts: 144 Location: South Africa

Thanks.
If i sent 4 bytes of data [preamble,data1,data2,data3] and i then recieve them with
temp = getcc1000 //preamble
temp1 = getcc1000//data1
temp2=getcc1000//data2
temp3=getcc1000//data3

wil the pic then insert preamble into temp,data1 into temp1,data2 into temp3 or will the bits become mixed up between the bytes.
How do i implement the sync into the recieving side. I think my problem is that i don't understand how each byte is entered and read from the buffer and how the pic treats the buffer if different bytes are recieved into the buffer?

libor · Joined: 14 Dec 2004 Posts: 288 Location: Hungary

They will be mixed up. The beginning of the preamble is usually get lost in the air. (and you can't tell how much of it, maybe just 2 bits, maybe 6. this can vary with each packet) This is what the preamble meant for. (to allow the receiver - hardware in case of CC1000 - synchronize to the bit's boundaries)

Regarding the byte boundaries one approach is: You can read all bytes into a buffer. And shift them (with rotating bits) untill they are aligned to the true byte boundaries. How many bits of shifting you need depends on how many bits are lost in the air from the very beginning of the packet (preamble)
You can insert a known combination of bits (eg. two sync bytes) into the stream, so you will know how many bits of shifting you'll need to restore the original packet.

newguy · Joined: 24 Jun 2004 Posts: 1903

Once again, read this: http://www.ccsinfo.com/forum/viewtopic.php?t=23886
...and this: http://www.ccsinfo.com/forum/viewtopic.php?t=23953

These posts WILL help you to understand a) what is going on, and b) how to successfully establish an RF data link.

libor · Joined: 14 Dec 2004 Posts: 288 Location: Hungary

newguy, the ER400TRS module (used in the example that you refer to) has its own onboard microcontroller (maybe a PIC, or some other) that runs a firmware doing the packet construction, decoding, byte boundary synchronizing, addressing, maybe also the checksum error detecting/correction, resending etc. Using this module you are only talking to this microcontroller and not to the RF IC itself.

Gerhard is trying to interface directly to a CC1000 RF IC with no other microcontroller (with some company's firmware in it) doing these things for him.

(you might what's the reason, an RF module with a microcontroller+firmware in it costs in the range of $40-50, a CC1000 (we use the CC1100) RF chip costs $1-2, on the difference (actually the firmware's royalty) you can make a living on if you use/sell hundreds of these devices and write your own software)

newguy · Joined: 24 Jun 2004 Posts: 1903

I appreciate the difference, but the underlying principle should still work. The only thing that the approach given in the links assumes is that the tx & rx are matched - that is a 1 sent by the transmitter means a 1 comes out of the receiver - and that both the transmitter & receiver each have a PIC (or any microcontroller really - one to pump data into the tx and other to catch data coming from the rx). Things become easier if each microcontroller has a UART.

To transmit:
a) send a 3 or 4 byte LAM (look at me)/preamble.
b) send a unique product/tx - rx pair "address".
c) send your data.
d) (optional) send a CRC.

To receive:
a) implement a state machine rx routine - look for the unique product/tx - rx pair "address" used in the transmitter's step b) above. DON'T look for the LAM signal in step a).
b) once the correct "address" unlocks the rx state machine, accept the next byte(s) as data/CRC.
c) (optional) perform a sanity check on the received data.
d) act on the received data.