I had to abandon the project for a while but recently I found time to dig a bit into the issue. Even without the sniffer I was able to track down the reason. However I still need your help.
My system uses the following algorithm. Coordinator and routers share the same network identificators that are stored in the EEPROM (CS_UID_ID, CS_EXT_PANID_ID, CS_NWK_PREDEFINED_PANID_ID, CS_NWK_PANID_ID, CS_CHANNEL_MASK_ID). I debugged the whole system and double checked that the values are identical on both sides. However in this case the router gets NWK_NOT_PERMITTED_STATUS. The issue is in CS_EXT_PANID_ID parameter. If I set this to 0 the router joins the network without problems. However this means that the router will join any available network which I don't want. Can you help me with a workaround?
Thanks in advance,
Without seeing sniffer logs it is hard to tell why device can't join the network.
NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.
I do not have a sniffer so I cannot provide the log. :-( I found all this while debugging with JtagICEmkII cable. However with older version of BitCloud things worked fine. This occured with the latest version of BitCloud. perhaps it is due to something in the configuration.h file but all the changes I made did not do any change. But I might have overlooked something.
You say that CS_UID is the same on all devices? This is clearly wrong.
It is weird but it is really like this. the same code works with older libraries of BitCloud. Also if I set the parameter to a fixed value on both coordinator and router I get NWK_NOT_PERMITTED_STATUS. Only when i set the value to 0 on router's side it works. The strange thing is that I apply the same principle with the remaining parameters and it does not cause any errors.
My zigbee network use ATZB-24-A2. It happened few times that I lost serialNet function. I have to
re-download SerialNet_RF230_Security through Jtag and re-setup the network.It may caused by ATmega1281 NVM Corruption or not ? Have ever seen this problem before?
No, I've never seen this before, but I've heard reports of this happening. From my point of view, the only reason for this to happen is problems with power supply or exceeding recommended operating conditions.
Next time this happens, before reprogramming the module, read its contents first to see if it is completely clean or there is something left.
I have new question to ask. I am using 1 coordinator (obviously) and few routers. I have implemented an aÅ¯gorithm in case router losts signal and has to rejoin. Here are the few steps to perform.
1. Router pings coodrinator every 30 secs.
2a. If the packet is delivered no action is performed.
2b. In case it is not delivered it unregisters all endpoints, changes state to APP_NETWORK_JOINING_STATE and waits for signal to rejoin the network.
3. Rejoins th network.
The problem is that when this happens the router gets ZDO_INVALID_REQUEST_STATUS from the coordinator. I have no idea why. Maybe I am unregistering the endpoints improperly. Here is the responsible piece of code.
unregEndpoint.endpoint = endpointParams[i].simpleDescriptor->endpoint;
appDataTransmissionState = APP_DATA_TRANSMISSION_READY_STATE;
appState = APP_NETWORK_JOINING_STATE;
You need to leave a network first. Search WSNDemo source code for "MGMT_LEAVE_CLID" to see how it is done.
Thanks a lot. Will look it up tomorrow. It is already late in Europe now and I need my deserved time off. :-)
Hi again. I am not sure whether I described the issue properly so let me try again.
I do not think the solution you described fits the situation. I assume I have to do the leaving procedure in case the router decides to leave working network. But I am solving a different case. I am trying to get the router to rejoin the network after it lost it for some reason. For example after coordinator was turned off (this is in fact how I am testing it; I turn off coordinator then turn it on after a while and wait what happens). In WSNDemo this would mean ZDO_NETWORK_LOST_STATUS but I do not see the way how to treat this other then I am trying. I unregister endpoints then get to APP_NETWORK_JOINING_STATE and I think this should do it. In the main handler under
I simply do
networkParams.ZDO_StartNetworkConf = ZDO_StartNetworkConf;
and I think that should do this. But I am getting the afforementioned ZDO_INVALID_REQUEST_STATUS which baffles me.
Thanks for your answers.
Router never "looses" a network. The fact that missing coordinator is a bad thing in your application does not mean that it will be a bad thing for another application. Router can still communicate to other nodes and route data, so it is on the network. That's why you need to leave first.
So I have to do the leave procedure even though the coordinator is off and will not recieve the request?
Yes, because internally stack thinks it is in the network, plus other devices in the network will receive this request and update their tables accordingly.
I am having issues with USART1 when using the stack functions (BitCloud_ZIGBIT_1_12_0). I was debugging it and the recieved characters are different from those I am sending from my PC. This happens with both SYNC and ASYNC modes. Is there a way I can write my own ISR routine? With the precompiled libraries the linker crashes with an error since I am trying to predefine already compiled function.
Yes, it is possible, but you will have to disable UART code in the HAL and recompile it.
On the other hand, it might be easier to debug why you are not receiving correct characters, since chances are, you won't receive them with the custom code as well.
Also, you don't need ISRs to test that communication works.
I am back with a new issue. This time it probably involves routing. I have an application consisting of coordinator and 10-14 routers. They are distributed in a room of about 40 square meters. The longest distance between router and coordinator is approx. 10 meters. All of the routers should be connected to coordinator directly, i.e. with no intermediate hops. I assume this because I set the value CS_MAX_CHILDREN_ROUTER_AMOUNT to zero for routers. However I am facing some routing issues. The main being the fact that when I am sending an unicast packet from coordinator to router some routers cannot be reached. However I can reach them via broadcast. I assume I have some values set wrong in configuration.h files for both coordinator and router (routing tables size and similar). Can you have a look at those for me please?
I'd start from increasing CS_NEIB_TABLE_SIZE and CS_ROUTE_TABLE_SIZE to be at least equal to the actual number of nodes connected.
Your archive appears to be broken and I can't extract Router configuration.
Sorry about that. I attached it once again. This time in ZIP format.
I have one more question in addittion to the configuration.h values.
Where are the CS values defined in configuration.h actually stored? Are they in EEPROM? I am asking because I store in EEPROM values that define the network (IDs etc.) I.e. if I do changes to firmware I can simply upload the new version to coordinator's FLASH and then rewrite the EEPROM with the original content. This way I do not have to set up the network again. After firmware update I can use the old network that has been already ste up. However if CS values are stored in EEPROM then I need to do network setup again.
Stuff defined in configuration.h is just static constants, they are stored in flash and memory is initialized from them at start up.
That is great. Makes things much simpler. I will test it on Wednesday. Thanks a lot. And thanks in advance for examining the configuration.h files.
Files look fine. Start from increasing CS_NEIB_TABLE_SIZE and CS_ROUTE_TABLE_SIZE to be at least equal to the actual number of nodes connected.
Great. I suspected these 2 as well. I was only wandering whether there are some others I overlooked. Thanks again.
So this thread is 49 pages long...Is it worth reading cover to cover? All I want to do is get Blink to blink the LEDs on my STK600/Atmega128RFA1-EK board. Am I looking in the right place?
If you've tried to compile and it does not work, then it is probably a good idea to read at least few last pages. If you have not, then try and see if it works first.
Thanks for the reply Alex. I've created a new topic so as to not confuse this one:
I have compiled, loaded and run it with dismal results so far. Your assistance would be appreciated. I will read this topic fully to make sure I haven't done something stupid.
Hi Alex. I have one application where I need to use broadcasting. Again it involves light intensity control. The thing I am experiencing is that broadcast seems to be significantly slower than unicast. In other words when I slide up the slider to increase the intensity and transmit the data on unicast the fixture increases the light smoothly. When this is done on broadcast then you can see flickering when increasing the intensity. Is there a way to influence this? Thanks for the answer.
There is a random delay applied to broadcast messages. The easiest way to remove this delay is to change two instances of "(rand() & NWK_TX_DELAY_JITTER_MASK) + 1" to "0" in nwkTx.c. Try and see if this helps.
Did not help. nwkTx.c is not included in the stack. Only the header file. Looks like it comes compiled in some library. Any other tips?
I've got confused. My advice was for Lightweight Mesh. There is nothing you can do about this in BitCloud.
That is quite disappointing. The brightness adjustment on broadcast does not look nice with those flickers. I am just thinking, would it be possible for you to recompile the necessary file with the changes you mentioned and send me the lib? I am using BitCloud_ZIGBIT_1_12_0.
Absolutely not. Unless you go through an official channel and they confirm your request. This is not likely to happen.
On the other hand, do you have a way to measure and describe exactly what is going on? May be a video of how it looks like? I've seen some commercial lamps using ZigBee, and yes, there is some delay, but I would not say it is that bad. But some people are more sensitive to this kind of stuff.
Hi Alex, after a while. I was engaged in another project for some time and put the ZigBee stuff aside for a while. Let me explain what is happening. The network setup is a coordinator which is in fact a capacitive slider that controls the light intensity and a number of lights set as routers. I do not want to go into details now but the whole concept requires the communication to be done in broadcast. Now the thing is that in case of unicast if one slides on the slider to change the light intensity the transition is smooth. However in case of broadcast the intensity change happens in steps. This is probably due to the random delay when the broadcast packets are sent from coordinator. It just degrades the product. When I show it on exhibitions people like the concept but not the visual feeling when the look at the lamps changing the intensity. Some of them say that it is ugly. I could not find a way of eliminating this when using broadcast. Any idea would be appreciated.
Use a different stack, for example.
ZigBee is not meant for real-time data. Network layer is just not set up for that.
Also, each broadcast frame in ZigBee is sent 3 times with delays between the attempts, which makes entire process even longer.
© 2021 Microchip Technology Inc.