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: For the lowest power (sensor and collector), is it best to use Beacon or Non-Beacon mode with the 15.4 stack?

Part Number: CC1310

I would like to have multiple sensors (5-10) join a PAN set up by the collector, and send data at a regular interval of every 15 minutes. My aim is to have both collector and sensor battery powered, so lowest power is very important. I hope to implement some sort of time-synchronized wake-ups to achieve the lowest power (if it's not already implemented by the stack).

The collector will also be operating a LoRa Module, so should have some space left for the LoRaWAN node libraries from Semtech.

I notice there is the option of using beacon or non-beacon mode with the 15.4 stack, but I am having difficulty assessing which mode will meet my requirements best. Frequency hopping is out since it's an 868 MHz project.

Could a TI employee weigh in on which route would be best to take and detail how best to approach this?

  • Hey Craig,

    Frequency hopping IS an option in the 868Mhz band with TI 15.4-Stack v2.0.1. However the collector does not go to sleep and leaves its RX on during idle so it will not save power on the collector side. The best option to save power both on the collector and sensor will be to use beacon mode with a high beacon order (the time between each beacon) and low superframe order ( the time the devices can communicate between each beacon, uses power). You might need to experiment a little with these numbers to get the right mix of performance and power savings. Non beacon mode has the collector always on so it will not be a good option for you.

    ~Brocklobsta

  • Hi Brocklobsta, thanks for your reply.

    I must have got confused about the frequency hopping thing, but it sounds like a bad idea for my application anyway!

    I did a bit more reading up on beacon mode, and it does sound like the closest thing to what I need with the 15.4 stack. If I understand correctly the beacons are sent at regular intervals (beacon order) and last a set time (superframe order) to allow constant synchronisation of time between sensor and collector? And if the sensor has data to send/request it can do so in response to these beacons?

    That's about as far as the developers guide seems to take the explanation. What it doesn't say though is what the beacon/superframe order values correspond to in terms of actual timing. Do you have any details on this so that I can calculate the average current consumption?

    Overall it sounds like it certainly will be lower power than the 15.4 stack alternatives, but maybe not as low power as implementing some sort of NTP based synchronisation with EasyLink?

  • Hey,

    Beacon Interval can Superframe duration can be calculated with the following formula

    BI = (960*2^(BO))/50000

    SuperFrame duration is calculated:

    SD = (960*2^(SO))/50000.

    Super Frame base duration = 960

    SO = Super frame order

    BO = Beacon order

    symbol rate = 50kbps.

    ~Brocklobsta

  • Thanks.

    And if I understand correctly this means at 50kbps Beacon interval ranges from 19.2ms to 314.5 seconds (BO 0 to 14), and these values also apply to the superframe duration?

    Also, is this information available in any official documentation? If so I'd be interested to see the document they came from if it has useful details like this.
  • Hello Brocklobsta,

    Just to let you know that in the "TI 15.4-Stack 2.0.1 Embedded Developers Guide.pdf" as found in the /docs directory of the Simplelink SDK v1.00.00.13, section 4.3.1 "Frequency-Hopping Mode" still states that "The TI 15.4-Stack supports an unslotted channel-hopping feature only in the 902-MHz to 928-MHz frequency band based on the directed frame exchange (DFE) mode of the Wi-SUN FAN specification v1.0 (see Chapter 15).".

    Are you saying that by, in config.h, changing the CONFIG_FH_ENABLE define to true and CONFIG_PHY_ID to APIMAC_STD_ETSI_863_PHY_3 that we can get FH in 863?

    If so then this is good to know as it looks too easy to bust ERC-70-03's duty cycle requirements in non-FH beacon mode at certain frequencies.

    Cheers,

    Steve
  • Thanks Steve,

    Thanks for bringing this to our attention. We will update the documentation in the next release!

    ~Brocklobsta

  • Brocklobsta, could you address my question about your last post in the thread please?

    Cheers,
    Craig
  • This information is explained in the IEEE 802.15.4 specification. I will take note that this information should be available and will update the documentation in the future.

    I recommend reading up on the specification to get a better understanding of what TI 15.4-Stack is doing.

    ~Brocklobsta