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.

LAUNCHXL-CC1310: Sending broadcast messages using the TI 802.15.4 stack

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Hi,

I am developing a 802.15.4 network based on the CC1310 MCU and the collector/sensor examples from the resource explorer. I have modified the code so every time a node triggers an alarm, it sends an alarm message to the collector.

This is working fine, but now I want the collector to notify all the other nodes when it receives an alarm notification. Is there some kind of broadcast message that the collector can send to notify all the other nodes?

Can you share any example code about this?

Thanks,

Javi

  • If 15.4 sensor is under sleeping, it won’t be able to receive broadcast messages. It is recommended to use unicast for such case.
  • Thanks YiKai for the answer. Yes, I want the nodes to be sleeping as much as possible to prolong battery life. I am using the beacon mode. In that mode the sleeping nodes wake up just before each beacon to receive it, am I right?

    If that's the case, the collector, instead of sending a broadcast message, could send a beacon with all nodes' addresses in the pending address list, informing that there is a message pending for them, then each node will send a data request to the collector after receiving the beacon and the collector will answer to each one with the alarm notification data.

    Would that be a valid solution or is there an easier way?

    Javi
  • I haven't try/test broadcast in beacon mode. You have to try/test this by yourself.

  • Hello Javi,

    If you are using beacon mode, you can modify the beacon payload and use it to let all the nodes in the network know on the next beacon interval that the alarm got triggered.

    Regards,
    AB
  • Hi AB, that is a great idea, since beacons are received by all nodes. I have looked into the code to see where to define the beacon payload and this is what I have deduced. Please, have a look and correct me if I am wrong.

    COLLECTOR SIDE

    In hmac_global.c there is a macBeaconPayload buffer and I guess that I need to insert its address and length into the macPibDefaults struct. Please, see my comments in the code.

    Does this mean that, doing this, all beacons will be sent with the payload contained in macBeaconPayload? If so, I would just need to update the alarm status in macBeaconPayload to notify all the nodes

    uint8 macBeaconPayload[MAC_PIB_MAX_BEACON_PAYLOAD_LEN] = {0};  // seems to be what I am looking for
    
    /* PIB default values */
    const macPib_t macPibDefaults =
    {
      54,                                    /* ackWaitDuration */
      FALSE,                                 /* associationPermit */
      TRUE,                                  /* autoRequest */
      FALSE,                                 /* battLifeExt */
      6,                                     /* battLifeExtPeriods */
    
      &macBeaconPayload,                     /* *pMacBeaconPayload */ // <---- It is NULL by default, I guess I have to put here the address of the payload as shown?
      MAC_PIB_MAX_BEACON_PAYLOAD_LEN,        /* beaconPayloadLength */// <---- 0 by default, I guess I have to insert here the size of the beacon payload buffer
    
      /* more elements omitted for clarity */
    }
    
    
    /* PIB access and min/max table.  min/max of 0/0 means not checked; if min/max are
     * equal, element is read-only
     */
    const macPibTbl_t macPibTbl[] =
    {
      {offsetof(macPib_t, ackWaitDuration), sizeof(uint8), 54, 54},          /* MAC_ACK_WAIT_DURATION */
      {offsetof(macPib_t, associationPermit), sizeof(bool), FALSE, TRUE},    /* MAC_ASSOCIATION_PERMIT */
      {offsetof(macPib_t, autoRequest), sizeof(bool), FALSE, TRUE},          /* MAC_AUTO_REQUEST */
      {offsetof(macPib_t, battLifeExt), sizeof(bool), FALSE, TRUE},          /* MAC_BATT_LIFE_EXT */
      {offsetof(macPib_t, battLifeExtPeriods), sizeof(uint8), 6, 6},         /* MAC_BATT_LIFE_EXT_PERIODS */
    
      {offsetof(macPib_t, pBeaconPayload), sizeof(uint8 *), 0, 0},           /* MAC_BEACON_PAYLOAD */ // <-- should I modify this 0, 0 seems to mean read-only
      {offsetof(macPib_t, beaconPayloadLength), sizeof(uint8), 0, MAC_PIB_MAX_BEACON_PAYLOAD_LEN}, /* MAC_BEACON_PAYLOAD_LENGTH */
    
      /* more elements omitted for clarity */
    }
    

    SENSOR SIDE

    In sensor.c, I will have to create a Beacon notify indication callback and add it here:

    /*! API MAC Callback table */
    STATIC ApiMac_callbacks_t Sensor_macCallbacks =
        {
          /*! Associate Indicated callback */
          NULL,
          /*! Associate Confirmation callback */
          NULL,
          /*! Disassociate Indication callback */
          NULL,
          /*! Disassociate Confirmation callback */
          NULL,
          /*! Beacon Notify Indication callback */
          NULL,                                      <-- add a pointer to my own callback where I will process the beacon payload
    
          /* more stuff omitted for clarity */
    }

    This callback will be called every time a beacon is received and I will be able to read the alarm notification sent by the collector.

    If this works it would be great! we could broadcast any message in a very simple way, but would processing every beacon has a significant impact in power consumption and battery lifetime?

    Thanks!

    Javi

  • Hello Javi,

    You are correct.

    Here is a quick example on how to implement it. This example uses a clock to update a variable and the contentsupdated_adding_usercontent.pdf of the payload, modify it to your liking.

  • Answering the question 13 minutes after asking it, I think this is a new record AB : )

    Thanks for your help!
  • Im glad I was able to help out!