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.
Part Number: CC1350
For our application we need to make sure that messages from the cloud are actually received by the sensor node.
Especially the part from the gateway through the collector and coprocessor is not providing acknowledgement.
We use linux collector app + cc1350 coprocessor.
From the gateway to the coprocessor there is only the status message success or transaction overflow if the coprocesor buffer is full. Although the TI software does nothing with this message it can be send to the gateway app. So we can at least make sure it is in the coprocessor.
From there on the coprocessor provides the callback function dataCnfCB which support multiple failure options (and of course success).
However as this is asynchronous to the gateway we need some way of tracking each message.
Is there a way of adding an identifier to each message and have the coprocessor reply to dataCnfCB with that identifier so we can track if messages are actually transmitted?
The collector application tracks the sensorMessagesReceived as well as the attempted/sent config and tracking messages. This is tracked in
All you need to do is expose this in the upper layers of your application (i.e. the Local Gateway Application shown in the link below).
You can also track this statistic from the sensor side in
Here you have the sensor messages attempted as well as the sensor messages sent. If both are the same, then your collector has not missed a message.
Please click the "This Resolved My Issue" button on this post if it answers your question
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
I would suggest you to implement application level ack by yourself for such requirement.
If my post answers your question, please click on "This Resolved my issue" button to benefit others who have the same issue.
How to use two UARTs in CC26x2 and CC13x2
How to add you own custom board files to CC26xx BLE stack
SwitchBot DIY using LPSTK-CC1352R , SG90 servo motor, and ProjectZero to away from COVID-19.
How to use two endpoints in SIMPLELINK-CC13X2-26X2-SDK Z-Stack.
CC13xx TRX WOR project.
How to create a periodic event to toggle BLE Advertising in CC26xx simple_peripheral example
How to use indication in simple_peripheral example and use Btool to enable indication
How to check APS ack in TI Z-Stack
How to detect button hold in CC26x2, CC13x0, CC13x2 SDK.
660 Zigbee devices in the same Zigbee network!
In reply to Ammar N:
Thanks for the suggestion of the message statistics. I will definitely make this available in our high level application.
The thing I still need however is a per message ack. Especially for some messages I need to know if they arrived so I can retry them if they failed.
From the statistic I can tell that a nr of messages did not arrive but not which message that was.
In reply to YiKai Chen:
Yes that is exactly what I want to do. But in the collector callback
static void dataCnfCB(ApiMac_mcpsDataCnf_t *pDataCnf)
I cannot find any message ID.
Can you point me to a solution to include a message identifier to a message so I can track it back in the confirmation callback?
In reply to Marijn Achterkamp:
In this case, as YK suggests, I would recommend you send application level messages. In dataIndCB(), you can see the switch statement that checks which message type was received, and then a call to a processXX() function. Inside this processXX() function, you can add your tracking variable.
If you want to add a custom message, there's a wiki page (here) that outlines what code additions are needed on both the collector/sensor side.
Thanks for the suggestion,
It could be a solution if no other possibility exists for transport layer ACK.
However from a network perspective, 15.4 stack has a transport layer so the responsibility for transmitting a message lies firstly in that layer.
If the transport layer cannot transmit the message it should report back to the next upper layer. The thing is, all the content is already there in software. There is a callback function, dataCnfCB, which has all that information, only not which message that callback is actually for. I'd really like to first solve it there if possible.
The problem with solving this application level, you have no idea where the message failed, only that a message did not return an answer somehow. For finding out what is going wrong it is much more helpful if the transport layer result is available for the message.
It took some digging, but I think I found a way to extract the message identifier in the DataCnfCb.
When each message is sent, it is sent with a particular MsduHandle, which is tied to an Smsgs_cmdIds_t type (see sendMsg on the collector).
You'll have to modify the getMsduHandle() function and add the appropriate Smsgs_cmdIds_t type in the conditionals. Then, in the DataCnfCb, you'll have to check for the specific MSDU_Handle to know which message was received.
Please let me know if you're able to get this to work.
Thanks for thinking with us. I see however that the MsduHandle is only a 8-bit uint of which 5 bits are used as a auto-rollover counter and 3 bits as flag to identify either config, broadcast or app message. This leaves no room for an identifier.
It would be great if I could enlarge it to a 32-bit uint which would be simple from the collector point of view. But the MsduHandle is sent to the coprocessor as wel and it expects an 8-bit there so no way I can just send a 32-bit to it and expect it back...
Maybe if we use use the collector app on the device rather then on the linux machine we have this more under control but that involves a rather larger change in our iot-gateway application...
You're free to modify and use the msdu handle as needed, it is defined in the application layer, and not used by the stack.
The implementation shown is just an example, so you can modify it to use all bits to receive identifiers in your case.
Another way to track messages may be to use the frameCntr, although I don't think this will provide you with specific identifiers for a particular message id.
But can I just increase it to a uint32? I thought that is was sent to the mac layer (at least it is sent to the coprocessor over serial connection) So if I just change it from 8bit to 32 bit uint probably the protocol does not handle that...
About the framCntr, Can you explain what this is? Can I set it myself or its it just a counter from the mac layer?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.