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.

RX_TIME usage in non WOR application

Other Parts Discussed in Thread: CC1101

Hi,

I'm trying to understand the RX termination feature by using MCSM2.RX_TIME_QUAL parameter in a non WOR environment. If RX_TIME_QUAL =0 the RX should stop if, after a given timeout after RX starts, there is no sync word found in the bits trail. To prove that, I imagined the following scenario:

Let's suppose that the TX speed is 9.6 kbps. If the sync word has 4 bytes the radio must spend at least 3.33 ms in RX in order to fully read it. As a direct consequence if the RX termination timer stops the RX before 3.33ms limit the packet cannot be read. To prove that I started with the following parameters:

TX speed: 9.6 kbps

EVENT0_HIGH 128
EVENT0_LOW 0
EVENT0 32768 =>

| tEvent0 = 1000ms

| WOR_RES = 0
| RX_TIME = 6
=> RX_TIMEOUT .20% * tEvent0 = 2ms


The value is way below the minimum read time for the sync word (3.33ms). I prepared two SmartRF sessions with the parameters above and I ran some packet transfers from device A to device B. All of them where successful and I don't understand why.

Please help,

Thanks

  • Hi

    Have you remembered to turn on the RC oscillator? This must be on even if you do not use WOR as it is the RCOSC that drives the timer used for the RX timeout. The RCOSC is enabled by setting WORCTRL.RC_PD = 0.

    Siri

  • Hi, yes I did.

    Can you please confirm that the logic in my first post is correct? Specifically, in order to be able to receive the sync word at a given speed, RX_TIME should be long enough?

    I tested again with a slightly different setup with no success. Here are the steps to reproduce the issue:

    Setup: Two sessions of SmartRFStudio each one controlling one device, device A and device B. The devices are EM430F6137RF900 boards.

    Step 1: For both devices select in SmartRF-> control panel first available setup: 1.2kbps, Optimized for sensitivity. Test the connection by sending some packets -> OK

    Step 2: For the receiving device set:

    WOREVT1 = 0x80

    WOREVT0 = 0

    WORCTRL.ACLK_PD = 0

    WORCTRL.WOR_RES = 0 (12.5%) from tEvent0

    MCSM2.RX_TIME = 0

    MCSM2.RX_TIME_QUAL = 0

    MCSM2.RX_TIME_RSSI = 0

    With the default settings from SmartRF Studio and first option selected in device control panel we have

    Bitrate: 1.2kbps

    Sync word size: 4 bytes

    So, in order to receive 4 bytes at 1 kpbs we need to spend in RX at least 26.67 ms. The settings mentioned at step 2 ensure an RX_TIMEOUT of 125ms, long enough to receive the sync words.

    The tests showed that no packet has been received which is (for me) inexplicable.

  • I'm stuck trying to make RX_TIME working. Basically I changed a simple TI example (CC430x613x RF examples\RF_Examples_CCS\Fixed_GT_FIFO) project like this:

    In RF1A.c I added some lines to WriteRfSettings function:

    WriteSingleReg(WORCTRL, 0x78);

    WriteSingleReg(WOREVT0, 0x00);
    WriteSingleReg(WOREVT1, 0x80);
    WriteSingleReg(MCSM2, 0x00);
    WriteSingleReg(PKTCTRL1, 0x00);

    WriteSingleReg(IOCFG1, 0x1F);

    The example starts by default in RX mode so if there is no TX the timer should fire shortly (tEvent0 is 1s, timeout is 12.5 % -> 125ms). I activated the interrupt on GDO1 to monitor it in CC1101_ISR but apparently it never happen.

    Thanks and regards

  • Hi

    I am not a CC430 expert so I do not know why you do not get the interrupts you want when running the CC430 code, but I do know why you are not receiving anything with SmartRF Studio when using an RX timeout. With the settings you are using the RX timeout is 125 ms and you are correct that it takes about 27 ms to transmit a sync word. However, as long as you are not able to start the transmitter so that first sync word is sent within the 125 ms RX time, you will not receive anything. The radio exits RX mode after 125 ms but the SmartRF Studio firmware waits for a packet received interrupt before it strobes RX again. Since this interrupt will not happen unless a sync word is found during the first 125 ms in RX, the radio will never enter RX again and will continue in IDLE mode.

    BR

    Siri