• State
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 82 views
  • Users 0 members are here
Support feedback
Options
Options
Related

CC1312PSIP: Bypass mac queue on transmission

Andrew Bakin
Prodigy 130 points
Part Number: CC1312PSIP

Tool/software:

Hi,

I am using simplelink_cc13xx_cc26xx_sdk_7_41_00_17 collector/sensor example. I have a radio message that needs to be sent with no delay as it is an alarm. I would like to bypass the mac queue and therefore the possible failures of transmission due to the mac queue being full or some other delay like heap allocation.

Is there a way to guarantee that a message will get transmitted immediately using TI 15.4?

I imagine the solution probably involves calling RF_runCmd() directly, but is it safe to use these functions along-side TI 15.4? How would the mac receive it at the other end? There would need to be the TI 15.4 headers attached. Is there anything to watch out for? What steps should I take to take control of the radio, transmit, and then return it to the previous state for TI15.4 to carry on?

Thanks for your help,

Andy

  • 0
    TI__Intellectual 1510 points

    Hi Andrew,

    I don't think this is advised, however I'll check with the TI15.4-Stack experts to check if there is a safe way to do it. In the meantime, can you give me the following information:

    1. What TI15.4-Stack mode are you running (beacon, non-beacon, frequency hopping, frequency hopping low latency broadcast )

    2. Is the message you want to send from Sensor to Collector? or the other way around?

    3. What is the band region you are using?

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 130 points

    Hi,

    Thanks for your response.

    I'm running non-beacon mode in non-sleepy sensor. The alarm message will be broadcast rather than unicast, to maximise the chances of the alarm being picked up by other listening nodes. The radio will be subject to high impact and so I need to ensure the alarm message is transmitted as quickly as possible. The system will run on 868MHz and 915MHz for EU and NA applications.

    I don't like the idea of using the radio symbols to do this directly, so I'm hoping there's a nice way of using the mac to bypass any potential delay in the transmission.

    Many thanks,

    Andy

  • 0 in reply to Andrew Bakin
    TI__Intellectual 1510 points

    Hi Andrew,

    I've checked with the team and there is no way to skip the messages queued in MAC. There is no priority in the message, the queue is first come, first served.

    There are two workarounds:
    1. Edit the MAC so that each packet contains a priority. The highest priority is placed on top of the queue. This will violate the first come, first served rule.

    OR

    2. Purge all the packets in the queue (ApiMac_mcpsPurgeReq) so that the queue is now empty, send the alarm message.

    Unless you are sending a lot of messages all the time, my guess is that a regular transmission would also work as the queue is probably empty.

    Bear in mind, that in any case, the transmission (even with an empty queue) could be delayed due to the Carrier Sense Multiple Access (CSMA).

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 130 points

    Hi,

    Thanks for help. 

    I thought about purging but didn't want to do this as it's another step. I am intrigued about editing the MAC to add a priority, but I did not think I am able to do that as they are library files. If I had access to these files then I could certainly create a robust solution. Is this possible?

    There will not be many transmissions, so as you point out, the likelihood that a messaged will be queued is small, but there may be a case where a device is transmitting alarm or status messages it has received from another device, when it enters an alarm state itself. This is when CSMA and queuing is going to have an impact.

    I can't do much about CSMA, but hopefully I can reduce the delay caused by queuing somehow. If I am unable to edit the MAC, may be another solution would be to reduce the MAC queue to one or two, to minimise the delay caused by the queue.

    Please let me know your thoughts.

    Thanks,

    Andy

  • 0 in reply to Andrew Bakin
    TI__Intellectual 1510 points

    Hi Andrew,

    I'm checking with the team about the first point.

    Regarding the MAC queue, take a look at MAC_CFG_TX_DATA_MAX, located in SDK_PATH/source/ti/ti154stack/high_level/mac_cfg.c

    Best regards,

    Daniel