• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 2811 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1101: CC1101 not decoding OOK RX data

crisgyorgus
Prodigy 235 points
Part Number: CC1101
Other Parts Discussed in Thread: CC110L, , TEST2

Hi! After some time using the CC110L on our own built board, we decided to try some quite inexpensive and apparently well built chinese boards with the CC1101 chip, due to modularity.

The transceiver should receive OOK manchester modulated signals from different senders, starting in packet mode to identify the sender and then switching to asynchronous mode for raw data transfer.

I have following problems:

1. Using the same register settings like for CC110L, the chinese module with CC1101 will not receive the packet. The CS signal is asserted but the packet data is not decoded. Running in parallel, the CC110L will decode and receive the packet. Even register settings tuning was not helpful. The CC110L is for more than a year now in use without any problems.

2. When trying lower data rates, 4kbit/s instead of 16kbit/s, I can receive the packets after the chip "starts working" - this means I keep trying several times (10..30) to send the message until it is received the first time, and then it will continue receiving it without problems. Like the chip has finally found the working AGC settings and then it works.!!! But if it waits in RX more than 10..30 minutes, it starts again not to receive anything. A reset command is not changing anything.

3. At 16kbit/s data rate, not even the asynchronous mode is working. I cannot receive anything out of it that can be decoded, only the CS signal.

