CC2530ZNP Mini Dev Kit Questions

Hi Richard,

1. You can place all the routers inside the room with coordinator
   and see if the obstacles is the issue here.
   It is very unlikely, but it can happen that all the routers connected to the coordinator,
   and therefore sends its messages directly to the it.
   Please, provide more information about the way you are registering the routers in
   ZigBee network and by the way, what is the version of Zstack you are running your
   application on? 
2. Regarding the "maximum distance" between the devices, read the following post,
   it might provide you with helpful information. 
3. In the "CC2530ZNP Interface Specification" document, go to page 117, there is a
   list of parameters for status return values: 0xCD means "ZNwkNoRoute". 

Hope it helps.

Br,

Igor

Hi Richard,

Can you please elaborate on the network topology? Did all the routers join the network, having the coordinator as the parent? Had all the routers been at the locations by the time they joined the network, or were they moved to the current places after they all joined the network?

If you provide Ubiqua sniffer log, it will help much.

- Cetri

Thanks for the replies and apologies for the delay in getting back to you.

What is the version of Zstack you are running your application on?

The firmware currently programmed on the CC2530 is CC2530-MK-Pro.hex found in C:\Texas Instruments\CC2530ZNP Mini Kit\Bin. According to the SYS_RESET_IND message the firmware version is 2.3 and the hardware version is 1.

Please, provide more information about the way you are registering the routers in ZigBee network

Not sure of exactly want information you want here, but basically I tell them to join a network with a given extended PAN ID. My startup procedure is as followed:

1. Set startup options STARTOPT_CLEAR_ CONFIG + STARTOPT_CLEAR_STATE
2. Reset ZNP
3. Set startup options STARTOPT_AUTO
4. Set extended PAN ID
5. Reset ZNP
6. Set Zigbee device type
7. Set channel
8. Set security mode SECURITY_MODE_OFF
9. Enable callbacks
10. Register generic application AF_REGISTR
11. Start application ZDO_STARTUP_FROM_APP

Can you please elaborate on the network topology? Did all the routers join the network, having the coordinator as the parent? Had all the routers been at the locations by the time they joined the network, or were they moved to the current places after they all joined the network?

I ran a couple of tests this morning and found that it seemed a lot more reliable when I let the routers join the network first and then moved them into position. Its hard for me to tell if the coordinator is the parent for all the routers as I only have serial debugging for two (those both are), the rest are battery powered and only have LEDS for debugging. If I move the routers into position first and then turned them on one by one (nearest first) I experience similar problems as those mentioned in my first post.

Regards

Richard

I'm starting to wonder if these messages are being sent but sometimes being reported as not sent.

Basically the router is saying a message has not been sent even though I can clearly see that the coordinator has received it.

Also I noticed that the coordinator will sometimes receives the same message (AF_INCOMING_MESSAGE) more than once. Below are 4 messages received by the coordinator from the same router. I know this is the same message because the last 2 bytes of the message is a transaction number. The only difference between the messages is the TimeStamp.

R:32 44 81 00 00 07 00 6A 7C D7 D7 00 00 00 06 D3 00 00 00 21 41 58 49 4F 4D 41 54 49 43 43 30 30 31 32 34 42 30 30 30 31 32 46 34 46 30 46 3A 30 30 31 3A 35 36
R:32 44 81 00 00 07 00 6A 7C D7 D7 00 00 00 6C 1C 01 00 00 21 41 58 49 4F 4D 41 54 49 43 43 30 30 31 32 34 42 30 30 30 31 32 46 34 46 30 46 3A 30 30 31 3A 35 36
R:32 44 81 00 00 07 00 6A 7C D7 D7 00 00 00 84 1C 01 00 00 21 41 58 49 4F 4D 41 54 49 43 43 30 30 31 32 34 42 30 30 30 31 32 46 34 46 30 46 3A 30 30 31 3A 35 36
R:32 44 81 00 00 07 00 6A 7C D7 D7 00 00 00 CA 65 01 00 00 21 41 58 49 4F 4D 41 54 49 43 43 30 30 31 32 34 42 30 30 30 31 32 46 34 46 30 46 3A 30 30 31 3A 35 36

Why could this be?

Hello -

I think that the examples in the mini-kit are not suitable for the large and potentially sophisticated network for which you intend to use the ZigBee Network Processor, aka ZNP. The use of the ZNP by the mini-kit are super simplistic, tiny footprint examples for a network of 1 to 2 or a few nodes, like a few low-power ZED sensors talking once in a while to the ZC.

Please take a look at the fully-featured use of ZNP by the ZAP (ZNP Application Processor) found in its own installer:

http://focus.ti.com/docs/toolsw/folders/print/z-stack.html

swrc173.zip (57.0MB) - contains ZStack-ZAP-MSP430-1.0.4.exe (the ZigBee Applications processor to be used with MSP430 product family).

The ZAP has been successfully used in something so complicated as a Smart Energy network. Unfortunately, the ZAP is too big for the tiny MSP on the mini-kit, it is more suitable for the MSP2618 or MSP5438, for example.

