原创 some problems about Z-stack

2009-4-23 12:10 3543 8 8 分类: 工程师职场


 

some problems about Z-stack






Hi, i am learning the SimpleApp, one of the examples from Z-stack, but i encountered some problems. i could understand how the messages flow on a device, but the LEDs on CC2430DB confuse me. i don't why they blinks, and which part of program controls them! In the sensor data collection application, i could see that afer joining the network successfully LED2(red) will blink fastly, and after binding with the coordinator LED1(Green) will blink fastly. but the source code in file simpleSensor.c only showes that function myApp_StartReporting() will set LED1 on after binding. why dose it blink quickly? could anybody give me a reason?  or please tell me how to find the program which controls the LEDs blinking if you can! thanks a lot!


 



 Hi Dasheng,


An excellent way of understadning Z-Stack sample application would be to monitor the packet exchange between nodes using our packet sniffer.  The toggle is due to the SAPI_ReceiveDataIndication which is called everytime you receive a message,  AF_INCOMING_MSG_CMD in the ProcessEvent loop of SAPI. This function calls again the  zb_ReceiveDataIndication(..) and in here if you receive the toggle message cluster you will toggle the LED. 


void zb_ReceiveDataIndication( uint16 source, uint16 command, uint16 len, uint8 *pData  )
{
  if (command == TOGGLE_LIGHT_CMD_ID)
  {
    // Received application command to toggle the LED
    HalLedSet(HAL_LED_1, HAL_LED_MODE_TOGGLE);
  }
}



 

 

 



Hi LPRF_Rocks,


My former problem has been resolved. I found that there is a denfination of POWER_SAVING in IAR's compile option so that LED1 will be blinking instead of always on. There is a explination in document " Simple API for Z-Stack " for this phenomena. If I delete POWER_SAVING then LED1 will be turned on and always be on after the sensor node has binded with collector node successfully. 


///////////////////////////////////////////////////////////////////////


But now i encounter another problem which is the same problem that ahmad  had already asked. when i use the collector node to collect information from five sensor nodes,  i find that two sensor nodes are assigned with the same short network address, which may be 0x7972, 0x7970, or 0x796f. the same problem will appear even if i only use four sensor nodes. i found this problem from the HyperTerminal on my PC which can receive the informtion sent by collector through serial port. when I use a CC2430DB as packet sniffer to watch the data pakets over the air, i found that some  sensor nodes were really assigned with identical short address. My Z-stack version is ZStack-1.4.3-1.2.1, and my hardware platform is CC2430ZDK. So can you give me some adveices on how to resolve this problem? thanks a lot!  


 

 

 



Hi ahmad,


 I suddendly know the reason of our problem when i try to check the IEEE address of each sensor node. I encountered  the same problem as yours in this morning,  and i was confused too. But just now i suspect that the reason may be  their IEEE addresses are identical, so i use SmartRF Flash Programmer to check each node's IEEE address, and i found that i am right. Two nodes' IEEE address were both 27 26 25 24 23 22 00 00, so when they join the network they will get the same short address. And this IEEE address is assigned by function zmain_ext_addr(), which use the following sentence to get a random number and assign this random number to the lower two bytes of the IEEE address.


AtoD = HalAdcRead (HAL_ADC_CHANNEL_7, HAL_ADC_RESOLUTION_10);


Unfortunately, the randomness of upper function is limited. So sometimes two or more nodes will get the same IEEE address. if you give each node a different IEEE address by SmartRF Flash Programmer or some other tools, then the problem will not appear again.


/////////////////////////////////////////////////////////////////



Copy from TI E2E Community.


question:


 My problem is that in the system we are building, there will be typically one coordinator, and one end device.


If multiple of these systems are deployed in the same area, and the end device is powered down and back up, it needs to remember which coordinator it was last connected to, and reconnect to that one. Its not possible to run it all under one coordinator, as the coordinators are not owned by the same user.


Currently, as far as I can tell, the PANID is ignored by the end device – it will connect to a coordinator that is configured to a different PAN id as itself.


The end device needs to get a list of coordinators available, and then select the appropriate one.


Also, the coordinator should ideally be able to check to see if the PANID it would use is in use, and pick a different one if it is.


answer:


If you have a device join a network and you would like that device to be able to sleep or be turned off, come back up and remain a member of the same network (not go through the discovery and joining process again) then you can use the NV_RESTORE feature which saves the state of the device to Non-Volatile memory and refreshes the status of the device on the network when it is powered back up.  Please check the developer's guide for more information on NV_RESTORE.



第一个关于LED的问题

第二个关于网络地址重复的问题

第三个讲了在退出网络后,如何重新加入原先的网络。

我自己看了后的一些理解,英文比较差,仅供参考!

 
PARTNER CONTENT

文章评论0条评论)

登录后参与讨论
我要评论
0
8
关闭 站长推荐上一条 /3 下一条