I did not put here my registers, as I have more than a few setups.

  • 0
    TI__Guru**** 317180 points
    - Are the boards using the same xtal frequency?
    - Program each board to send a CW and check the the boards are sending on the same frequency.
  • 0 in reply to TER
    Prodigy 235 points

    TER: yes the boards have the same crystal frequency, 26 MHz. I also tried adjusting FREQ0 register to compensate possible crystal frequency deviations, but no improvement was seen.

    Here is one set of registers we use for receiving packets on 16 kHz symbol rate:

    $0000: 0x2E,0x2E,0x2E,0x47,0x9D,0x35,0x0A,0x04,0x00,0x00,0x00,0x0C,0x00,0x10,0xB0,0x71
    $0010: 0xE9,0x42,0x3E,0x33,0x3B,0x47,0x07,0x3C,0x18,0x74,0x01,0x03,0x07,0x92,0x87,0x6B
    $0020: 0xF8,0x56,0x11,0xA9,0x0A,0x20,0x0D,0x41,0x00,0x59,0x7F,0x3F,0x81,0x35,0x0B,0x00

    (the GDOi configuration regs are overritten by the MCU when entering different active modes)

    I would try to transmit the CW with the boards but I cannot measure the emitted signal - lack of equipment.

  • 0 in reply to crisgyorgus
    TI__Guru**** 317180 points
    The format you have given the register settings is not very easy to read.

    Given that your old board are able to receive the signal and you don't receive anything with the module the register settings are not my first suspect. It sounds more like it's a difference in the BOM of the boards that causes this.

    - Do you have some more information about the module?
    - Do you read the same RSSI value from both boards with the same input signal (with a input signal lower than -20 dBm to avoid saturation)

    A low resolution way to read the CW is to adjust the frequency in small steps on a sniffer and read out the RSSI value to see if the RSSI max is on the same frequency for both DUTs.
  • 0 in reply to TER
    Prodigy 235 points

    I also did not suspect the registers, as they worked with CC110L, that's why I did not make a big post with names and values of the registers.

    So, I did measured the RSSI level of a CW (same frequency as the signal I want to receive), and to get maximum level I had to modify FREQ0 from 0x71 to 0x72 on the chinese board. So, that's a less than 400 Hz carrier deviation.

    I also tried different values for the factors of data rate compensation, Ki & Kp before and after sync-word, maximum data rate offset saturation, but no results.

    I do not have more info on the board, it's done with discrete L-C, standard schematics, but I have no values for the LC parts. It should be ok, because I receive the same RSSI level for the CW like our own board with the CC110L (2..3 dBm differences).

    So, maybe it's still something different with CC1101 than CC110L. When I configure the radio, I write all 48 registers in one burst write. Are there any other reserved bits that may not be set correctly?

  • 0 in reply to crisgyorgus
    TI__Guru**** 317180 points
    I have no idea why this should be different between the two boards but I have seen before that writing to all registers could cause some issues. Try to write only to the registers that should be set to something different than the reset value, that is a much shorter list than 48 registers.
  • 0 in reply to TER
    Prodigy 235 points

    So, now I've tried to issue a software reset, then manually write every register that is different from the reset value to the wanted value, than enter RX. The same problem, no difference, the radio still cannot receive the packets. I also tried a second module, thinking something might be wrong with it, but the same.

    I also tried to receive tha packet without Manchester enabled, setting the sync-word to the manchester bits sequence and doubling the packet lenght, with _/ & \_ manchester coding, but still nothing.

    Could someone please check my registers, I think it may still be something that needs to be different on the CC1101 than CC110L:

        0x2E; 0000:IOCFG2, GDO2 Output Pin Configuration
        0x2E; 0001:IOCFG1, GDO1 Output Pin Configuration
        0x2E; 0002:IOCFG0, GDO0 Output Pin Configuration
        0x47; 0003:FIFOTHR, RX FIFO and TX FIFO Thresholds
        0x9D; 0004:SYNC1, Sync Word, High Byte
        0x35; 0005:SYNC0, Sync Word, Low Byte
        0x0A; 0006:PKTLEN, Packet Length
        0x04; 0007:PKTCTRL1, Packet Automation Control
        0x00; 0008:PKTCTRL0, Packet Automation Control
        0x00; 0009:ADDR, Device Address
        0x00; 000A:CHANNR, Channel Number
        0x0C; 000B:FSCTRL1, Frequency Synthesizer Control
        0x00; 000C:FSCTRL0, Frequency Synthesizer Control
        0x10; 000D:FREQ2, Frequency Control Word, High Byte
        0xB0; 000E:FREQ1, Frequency Control Word, Middle Byte
        0x71; 000F:FREQ0, Frequency Control Word, Low Byte
        0xE9; 0010:MDMCFG4, Modem Configuration
        0x42; 0011:MDMCFG3, Modem Configuration
        0x3E; 0012:MDMCFG2, Modem Configuration
        0x33; 0013:MDMCFG1, Modem Configuration
        0x3B; 0014:MDMCFG0, Modem Configuration
        0x47; 0015:DEVIATN, Modem Deviation Setting
        0x07; 0016:MCSM2, Main Radio Control State Machine Configuration
        0x3C; 0017:MCSM1, Main Radio Control State Machine Configuration
        0x18; 0018:MCSM0, Main Radio Control State Machine Configuration
        0x74; 0019:FOCCFG, Frequency Offset Compensation Configuration
        0x01; 001A:BSCFG, Bit Synchronization Configuration
        0x03; 001B:AGCCTRL2, AGC Control
        0x07; 001C:AGCCTRL1, AGC Control
        0x92; 001D:AGCCTRL0, AGC Control
        0x87; 001E:WOREVT1, High Byte Event0 Timeout
        0x6B; 001F:WOREVT0, Low Byte Event0 Timeout
        0xF8; 0020:WORCTRL, Wake On Radio Control
        0x56; 0021:FREND1, Front End RX Configuration
        0x11; 0022:FREND0, Front End TX Configuration
        0xA9; 0023:FSCAL3, Frequency Synthesizer Calibration
        0x0A; 0024:FSCAL2, Frequency Synthesizer Calibration
        0x20; 0025:FSCAL1, Frequency Synthesizer Calibration
        0x0D; 0026:FSCAL0, Frequency Synthesizer Calibration
        0x41; 0027:RCCTRL1, RC Oscillator Configuration
        0x00; 0028:RCCTRL0, RC Oscillator Configuration
        0x59; 0029:FSTEST, Frequency Synthesizer Calibration Control
        0x7F; 002A:PTEST, Production Test
        0x3F; 002B:AGCTEST, AGC Test
        0x81; 002C:TEST2, Various Test Settings
        0x35; 002D:TEST1, Various Test Settings
        0x0B; 002E:TEST0, Various Test Settings
        0x00; Not used

  • 0 in reply to crisgyorgus
    TI__Mastermind 39860 points

    I would have looked more closely at register AGCCTRL2. MAGN_TARGET which sets the signal power level into the demodulator. If this is set too low the demodulator will have too small SNR to demodulate correctly. AGCCTRL2[2:0].MAGN_TARGET is set to 3 in your settings. Try with higher values. See also www.ti.com/.../swra215e.pdf. Figure 1 shows what happens if the settings are not optimum. The carrier sense threshold changes with MAGN_TARGET so suggest you set AGCCTRL1 =0x0 initially when checking if adjusting MAGN_TARGET improves the reception.

    Also, what does the RSSI look like vs input power level. Does it increase linearly from -105 dbm (say) up to the saturation level? Reason for asking is that if there is a 20 dB shift down in the RSSI reading at -60 dBm (depends on the settings actually) then there is an ESD issue.

  • 0 in reply to Sverre
    Prodigy 235 points

    Sverre: I tried now all combinations of MAGN_TARGET settings, from 0..7, with CARRIER_SENSE_ABS_THR[3:0] set to 0 like you suggested, than also with values above MAGN_TARGET, but with no success.

    What exactly do you mean ESD issue? An event that might have partially destroyed the chip or something currently influencing the reception? I did not get to test the RSSI vs. input power level yet, but I will do that and come back with results.

  • 0 in reply to Sverre
    Prodigy 235 points
    Sverre: I did try now, like you suggested, with higher MAGN_TARGET values, actually all combinations of MAGN_TARGET and CARRIER_SENSE_ABS_THR, but with no success.
    What exactly do you mean with ESD issue? An event that might have partially destroyed the chip or something currently affecting the reception?
    I did not get to read RSSI vs. input power level, but I will do that and come back with the results.
  • 0 in reply to crisgyorgus
    TI__Mastermind 39860 points
    The "ESD issue" is a long shot, but if there is one it will affect the reception. What could happen is that input LNA gets a ESD hit and there will then by a region of input power levels where the radio goes "deaf". RSSI vs input power level will show if this is the case here.
  • 0 in reply to Sverre
    TI__Guru**** 317180 points
    Is this case resolved?
  • 0 in reply to TER
    Prodigy 235 points

    No, it is not.

    We do not understand what is happening, and we do not have the necessary equipment to properly investigate.

    While trying to measure the RSSI level for a CW, we discovered that also sending OOK data with the CC1101 boards is not working well, even at low data rates, see following sample of an asynchronously received file:

    Fullscreen log_async_rx_18-08-06_dt.txt Download 
    Data rate:		4,389 kb/s -> T=228µs, t=T/8=28,5µs -->> 200µs/256µs
