CC1352 OpenThread Sub-1GHz 868MHz

[MichalPoterek]

I would like to experiment with the OpentThread network in the Sub-1GHz band to explore what kind of coverage and performance I can get.

I'm using Texas Instrument CCS with TI OpenThread SDK.

I found out that going to the 868MHz band will be not as easy as configuring the appropriate frequency in the configurator. I was looking in google is there are any pieces of information about similar ideas realized for TI chipsets. Unfortunately, I haven't any good explanation for TI.

Based on a comment to code below let me know if I'm going in the right way and if these are all places that I need to modify. I will be appreciated any help with that :)

`###################################
####### openthread-core-default-config.h
###################################

#ifndef OPENTHREAD_CONFIG_RADIO_915MHZ_OQPSK_SUPPORT
#ifndef OPENTHREAD_CONFIG_RADIO_2P4GHZ_OQPSK_SUPPORT
#define OPENTHREAD_CONFIG_RADIO_915MHZ_OQPSK_SUPPORT 1 //this I think need to be changed to 1
#define OPENTHREAD_CONFIG_RADIO_2P4GHZ_OQPSK_SUPPORT 0 //this I think need to be changed to 0
#endif
#endif

#ifndef OPENTHREAD_CONFIG_DEFAULT_CHANNEL
#if OPENTHREAD_CONFIG_RADIO_2P4GHZ_OQPSK_SUPPORT
#define OPENTHREAD_CONFIG_DEFAULT_CHANNEL 11
#else
#if OPENTHREAD_CONFIG_RADIO_915MHZ_OQPSK_SUPPORT
#define OPENTHREAD_CONFIG_DEFAULT_CHANNEL 1
#endif // OPENTHREAD_CONFIG_RADIO_915MHZ_OQPSK_SUPPORT
#endif // OPENTHREAD_CONFIG_RADIO_2P4GHZ_OQPSK_SUPPORT
#endif // OPENTHREAD_CONFIG_DEFAULT_CHANNEL

####################################
######### radio.c
####################################

/**

• Function documented in platform/radio.h
  */
  otError otPlatRadioEnable(otInstance *aInstance)
  {
  otError error = OT_ERROR_BUSY;
  RF_Params rfParams;
  (void)aInstance;

  if (sState == platformRadio_phyState_Sleep)
  {
  error = OT_ERROR_NONE;
  }
  else if (sState == platformRadio_phyState_Disabled)
  {
  RF_Params_init(&rfParams);

   rfParams.pErrCb         = rfCoreErrorCallback;
   rfParams.nID            = RF_STACK_ID_THREAD;    //here I think it should be changed to RF_STACK_ID_154  or RF_STACK_ID_CUSTOM 
   sRfHandle = RF_open(&sRfObject, &RF_prop,
           (RF_RadioSetup *)&sRadioSetupCmd, &rfParams);
  
   otEXPECT_ACTION(sRfHandle != NULL, error = OT_ERROR_FAILED);
   sState = platformRadio_phyState_Sleep;
  
   error = OT_ERROR_NONE;
  

  }

exit:
if (error == OT_ERROR_FAILED)
{
sState = platformRadio_phyState_Disabled;
}

return error;

}

/**

• @brief initialize the RX command structure

• Sets the default values for the receive command structure.
  */
  static void rfCoreInitReceiveParams(void)
  {
  sReceiveCmd = RF_cmdIeeeRx;

  sReceiveCmd.pRxQ = &sRxDataQueue;
  sReceiveCmd.pOutput = (rfc_ieeeRxOutput_t *) &sRfStats;
  sReceiveCmd.numShortEntries = PLATFORM_RADIO_SHORTADD_SRC_MATCH_NUM;
  sReceiveCmd.pShortEntryList = (void *) &sSrcMatchShortData;
  sReceiveCmd.numExtEntries = PLATFORM_RADIO_EXTADD_SRC_MATCH_NUM;
  sReceiveCmd.pExtEntryList = (uint32_t *) &sSrcMatchExtData;
  sReceiveCmd.channel = OT_RADIO_2P4GHZ_OQPSK_CHANNEL_MIN; //here I think I should change to OT_RADIO_915MHZ_OQPSK_CHANNEL_MIN

######################################
############ RFC26X2.h
######################################

/**

• @name Stack ID defines
• @anchor RF_Stack_ID
• Reserved values to identify which stack owns an RF_Handle h (stored as h->clientConfig.nID)
• @{
  */
  #define RF_STACK_ID_DEFAULT 0x00000000 ///< No value is set.
  #define RF_STACK_ID_154 0x8000F154 ///< ID for TI 15.4 Stack //this is what I consider but I'm not sure if better would be RF_STACK_ID_CUSTOM
  #define RF_STACK_ID_BLE 0x8000FB1E ///< ID for TI BLE Stack
  #define RF_STACK_ID_EASYLINK 0x8000FEA2 ///< ID for TI EasyLink Stack
  #define RF_STACK_ID_THREAD 0x8000FEAD ///< ID for TI Thread Stack
  #define RF_STACK_ID_TOF 0x8000F00F ///< ID for TI TOF Stack
  #define RF_STACK_ID_CUSTOM 0x0000FC00 ///< ID for Custom Stack //this is what I consider but I'm not sure if better would be RF_STACK_ID_154

###################################

ti_radio_config.c

###################################
//My idea is to use TI Smart RF Studio to generate configuration files for option: IEEE 802.15.4, 50 kbps, 25 kHz Deviation, 2-GSAK, 100kHz RX Bandwidth. Below is what is set in default

// CMD_RADIO_SETUP
// Radio Setup Command for Pre-Defined Schemes
const rfc_CMD_RADIO_SETUP_t RF_cmdRadioSetup =
{
.commandNo = 0x0802,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.mode = 0x01,
.loDivider = 0x00,
.config.frontEndMode = 0x0,
.config.biasMode = 0x1,
.config.analogCfgMode = 0x0,
.config.bNoFsPowerUp = 0x0,
.config.bSynthNarrowBand = 0x0,
.txPower = 0x7217,
.pRegOverride = pOverrides
};

// CMD_IEEE_TX
// IEEE 802.15.4 Transmit Command
const rfc_CMD_IEEE_TX_t RF_cmdIeeeTx =
{
.commandNo = 0x2C01,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.txOpt.bIncludePhyHdr = 0x0,
.txOpt.bIncludeCrc = 0x0,
.txOpt.payloadLenMsb = 0x0,
.payloadLen = 0x1E,
.pPayload = 0,
.timeStamp = 0x00000000
};

// CMD_IEEE_RX
// IEEE 802.15.4 Receive Command
const rfc_CMD_IEEE_RX_t RF_cmdIeeeRx =
{
.commandNo = 0x2801,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.channel = 0x00,
.rxConfig.bAutoFlushCrc = 0x0,
.rxConfig.bAutoFlushIgn = 0x0,
.rxConfig.bIncludePhyHdr = 0x0,
.rxConfig.bIncludeCrc = 0x0,
.rxConfig.bAppendRssi = 0x1,
.rxConfig.bAppendCorrCrc = 0x1,
.rxConfig.bAppendSrcInd = 0x0,
.rxConfig.bAppendTimestamp = 0x0,
.pRxQ = 0,
.pOutput = 0,
.frameFiltOpt.frameFiltEn = 0x0,
.frameFiltOpt.frameFiltStop = 0x0,
.frameFiltOpt.autoAckEn = 0x0,
.frameFiltOpt.slottedAckEn = 0x0,
.frameFiltOpt.autoPendEn = 0x0,
.frameFiltOpt.defaultPend = 0x0,
.frameFiltOpt.bPendDataReqOnly = 0x0,
.frameFiltOpt.bPanCoord = 0x0,
.frameFiltOpt.maxFrameVersion = 0x3,
.frameFiltOpt.fcfReservedMask = 0x0,
.frameFiltOpt.modifyFtFilter = 0x0,
.frameFiltOpt.bStrictLenFilter = 0x0,
.frameTypes.bAcceptFt0Beacon = 0x1,
.frameTypes.bAcceptFt1Data = 0x1,
.frameTypes.bAcceptFt2Ack = 0x1,
.frameTypes.bAcceptFt3MacCmd = 0x1,
.frameTypes.bAcceptFt4Reserved = 0x1,
.frameTypes.bAcceptFt5Reserved = 0x1,
.frameTypes.bAcceptFt6Reserved = 0x1,
.frameTypes.bAcceptFt7Reserved = 0x1,
.ccaOpt.ccaEnEnergy = 0x0,
.ccaOpt.ccaEnCorr = 0x0,
.ccaOpt.ccaEnSync = 0x0,
.ccaOpt.ccaCorrOp = 0x1,
.ccaOpt.ccaSyncOp = 0x1,
.ccaOpt.ccaCorrThr = 0x0,
.ccaRssiThr = 0x64,
.__dummy0 = 0x00,
.numExtEntries = 0x00,
.numShortEntries = 0x00,
.pExtEntryList = 0,
.pShortEntryList = 0,
.localExtAddr = 0x12345678,
.localShortAddr = 0xABBA,
.localPanID = 0x0000,
.__dummy1 = 0x000000,
.endTrigger.triggerType = 0x1,
.endTrigger.bEnaCmd = 0x0,
.endTrigger.triggerNo = 0x0,
.endTrigger.pastTrig = 0x0,
.endTime = 0x00000000
};

// CMD_TX_TEST
// Transmitter Test Command
const rfc_CMD_TX_TEST_t RF_cmdTxTest =
{
.commandNo = 0x0808,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x0,
.condition.nSkip = 0x0,
.config.bUseCw = 0x0,
.config.bFsOff = 0x0,
.config.whitenMode = 0x0,
.__dummy0 = 0x00,
.txWord = 0x0000,
.__dummy1 = 0x00,
.endTrigger.triggerType = 0x0,
.endTrigger.bEnaCmd = 0x0,
.endTrigger.triggerNo = 0x0,
.endTrigger.pastTrig = 0x0,
.syncWord = 0x00000000,
.endTime = 0x00000000
};

// CMD_IEEE_ED_SCAN
// IEEE 802.15.4 Energy Detect Scan Command
const rfc_CMD_IEEE_ED_SCAN_t RF_cmdIeeeEdScan =
{
.commandNo = 0x2802,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x0,
.condition.nSkip = 0x0,
.channel = 0x00,
.ccaOpt.ccaEnEnergy = 0x0,
.ccaOpt.ccaEnCorr = 0x0,
.ccaOpt.ccaEnSync = 0x0,
.ccaOpt.ccaCorrOp = 0x0,
.ccaOpt.ccaSyncOp = 0x0,
.ccaOpt.ccaCorrThr = 0x0,
.ccaRssiThr = 0x00,
.__dummy0 = 0x00,
.maxRssi = 0x00,
.endTrigger.triggerType = 0x0,
.endTrigger.bEnaCmd = 0x0,
.endTrigger.triggerNo = 0x0,
.endTrigger.pastTrig = 0x0,
.endTime = 0x00000000
};

// CMD_IEEE_CSMA
// IEEE 802.15.4 CSMA-CA Command
const rfc_CMD_IEEE_CSMA_t RF_cmdIeeeCsma =
{
.commandNo = 0x2C02,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x0,
.condition.nSkip = 0x0,
.randomState = 0x0000,
.macMaxBE = 0x00,
.macMaxCSMABackoffs = 0x00,
.csmaConfig.initCW = 0x0,
.csmaConfig.bSlotted = 0x0,
.csmaConfig.rxOffMode = 0x0,
.NB = 0x00,
.BE = 0x00,
.remainingPeriods = 0x00,
.lastRssi = 0x00,
.endTrigger.triggerType = 0x0,
.endTrigger.bEnaCmd = 0x0,
.endTrigger.triggerNo = 0x0,
.endTrigger.pastTrig = 0x0,
.lastTimeStamp = 0x00000000,
.endTime = 0x00000000
};

// CMD_IEEE_RX_ACK
// IEEE 802.15.4 Receive Acknowledgement Command
const rfc_CMD_IEEE_RX_ACK_t RF_cmdIeeeRxAck =
{
.commandNo = 0x2C03,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x0,
.condition.nSkip = 0x0,
.seqNo = 0x00,
.endTrigger.triggerType = 0x0,
.endTrigger.bEnaCmd = 0x0,
.endTrigger.triggerNo = 0x0,
.endTrigger.pastTrig = 0x0,
.endTime = 0x00000000
};
`

