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.

CC1310: Is there any information on the robustness to interference for the TI 15.4 stack running on the CC1310 ?

Part Number: CC1310


I am attempting to compare different sub-GHz technologies and as more and more sub-GHz systems are emerging, trying to pick a solution that will be as future-proof as possible is difficult. The ability of a sub-GHz system to operate in the presence of noise due to other systems is likely to be a big factor in the future as the bands fill up with LoRaWan and other long range signals. If anyone can provide help with assessing the TI 15.4 stack on the CC1310 hardware (or other hardware if likely to be better) in this respect please, that will be very much appreciated!

Roy

(I am not an RF expert but I am doing my best learn and to ask the right questions. Do say if you think I am missing something!)

  • Hi Roy,

    Depends on what you mean by "robustness to interference". Are you talking about how well a protocol can coexist in a noisy environment? Or, are you talking about how well a protocol can mitigate and avoid noisy environments? Or, maybe both?
  • Hello Severin,

    Thank you for your interest in my question. In short, I think "both" is the answer to your question. I am imagining the European band 863-870 MHz and US band 902-928MHz having more activity as time goes on. As I said, I am not an RF expert, but I am trying to assess how well the TI solution will work in noisy situations compared to other sub-GHz technologies such as LoRaWan and other proprietary offerings such as Digi XBee (www.digi.com/.../digi-xbee-sx-868). Digi claim: "Design includes SAW filter for optimal performance in noisy RF environments." As a non-RF expert, that leaves me wondering if this is superior to the TI technology, for example.

    Best regards,

    Roy
  • Note that since my reply to Severin above, I realise that a SAW filter is likely to be external to the fundamental radio IC, so is not a fair comparison if comparing radio ICs. This document has been very useful for basic RF understanding: www.ti.com/.../slap127.pdf . It seems that it's difficult to avoid diving into the detail of the RF specification and comparing such parameters as:

    Phase noise
    Co-channel rejection
    Receive selectivity
    Image rejection
    Receiver sensitivity
    Blocking / desensitisation
  • So there are multiple factors on how to mitigate as well as avoid noisy environments. This includes factors all the way from your RF design to the network protocol.

    If we specifically take a look at the TI 15.4-stack, then RF design cannot really be taken into consideration here, as it is a networking stack which can run on multiple devices and RF configurations. Hence comparing a device using SAW filter to the 15.4-stack specifically is unfair, because we could use a SAW filter in the RF design on the device running the 15.4-stack (with its pros and cons).

    The TI 15.4-stack is based on the IEEE 802.15.4 specification. IEEE 802.15.4 is specifically designed for unreliable wireless links, which takes extra care to mitigate noisy environments on a single link basis. This includes acknowledgments, re-transmissions, and CSMA/LBT MAC protocols to ensure transmissions are successful. There are also higher level MAC operating modes, such as beacon mode, non-beacon mode and time slotted channel hopping (TSCH), which both has it's pros and cons regarding both mitigation and avoiding noisy environments. At the most extreme, TSCH is probably the most "robust" mode as it constantly switches channels at a network level. This means an unsuccessful transmission on a given channel will re-transmit on a different, most likely less noisy channel.

    You can also implement higher level nework logic to have what is called frequency agility. This means if a network only operates on a single channel, then the network migrates to a different channel if the current one is discovered to be noisy. This, however, is not something that is supported out-of-the-box with 15.4-stack, but shouldn't be too difficult to implement.
  • Hello Severin,

    Thank you for your excellent and considered advice above which is very helpful. I really appreciate your time here.

    Best regards,

    Roy