Modulation format:	OOK
Radio inferface:	Asynchronous serial

18:08:10,682425 -> CS start _/ 0001;
31\343/113\316/143\371/86\318/143\371/85\320/144\343/142\286/143\376/117\288/143\377/87\320/145\349/146\261/173\347/114\317/143\343/142\288/143\342/317\57/200\370/202\116/228\377/175\116/262\344/604\343/576\315/602\319/610\316/608\319/579\351/175\288/85\408/58\377/87\378/86\373/87\372/86\344/115\401/57\374/86\372/114\346/87\372/114\343/86\399/85\344/114\370/114\318/115\377/116\290/145\371/115\315/115\377/117\291/145\345/144\291/174\318/115\318/144\344/143\287/144\343/172\29/144\116/175\232/172\343/173\232/146\145/116\88/146\344/115\318/143\115/114\85/142\115/142\57/141\369/115\290/144\378/146\29/146\145/117\292/144\115/351\344/346\116/343\114/369\86/569\343/602\86/381\316/369\117/117\89/118\146/117\
08:11:26,611075 -> CS stop  \_ 0001;
18:08:11,547581 -> CS start _/ 0004;
61\354/118\326/118\381/88\322/148\349/117\319/117\376/87\317/146\359/119\329/89\390/88\330/151\362/119\298/147\353/121\298/119\385/120\272/181\329/148\120/60\60/180\360/270\30/270\365/149\185/216\365/572\327/181\91/296\364/600\296/589\332/601\337/579\364/243\154/183\327/121\299/149\357/119\301/151\358/118\298/148\353/119\322/119\363/119\320/87\408/89\319/118\377/117\330/121\361/119\298/120\384/121\298/148\352/119\300/150\354/119\299/150\361/149\119/296\351/118\291/148\347/147\29/406\344/145\29/170\113/601\326/562\119/331\389/89\329/119\149/88\119/118\148/89\120/90\384/90\356/118\322/148\90/120\151/91\335/120\149/90\90/121\360/120\91/120\122/152\61/152\91/153\61/152\91/121\333/120\359/121\329/89\179/
08:11:26,611075 -> CS stop  \_ 0004;
18:08:12,246015 -> CS start _/ 0007;
368/120\304/119\382/118\293/148\380/88\320/117\382/119\295/146\351/116\322/117\379/90\325/117\377/148\265/146\352/147\295/117\380/116\294/146\350/146\263/174\347/145\262/174\347/145\174/232\345/605\316/574\371/573\343/576\320/605\312/599\341/201\257/113\342/114\342/113\375/87\345/115\370/114\319/115\371/114\343/114\376/87\317/143\346/117\318/115\372/115\316/144\371/85\310/142\367/115\315/141\338/140\281/142\367/139\281/141\368/114\310/112\398/85\308/142\373/114\318/113\375/144\28/145\146/116\292/144\375/144\234/173\116/145\58/146\350/586\116/319\116/374\319/603\318/343\114/171\286/114\144/115\86/115\377/87\117/115\144/86\115/116\144/116\87/116\144/117\319/116\349/146\317/115\115/114\113/115\373/117\
08:11:26,611075 -> CS stop  \_ 0007;
18:08:13,167335 -> CS start _/ 0010;
31\28/144\379/87\350/116\380/87\324/116\372/116\313/141\368/115\281/143\366/114\337/114\365/114\307/142\334/168\197/224\336/140\254/196\336/110\333/111\387/83\332/139\363/113\307/140\365/111\304/141\358/112\302/140\359/112\312/141\367/113\279/167\361/141\28/85\140/166\359/568\343/286\56/225\362/571\338/570\340/170\283/114\398/85\315/142\373/85\337/114\369/113\334/113\361/112\334/112\359/112\333/140\337/139\309/113\368/114\312/142\366/113\311/113\364/110\333/111\390/85\336/112\364/140\276/141\360/140\302/140\358/112\82/137\110/166\28/27\196/167\333/168\252/167\112/329\356/582\111/362\113/335\338/585\331/192\28/137\137/110\303/140\138/83\112/113\362/139\56/141\139/84\137/110\110/137\81/137\110/137\304/
08:11:26,611075 -> CS stop  \_ 0010;


