CC1101 Receiver

Wireless & IoT
1

Hi Folks,

CC1101 newbie here.

Have been working on a CC1101 435MHz simplex bi-directional system

for a while & having trouble getting the receiver to receive a 15 byte

packet.

Using the TI RF evm boards attached to my micros. Got the transmitter

working on the proper frequency, sending a single packet of data upon

pressing a switch.

Used basically the same register values for the receiver - using the TI

SmartRF studio. Set the GDO2 to go low when a packet is received with

a good CRC.

Have set up the sync words & serial #s to be the same, but still no

receive data.

Checking the status register as I am sending commands, etc, all seems

OK, and does show it to be in the receive mode while waiting for the

pin to go low.

Any Ideas?

Thanks,

Tim

2

The problem is that there are ten registers that can affect the reception. Double check that the packet size is correct, and try sending a packet with one byte payload. Turn the receiver into a transmitter, and check that it is at the same frequency as the actual transmitter. I had an offset problem that made one unit come up 700 KHz off. Simplify your protocol and crc until you get some response, then build up from there. Look at the TI website for sending an unmodulated carrier for test purposes. Finally, post your register presets and I’ll compare to working code.

Ron

3

Hi Ron,

Thanks for the post.

I put both modules into the transmit mode, and they were all very

close to the same frequency. (on spec analyzer with 100khz/div),

appeared at identical place. Couldn’t find the CW docs on TIs site.

Here are the RX register values in the order that they are sent. The

TX sequence is just a bit different at the end (load up TXFIFO & put

into TX mode).

Thanks,

Tim

ps: have some cousins that live in Stowe. Didn’t know where you were.

//RESET Chip

sendval = 0x3000;

// IOCFG2

sendval = 0x0047; // set for rcvd packet with correct crc

// FIFO THRESHOLD

sendval = 0x0344;

// SYNC 1

sendval = 0x0400;

// SYNC 2

sendval = 0x0501;

// PACKET LENGTH = 1 byte

sendval = 0x0601;

// PACKET CONTROL 1

sendval = 0x070c;

// PACKET CONTROL 0

sendval = 0x0844;

// FREQUENCY SYNTHESIZER CONTROL 1

sendval = 0x0b06;

// FREQUENCY SYNTHESIZER CONTROL 0

sendval = 0x0c00;

// FREQ 2

sendval = 0x0d10;

// FREQ 1

sendval = 0x0ebb;

// FREQ 3

sendval = 0x0f13;

// MODEM CONFIG 4

sendval = 0x10f5;

// MODEM CONFIG 3

sendval = 0x1183;

// MODEM CONFIG 2

sendval = 0x1230;

// MODEM CONFIG 1

sendval = 0x1302;

// MODEM CONFIG 0

sendval = 0x14f8;

// DEVIATION

sendval = 0x1515;

// MAIN RADIO CONTROL STATE 1

sendval = 0x1730;

// MAIN RADIO CONTROL STATE 0

sendval = 0x181c;

// fREQ OFFSET COMPENSATION CONFIG

sendval = 0x1914;

// BIT SYNCH CONFIG

sendval = 0x1a6c;

// AGC CONTROL 2

sendval = 0x1b03;

// AGC CONTROL 1

sendval = 0x1c40;

// AGC CONTROL 0

sendval = 0x1d92;

// FRONT END 1

sendval = 0x2156;

// FRONT END 2

sendval = 0x2211;

// FREQ SYNTH CALIBRATION 3

sendval = 0x23e9;

// FREQ SYNTH CALIBRATION 2

sendval = 0x242a;

// FREQ SYNTH CALIBRATION 1

sendval = 0x2500;

// FREQ SYNTH CALIBRATION 0

sendval = 0x261f;

sendval = 0x3300; // calibrate synth

sendval = 0x3400; // place in receive mode

4

Anybody else have any ideas?

I’ve pretty much reduced it as far as it’ll go - still no action.

Also, can someone point me to the unmodulated carrier info

for the part? I couldn’t find it on the TI site.

Thanks,

Tim

5

I have PKTCTRL1 as 5 and PKTCTRL0 as 4

6

Hi all,

Well, after scratching my head for a while, I figured that the best way

to get things rolling was to get one of the EB systems from TI. The

system includes two PCBs with micros & USB connector, along with

2 RF decks & antennas. They talk to the SmartRF studio software.

Hey, at least I could use one of them as a receiver & I’d tweak my

transmitter until it works.

Ok, 1st step - got the eval boards talking together in the mode that

I wanted (OOK, etc).

Now, setup one of the eval boards as a receiver & use my custom

board as the transmitter.

Hmmm, their receiver doesn’t receive what I’m transmitting.

Alright, let me setup my TX on my custom board identically to what

the EB does.

I set the spectrum analyzer in the ‘zero’ mode (basically displays

the OOK waveform). Using the EB system as a transmitter, I see

the 1010 preamble, the two sync bytes that I’ve set in the software,

and the 2 bytes of data (1st byte is the # of bytes in packet length).

(the Studio software doesn’t do fixed length packet).

Now, I set up my transmitter with the identical data (sync, data, etc).

Wait a minute, the sync bytes are inverted, the data is inverted. On

the EB I had set the Sync bytes to 01 01. On my board, I have to

set it to FE FE for it to look the same on the scope. Same for the

transmitted data.

Anybody have a clue how this can happen? I can send scope photos

if anybody is interested, but the data is truly inverted.

I’ve read back the registers that I’ve written, and they are correct.

Thanks for reading this late night journal!

There must be something about the forest for the trees.

Tim

7

Check your SPI comms. It sounds like the rising edge should be a falling edge, or vice versa. I had this problem in a prototype I made once. I changed the transmit idle state, and it worked fine after that.

8

Hi Ronny,

I thought that might be the case as well, but I captured the

data on my scope, and it’s picture-perfect per the CC1101

data sheet.

As a check, all of the commands work as they should -

frequency, turning on the transmitter, etc, & if the data

was really inverted, then I figured that wouldn’t work

right.

I’m sure it’s something extremely simple… where’s that

20-20 hindsight?

Thanks!

Tim

9

Hi Ronny,

Found it.

To keep things simple, I was only using single byte writes, instead

of using the burst mode.

HOWEVER, to write to any other index in the PATABLE, you must

use the burst mode. Every time the CS line goes high on the part,

the PATABLE index gets reset to 0. I was only writing to index 0.

And… Index 0 is the value programmed in for a logic 0! A logic

1 must be programmed at Index 1.

The not-so-fine-print says "PATABLE must be programmed in burst

mode if you want to write to other entries than PATABLE[0]". Hmm,

not sure why you’d want to do that, other than to invert the data! :shock:

Just got the waveforms to look good, next I’ll try out the real transfer

of data.

Thought I’d pass this one along… knew it was something easy!

Thanks,

Tim

10

I never experimented with OOK or the PATABLE. Sorry I wasn’t much help…

Ron

PS. I’ve got the CC1110 blinking an LED! Sending data is still a few days off! It’ll be nice not needing another processor to run the comms.