• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 421 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Example main_manyEDs_autoack

Henrik Danielsson
Expert 1405 points

Hi!

 

I'm looking at the example "main_manyEDs_autoack.c" and I have doubts about this code

-  In "static void linkTo()" A SMPL_Ping is done if there is no ACK after a number of retries.  Why? The SMPL_Ping only pings the device the connection is on, right?  The device sLinkID1 is linked tomay have restarted and don't have the connection any more. So just because SMPL_Ping succeded there is no guarantee that the SMPL_SendOpt will succeed even if the frames are transmitted ok?  I thnik the Join and Link has to be run again here instead of the ping. Anybody agree?

- Why don't we want to do a scan (ping) just because a CCA failed? I don't get that. The air is busy and we didn't get the ACK after several retries. Why don't do the scan, the channel might have changed just because the current channel is busy.

 

Regards Henrik

  • 0
    Expert 1365 points

    Hello.

    As to your points:

    - The reason for the SMPL_Ping() call is to find out if the current channel has changed. You won't get an ack if the device is on the wrong channel. If Frequency Agility has not been enabled the Ping is not executed.  Of course, there are other reasons the ping could fail, and yes, if the connection is broken the ping may succeed anyway. If you read the documentation carefully you will see that the SMPL_Ping() API explicitly does not guarantee that the connection is OK -- it is not a peer-to-peer ping. It only guarantees that the other device is there. You are correct -- If the connection is broken the linking transaction must be re-executed unless the connection information has been stored in NV memory.

    - The code I am looking at does not do the ping if a send has failed because of CCA failure. The send re-try loop must fail each time because of no ack. Only then is the ping done.

    Hope this helps.

    lfriedman

     

  • 0 in reply to lfriedman
    Expert 1405 points

    Hello Ifriedman!

    If some other device has taken over the channel then CCA will always fail. Now it would be very appropriate to do the ping but the sample code doesn't.

    Another question. You mention storing connection information in NV memory. Will it work if security is enabled? Mustn't the link be reexecuted anyway to initialize the counter values used by encryption/decryption?

    /Henrik

  • 0 in reply to Henrik Danielsson
    Expert 1365 points

    Hello again.

    Henrik Danielsson said:
    If some other device has taken over the channel then CCA will always fail. Now it would be very appropriate to do the ping but the sample code doesn't.

    Yes, this is right. It is left as an exercise for the reader to fine tune the application! There was no way to write an application that aniticipates all possible reasons for channel contention. Hopefully the APIs supply enough flexibility to permit you to modify the code depending on conditions in your scenario.

    Henrik Danielsson said:
    Another question. You mention storing connection information in NV memory. Will it work if security is enabled? Mustn't the link be reexecuted anyway to initialize the counter values used by encryption/decryption?

    This is a good question. The answer is that the connection will probably work without a new link transaction but there is no guarantee. The counter values are saved as part of the connection context. If traffic between the peers remains quiet while one side is down the dynamic counter values will not change since the counter values only change when a frame is communicated. When the context is restored things should still be OK. In addition there is substantial leeway allowed for non-synchronized counter values. See the CTR_WINDOW macro in the nwk_securty.c file. By default this window is set to the maximum size.

    Hope this helps.

    lfriedman