18:08:16,543745 -> CS start _/ 0016;
117/288\174/260\202/260\202/259\202/259\201/259\202/259\201/259\201/259\202/258\202/260\201/260\201/260\201/259\201/259\202/259\201/260\201/259\201/260\201/259\202/259\202/260\201/259\202/259\201/259\202/259\201/260\202/259\202/259\201/259\201/260\202/260\202/259\201/259\201/259\201/259\201/259\201/260\201/259\202/259\202/259\202/259\201/259\202/260\202/260\201/260\202/260\202/259\201/259\201/259\201/259\202/259\202/259\201/260\202/260\202/259\202/259\200/259\201/259\201/259\201/259\202/259\202/259\202/260\202/260\202/259\202/259\202/259\201/258\202/259\201/259\202/260\201/260\201/259\202/259\202/260\202/260\201/259\202/259\202/260\201/259\202/259\201/259\201/259\202/259\202/260\202/258\433/489\202/
08:11:26,611075 -> CS stop  \_ 0016;
18:08:17,415606 -> CS start _/ 0019;
147/267\209/238\211/270\212/242\212/243\212/242\210/270\209/237\206/265\204/234\232/232\231/230\229/229\228/228\228/256\199/256\227/227\227/227\227/256\200/257\200/257\200/258\200/259\230/230\230/231\201/259\230/231\202/261\231/231\202/261\231/230\203/260\202/260\202/260\201/260\202/259\203/259\201/260\201/259\203/258\202/259\202/258\202/259\202/259\202/259\201/259\202/260\202/259\201/260\201/259\202/258\201/259\202/259\202/258\202/260\202/260\202/259\201/260\202/259\202/259\203/260\202/259\202/259\202/259\202/259\202/259\202/259\202/259\201/259\202/259\202/258\202/258\202/258\201/259\202/260\201/260\202/260\202/259\201/259\201/259\202/258\201/259\201/259\202/259\202/259\202/260\202/260\433/490\202/
08:11:26,611075 -> CS stop  \_ 0019;
18:08:18,251754 -> CS start _/ 0022;
115/251\223/252\196/251\223/252\197/253\227/226\227/227\229/229\229/230\230/230\230/260\203/231\232/232\233/232\232/232\233/231\232/232\203/260\202/260\202/260\202/260\202/259\201/260\201/258\202/258\201/259\202/259\202/259\202/259\202/259\202/259\201/259\201/259\202/258\202/259\202/259\201/260\201/259\201/259\201/258\202/259\202/259\202/259\202/259\202/260\201/259\201/260\201/260\201/259\202/259\202/259\201/259\202/259\201/258\202/258\201/259\202/258\201/259\202/259\203/260\202/259\202/259\202/259\201/259\202/259\202/259\201/260\201/260\201/260\201/259\202/259\201/259\202/259\202/259\201/259\202/260\201/259\202/259\202/259\202/259\202/260\201/259\201/259\201/259\201/259\202/259\201/260\433/489\203/
08:11:26,611075 -> CS stop  \_ 0022;

    In the above file, the first 4 data lines ( format: /t_on\t_off/, [µs] ) were sent with the CC1101 module, and the last 3 data lines with the original modules that we interface. In the file is only the preamble, so all periods should normally be 228µs (200..256µs with the 1/8 chip detection resolution), as is the case in the last 3 data lines, but in the first 4 lines - the ones transmitted with the CC1101, the periods are off limits and the signal cannot be decoded.

    I tried with other 2 modules, to eliminate the chance of a faulty one, but all 3 work the same.

    I tried some FSK settings, and they all worked good, as expected.

  • 0 in reply to crisgyorgus
    TI__Guru**** 317180 points
    What I don't understand in this case is that with the same settings your CC110L and the CC1101 should give the exact same result. If they don't give the same performance some hardware difference should exist even though I find it strange that both modules seems to give the correct result for FSK.
  • 0 in reply to TER
    Prodigy 235 points

    So, I finally had some time to further investigate this, with different settings and signals, and my conclusion is that the balun and matching circuit influence the OOK received signal. I analyzed the asynchronous received signal for a continuous 010101 signal of different data rates sent asynchronously. The received signal for the 2 boards (CC1101 & CC110L) was compared and the result shows that for the CC1101 board the 0 level is too short at higher data rates:

    CC110L board: / ̅ ̅ ̅ ̅\____/ ̅ ̅ ̅ ̅\____/ ̅ ̅ ̅ ̅\____/

    CC1101 board: / ̅ ̅ ̅ ̅ ̅ ̅\__/ ̅ ̅ ̅ ̅ ̅ ̅\__/ ̅ ̅ ̅ ̅ ̅ ̅\__/

    For the CC110L, eliminating the (1/8)·T detection resolution, the received signal is 50% in duty cycle - so, perfect; and for the CC1101 board is >> 75% at data rates higher than 6kHz, and with data rates higher than 10kHz is almost randomly detected. The best detection was obtained for AGCCTRL0/FILTER_LENGTH=01 (8dB), and all 4 settings were tried.

    For the CC110L board we used the Johanson T. balun, and the CC1101 boards are built with discrete components. I do not have the necessary equipment to investigate the balun and matching circuit, nor do I have the exact BOM for the board. I will change all components for the balun filter from 1 board with the datasheet values and test it afterwards.

  • 0 in reply to crisgyorgus
    TI__Guru**** 317180 points
    For this experiment, are you running the same software on the CC1101 and CC110L boards and the same TX source is received by both boards?