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.

CC110L configuration in SimpliciTI

Other Parts Discussed in Thread: CC110L, SIMPLICITI, CC1100, TEST2, CC1101

Hello,

I have a problem with CC110L configuration and/or SimpliciTI regarding the base frequency. Here are my experiences:

First I set the CC110L  (assembled on a TRxEB) by feeding with a configuration provided by SmartRF Studio according to the settings listed at the end of this post, and on this screenshot:

The results is observable on the spectrum analyzer, which is as expected, according to the setup in SmartRF  Studio (peak at 902 MHz):

Also the packets can be received on another machine with another TrxEB with a CC1100:

So far it is great.

Then I export the settings to a system that uses SimpliciTI, with test software that periodically sends out fast short packets. Here I experience that the peak on the spectrum analyzer moved up about 100kHz: 

Packets are not received any more on the receiver, unless I move the base frequency up by 100kHz to 902.1MHz. If I moved, then everything goes all right, packets a reperfectly received again:

Seems that spectrum analyzer and SmartRF Studio receiver side results do match.

Could someone please analyze my settings, what could be wrong? I think it is not a simple channel setting problem in SimpliciTI, otherwise the shift should be a multiple of 400kHz, based on the channel spacing setting. Additionally I believe that the hardware is quite thoroughly tested and verified, so first I'd try to exclude such issues.

Thank you for any reply in advance,

Best regards.

Gyula Kiss

Here is the register export as complete text out SmartRF Studio:

/* Modulation format = GFSK */
/* Data format = Normal mode */
/* Packet length mode = Variable packet length mode. Packet length configured by the first byte after sync word */
/* RX filter BW = 101.562500 */
/* CRC enable = true */
/* CRC autoflush = false */
/* Address config = No address check */
/* Base frequency = 901.999969 */
/* Data rate = 19.1917 */
/* Carrier frequency = 901.999969 */
/* Channel spacing = 399.902344 */
/* Device address = 0 */
/* Deviation = 9.521484 */
/* Sync word qualifier mode = 30/32 sync word bits detected */
/* Manchester enable = false */
/* Preamble count = 4 */
/* Modulated = true */
/* TX power = 0 */
/* Packet length = 255 */
/***************************************************************
* SmartRF Studio(tm) Export
*
* Radio register settings specifed with C-code
* compatible #define statements.
*
* RF device: CC110L
*
***************************************************************/

#ifndef SMARTRF_CC110L_H
#define SMARTRF_CC110L_H

