CC110L: rx config.

Hi Jose

Unfortunately, I am not in the office this week and do not have the proper HW to test this myself and to send you plots showing how things should look like on the GDO lines etc., but there are several things I would like you to check:

Please make sure that the GPIO you have connected to GDO0 is configured as an input and that there is nothing else connected to this pin/driving this pin. If you have configured an interrupt on this GPIO, please make sure that it works as expected (do not have the CC110L GDO0 as input on the pin, but a known signal that you can control, to make sure that everything is OK).

You reading of RXBYTES does not make sense.

Nothing will ever be put in the RX FIFO unless you have found sync word, and if you have found sync you will have a rising edge on GDO0 (if IOCFG0 = 0x06). Since you are also using address filtering, then you can risk that the GDO0 signal is de-asserted again if the address does not match (and in that case nothing is put in the RX FIFO), or the address matches, and you will receive the number of bytes indicated by the length byte (first byte received after sync).

There are several things you can test/check here.

Make sure that you are using length filtering if there are room for the complete packet in the RX FIFO. This will make sure that you do not run into an overflow situation.

Make sure that you are transmitting a correct packet on the TX Side.

You are using variable packet length and address filtering, so a valid packet sent would for example be: 0x06, 0x21, 0x01, 0x02, 0x03, 0x04, 0x05, where 0x06 is the length byte, 0x21 is the address, and 0x01 to 0x05 is the payload.

On the RX side, if GDO0 is not first asserted and then de-asserted there are two possible problems:

1. There is something wrong with the configuration of the pin connected to GDO0 (as described above) or
2. there is something wrong with your design, so that the RF performance is not good enough to receive anything.

If the latter is the case, nothing will be put in the RX FIFO, and you need to double-check what is actually sent on the SPI when you are reading RXBYTES register. Remember that this register is a status register, and that the burst bit needs to be set when reading the register.

If GDO0 is asserted because you have received a valid sync, and the address matches so that data is put in the RX FIFO, the reading of RXBYTES, will give you an increasing value from 0 (empty FIFO), to 0x09 (complete packet received in the FIFO, if the packet is the one described above).

Siri

Hello Siri, good morning,

