This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem with Packet RX/TX Tests in SmartRF Studio with CC1101

Hi

I am using two SmartRF04EB 1.9 boards, firmware revision 0045, to carry out some testing using SmartRF Studio 7 (1.10.2).
I have tried doing similar tests with two different devices: the CC1101EM 3.0 868MHz, and the CC1101EM 2.0 434MHz.

With the 868MHz device, I have used one of the generic 868MHz settings built in to SmartRF studio. For the 434MHz version, I am using the following settings (extracted from the device datasheet):

#define SMARTRF_SETTING_IOCFG0 0x06

#define SMARTRF_SETTING_FIFOTHR 0x65A2

#define SMARTRF_SETTING_PKTCTRL0 0x05

#define SMARTRF_SETTING_FSCTRL1 0x12

#define SMARTRF_SETTING_FREQ2 0x10

#define SMARTRF_SETTING_FREQ1 0xB0

#define SMARTRF_SETTING_FREQ0 0x3F

#define SMARTRF_SETTING_MDMCFG4 0x2D

#define SMARTRF_SETTING_MDMCFG3 0x3B

#define SMARTRF_SETTING_MDMCFG2 0x93

#define SMARTRF_SETTING_MDMCFG1 0x00

#define SMARTRF_SETTING_DEVIATN 0x62

#define SMARTRF_SETTING_MCSM0 0x18

#define SMARTRF_SETTING_FOCCFG 0x1D

#define SMARTRF_SETTING_BSCFG 0x1C

#define SMARTRF_SETTING_AGCCTRL2 0xC7

#define SMARTRF_SETTING_AGCCTRL1 0x00

#define SMARTRF_SETTING_AGCCTRL0 0xB0

#define SMARTRF_SETTING_WORCTRL 0xFB

#define SMARTRF_SETTING_FREND1 0xB6

#define SMARTRF_SETTING_FSCAL3 0xEA

#define SMARTRF_SETTING_FSCAL2 0x2A

#define SMARTRF_SETTING_FSCAL1 0x00

#define SMARTRF_SETTING_FSCAL0 0x1F

#define SMARTRF_SETTING_TEST0 0x09

#define SMARTRF_SETTING_RSSI 0x80

#define SMARTRF_SETTING_MARCSTATE 0x01

#define SMARTRF_SETTING_VCO_VC_DAC 0x94

The tests I have carried out have used SmartRF studio:

- Carry out a packet TX (payload size 30) for 10 packets (with the packet RX set with an infinite expected packet count).

- I then wait approx 30s.

- TX a further 10 packets.

The first 10 packets are received without error, but the later 10 packets are not received at all. On the receiver, the radio state is shown as "N.A."

Do you have any idea what could be causing this problem?

Many thanks

  • Hi

    What happens if you do not wait between the bursts of packets (e.g. send 1000 packets)?  Do you get all the packets then?

  • Martin B said:

    Hi

    What happens if you do not wait between the bursts of packets (e.g. send 1000 packets)?  Do you get all the packets then?

    Hi Martin

    I've just run a test transmitting 1000 packets and yes, all packets were received ok.

  • Further, I've just tested it with a pair of CC2500EM 3.0 modules (using typical settings in SmartRF Studio), and it exhibits the same problem.

    Has anyone else experienced this issue?

    Many thanks
    Alex

  • Hi

    Have you checked that you do not get in a RXFIFO overflow state during the 30 s period without sending packets. If there is a lot of noise in your channel you may experience a lot of "false syncs" which can cause the radio into a overflow state. If this is the case you may want to increase your PQT threshold

  • Hi Martin

    How do I check that (and set the PQT threshold) in SmartRF Studio? I have checked the Advanced settings and the 'FIFO Auto Flush' box is ticked.

    Thanks
    Alex

  • Hi

    PQT can be set in the PKTCTRL1 register. (PKTCTRL1.PQT).  A “Preamble Quality Reached” signal can be observed on one of the GDO pins by setting IOCFGx.GDOx_CFG=8. It is also possible to determine if preamble quality is reached by checking the PQT_REACHED bit in the PKTSTATUS register. This signal / bit asserts when the received signal exceeds the PQT.

  • Hi AlexSW,

    This is a known problem with the FW on SmartRF04EB. The packet handler on this board is the same for SmartRF Studio as for the stand alone PER test.
    The standalone PER test is based on a two way communication and a timer is used to detect any missing reply. If no packets received within the specified time (10-15 sek), the receive function will time out and the chip set in IDLE mode.

    To solve this it would be required with different handling for SmartRF Studio and the stand alone PER test. The biggest problem with this is that the flash area is full. A bigger change of the FW would be required and unfortunately it has not been planned to do so.

    Regards,
    Øyvind