Network collapse when Zigbee light bulb example runs

[mau]

Hello to all,

i've developed some application under 3.2.0 SDK. Now I want to port my application on new 4.1.0 SDK but a I have found a relevant issue.

Before migrating my application (I read migration guide and the modifications are consistent), I decided to try light bulb example.

When the example runs all network activity stops, on the sniffer the last message is identified as "beacon request".

Until the example is still running, I can't see any other message, any command from coordinator and other device (and vice-versa) doesn't work.

I attach sniffer trace sdk_410_starts.pcapng to show you wath happens. In order to view the trace this is the key: 8a:89:a1:cc:a3:66:11:15:05:88:8f:a7:9e:f5:99:67

BR,

Maurizio

[Edvin]

Hello,

Are the other devices in the network also nRF devices running on SDK4.1? It shouldn't really matter, but for debugging purposes.

Does the coordinator receive any event? Does it say anything after the beacon request from the nRF light bulb? Does this also happen if you try the light_control example (light- bulb, switch, and coordinator) from SDK4.1?

[mau]

Hi,

Edvin said:

Are the other devices in the network also nRF devices running on SDK4.1?

there's no other nRF devices.

Edvin said:

Does the coordinator receive any event? Does it say anything after the beacon request from the nRF light bulb?

Coordinator is based on ETRX357 Telegesis with CLI interface, but on CLI I've no event on beacon request. 

Edvin said:

Does this also happen if you try the light_control example (light- bulb, switch, and coordinator) from SDK4.1?

I've only two Nordic board, and I can't try full example, but if I try the same example based on SDK 3.2.0 this issue doesn't occur.

BR,

Maurizio

[Edvin]

Perhaps the coordinator doesn't like that there is a "new" device that tries to join with the same address as the old light bulb? Do you have any possibility to debug the coordinator? I don't know what their SDK looks like, but there must be some event that is generated when a new device tries to join. Did you remove the device properly from the network first?

I can't say anything from the sniffer trace. After the new node's beacon request, the coordinator should reply to this, which it doesn't do in the sniffer trace.

BR,
Edvin

[mau]

Hi Edvin,

Edvin said:

Perhaps the coordinator doesn't like that there is a "new" device that tries to join with the same address as the old light bulb?

To clarify the device with light bulb example on 4.1.0 is only powered and never associated to my network.

Edvin said:

Do you have any possibility to debug the coordinator?

I guess not, this is not mentioned in the documentation.

Edvin said:

Did you remove the device properly from the network first?

I've also tried with no device associated to the network (coordinator only), and the only messages sniffed are link status, but when I turn on light bulb example the beacon request message appears and then nothing until device is powered. 

Edvin said:

I can't say anything from the sniffer trace.

In all situations, as soon as I turn off device with light bulb example the network is "unlocked" and messages return to normality.

