• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 54 subscribers
  • Views 1000 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.

CC1310: When is a node added to the coordinator's frequency-hopping neighbor table?

Eugene Peng
Intellectual 620 points
Part Number: CC1310

Hi,

In a frequency hopping network, I observe that if a coordinator resets (i.e. loses its neighbor table), it does not add other nodes to the neighbor table even if it successfully receives messages from the other nodes.

The coordinator only adds the node to a neighbor table after the node goes through the async and association phases.

Is that correct and expected?

If so, what is the recommended way to handle a reset on the coordinator? Reset all other nodes on the network too, or have the coordinator send out async requests?

Thanks!

Eugene

  • 0
    TI__Guru**** 217467 points
    Hi Eugene,

    Yes, this is the correct and expected behavior of a PAN coordinator. Please see Frequency-Hopping Mode -> Network Join: dev.ti.com/.../frequency-hopping-mode.html

    With the loss of the coordinator, nodes will orphan after CONFIG_POLLING_INTERVAL fails CONFIG_MAX_RETRIES times. Assuming the coordinator is using the same PanID and extended IEEE address then upon re-forming the network and opening to allow joining, the nodes should recognize the network and re-join without having to be reset. You may want to shorten CONFIG_ORPHAN_BACKOFF_INTERVAL for a quicker re-connection.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 620 points

    Hi Ryan,

    Thanks for answering.

    A follow up question:

    When a node is not in a coordinator's neighbor table, does the coordinator respond to the node's poll request?

    Thanks,

    Eugene

  • 0 in reply to Eugene Peng
    TI__Guru**** 217467 points
    Hi Eugene,

    No, by default the coordinator will validate that the message is requesting its Pan ID but since the polling device is not recognized as a child device then the coordinator will not provide a response. This makes sense as to diminish redundancy within the network. Once the child enters orphan mode it will start to send orphan notifications, although this message is also ignored on the coordinator by default you can modify the application to respond in such a way that the child understands that the neighbor table has been lost and that disassociation will need to occur for a new network join.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 620 points
    Thanks Ryan.

    1. Does a FH child node send Orphan Notifications? My understanding is that it sends ASYNC frame PCS to re-establish the connection with the coordinator.

    2. Does the neighbor table have any relevance in a non-FH network?

    3. Is there any way to query the stack for what is in the FH neighbor table? (through the TI 15.4 COP UART interface)
  • 0 in reply to Eugene Peng
    TI__Guru**** 217467 points
    1. Yes, orphan mode is available in every mode
    2. No, neighbor tables only apply to Frequency Hopping networks
    3. Not directly, although you can keep track of MAC_ASSOCIATE_IND in your host's application and send occasional MAC_DATA_REQ to check the return values and responses of each node.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 620 points

    Hi Ryan,

    "Orphan mode is available in every mode".

    The example sensor application, when it starts up, does not use orphan scan to rejoin the network in frequency-hopping mode. It uses ASYNC frames.

    But you are saying orphan scan should work in frequency-hopping mode too?

    Eugene

  • 0 in reply to Eugene Peng
    TI__Guru**** 217467 points
    Hi Eugene,

    My apology, I confused the machine logic with actual operation. The device will enter an internal orphan state but will not perform any orphan scans because of the built-in ASYNC frames you've mentioned. Frequency hopping uses ASYNC frames for all [re]joining processes.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 620 points

    Hi Ryan,

    Can you share more about when does the coprocessor exactly add a device to the frequency-hopping neighbor table?

    My understanding is it is added somewhere in the ASYNC and Association phase. But it would be helpful to know the precise condition that triggers the coordinator to add the node.

    During my test of a network (28 nodes), I haven't been consistently able to get them into the neighbor table, even though they all join successfully.

    Thanks,

    Eugene

  • 0 in reply to Eugene Peng
    TI__Guru**** 217467 points

    Hi Eugene,

    You cannot modify the neighbor table for frequency hopping as it is handled by the 15.4-Stack, however you can keep a list of associated devices in your application.  Please refer to the following:

    e2e.ti.com/.../
    e2e.ti.com/.../
    e2e.ti.com/.../

    On a coprocessor, this depends on the linux application receiving the association indications which handles the stack logic. For a collector project, refer to the Cllc_associatedDevList.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 620 points

    Hey Ryan,

    I don't need more information about the association table. I do need more details on exactly when the 15.4-stack add a device to the FH neighbor table, because I have not seen devices being added in a predictable manner.

    Thanks,

    Eugene

  • 0 in reply to Eugene Peng
    TI__Guru**** 217467 points
    Hey Eugene,

    This should occur during association, since the PAN coordinator cannot detect if a device has successfully joined the network due to the silent nature of the asynchronous message join procedure (defined by Wi-SUN specification). This is explained in Phase 2 of the Network Join section of the TI 15.4-Stack User's Guide I referenced earlier. Please provide further debug information if you believe there is a bug prevalent in the stack.

    Regards,
    Ryan