• TI Thinks Resolved

CC1350: How to verify if messages are received by sensor node?

Intellectual 460 points

Replies: 12

Views: 116

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?

  • Hey Marijn,

    The collector application tracks the sensorMessagesReceived as well as the attempted/sent config and tracking messages. This is tracked in 

    Collector_statistics_t Collector_statistics;

    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).

    http://software-dl.ti.com/simplelink/esd/ti15.4stack_linux_x64/3.30.00.12/exports/docs/ti154stack/html/ti154stack-linux/linux-example-applications.html#linux-collector-and-gateway-example-applications

    You can also track this statistic from the sensor side in 

    Smsgs_msgStatsField_t Sensor_msgStats

    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.

    Regards,

    Ammar

    Please click the "This Resolved My Issue" button on this post if it answers your question

  • 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.

    Regards,

    Ammar

    Please click the "This Resolved My Issue" button on this post if it answers your question

  • In reply to Ammar N:

    Hi Ammar,

    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.

    kind regards,

    Marijn

  • In reply to Marijn Achterkamp:

    Hey Marjin,

    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.

    Regards,

    Ammar

    Please click the "This Resolved My Issue" button on this post if it answers your question

  • In reply to Ammar N:

    Hi Ammar,

    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...

  • In reply to Marijn Achterkamp:

    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.

    Regards,

    Ammar

    Please click the "This Resolved My Issue" button on this post if it answers your question

  • In reply to Ammar N:

    Hi Ammar,

    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?