uMiRF Sparkfun example code

Wireless & IoT
1

Hi All,

Very new to this stuff so here goes. I am awaiting my uMiRF boards and have already been looking at the example code from Sparkfun (RF-24G-Example.zip). In the code for the 256 bit payload the NOTE below has a few suggestions for improvement.

NOTE: ... With the CRC set to 8 bit (default) the receiver will find all sorts of junk in the air with a correct CRC tag. Our recommendation is to either transmit a resonably constant stream of data, use 16-bit CRC, and/or use additional header/end bytes in the payload to verify incoming packets.

This code already seems to use a 16bit CRC, correct ?

I assume adding manchester encoding to the code would make it more robust?

Increasing the header and end bytes would reduce the actual space available for data so there seems to be a tradeoff. Is there a sweet spot here?

Anyone have any other suggestion to improve things?

Kind thanks,

Serge

2

Just some thoughts

With the CRC set to 8 bit (default) the receiver will find all sorts of junk in the air with a correct CRC tag. Our recommendation is to either transmit a resonably constant stream of data, use 16-bit CRC, and/or use additional header/end bytes in the payload to verify incoming packets.

This above note is correct if using 8 bit crc

recommend using 16 bit crc

I assume adding manchester encoding to the code would make it more robust?

not required as the module already does all the error checking for you

IE: it must get a correct address and crc to record valid data

Increasing the header and end bytes would reduce the actual space available for data so there seems to be a tradeoff. Is there a sweet spot here?

this is true increases in address and crc values decrease the packet size

accordingly. the tradeoff is if you want to get reliable data make these

as big as you can afford IE: 40 bit address 16 bit crc and to further

increase valid data drop down to 256kbits vice 1mbits

happy uMiRFing

3

Hi fletch,

OK thanks for this input. So basically the chances of a parasite packet coming through with the correct address and CRC are pretty slim.

With regards to manchester encoding, you say it is not required because there is some form of error checking done by the module already.

Would doing the encoding in addition to the rest bring any value at all or will it simply decrease the number of bits available for user data without any added benefit?

Sorry if some of these questions sound like they are from a beginer, but I am :slight_smile:

Kind thanks,

Serge

4

reply

OK thanks for this input. So basically the chances of a parasite packet coming through with the correct address and CRC are pretty slim.

if you use 40bit addr and 16crc chances are about nill

manchester encoding

the chip provides its own encoding so adding it is definitly not reqd

this is the great thing about these modules versus the tlp/rlp series

which do require manchester encoding ive been there it isnt worth

it imho

5

just may help to realize it all this is a copy of my rf24g code

which does what we have been talking about

this code tx 4 bytes of data {12,34,AB,CD}

to address {AA,55,FF,00,AA} with 16 bit crc

void configure_transmitter(void)

{

//Config Mode

TX_CE = 0; TX_CS = 1;

//Delay of 5us from CS to Data (page 30)

delay_ms(5);

/*config word Gives u lowest error rate, if u want a 8 byte payload

just change Data1_W to 0b00001000. It operates in shockburst/250kbs

16 bit crc on channel #2, full rf pwr, 1 channel rx only, 16mhz rf24g clk

addr width 5 bytes IE 40bits

*/

//All this is the same setup in the receiver bit 0 is changed to rx/tx as req

spi(0b00100000); //Data1_W - 32 bits in payload 4 bytes

spi(0x00); //ADDR2 - 1 //We only use 1 addr so set this to zero

spi(0x00); //ADDR2 - 2

spi(0x00); //ADDR2 - 3

spi(0x00); //ADDR2 - 4

spi(0x00); //ADDR2 - 5

spi(0xAA); //ADDR1 - 1 //1 - 5 This is our tx and rx addr

spi(0x55); //ADDR1 - 2

spi(0xFF); //ADDR1 - 3

spi(0x00); //ADDR1 - 4

spi(0xAA); //ADDR1 - 5

spi(0b10100011); //ADDR_W - 40 bits wide - CRC en 16bits

spi(0b01001111); //Full pwr- 16mhzclk- 250kbs-shkburst-1 chan only

spi(0b00000100); //RF Channel #2 and TX/RX - TX = 0 bit 0;

//Configuration is actived on falling edge of CS (page 10)

TX_CE = 0; TX_CS = 0;

}

// this sends address then sends data

void transmit_data(void)

{

TX_CE = 1; //set up for transmit

delay_ms(5);

spi(0xAA); //ADDR1 - 1 Send addr our receive is expecting

spi(0x55); //ADDR1 - 2

spi(0xFF); //ADDR1 - 3

spi(0x00); //ADDR1 - 4

spi(0xAA); //ADDR1 - 5

spi(0x12); //4 bytes data to transmit to the receiver

spi(0x34);

spi(0xAB);

spi(0xCD);

TX_CE = 0; //Start transmission

}

6

hello,

I have a small problem with one line in the code.

config_setup <<= 1;

CC5X free edition tells me it doesn’t understand it.

I changed it to config_setup = config_setup << 1;

and CC5X said that << is not supported in the free version.

I tried a different CC5X.

It said :

Error C:\pics\code\rf01\rf01.c 115: Unable to generate code

(The C syntax is correct. However, CC5X is unable to generate code.

The workaround is often to split the code into simpler statements,

using an extra variable to store temporary results. Sometimes it is

enough to change the sequence of operations)

I tried doing

uns24 shifted;

shifted = config_setup << 1;

config_setup = shifted;

but same problem.

Why am I getting this?

and how can i fix it?

7

Try changing config_setup <<= 1; to config_setup *= 2; or ```
config_setup = config_setup * 2;


Converting multiplication by a power of 2 to left shifts is a common compiler optimization, so it should work the other way around as well.
8

same problem

config_setup = config_setup * 2;

^------

Error C:\pics\code\rf01\rf01.c 115: Unable to generate code

(The C syntax is correct. However, CC5X is unable to generate code.

The workaround is often to split the code into simpler statements,

using an extra variable to store temporary results. Sometimes it is

enough to change the sequence of operations)

Error options: -ew: no warning details -ed: no error details -eL: list details

I really don’t understand this problem.

Also the free compiler doesn’t support this. I had to use another CC5X that I found that I guess is not a free copy.

Any other suggestions?

can you try it on your compiler .

Maybe its the chip PIC16F88

9

I’ve had nothing but trouble with CC5X.

I didn’t realize it was this bad. Most likely, the compiler is complaining that it can’t read, modify, and store the same variable in one operation.

It looks like you’re going to have to combine the solution you tried, storing the value in a temporary variable, and replacing the shift with a multiplication.

Incidentally, I was never able to get two nested for loops to generate correct code in CC5X. I didn’t get any compile warnings about it, but the function never worked. I ended up having to replace one with a while loop and a break.