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.

RTOS/CC1310: Improving radio performance

Part Number: CC1310

Tool/software: TI-RTOS

Speaking of the difference between 1.60 and 2.20 SDK, can somebody help translate the initializer values below? The first are ones recommended for use with SDK 1.60. As you can see, the second have changed field names but also the last three are quite different. Any recommendations would be appreciated. We're using EasyLink_Phy_Custom for one application and EasyLink_Phy_625bpsLrm for another, with the former having potentially high collision rates with many sensor nodes banging on a small number of concentrators.

const RFCC26XX_HWAttrsV2 RFCC26XX_hwAttrs = {
    .hwiCpe0Priority = INT_PRI_LEVEL7,//~0,
    .hwiHwPriority   = INT_PRI_LEVEL7,//~0,
    .swiCpe0Priority =  5,//0,
    .swiHwPriority   =  5,//0,        
}
const RFCC26XX_HWAttrsV2 RFCC26XX_hwAttrs = {
    .hwiPriority        = ~0,       /* Lowest HWI priority */
    .swiPriority        = 0,        /* Lowest SWI priority */
    .xoscHfAlwaysNeeded = true,     /* Keep XOSC dependency while in stanby */
    .globalCallback     = NULL,     /* No board specific callback */
    .globalEventMask    = 0         /* No events subscribed to */
};

Regards,

  • Hello,

    How many sensors are we talking about? Keep in mind that easylink is not a robust wireless protocol and its intended use is to give an easy way to test the radio with easy to use APIs and not have to us ethe radio directly. This is the possible reason for collisons, if you wish to have a more roust network that handles collisions and many other common problems with Wireless protocols check out our TI 15.4 stack.

    As far as the those definitions,
    The implementations on the RF Drivers changed a bit and so did the structures used for defining the hardware. It is now basically giving you the option to keep the HF oscillator active while the device is in standby(.xoscHfAlwaysNeeded), and also pointing to a callback(.globalCallback) when a specific event gets called(.globalEventMask)

    Regards,
    AB
  • Thanks very much. That's part of what I was looking for. I realize these parameters won't do much if anything for the lack of a robust protocol but was told the defaults can be problematic.

    Regards,
  • To be clear about the collisions, implementing a real ARQ protocol to deal with these is naturally on the list if sticking with EasyLink. Sorry for the distraction. My client is going to get a real protocol real soon now. But in the meantime is there any concensus within TI that the example program priorities are unwise and INT_PRI_LEVEL7 for both is going to help more often than hurt?

    Thanks,