CC1101 Receiver issue

If you have the sender and receiver close to earth other you may saturate the receiver. Try with lager distance between the two. Also have you checked MARCSTATE on borg sides when you don't get a interrupt?

Hello TER,

We didn't tried reading MARCSTATE. When the receiver are close to each other the communication is proper and if the receiver is taken away from transmitter say 6 mts the receiver stops receiving the data. If we bring the receiver close to transmitter still the modules are not communicating.

We will try to read MARCSTATE once the communication is lost.

Thanks,

Sreekanth

Use packet length filtering and set max packet length to 61 to avoid overflow and to avoid the overflow issue (Radio stays in RX state instead of entering RXFIFO_OVERFLOW state) described in the errata note (http://www.ti.com/lit/swrz020)

Siri

Hello Siri,

Thanks for the response.

In our case the Receiver is properly receiving the data when both the modules are close to each other. But when the receiver is far say 5-6mts from transmitter the receiver will not receiver any data and when we bring the receiver close to transmitter the receiver will not receive the data.

In another condition the transmitter and receiver are kept close, both the modules work fine but after some time the receiver will not receive any data.

We will test the modules as you suggested and as per the errata.

Thanks,

Sreekanth

Hi

The receiver not being able to receive when the distance to the transmitter is more than 5-6 meters sound like a problem with the HW or RF register settings. I am not an expert on this and will leave it to other to comment on that. What I can do is to look at your SW routine for receiving packets and your register settings related to the packet engine to make sure that the problem is not related to unhandled overflow situations etc.

BR

Siri

Hello Siri,

I suspected the RF module issue and we tried with other modules and the results are same.

Regarding the register settings we downloaded the register settings from Anaren website and the setting we are using are,

A1101R08X_M12_Band_10_GFSK_4.8kB_13.2kDev_60kRX_PA_Table_0xC0.txt downloaded from the below link

http://www.anaren.com/air/a1101r08x-register-files 

BR,

Sreekanth

Hi Sreekanth

From the register settings I see that no packet length filtering is used.

This means that you potentially can run into the issue described in the errata. In addition to read MARCSTATE when the modules are failing it would be useful if you could read NUM_RXBYTES also. Remember that these registers are status registers so the burst bit needs to be set when accessing them.

I you want me to I can take a look at your receive routine as well.

BR

Siri

Hello Siri,

We modified the register settings. We are now writing the packet length as 8 bytes and in the packet control register packet is configured to fixed packet length.

We also read MARCSTATE and NUM_RXBYTES registers and found that MARCSTATE =1 and NUM_RXBYTES =10.

In our code before entering TX or RX we are putting the module to IDEAL state and then RX or TX mode.

Still we are facing the same issue.

BR,

Sreekanth

Hello Siri,

We have two RF modules, for testing purpose we configured one as transmitter and the other one as receiver. the transmitter is transmitting 20 bytes of data every one second and the receiver is continuously in listen mode receiving the data.Please find attached our test code for transmitter and receiver.Currently we are testing with rf settings mentioned in A1101R08X_M6_Band_10_GFSK_10kB_13kDev_60kRX_PA_Table_0xC0.txt.

The projects are created in IAR IDE.6431.rf_rx_test.zip8510.rf_tx_test.zip

Regards,

Jis 

Hi, 

I looked at the settings and could not see anything very wrong. You should turn on the ADC retention (FIFOTHR 0x47), and we use a if freq FSCTRL1 0x06, but this should not create the behaviour you describe. Can you set up your modules so that you can run SmartRF Studio and thus known SW? Do you use carrier sense? I see this is not set in the settings you show, but since you have altered the AGC settings, maybe you use this in your SW? Anyway, if you use CS, make sure the threshold is set to a reasonable level. I see that you use max output power, what RSSI do you read for the different distances within your range? I am not familiar with the HW you are using, but 5-6 m sounds very little for this much output power and settings, do you have a kit from us you can test with? Have you done any conducted testing (require soldering to remove the antenna and add a semirigid cable)?

I have run a code example here with your settings and they work fine.

However, I have some comments to your code:

1) You should always wait for CHIPRDYn (MISO) going low before starting the SPI clock. This is especially important when you have put the chip in SLEEP mode

2) When transmitting packets, you should wait for a packet to be sent by polling GDO2 (sync sent/received)

3) I did not understand  the for(count = 0; count < 4; count++) loop.

Is it because of the SPI bug? As long as you wait for the packet received signal (falling edge of GDO2) the radio is in IDLE (or overflow) when you read this registers and hence it cannot change in the middle of a read.

BR

Siri