In order to try and overcome these issues I'm trying to update the firmware on the CC2530 to the latest version of ZStack (2.5.0)

I've programmed the firmware to C:\Texas Instruments\ZAP-MSP430-2.5.0\Projects\zstack\ZAP\ZNP-HexFiles\CC2530ZNP-Pro.hex, found by installing ZStack-ZAP-MSP430-1.0.4.exe. Unforuntately as soon as I try an SPI write the firmware on the MSP430 locks up waiting for the SRDY pin to go low.

Is there any reason why this version of firmware won't work on the CC2530ZNP mini kit?

My initial thought was because the CFG0 (32KHZ crystal) and CFG1 (Transport mode) pins are not set, but changing those to any combination appears to have no effect. The only other thing I can think of is because its using a different pin configuration.

Thanks for your help, it's much appreciated.

I believe the current version of the ZStack on my development kit is 2.3 so there maybe some important fix in 2.4.

Although I've used the examples as a starting point I have infact created my own version of firmware that deals with some of the issues (I may have missed some ofc, will double check). The test system is fairly straight forward though. The coordinator creates a network with a given extended PANID and outputs all the messages it receives down the UART. The routers (6 in total) join this network and send a simple message to the coordinator every 10 seconds.

Not really sure what else I can tell you.

Regarding the pin configuration. Can this version of firmware be easily built if I get the ZStack source code? I assume there is some compiler/build option that states what pin configuration is being used?

Many thanks

Richard

Hello Richard,

ZNP Mini kit have range greater than 5 meter and so range limitation does not seem to be the issue.But when you are testing how high are the router units above the ground, what is the surrounding of the kits. Below are few suggestions:

1. From your 1st post it looks like upto 2nd node communication is working properly, when you bring in the 3rd node problem starts, did you try bringing the 3rd node closer to the 2nd node and tried if that improved the network operation.

2. If you have used Simple application Example there is a bug in the example see the following post for the fix, http://e2e.ti.com/support/low_power_rf/f/158/p/104163/415685.aspx#415685

3. Do you have a CC2531USB Dongle, I would recommend that highly when working on Zigbee Network development. You can use  this dongle with Ubiqua packet sniffer or TI packet Sniffer to observe network behaviour which becomes an important aid when developing Zigbee Networks.

4. To build the Image for ZNP Mini Kit , download the Z-Stack-2.5.0 from www.ti.com/z-stack. In the installed Z-stack use the project at C:\Texas Instruments\ZStack-CC2530-2.5.0\Projects\zstack\ZNP\CC253x named znp.eww. To build you ZNP Mini Kit image have the compile option CC2530_MK enabled. I am attaching the hex file that I am working with currently (without security), build using the Testhex project in Z-Stack-2.5.0, Please try this and let me know if it works for you, thanks

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/158/6406.CC2530ZNP_2D00_MK_2D00_Pro.hex

Regards 

Suyash Jain

Hello Suyash

In answers to your questions:

1) The coordinator and routers 1 and 2 are about 1 metre off the floor, but routers 3 / 4 / 5 are on the floor (see diagram in original post).

2) I am aware of that bug but thank you for pointing it out.

3) I do not have one but I will look into this as your not the first person to suggest it.

4) Thanks for this information and build of ZStack, will try it when I arrive at work tomorrow and let you know how I get on.

Many Thanks

Richard

Suyash makes a very important point - concrete is an incredible RF black hole, most especially on those poor little PCB antennas!  Even just having a nice omni would help get away from that damper effect. Another customer made the same mistake but in the other direction by mounting directly to the concrete ceilings of a building - it "looks" like that would give great range, but the concrete sucks the life out of the low-power RF signal.

I've programmed the new firmware onto the CC2530 and can now communicate with it via SPI. Not given it a thorough test yet but a router with this firmware connects to my Zigbee network.

Placed the routers on the floor 1 metre off the ground and that appears to have improved things a bit.

Regarding messages being received several times. It it possible that when a router forwards a message to another, it never receives an ACK  (even though the message has been forwarded) and therefore sends it again? Suddenly there are two copies of the message in the network.

Regarding messages being reported as not being sent but have been. I'm requesting an ACK from the coordinator when sending. Is it possible that the ACK is failing to be sent back (lost)? Is it also possible that there is a timeout  when waiting for an ACK and its too small for my network?

Regarding messages that are not being received at all. From past experience I've found that wireless technology is a lot less reliable than wired. Obviously without seeing my network layout and surroundering you can't tell but I assume a given percentages of messages will fail to be sent, especially the further you are away from the coordinator?

Many thanks

Richard

Thanks for the suggestions, will try give them a try.

Silly question but is it possible that a 802.11 wireless network could cause interference?

Many thanks

Richard

Hello Richard,

Yes, ZigBee Operates in 2.4GHz ISM band and so does Wifi, and other 2.4GHz devices like microwaves, cordless phones, Bluetooth, etc which can act as potential sources of interference to the Zigbee's RF signal.

Regards,

Suyash Jain

If I place all 6 routers in the same room, close to the coordinator, I get no repeated messages or errors.

