cc1310 monitoring some frequencies

Vladimir,

The switching time of the CC1310 is limited by the overhead of the communication interface between the Radio core and the main MCU core. This will limit the switching speed to about 750us.

Here is a plot of how much current the sniff mode function consumes. This case here we configured it for 30kbps data rate and 1 sniff per second. The blue curve below is the current consumption versus time (time is measured in milliseconds) and the green curve is the integrated energy consumption in uA*S.

So in this case the end device will consume 10.5uA sniffing for a packet every 1 second.

I suggest if that you two frequencies that you want to monitor, why not just have two CC1310 inside the concentrator. 

/TA

Hi Vladimir,

did the customer also consider to implement a synchronous protocol where the concentrator sends a periodic beacon message, nodes synchronize their local clocks to the concentrator and everything operates on a single channel?

The problem that I see with the described approach is, that every node will either have to repeat its message multiple times in order to guarantee that the concentrator sees the message or they will have to send a rather long preamble.

In order to have a very quick channel transition and avoid the command handling overhead on the main core, the customer could create a command chain of CMD_FS and CMD_CS. Have a look at the rfListenBeforeTalk example that exercises command chaining. I did a quick test and created an endless loop of a single CMD_FS that executes completely autonomously on the RF core. In the callback, I toggle a pin.

void rfCallbackFunction(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
{
    // We get this callback each time CMD_FS finishes.
    if (e & RF_EventCmdDone)
    {
        // Circumvent the validity checks of the PIN driver and use the
        // platform implementation directly.
        PINCC26XX_setOutputValue(Board_LED3,!PINCC26XX_getOutputValue(Board_LED3));
    }
}

    // Set the synth to RX mode
    RF_cmdFs.synthConf.bTxMode = 0;

    // Chain CMD_FS to itself.
    RF_cmdFs.pNextOp = (RF_Op*)&RF_cmdFs;

    // Always run the next command.
    RF_cmdFs.condition.rule = COND_ALWAYS;

    /* Set the frequency */
    RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, &rfCallbackFunction, RF_EventCmdDone);

    // We should never reach this point. Only when running on a CC1350, there is
    // the possibility that CMD_FS might fail in rare cases (see SWRA521) and must
    // be repeated.
    // if (((volatile RF_Op*)&RF_cmdFs)->status == ERROR_SYNTH_PROG) ...
   for (;;);

I got a channel switching time of 300-400us. Taking the average period should rule out any errors due to delays on the main core. I also repeated the test with altering frequencies and the timing didn't change.

[Edit] I simplified the code a bit.