• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 2220 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sending messages from a end device...

Claudio_10
Prodigy 200 points
Other Parts Discussed in Thread: Z-STACK

Hello everyone,

i made an application in which when a specific event occours two different routers send a message to a end device, and the end device replies to them in 1-hop mode, since i want the message to be sent directly from the end device to the routers, because i want to use its RSSI. This application works, and using a sniffer i can see that the requests from the routers are routed correctly and arrive to the end device through his parent, and the reply of the end device does a direct path from him to the routers, without being routed. 

The question is: how is this even possible? From what i understood, a end device can communicate only with his parent both in transmission and in reception, as for example is stated here

http://e2e.ti.com/support/low_power_rf/f/158/t/220798.aspx

so my guess is:

- what stated above is not true and a end device has to rely on his parent only for the reception of the messages, not for the transmission

- the end device changes his parent multiple times in a "transparent" way (i don't see any message on the sniffer apart from the ones i expect), communicates with them and then goes back to his original parent (in this case the coordinator)

does anybody know the answer?

thanks and regard

Claudio

  • 0
    TI__Genius 16570 points

    Hi Claudio,

    as mentioned in Chapter 5.2 of Z-stack developer's guide, end devices use their parent to send the data to and to receive the data from for any node in the network.

    End devices can change parent but they don't do this 'silently' (ie you should see some activity in the sniffer like orphan notification)

    Are you sure you are not sending a broadcast message?

    Please attach the sniffer log and provide information of which TI ZigBee SW product you are using.

    Thanks,

    TheDarkSide

  • 0 in reply to TheDarkSide
    Prodigy 200 points

    Hi TheDarkSide, thank you for your answer.

    I'm using IAR 8051 8.10 to program the devices, and the 2007 ZigBee Pro Z-stack

    I'm sure i'm not sending a broadcast message, here's the code i use for the message from my end device to the router:

    buff = (uint8*) osal_mem_alloc (1);
    *buff = MY_COMMAND;
    afAddrType_t dstAddr;
    dstAddr.addrMode = (afAddrMode_t)Addr16Bit;
    dstAddr.addr.shortAddr = pkt->srcAddr.addr.shortAddr; ;
    dstAddr.endPoint = MY_ENDPOINT;
    AF_DataRequest( &dstAddr, &my_descriptor, MY_CLUSTERID, 1, buff,&ZCube_TransID,AF_SKIP_ROUTING, 1); //sending the 1-hop message
    HalLedBlink (HAL_LED_1, 3, 50, 200);
    osal_mem_free(buff);

    this is placed in the function that handles the AF_INCOMING_MSG_CMD event, so the address i'm sending the 1-hop message to is the address of the device who just sent me a message (one of the two routers).

    i tried to attach the sniffer log but it's oversized (over 30MB) and besides that i'm not sure it's understandable since i'm not using the TI sniffer but Wireshark, because i'm using the home automation profile and the TI sniffer doesn't decrypt the data...so i attached a picture of the part of my interest, since it's more immediate to understand. Anyway if you need the log i will try to send it.

    In the picture the messages signed with a red cross are not important to this case because they are messages that the two routers send to each other. The two routers are 928c and 7c2b, while the end device is 377a. 928c is also the parent of the end device. As you can see, on message 56419, 928c routes the request of 7c2b to the end device. Then in the next message, the one highlited in blue, the end device replies directly to 7c2b. Then on message 56429, 928c sends his own request to the end device, and the end device replies to him. In all this process, 928c remains the parent of the end device, because the Data Request are always directed to him.

    So to me it really looks like the end device replies directly to both routers. Another proof of that is that if i cover the antenna of the end device, i see the RSSI decreasing on the reception of both routers: if the message was routed from the parent to the other router, i wouldn't see the RSSI decreasing.

    I also used the sniffer Ubiqua by Ubilogix, and the results are the same.

    Thanks.

    Claudio

  • 0 in reply to Claudio_10
    TI__Expert 5255 points

    Have a look at the description for AF_DataRequest() in the Z-Stack API.pdf document (section 3.2.1.2). Your code is specifying AF_SKIP_ROUTING in the options parameter: "Setting this option will cause the device to skip routing and try to send the message directly (not multihop). End devices will not send the message to its parent first..."

  • 0 in reply to xyzzy
    Prodigy 200 points

    thank you xyzzy, this solves the problem :)

    i guess this only works in transmission, right? I mean, i can't directly send a message to a end device even setting the AF_SKIP_ROUTING, i still have to pass through his parent...or can i?

  • 0 in reply to Claudio_10
    TI__Genius 16570 points

    An end device would typically sleep and only opens the receiver only after the parent did notify him that there's data available. 

    Therefore reception of data for sleepy end devices happens 'in sync' with parents sending data and it is unlikely other nodes would be able to send data exactly at the same time in an un-synchronized system like ZigBee.

    In theory, nothing prevents ZigBee end devices to receive data directly from other nodes but as mentions this would have to happen in sync with the moment where an end device has the receiver window opened.

    Though there are implementations of non sleeping end devices (with receiver always on), these are a-typical as nodes that are battery powered are built as sleeping end devices to save battery.

    Thanks,

    TheDarkSide

  • 0 in reply to TheDarkSide
    Prodigy 200 points

    just as i thought.

    thank you.

    Claudio