• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 1191 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.

CC2530: ZStack 3.0.2 BDB in the most basic scenario

Peter Drozda
Prodigy 140 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK,

Hi guys,

I'm trying to migrate my ZStack 1.2 project to ZStack 3.0.2.

I have the most common and simple scenario. 

- battery powered SED

- polling every 15 seconds to get attributes update

- It does NOT support binding, no EZ, no TL... only simple scenario - automatically join existing network - nothing more.

As a base for my migration I took generic app from examples.

In Zstack 1.2 by default when device booted, it tried to join or re-join the network. It seems it does not occur automatically in Zstack 3.0.2.

I found here in dicsussions that it is probably necessary to call bdb_StartCommissioning(0) in the init method.

Question nr.1: Is it true? Should I call bdb_StartCommissioning(0) in my initialization? Would it take care of "first time" joining and also re-joining?

Question nr.2: I'm little bit configused about that 0 as and argument to bdb_StartCommissioning(). Usually there are many examples in the documentation where e.g. "BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING" is passed.. But as long as I don't plan to support binding it does not make much sense to me..

Question nr.3: Would the default BDB related code provided in genericApp take care of situations when parent is lost (changing parent/re-joining) or do I have to implement anything additional there?

Question nr.3: Is it still OK to use zcl_SendReportCmd also in ZStack 3.0.2? I noticed there is bdb_RepChangedAttrValue. Does it serve the same purpose? E.g. if I want to send periodic reports to parent without any additional reporting configuration whatsoever.

Question nr.4: Do I have to change the poll rate when device changes its network status? E.g. if it gets orphaned? My poll rate is set to 10 seconds in config and I use polling to get my custom attributes written.. But, is it necessary to make the polling more intense in some cases when parent is lost or joining is performed? Or is it done automatically or I shouldn't care?

Thank you very much!

  • 0
    Guru 735695 points

    1. Yes.

    2. If you don’t use binding, don’t use BDB_COMMISSIONING_MODE_FINDING_BINDING

    3. Z-Stack 3.0.2 should take care orphan case and it’s OK to use zcl_SendReportCmd

    4. When device goes orphan, no need to change polling rate 

  • 0 in reply to YiKai Chen
    Prodigy 140 points

    Thanks for reply. But it somehow doesn't work this way for me.

    When I flash the ZED for the first time and bdb_StartCommissioning(0) is called in the init, the device does not try to join the network. It does not do anything.

    I debugged what's going on in bdb_StartCommissioning and it seems it ends up in this part:

    if(bdbAttributes.bdbCommissioningMode == 0)
    {
    //Set the initialization state and report it to fail
    bdbCommissioningProcedureState.bdbCommissioningState = BDB_INITIALIZATION;
    bdb_reportCommissioningState(BDB_INITIALIZATION,FALSE);
    return;
    }

    And that's all.. as far as I understand the code, it simply sets the initialization as a failed.

    I sniffed and the device doesn't even try to join the network.. nothing..

    Could be the problem that the device was never factory reset? I would like to have automatic procedure as it was in Zstack 1.2 - fresh device joins the available network on startup.. Am I doing anything wrong?

    Thank you

  • 0 in reply to Peter Drozda
    Prodigy 140 points

    Could it be that my problem is that I have sleepy end device? From the debugger it seems that it goes to "BDB_COMMISSIONING_INITIALIZATION" with status "IN PROGRESS" and then sleeps.. Is it necessary to call bdb_StartCommissioning(0) periodically in my own timer? If so, is there any example how to do that? Because I'm not sure which condition should I check to stop the retries.. Isn't it handled automatically?

  • 0 in reply to Peter Drozda
    TI__Guru**** 219597 points

    For your CC2530 Z-Stack 3.0 use case, the following would be recommended:

      bdb_StartCommissioning(BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP);
  
  bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING);

    I'm using the SampleSwitch project's functions as an example, where UI_Init performs the first bdb_StartCommissioning call and uiActionStartComissioning would perform the second.  Since the GenericApp does not include the UI, BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP (0x00) should be performed during initialization and BDB_COMMISSIONING_MODE_NWK_STEERING (0x01) when a network should be discovered and joined (this could also be accomplished by HAL_KEY_SW_2 if/when using a SmartRF05EB hardware development solution with the default GenericApp example).  I've removed BDB_COMMISSIONING_MODE_FINDING_BINDING since you've indicated that you do not want to support binding.  You could manage the BDB_COMMISSIONING_NWK_STEERING case of zclGenericApp_ProcessCommissioningStatus if the device cannot find a network to join on the first try, like starting a timer to try another attempts after a determined number of seconds.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 140 points

    Thanks a lot Ryan,

    Does that mean that if I don't want to start commissioning by button press but rather automatically I should call both methods in a row during init? Or what would be the preferable place to call BDB_COMMISSIONING_NWK_STEERING?

    I'm also little bit confused of naming.. I thought that NWK_STEERING means to be in a role of coordinator.. so I was completly wrong here probably :(

  • +1 in reply to Peter Drozda
    TI__Guru**** 219597 points

    You can attempt consecutive calls to bdb_StartCommissioning, but I would not recommend it given that this function returns immediately and without providing a status value. In the past I have started a one-shot timer to call  for BDB_COMMISSIONING_MODE_NWK_STEERING a few seconds past initialization.  Another idea is to wait for the BDB_COMMISSIONING_INITIALIZATION case (fail status or otherwise) in the zclGenericApp_ProcessCommissioningStatus before beginning the network steering.  BDB_COMMISSIONING_MODE_NWK_FORMATION is only for the coordinator, BDB_COMMISSIONING_MODE_NWK_STEERING is used by any node type (ZC, ZR, or ZED) to find and join a network.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 140 points

    Many thanks Ryan. Now I finally understand the concept behind and the BDB state machine.