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: CC1310 15.4 stack none-beacon mode, is it possible the collector to broadcast message to some certain sensors?

Part Number: CC1310

Hi Team,

My customer is using CC1310 15.4 none-beacon mode for their current products. Now they want to add some new nodes which have mains power supply(always on, not battery). For those nodes, they want to receive some certain messages from collector at the same time (expect to have no time delay between nodes). So enable broadcast in the network would be a good idea, the question is, is it possible to enable broadcast on collector in a none-beacon mode network and let the nodes get same message at the same time while they set the CONFIG_RX_ON_IDLE to be true?

Thanks!

  • Hey Yan,

    Yes, this is possible. I would start by using the generateBroadcastCmd() api in collector.c to send the broadcast from the collector.

    You'll have to remove the following lines from sendBroadcastMsg():

    /* Only supported for FH mode */
        if(!fhEnabled)
        {
             return;
        }

    The reason broadcast messages are only supported in FH mode is because we cannot guarantee the reception of a broadcast message to a sensor as there is no ack for broadcast messages. In FH mode, there is a specific time slot where sensors are ready to receive the broadcast message. If the nodes are non-sleepy (i.e. RX_ON_IDLE set to true), the sensors should be able to receive the broadcast. That is, if the sensor is not sending a TX cmd when the collector sends the broadcast; otherwise the sensor may miss the broadcast message.

    There's a related post that can provide additional insight here: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/584425. In short,

    "The problem is that since it is a broadcast frame you don't ack. This means that if a device is asleep during the message, the collector has no confirmation that the message was not received. non-sleepy devices will receive broadcast frames successfully. Another solution is to iterate through a list of sleepy devices and send a unicast message to each."