#define SMARTRF_RADIO_CC110L
#define SMARTRF_SETTING_IOCFG2 0x29
#define SMARTRF_SETTING_IOCFG1 0x2E
#define SMARTRF_SETTING_IOCFG0 0x06
#define SMARTRF_SETTING_FIFOTHR 0x47
#define SMARTRF_SETTING_SYNC1 0xD3
#define SMARTRF_SETTING_SYNC0 0x91
#define SMARTRF_SETTING_PKTLEN 0xFF
#define SMARTRF_SETTING_PKTCTRL1 0x04
#define SMARTRF_SETTING_PKTCTRL0 0x05
#define SMARTRF_SETTING_ADDR 0x00
#define SMARTRF_SETTING_CHANNR 0x00
#define SMARTRF_SETTING_FSCTRL1 0x08
#define SMARTRF_SETTING_FSCTRL0 0x00
#define SMARTRF_SETTING_FREQ2 0x22
#define SMARTRF_SETTING_FREQ1 0xB1
#define SMARTRF_SETTING_FREQ0 0x3B
#define SMARTRF_SETTING_MDMCFG4 0xC9
#define SMARTRF_SETTING_MDMCFG3 0x83
#define SMARTRF_SETTING_MDMCFG2 0x13
#define SMARTRF_SETTING_MDMCFG1 0x23
#define SMARTRF_SETTING_MDMCFG0 0xF8
#define SMARTRF_SETTING_DEVIATN 0x24
#define SMARTRF_SETTING_MCSM2 0x07
#define SMARTRF_SETTING_MCSM1 0x30
#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 0xB2
#define SMARTRF_SETTING_RESERVED_0X20 0xFB
#define SMARTRF_SETTING_FREND1 0xB6
#define SMARTRF_SETTING_FREND0 0x10
#define SMARTRF_SETTING_FSCAL3 0xE9
#define SMARTRF_SETTING_FSCAL2 0x2A
#define SMARTRF_SETTING_FSCAL1 0x00
#define SMARTRF_SETTING_FSCAL0 0x1F
#define SMARTRF_SETTING_RESERVED_0X29 0x59
#define SMARTRF_SETTING_RESERVED_0X2A 0x7F
#define SMARTRF_SETTING_RESERVED_0X2B 0x3F
#define SMARTRF_SETTING_TEST2 0x81
#define SMARTRF_SETTING_TEST1 0x35
#define SMARTRF_SETTING_TEST0 0x09
#define SMARTRF_SETTING_PARTNUM 0x00
#define SMARTRF_SETTING_VERSION 0x07
#define SMARTRF_SETTING_FREQEST 0x00
#define SMARTRF_SETTING_CRC_REG 0x11
#define SMARTRF_SETTING_RSSI 0x80
#define SMARTRF_SETTING_MARCSTATE 0x01
#define SMARTRF_SETTING_PKTSTATUS 0x00
#define SMARTRF_SETTING_TXBYTES 0x00
#define SMARTRF_SETTING_RXBYTES 0x00