It would seem that as long as the device with the example is running the radio channel remains busy and no other device is able to communicate. In fact if I set on the example the Zigbee channel to one different to my network (I'm using channel 11) this issue doesn't happen.

I had not yet said I am using the PCA10056 board, maybe the issue is related to nRF52840 hardware?

BR,

Maurizio

[Edvin]

mau said:

To clarify the device with light bulb example on 4.1.0 is only powered and never associated to my network.

 But you said that the network stops working after you turn it on, is that the case?

 

mau said:

I guess not, this is not mentioned in the documentation.

 So it is not something you have made? It is a product that you bought of the shelf?

 

mau said:

when I turn on light bulb example the beacon request message appears and then nothing until device is powered. 

 What device? And do you mean power cycled? What happens then?

I just tested the light bulb with a coordinator running on the CLI example, both running on pca10056 boards. No issues there.

Can you say something about the coordinator? What is the coordinator looking for? Will it accept any device? Please note that there is a difference in the light bulb example and e.g. a Philips Hue light bulb, 

Can you test two things for me:

1: Delete the entire flash of the light bulb before you try to run the light bulb example. Perhaps it has some old network settings in flash from when you were using the older SDK. Use the command "nrfjprog --eraseall" (you must have nrfjprog installed. Let me know if you don't know how to install it).

2: You said you have two DKs. Can you try to use one with the light bulb example (remember to erase the flash first). Program the other one with the CLI example from SDK\examples\zigbee\experimental\cli. Once you have programmed it and you have a putty terminal with the correct settings, type the commands:

bdb channel <the channel that you use on your lightbulb>.

bdb role zc

bdb start.

Does that work?

[Edvin]

By the way, instructions on how to set up the cli example can be found here:

https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/zigbee_example_cli_agent.html

And how to set up your CLI terminal (putty) here:

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_cli.html#lib_cli_terminal_settings

[mau]

Hi Edvin,

Edvin said:

But you said that the network stops working after you turn it on, is that the case?

I confirm.

Edvin said:

So it is not something you have made? It is a product that you bought of the shelf?

Yes, the coordinator is a commercial product.

Edvin said:

What device? And do you mean power cycled? What happens then?

The device running Light Bulb Example as mentioned above.

Edvin said:

I just tested the light bulb with a coordinator running on the CLI example, both running on pca10056 boards. No issues there.

 I tried this setup before on SDK 3.2.0 and after on SDK 4.1.0. These is the results:

On SDK 3.2.0 I programmed one board as CLI and the other one with Light Bulb Example. At startup the board with Light Bulb Example has LED 4 switched on and LED3 switched off. On CLI I issue:

bdb channel 11

bdb role zc

bdb start

LED3 on the board with Light Bulb Example is switched on to indicate right association.

Then I issued this command:

zcl cmd F4CE368732AA67A8 10 0x0008 -p 0x0104  0x00 -l 00ffff

LED4 on the board with Light Bulb Example is switched off in response of my level control command

And at the end I issued this command:

zcl cmd F4CE368732AA67A8 10 0x0008 -p 0x0104  0x00 -l ffffff

LED4 on board with Light Bulb Example is switched on again.

At this point I executed "nrfjprog --eraseall" for each board and then I programmed with SDK 4.1.0.

I ran the same commands but on the board with Light Bulb Example LED4 is alway on and LED3 is always off.

You say that you have no issues with this setup, what tests did you get after bdb start?

BR,

Maurizio

[Edvin]

Well, initially I only checked that the LED3 was turned on, indicating that the bulb had successfully joined the network. But when you wrote this, I tested the same set of procedures on both 3.2.0 and 4.1.0. In my case, it worked in both versions. (Wait to send the match desc until LED3 turns on).

These are the commands that I used:

> bdb role zc
Coordinator set
Done
> bdb channel 11
Setting channel to 11
Done
> bdb start
Started coordinator
Done
> zdo match_desc 0xffff 0xffff 0x0104 1 0x0006 0
Sending broadcast request.
src_addr=72E5 ep=10
> zdo ieee_addr 72e5
f4ce3752d0756231
Done
> zcl cmd f4ce3752d0756231 10 0x0008 -p 0x0103 0x00 -l 00ffff
Done
> zcl cmd f4ce3752d0756231 10 0x0008 -p 0x0103 0x00 -l ffffff
Done

[mau]

I've some updates for you.

As I said, I've two boards, one is a PCA10056 and the other is MDBT50Q-DB (from RAYTAC).

I never used PCA10056 as CLI or sniffer because has faulty nRF USB port so I always used PCA10056 to run the Light Bulb Example which does not need USB to work. 

Today I tried to use my original coordinator (based on ETRX357 Telegesis) and MDBT50Q-DB to run the Light Bulb Example over 4.1.0. 

Now it work!

Then seems that faulty USB port on PCA10056 is the responsible for the problem.

Probably the same example based on 3.2.0 don't care about this.

BR,

Maurizio