[jwhui]

The existing sub-GHz implementation is a prototype and not anything that is currently specified in Thread. The existing prototype implements IEEE 802.15.4 O-QPSK in the sub-GHz bands.

I'm not sure if the CC1352 supports IEEE 802.15.4 O-QPSK in sub-GHz bands. @srickardti , can you help provide some insight?

[srickardti]

Yes, setting the Sub-1GHz O-QPSK modulation is not supported on the CC1352. The device has not been characterized for 868MHz or 915MHz operation as defined by IEEE 802.15.4-2015 chapter 12. You can find the characterized PHYs in chapter 8 sections 10 to 23 of the CC1352R Datasheet. Unfortunately, adding a PHY is not just tuning the transmitter and receiver to a lower frequency.

Furthermore, to enable the other PHY options for the radio, the commands will need to be translated from the IEEE command set to the PROP command set. To achieve lower power operation the current implementation relies on the radio core for some of the low level MAC operations like CSMA-CA, frame filtering, and ack matching. These are not available with the other physical layers. So the OpenThread software MAC will need to take up the difference.

[MichalPoterek]

Thank you for your help and deep explanation. Looks like probably better to use another vendor chip which provides already SDK for this purpose. Do you have any experience with that? Which vendor might be best suited to use with thread?

[srickardti]

I believe this feature was used as a proof of concept for one vendor's silicon offering. Currently there is no standard, interoperable, way to run a Thread network in Sub-1GHz, however the Thread Group is currently working on this.

I would caution running this feature in a shipped product. Since this question calls out the 868MHz band, I assume this is operating in a region following ETSI regulations. Consider ERC 70-03 for the spectrum allocation and EN 300 220-1 for the definition of polite spectrum access. This feature in OpenThread seems to be running the 2.4GHz O-QPSK MAC at Sub-1GHz frequencies with minimal changes. This has the potential to easily run afoul of the ETSI regulations.

[jwhui]

Yes, as I mentioned in #7525 (comment), the current sub-GHz implementation is a proof-of-concept and not something that's included in the current Thread Specification.

[MichalPoterek]

@jwhui Connection all thread benefits with lower frequency bands giving additional interesting opportunities so that's why this topic is quite interesting ;)