I checked the hardware and it seems right. Crystal is 26MHz +/-30ppm in both sides (tx&rx), with two 10pF capacitors giving a CLoad of 7.5pF more or less according to the expected by the datasheet of the crystal. I attach the spectrum of a carrier non modulated that I used to test the accuracy of the synthesizer: it drifts only -2KHz in one side, and -4KHz in the other. Then in SmartRF Studio I set a deviation of 25KHz, a RX BW of 270KHz, and a data rate of 5Kbps (slow data rate). It should be enough ... Yes, the GPIO for the GDO0 is configured as 0x06, and in my micro as a Digital Input with no internal pullup/pulldown (I will try in fact with a pulldown). No interrupt is defined (I read the GPIO inside a while loop every time, 500ms, because it's the only way i had to capture an assert on the GDO0 and a de-assert). Once I captured the high value on GPIO (not always), I wait until it de-asserts, thus the current state is IDLE, so now i read the RSSI, CRC value, and the content of the message, length (the first byte in the fifo) and RXBYTES (with a status command and then with a read burst on the fifo to look at the message received). For my surprise, the length retrieved is incoherent, also the RXBYTES inside the FIFO. And the message, (Hello World!) appears always with strange characters at the beginning (are they the preamble and sync word??). Let's have a look to my console (picture attached, the RSSI is very good as expected and the CRC is ... OK?) Once i have read all the data, i flush the RX FIFO (Iam in idle state, i can do it) and strobe first a SFSTXON, and then a SRX to turn on the receiver again.

Regards

I get a bit confused regarding your settings. First you say that you are using 1.2 kbps, and now you say that you are using 5 kbps. Until you get this up and running, I strongly recommend that you stick to one of the default settings from SmartRF Studio.

You should also try to use fixed packet length and disable address filtering for now, to remove stuff that can make packets be filtered away. With fixed packet length = x, the radio will always put 5 bytes (+ 2 status bytes) in the FIFO if sync has been received.

Polling GDO0 every 500 ms is not a solution you can use. With a data rate of 5 kbps, the signal will not be asserted for more than 2*8/5000 = 3.2 ms if address filtering rejects the packet, and even if you fill the FIFO completely (64 bytes), the signal will only be asserted for 64*8/5000 = 102.4 ms

If you miss an assertion, you will not read/flush your FIFO, and the old data will still be there.

Another thing is that the SPI reading that you show me is of little use, as it does not tell me if you interpret the data correctly or not. You need to provide plots from a logic analyzer showing the SPI traffic that is actually going on between the MCU and the radio.

Try for example the following settings:

// Address Config = No address check
// Base Frequency = 433.999969
// CRC Autoflush = false
// CRC Enable = true
// Carrier Frequency = 433.999969
// Channel Spacing = 199.951172
// Data Format = Normal mode
// Data Rate = 1.19948
// Deviation = 5.157471
// Device Address = 0
// Manchester Enable = false
// Modulated = true
// Modulation Format = GFSK
// Packet Length = 10
// Packet Length Mode = Fixed packet length mode. Length configured in PKTLEN register
// Preamble Count = 4
// RX Filter BW = 58.035714
// Sync Word Qualifier Mode = 30/32 sync word bits detected
// TX Power = unknown
// PA table

#define PA_TABLE {0x50,0x00}

static const registerSetting_t preferredSettings[]=
{
    {CC110L_IOCFG0, 0x06},
    {CC110L_FIFOTHR, 0x47},
    {CC110L_PKTLEN, 0x0A},
    {CC110L_PKTCTRL0, 0x04},
    {CC110L_FSCTRL1, 0x06},
    {CC110L_FREQ2, 0x10},
    {CC110L_FREQ1, 0xB1},
    {CC110L_FREQ0, 0x3B},
    {CC110L_MDMCFG4, 0xF5},
    {CC110L_MDMCFG3, 0x83},
    {CC110L_MDMCFG2, 0x13},
    {CC110L_DEVIATN, 0x15},
    {CC110L_MCSM0, 0x18},
    {CC110L_FOCCFG, 0x16},
    {CC110L_RESERVED_0X20, 0xFB},
    {CC110L_FSCAL3, 0xE9},
    {CC110L_FSCAL2, 0x2A},
    {CC110L_FSCAL1, 0x00},
    {CC110L_FSCAL0, 0x1F},
    {CC110L_TEST2, 0x81},
    {CC110L_TEST1, 0x35},
    {CC110L_TEST0, 0x09},
};

These are the standard 1.2 kbps settings at 434 MHz, no address filtering, and fixed packet length set to 10.

You code should do the following, and nothing else:

Init MCU

Init Radio (Reset + configure the registers with the settings above)

Strobe SRX

Start polling MARCSTATE continuously (not once every x ms)

MARCSTATE will report that you are in RX STATE (If your SPI is very fast you might see some of the states between IDLE (0x01) and RX (0x0D), but it should end up reporting 0x0D

Transmit a packet after you have confirmed that you receiver is in RX state.

If your RF design is OK, you will not detect the sync word and 10 (PKTLEN) bytes will be put in the RX FIFO, together with the 2 status bytes. After this the radio will enter IDLE mode

When MARCSSTATE reports IDLE, you should read RXXBYTES, and it will report 0x0C

You can now read the 12 bytes in the RX FIFO

Please do the test above and send me the SPI plots for me to analyze.

BR

Siri

According to the CC110L datasheet. CLoad min is 10 pF for the xtal. 

Hello Siri,

I thoroughly did what you say, but it's still not working with these settings. I do not see anything.

The only way I have found to see a change in the MARCSATE to Idle is with this: data rate 100Kbps / Deviation of 25KHz / RX BW of 300KHz

Although with my settings I get an Idle State (I also see a pulse in the GPIO0) when I send a packet of fixed length (10 bytes), the length that I read from the RXFIFO does not make sense. At this point we could say that the preamble and sync word are detected by the Packet Handler, but the retrieved length is still incoherent, and not to say the message ...

I've checked that both sides (the transmitter and the receiver) have the same crystal 26MHz with the same capacitors, and are able to transmit an unmodulated carrier at 434MHz with a deviation < 5KHz. If i'm missing more calibration i don't know.

Jose.

If your HW does not work with the recommended settings from SmartRF Studio, there is something wrong with your HW.

I tested the 1.2 kbps settings from Studio at 434 MHz, but changed to fixed packet length mode and set the packet length to 10.

Settings as follows:

// Address Config = No address check 
// Base Frequency = 433.999969 
// CRC Autoflush = false 
// CRC Enable = true 
// Carrier Frequency = 433.999969 
// Channel Spacing = 199.951172 
// Data Format = Normal mode 
// Data Rate = 1.19948 
// Deviation = 5.157471 
// Device Address = 0 
// Manchester Enable = false 
// Modulated = true 
// Modulation Format = GFSK 
// Packet Length = 10 
// Packet Length Mode = Fixed packet length mode. Length configured in PKTLEN register 
// Preamble Count = 4 
// RX Filter BW = 58.035714 
// Sync Word Qualifier Mode = 30/32 sync word bits detected 
// TX Power = unknown 
// PA table 
#define PA_TABLE {0x50,0x00}

static const registerSetting_t preferredSettings[]= 
{
  {CC110L_IOCFG0,           0x06},
  {CC110L_FIFOTHR,          0x47},
  {CC110L_PKTLEN,           0x0A},
  {CC110L_PKTCTRL0,         0x04},
  {CC110L_FSCTRL1,          0x06},
  {CC110L_FREQ2,            0x10},
  {CC110L_FREQ1,            0xB1},
  {CC110L_FREQ0,            0x3B},
  {CC110L_MDMCFG4,          0xF5},
  {CC110L_MDMCFG3,          0x83},
  {CC110L_MDMCFG2,          0x13},
  {CC110L_DEVIATN,          0x15},
  {CC110L_MCSM0,            0x18},
  {CC110L_FOCCFG,           0x16},
  {CC110L_RESERVED_0X20,    0xFB},
  {CC110L_FSCAL3,           0xE9},
  {CC110L_FSCAL2,           0x2A},
  {CC110L_FSCAL1,           0x00},
  {CC110L_FSCAL0,           0x1F},
  {CC110L_TEST2,            0x81},
  {CC110L_TEST1,            0x35},
  {CC110L_TEST0,            0x09},
  {CC110L_CRC_REG,          0x1F},
  {CC110L_RSSI,             0x80},
  {CC110L_MARCSTATE,        0x01},
};

I then transmitted a 10 bytes long packet: 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x07, 0x08, 0x09, 0x0A

On the receive side, I waited for falling edge interrupt on GDO0, read RXBYTES (it returned 0c0C as expected, and read the 10 payload bytes + the 2 status bytes from the RX FIFO:

Have you followed our reference design when making your own HW?

BR

Siri

In addition to the SPI plots: 

Are you able to receive if you connect a CCDebugger to the SPI interface and let SmartRF Studio control the CC110L? 

Please provide a schematic for the CC110L part to verify that this looks ok.