• State Answer Suggested
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 59 subscribers
  • Views 759 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.

Rejoin/join problem

Rooney
Prodigy 95 points

Hello!

I'm having troubles with rejoining/joining a network (Zstack 2.2.0).

Imaging following situation:

# A coordinator is starting, building up the network.

# An end-device is joining the network and will send status messages periodically.

# After that the coordinator is shut down or is not reachable due to range limitations.

# The end-device will detect a sync loss to the coordinator because there will not be received an APS/MAC acknowledgment when transmitting status messages. In this case I will execute ZDO_StartDevice(NODETYPE_DEVICE, MODE_JOIN, BEACON_ORDER_NO_BEACONS, BEACON_ORDER_NO_BEACONS) to reset the Zigbee stack.

# If the coordinator is reachable again it sometimes takes about 1min to rejoin the network. Sometimes it even doesn't join anymore at all.

What am I doing wrong?
Why takes it longer to join the network when executing ZDO_StartDevice() than doing a hardware reset on the end-device and completely reset the microcontroller?
How to correctly reset the Zstack without doing a hardware reset? I don't want to loose variables stored in RAM of my application.

 

Regards

Rooney

  • 0
    Expert 1075 points

    Hi Rooney

    Are you using the NV_RESTORE compile option (see the following thread for details https://community.ti.com/forums/p/1442/4944.aspx#4944)?

    If you use it the re-join should go quicker and smoother as the coordinator will come up with the same settings (PAN ID, frequency, etc.), which is what I use to handle little power cycles.

    Otherwise it will depend on your settings e.g. in the f8wConfig.cfg file what happens, because it could be that the upstarting coordinator does an energy scan or an active scan (sending its Beacon) to see whether the channel is free and then either start the network there (maybe even using a new PAN ID) or going to a different channel/frequency as it received the end-device message in exactly that moment (which indicate that the channel/PAN ID is taken).

    For more details regarding the f8wConfig.cfg and configuration of the start up you can check the following training material: http://tiexpressdsp.com/images/8/8a/08_-_ZigBee_Stack.pdf

    which I found on http://wiki.davincidsp.com/index.php?title=Low_Power_RF_Solutions_Workshop

    Good luck!

    -LL-

  • 0 in reply to LuckyLuke
    Prodigy 90 points

    Sorry Rooney but I want to ask you and LuckyLuke a rejoin and join question here.

    I'm doing a power consumption test with CC2430ZDK. I enabled POWER_SAVING in a end device and try to compare the power consumption when it lose connection and tries to rejoin, with when it first starts and tries to join the network.


    1.For rejoin, it sends beacon request periodically and goes to sleep after each try. In each circle, current consumption is first 31mA and then a few μA.
    2.For starting to join, it also sends beacon request but it doesnt go to sleep. In each circle, current consumption is first 31mA for 70% of the time and then 12mA.

    For the second one, what shall I do if I want it to behave the same as rejoin? Why the it is listening for 70% of the time? Thank you for your time!

     

     

  • 0 in reply to Kui Liu
    Prodigy 150 points

    The problem here is that the first call to osal_pwrmgr_device is done after the first join of the network.

    I solved that problem adding this line  

    osal_pwrmgr_device(PWRMGR_BATTERY);

    In the init function of my application.

  • 0 in reply to luimmi
    Prodigy 90 points

    Thank you very much Luimmi, that's very helpful.

    Do you know why join process is much longer than rejoin? I guess there are more things to do for join, but I dont know the details.

     

  • 0 in reply to Kui Liu
    Prodigy 150 points

    No, I don't know why, but I'm working just now on reduce joining time.

    I have great results working with some constants in the stack. If you want to try, just modify the values of STARTING_SCAN_DURATION on NLMEDE.h (set it to 1) and NUM_DISC_ATTEMPTS on ZDApp.h (set it to 1 too).

    I don't know if it could have some collateral effects, but joining time reduces to less than 150ms.

    Hope it helps !

  • 0 in reply to luimmi
    Expert 1075 points

    The re-join should go faster as the device already knows which network it wants to re-join (it already has relevant info), while in a join it first has to do the scan to find a network to join etc.

    -LL-