If I then move half the routers about 7metre still with direct line of sight, I sometimes get repeated messages from those routers.

I then did a test using my original setup. It seems the more routers that get added the more repeated messages I get. Even get repeated messages from the router closest the coordinator.

Not sure its of any interest but just wondering if the timestamp of the message gives a clue as to what might be going on?

Below is an example repeated message.

RX: 32 44 81 00 00 07 00 FD B2 D7 D7 00 2C 00 86 0D 06 00 00 21 41 58 49 4F 4D 41 54 49 43 43 30 30 31 32 34 42 30 30 30 31 31 46 36 41 32 43 3A 30 30 31 3A 39 43
RX: 32 44 81 00 00 07 00 FD B2 D7 D7 00 2C 00 97 0D 06 00 00 21 41 58 49 4F 4D 41 54 49 43 43 30 30 31 32 34 42 30 30 30 31 31 46 36 41 32 43 3A 30 30 31 3A 39 43

Thanks

Hello Richard,

It looks like the coordinator/a hop in between is not acknowledging the packet or acknowledgement is/are getting lost. Causing re-transmissions and multiple copies of a message reaching the coordinator. I will recommend you use sniffer to see what is happening over the air.

Regards,

Suyash Jain

Hi Suyash

I've purchased a CC2531 dongle which should arrive tomorrow. Are there any specific tests I should perform?

Thanks

Richard

Hello Richard,

I will recommend you start with small network, see if packets are reaching the coordinator and you can identify sniffer (I will recommend Ubiqua Sniffer) capturing the Data Requests from the Router and Acknowlegement from each hop and from the coordinator (getting familiar with Sniffer). After that, build up the big network where you start seeing the repeated messages reaching the coordinator, if you see that a particular node is causing re-transmission since it is not receiving acknowldegments, etc you can try to put a router node in between to introduce another hop or reduce the distance of this node from other routers.

Regards,

Suyash Jain

1220.resent data packet.psd

I've attached a TI SmartRF sniffer log that shows the messages being sent several times. Packets 2513 to 2518 appear to show the problem. The source address of the packets is 0x1357 which is the router in the same position as router 2 only to the left a bit more.

Regards

Richard

Not sure why this question has been marked as answered.

Hello Richard,

Looking at the Sniffer plot, I see that 0x1357 tries for the 1st time, and it fails to see MAC ACK from the next node, so it tries again and does bot recieve the MAC ACK (but the the next device did receive the message and sends MAC ACK).

So it (0x1357) should have stopped retrying, but since it has not recieved the MAC ACK  it tries again but there is again no MAC ACK from the next hop, it tries again and this time it recieves the MAC ACK. So it stops re-trying to send the message.

So, in the whole picture, the next hop sends back MAC ACK for two messages, and as can be seen these are two messages that get APS ACk from the coordinator.

Question I have are: were the devices stationary during this time, - trying to understand what is making 0x1357 miss the ack and the next hop miss the packets from 0x1357. How often do you see such behaviour, Have you tried reducing the distance between the 0x1357 and coordinator and see if this atill occurs.

Regards,

Suyash Jain

Hi Suyash

In answer to your questions.

Were the devices stationary during this time? - Yes

Have you tried reducing the distance between the 0x1357 and coordinator and see if this atill occurs? No, the device is only 2 metres away with direct line of sight.

How often do you see such behaviour? See below

The results below are based on a 6 router system:

Channel 11: Runtime 40 minutes, Packets received 1373, Duplicated 160 (11.6%)
Channel 11: Runtime 1 hour, Packets received 1640, Duplicated 306 (18.7%)
Channel 13: Runtime 1 hour, Packets received 1969, Duplicated 60 (3%)
Channel 13: Runtime 1 hour, Packets received 2193, Duplicated  2 (0.1%)
Channel 13: Runtime 45 minutes, Packets received 1657, Duplicated 60 (3.6%)
Channel 13: Runtime 1 hour, Packets received 2041, Duplicated  5 (0.24%)
Channel 15: Runtime 2.5 hours, Packets received 5447, Duplicated  70 (1.29%)

The more testing I do the more I believe it is infact down to RF interference. Not only do I seems to get more duplicated packets on certain channels I also go a more packets that fail to be sent.

At the moment the coordinator is set up so that it scans all channels and picks a suitable one based on the results. This normally picks channel 11 which also happens to be the same as our wireless network. Therefore I think I'm going to have to modify my coordinator so that the user can pick any channel they want to avoid problems with other networks.

Do you think the results for channels 13 and 15 are what you might consider normal / acceptable?

Regards

Richard

Hello Richard,

Ideally we would like no interference, but in presence of it retry mechanism in zigbee ensure that information is reliably transmitted (which is becoming the problem here!). I would say these numbers are acceptable but these numbers may still vary depending on the envoirmental conditions at a given time and if your final network deployment area changes. If you dont want repeated messages to pass through your application layer, you can try to add a check in your application using source device address and packet numbering to drop the duplicated packets.

Regards,

Suyash Jain