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.

CC1352R: Sensor_sendMsg give false positives acknowledge

Part Number: CC1352R

For keeping track of message arriving on the collector we use the result of the 

Sensor_sendMsg function which is supposed to be true for a succesfull transmission (acked by the collector).

However I found out that I get false positives from this function.

To test it I shut down and removed power from the collector and after this it still give me true as a result which obviously cannot be the case.

How can I know for sure that a message is either acked or not acked by the collector?

  • Hi Marijn,

    The value of true being returned by the Sensor_sendMsg means that the MAC layer received the message to be sending.

    In sensor.c, there are two functions called dataCnfCB (data confirm callback) and dataIndCB (data indication callback) that will get a status ApiMac_status_success. The indication callback is indicating that you had data incoming. The confirmation callback is telling you whether the sent data came back as successful or if there are any other errors in the sending process.

    So to know for sure if that message is acked or not acked, look at the status in dataCnfCB function.

  • Hi Chris,

    Thanks for your reply.

    I just assumed that the return value was the result of sending the message as the name of the function (Sensor_SendMsg) kinda implies that.

    The issue now is with the callback function that this is asynchronous with the send functions so there is now way of telling to which message the callback belongs. This is the same issue as here with the collector all over again.

    How to verify if a message was successfully sent??? The MAC layer has this information present but in the TI implementation there is now way of linking it back to a message for now. 

  • Marijn,

    As I mentioned in my last post, to verify if your message was successfully sent, just look at the status of dataCnfCB. As others in your previous post mentioned, you can add code to let you keep track of which message is which if you cannot do it right off the bat. You can also verify messages are sent and received by using a sniffer.

    You are more than welcomed to make changes to the code you download in the SDK and we expect our customers to do so.

    I would also suggest you to take a look at the 15.4 spec along with our documentation and fully familiarize yourself with what is going on in the projects you are looking at. 

  • Hi,

    Chris S said:
    As I mentioned in my last post, to verify if your message was successfully sent, just look at the status of dataCnfCB

    As mentioned in my previous post, the dataCnfCB result is completely useless as it has no way, (in the currently available data struct), to keep track of to which message that callback belongs.

    Chris S said:
    As others in your previous post mentioned, you can add code to let you keep track of which message is which if you cannot do it right off the bat.

    As you can read in that (quite lengthy thread), there is no way of adding code to keep track of the message because the dataCnfCB does not give back any of that data. I have to edit the MAC itself to accomplish that and as far as I know that code is not available. If this is possible let me know where the MAC layer code is.

    Chris S said:
    You can also verify messages are sent and received by using a sniffer.

    This is not helpfull, I'm looking for a production solution, not a debug solution.

    Chris S said:

    You are more than welcomed to make changes to the code you download in the SDK and we expect our customers to do so.

    I would also suggest you to take a look at the 15.4 spec along with our documentation and fully familiarize yourself with what is going on in the projects you are looking at. 

    My issue is not with the 15.4 spec, I'm quite familiar with it. My issue is with the MAC layer which, although it has the needed information on succesfull/failed transmission, fails to pass that information back in a useful manner.

    If I can pass just a simple uint32_t transaction ID to the mac dataReq and get that back in the dataCnfCB I can track my messages, no problem.

    But in the thread I mentioned there is a lot of suggestions to add this at application level which is such an overkill of unneeded data and battery power because the needed information is right there in the MAC layer.

  • Marijn,

    Marijn Achterkamp said:
    As mentioned in my previous post, the dataCnfCB result is completely useless as it has no way, (in the currently available data struct), to keep track of to which message that callback belongs.

    • The TX Buffer is FIFO, so you can check the frame counter of the message you are queuing up to send and compare it to the frame counter in the dataCnfCB. To do this, use the pDataCnf->frameCntr variable in dataCnfCB. And to check the current device frame counter, you can use either Csf_getFrameCounter for collector or Ssf_getFrameCounter for sensor. This should give you some ideas and a place to start on looking at which message is sent. 
    • Can you give me any more info as to why you want to verify or know which message got sent? Some info on this might clarify the needs of your question.
      • I think this was mentioned or you might know this, but if the MAC sees the TX was not completed successfully, it will auto retry based on your setting of number of retries in the syscfg module.

    Marijn Achterkamp said:
    I have to edit the MAC itself to accomplish that and as far as I know that code is not available. If this is possible let me know where the MAC layer code is.

    • The MAC is not available to customers as its our internal implementation. I can look further into the code to see if there is an area for you to use to access the info youd like, but other than what is mentioned here and in your previous thread, there might not be other ways. It might be a good idea to try the transaction ID info to see if it gives you what you want in the mean time if the frame counter suggestion does not pan out to what you are looking for.

    Marijn Achterkamp said:
    This is not helpfull, I'm looking for a production solution, not a debug solution.

    • I did not know that this was for production, so I apologize for the misunderstanding there.

    Marijn Achterkamp said:
    My issue is not with the 15.4 spec, I'm quite familiar with it. My issue is with the MAC layer which, although it has the needed information on succesfull/failed transmission, fails to pass that information back in a useful manner.

    • Is there any more info you can give me about your application? Why is it so important to know which message got sent if not for a debugging product or testing case? Giving more info here could help clarify.

  • Hi Chris,

    Thanks replying.

    I looked into the frameCntr but the get Ssf_getFrameCounter only returns the last saved framecounter, not the current framecounter. 

    Chris S said:
      • I think this was mentioned or you might know this, but if the MAC sees the TX was not completed successfully, it will auto retry based on your setting of number of retries in the syscfg module.

    Yes I know this, it does not help however in the situation that e.g. a collector is down for a few minutes. It'll quickly run through its retries and fail nonetheless without letting me know for which message.

    Chris S said:
    The MAC is not available to customers as its our internal implementation. I can look further into the code to see if there is an area for you to use to access the info youd like, but other than what is mentioned here and in your previous thread, there might not be other ways. It might be a good idea to try the transaction ID info to see if it gives you what you want in the mean time if the frame counter suggestion does not pan out to what you are looking for.

    That will be great. The best thing for me is to be able to pass a value "id" along with the message so I can track that in the dataCnfCB.

    Chris S said:
    Is there any more info you can give me about your application? Why is it so important to know which message got sent if not for a debugging product or testing case? Giving more info here could help clarify.

    Because this code is used in building access technology it is important to make 100% sure no 'access event' data is lost. That's why I need to know for sure if a message is delivered or not. I can 'cache' the data locally if a message fails to reach the cloud but for flash lifetime saving I don't want to cache every event, only the ones that fail to deliver to the gateway.

    Thanks, Marijn

  • Marijn,

    I looked into maybe increasing the size of the msduHandle variable to 16 or 32 bit, and unfortunately, I do not think that will be possible. However, I can give you some insight that the msduHandle is only passed along in the MAC layer, and only really used in the application layer. So, I think you could repurpose the 8 bits to be a sort of ID for your purposes. I know its not much, but that gives you 128 ID numbers to use to keep track of different messages. That along with maybe using the frame counter to check against your sent messages, you can throw together a way to verify messages are transmitted properly. 

    You could also try to come up with your own solution for tracking the messages separate. But we do not really have anyway to track messages as you would like. Good luck!