some problems about Z-stack

 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);
  }
}

 I am trying to learn more about z stack, I don't know why some of my devices got the same network address 0x796f, I am using simpleapp the same as you.

c an any body help me figure out the problem.

Hi LPRF_Rocks,

i think you had made a mistake on my problem. What you had discussed is about the SampleApp in Z-stack. But my question is about the SimpleAPP, which is an example that has collector and sensor nodes in it and the collector node could receive the temperature and voltage information from these sensor nodes. In this example, i found the function myApp_StartReporting() in SimpleSensor.c, and it is as follows:

void myApp_StartReporting( void )
{
  osal_start_timerEx( sapi_TaskID, MY_REPORT_TEMP_EVT, myTempReportPeriod );
  osal_start_timerEx( sapi_TaskID, MY_REPORT_BATT_EVT, myBatteryCheckPeriod );

  HalLedSet( HAL_LED_1, HAL_LED_MODE_ON );
}

this function is executed afer the sensor node binding with the collector node successfully, and this function just sets LED1 on in my opinion, but when i download it into CC2430, i find that LED1 blinks fastly after this function has been executed. So, can you tell me why?

Thanks for your help!

Hi there,

I am sorry for not being helpful.

I am working on the same sample which is simpleapp not sampleapp.

I am trying to utilize the sample in my own project.I am asking if have

faced aproblem like the different nodes(sensors) got the same network

address.

 Hi ahmad,

What version of Z-Stack are you using? Where do see the duplicated addresses? Are you using a packet sniffer? 

You have to End Devices with the same 0x796f; Right?

LPRF_Rocks

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.

Hi dasheng, you're right, if the IEEE ends up being the same, then when the device joins it will get the same short address. The devices should really be programmed with a specific IEEE address using the smartRF programmer to prevent any chance that it might end up with the same IEEE address. You could try using macMcuRandomByte() to make it a little more random.

I am having the similar problem of end devices being assigned same short address by the coordinator. Once I start the network, initially the nodes (end devices) will be assigned different short addresses starting from 0x796f. After  a while, the nodes are being assigned by the same short address.  I programmed end devices with different IEEE addresses.

I am using NV_RESTORE compile option.

I am using IEEE address programmer to program address.

I am using Packet Sniffer to see the packet source address.

Can some one enlighten me on this??

Thanks in advance....

--Adi

Same problem ... To solve it , we don't use NV_RESTORE compile option on Coordinator and nodes. But if the coordinator breaks down, we have a PAN_ID increment (even if we use NV_RESTORE, don't know why ...) 

To my understanding of the sample applications and their start up sequence a coordinator starts up (without NV_RESTORE) and sends out a beacon request to see whether a network already is present on that channel. If then a router or a coordinator answer by sending their beacon the coordinator see sthat there already is a network. So it will start one with a new PAN ID to avoid a conflict.

So if the parameter that determines which PAN ID it should use (parameter set in cfg file) is the same as the one that replied the coordinator simply increments it to avoid the conflict.

Did you try to use NV_INIT + NV_RESTORE? The NV_INIT determines to my knowledge that the coordinator at start up should not run a full initialization based on the network info (from the cfg file), but instead it should just come back as if it was never gone.

To my knowledge NV_RESTORE only stores the network info received after start up, while NV_INIT has an influence on the start up procedure.

-LL-

Hi double 0, I am trying to use macMcuRandomByte() as following in order to get more random IEEE address:

static ZSEG void zmain_ext_addr( void )
{

 ...

  // Plug AtoD data into lower bytes
  // AtoD = HalAdcRead (HAL_ADC_CHANNEL_7, HAL_ADC_RESOLUTION_10);
  AtoD = Onboard_rand ( );

  xad = (uint8*)&aExtendedAddress;
  *xad++ = LO_UINT16( AtoD );
  *xad = HI_UINT16( AtoD );

...

}

however it seems it doesnot work in debug mode:  Onboard_rand ( ) always return same value.

and in debug mode it is found AtoD even does not equal the value Onboard_rand ( ) should return. Could you give me a hand? Thanks!