Can't compile samples from BitCloud (ZigBee) with WinAVR

Go To Last Post
986 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex,

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,
Radovan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You say that CS_UID is the same on all devices? This is clearly wrong.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alexru,
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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ALex,

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.

for (i=0;i unregEndpoint.endpoint = endpointParams[i].simpleDescriptor->endpoint;
APS_UnregisterEndpointReq(&unregEndpoint);
}
appDataTransmissionState = APP_DATA_TRANSMISSION_READY_STATE;
appState = APP_NETWORK_JOINING_STATE;
SYS_PostTask(APL_TASK_ID);
return;

Any clues?

Best regards,
Radovan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to leave a network first. Search WSNDemo source code for "MGMT_LEAVE_CLID" to see how it is done.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot. Will look it up tomorrow. It is already late in Europe now and I need my deserved time off. :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

case: APP_NETWORK_JOINING_STATE

I simply do

networkParams.ZDO_StartNetworkConf = ZDO_StartNetworkConf;
ZDO_StartNetworkReq(&networkParams);

and I think that should do this. But I am getting the afforementioned ZDO_INVALID_REQUEST_STATUS which baffles me.
Any clues?

Thanks for your answers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I have to do the leave procedure even though the coordinator is off and will not recieve the request?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again,

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry about that. I attached it once again. This time in ZIP format.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stuff defined in configuration.h is just static constants, they are stored in flash and memory is initialized from them at start up.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great. I suspected these 2 as well. I was only wandering whether there are some others I overlooked. Thanks again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply Alex. I've created a new topic so as to not confuse this one:

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=130163

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Regards,
Radovan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've got confused. My advice was for Lightweight Mesh. There is nothing you can do about this in BitCloud.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Regards,
Radovan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Pages