#endif

  • Gyula,

    Gyula Kiss said:

    First I set the CC110L  (assembled on a TRxEB) by feeding with a configuration provided by SmartRF Studio according to the settings listed at the end of this post, and on this screenshot:

    So far it is great.

    If using our development works, and i guess you are then testing it on your custom hardware:

    Gyula Kiss said:

    Then I export the settings to a system that uses SimpliciTI, with test software that periodically sends out fast short packets. Here I experience that the peak on the spectrum analyzer moved up about 100kHz: 

    I guess this must be a hardware problem. Have you tried to check your hardware?

  • I note that you write to some registers that you don't have to write to (PARTNUM etc + _RESERVED_0X). Try to write to only the registers you need to write, it could be that some of the extra registers you write to causes an issue.

  • Dear Leo,

    First, thank you for your reply.

    To be honest, I have quite strong confidence in the schematics, since it has been implemented and validated under the help of some TI experts in Oslo. (here I would express my appreciation for them again...)

    Additionally the same effect can be obvserved on several instances on three different kind of boards. (I have three layout designs, and at least 5 pieces are available from each hardware.) I think it is quite unrealistic that all do the same error. (e.g. xtal tolerances, ... )

    One (maybe) important note, we may think about: SimpliciTI is used as if my chip would be CC1101. However my realization is with CC110L. This was an advice from your colleagues before. Can't it be some difference in this regards?

    Thank you for any reply in advance,

    best regards,

    Gyula

  • Hello Ter, 

    Thank you for your note as well,

    This is only a list of defines, of course with notable overhead in it..

    I believe SimpliciTI writes only the ones which are part of mrfiRadioCfg (if I am not mistaken), as follows:

    static const uint8_t mrfiRadioCfg[][2] =

    {
    /* internal radio configuration */
    { IOCFG0, MRFI_SETTING_IOCFG0 },
    { MCSM1, MRFI_SETTING_MCSM1 }, /* CCA mode, RX_OFF_MODE and TX_OFF_MODE */
    { MCSM0, MRFI_SETTING_MCSM0 }, /* AUTO_CAL and XOSC state in sleep */
    { PKTLEN, MRFI_SETTING_PKTLEN },
    { PKTCTRL0, MRFI_SETTING_PKTCTRL0 },
    #ifdef MRFI_CC1101
    { FIFOTHR, MRFI_SETTING_FIFOTHR },
    #endif

    /* imported SmartRF radio configuration */
    { FSCTRL1, SMARTRF_SETTING_FSCTRL1 },
    { FSCTRL0, SMARTRF_SETTING_FSCTRL0 },
    { FREQ2, SMARTRF_SETTING_FREQ2 },
    { FREQ1, SMARTRF_SETTING_FREQ1 },
    { FREQ0, SMARTRF_SETTING_FREQ0 },
    { MDMCFG4, SMARTRF_SETTING_MDMCFG4 },
    { MDMCFG3, SMARTRF_SETTING_MDMCFG3 },
    { MDMCFG2, SMARTRF_SETTING_MDMCFG2 },
    { MDMCFG1, SMARTRF_SETTING_MDMCFG1 },
    { MDMCFG0, SMARTRF_SETTING_MDMCFG0 },
    { DEVIATN, SMARTRF_SETTING_DEVIATN },
    { FOCCFG, SMARTRF_SETTING_FOCCFG },
    { BSCFG, SMARTRF_SETTING_BSCFG },
    { AGCCTRL2, SMARTRF_SETTING_AGCCTRL2 },
    { AGCCTRL1, SMARTRF_SETTING_AGCCTRL1 },
    { AGCCTRL0, SMARTRF_SETTING_AGCCTRL0 },
    { FREND1, SMARTRF_SETTING_FREND1 },
    { FREND0, SMARTRF_SETTING_FREND0 },
    { FSCAL3, SMARTRF_SETTING_FSCAL3 },
    { FSCAL2, SMARTRF_SETTING_FSCAL2 },
    { FSCAL1, SMARTRF_SETTING_FSCAL1 },
    { FSCAL0, SMARTRF_SETTING_FSCAL0 },
    { TEST2, SMARTRF_SETTING_TEST2 },
    { TEST1, SMARTRF_SETTING_TEST1 },
    { TEST0, SMARTRF_SETTING_TEST0 },
    };

    Thank you, for your note anyway,

    Do you have maybe another idea? I would appreciate for any hints or ideas.

    best regards,

    Gyula

  • Gyula,

    i can't see the issue. I tried to run SimpliciTI with MSP-EXP430G2 Launchpad + CC110L EM + CC EM Adapter Boosterpack, and i see the following:

    while with SmartRF Studio using TrxEB and the same CC110L EM, i got more or less the same result:

  • Hello Leo,

    Thank you again for dealing with my problem.

    We performed a lot of additional test with the hardwares we have. Now I think, I can confirm your suspicion that the problem is hardware related. I can hardly imagine this could be true. Here are some collected facts & observations:

    - We confirm that the eval boards (trxeb+cc11xx)  work appropriately

    - All our different hardware (checked with multiple samples, each), are shifted up around 50kHz

    - We use TXC 26MHz 10ppm 18pF everywhere: ( http://www.farnell.com/datasheets/1497895.pdf )

    - Putting an XTAL from a CC11xx eval board on to our hardware, the peak stays 50kHz above -> no change

    - Replacing the 18pF capacitors to 27pF the peak of the expected 902 MHz peak becomes perfectly as expected (on all our different hardwares and on any samples )

    - By controlling our hardware from SmartRFStudio the issue is the same. Now, I think the issue is not related to SimpliciTI or our software.

    I can't explain this result. No idea. The XTAL is 26MHz 10ppm 18pF. I thought 18pF is required towards the GND on its both sides. XTAL is applied with short paths.

    Do you have any idea / hint / explanation of the phenomenon?

    Thank you for any help in advance,

    best regards,

    Gyula

  • Gyula,

    unfortunately I am not really the correct person to ask. TER should be able to help you more in this case, and I will let him know to give response on your questions.

  • Hi TER, 

    | think you are perfectly right, unfortunately I didn't take enough care on this fact.

    Thank you for pointing it out,

    br,

    Gy.