• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 789 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.

CC2480 end-device poll callback

mlaibow
Prodigy 100 points


I have a quick question...

I am about to enable the end device polling of its parent for data. I currently only send periodic packets from the end device to whatever routers are one hop away and I would like to add the ability to send an occasional packet from the routers to the end devices.

My question is if it is possible instead of pre-arranging the packet in the router and waiting for the poll to arrive, if it is possible to create the packet immediately when the poll arrives.

The scenario is that I will have a long poll interval, 30 seconds or longer, and when the parent receives the poll, if it does not have a data packet, it might respond with a timestamp or other synchronization information that will have to be generated at the time of the poll being received.

I think this would require some kind of callback to the main processor. Does this exist for automatically enabled end-device polls? Or is the only way to do this with the end device's application generating its own polls using data request calls? If I have to use a data request to poll for data, is there a way to have the CC2480 remain awake to await a data packet from the parent following the ack of the data request? I know there is the RESPONSE_POLL_RATE parameter which sets the polling rate to a shorter value following a data request send. Does this work if the main polling is turned off?

Okay, not such a quick question after all, but I think what I am getting at is kind of straightforward. 

Let me try to answer my own question, and you can just say that what I am thinking is correct...

The end device poll can only receive packets pre-requested in the parent that have not yet timed out as set by INDIRECT_MSG_TIMEOUT. There is no call back to the application processor when a poll is received, except for maybe a SEND_DATA_CONFIRM if a packet was previously queued and was fetched with the poll.

Therefore, the only way to do what I want to do is with the following steps:

1) set POLL_RATE to anything but 0, this will allow the end device to receive any queued messages, this will also keep the end device rejoining and finding a new parent when it moves

2) set RESPONSE_POLL_RATE to something reasonable, like 10ms

3) have my end-device application periodically send data request packets to its parent to ask for time sensitive data

4) have my router application on the parent receive the incoming msg indication callback (the CC2480 should have already acked the packet, so that the end-device will start the 10ms counter). and within 10ms execute a send data request with the timestamp for that child node.

5) the end device automatically polls in 10ms and sends the indication to the application processor and then goes to sleep.

Is that the only way and a good way to do this?

Thanks, and I can probably share my code whenever I get this working.

-mat

  • 0
    Prodigy 100 points

    I have it working as I suggested to answer my own question.

    I also have it working using the AF/ZDO since I use LQI for a coarse location system, aided by the fact that the routers are permanently mounted and connected via wired ethernet.

    So at this point I have a few simpler questions...

    As far as I can tell, the automatic polling by the end device is a fairly useless way to send data from the parent to the end device. I think this because the parent device does not send the fact that it received a poll to the application code and as far as I can tell there is no way to query the CC2480 for a list of children. So the only way to know what short addresses you can send indirect data to, is to maintain a list of children in the application code, which will require the end device to send an actual data packet or an end device announce. So the question is, is the only real use of the automatic polling so that the end device can rejoin when it's communication is lost? And if I actually want data back, since the indirect messaging does not work with broadcast messages, the end device will have to ask for it in a way that actually gets pushed to the application code? This is also the only way that I can actually tell in my router's application code that there is a child?

    That is what I have working now, I periodically send an announcement which registers the child with my application and also asks for data. Which can also cause a rejoin, so, unless I am wrong, I have no need for the automatic polling.

    Do the software timers on the CC2480 cause it to remain out of sleep mode or have any effect on the power consumption of the device in end device mode? I would like to use them for my CC2480 related polling and timers, so that the code is even more platform-independent and does not rely on timers of the host processor. I would imagine this is not a problem since there must already be timers running to handle the polling.

    So to summarize the questions out of that long paragraph:

    Is there any way to query the list of children of the local CC2480 from the host application?

    Is there any real use of the automatic polling except in end-devices that only ever send data and can use the polling to check if their parent is still there?

    Is there anything I should know about the CC2480's software timers? They should wake-up the chip and send an SRDY when they expire. The SRDY can wake-up my processor which can query it and then execute CC2480 commands accordingly.

    Thanks.

    -mat

     

  • 0 in reply to mlaibow
    Prodigy 100 points

    I will try it in the next couple of days, but I think I can query the list of children by executing either the ZDO_NWK_ADDR_REQ or the ZDO_IEEE_ADDR_REQ using Extended for the ReqType and using the local address. In this mode, these requests should return a list of associated devices along with the request address.

    I am assuming that the CC2480 will not broadcast this request if it's own address is the one being searched for.

    I will post my results.