• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 55 subscribers
  • Views 1273 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.

CC2530: Problem with AF_DATA_REQUEST from coordinator to endpoints

Tomas Varela
Intellectual 575 points

Part Number: CC2530
Other Parts Discussed in Thread: CC2531

Hello, I am developing an application that communicates from a host to a CC2530 through UART. I configure it as a coordinator to receive data from security sensors (magnetic door sensor, movement sensor, etc.).

My configuration routine is:

  1. Reset
  2. Configure start up options
  3. Configure as Coordinator
  4. Start Up (until is coordinator)U
AF_REGISTER: (FE 2401 01 0401 0001 00 00 02 0000 0600 02 0000 0600 Checksum)
  1. EP: 01
  2. AppProfId: 0x0104
  3. AppDeviceID: 0x0100
  4. AppDevVer: 00
  5. LatencyReq: 00
  6. InClusterNum: 02
  7. ClusterIN: 0x0000, 0x0006
  8. OutClusterNum: 02
  9. ClusterOUT: 0x0000, 0x0006
  • Permit Join

By doing this, I am able to receive de AF_INCOMING_MSG from the sensors as they sense some change. I also receive their check-in message with 1 hour period. However, because of my application I need to be able to request their state manually. I understand that I can achieve this with the command AF_DATA_REQUEST but I do not find information of what the Data field should be fill with.

Example of the AF_INCOMING_MSG that I receive when a sensor changes its state:

FE 18 44 81 00 00 06 00 1C 7F 01 01 00 A2 00 50 CB 00 00 00 07 18 2B 0A 00 00 10 00 AF 

Being:

ClusterID: 0x0006

Short address: 0x7F1C

Src Ep: 01

Dst Ep: 01

Data: 18 2B 0A 00 00 10 00

I want to be able to trigger this message anytime I want. My current AF_DATA_REQUEST msg is: FE 0F 24 01 1C 7F 01 01 06 00 00 10 0F 05 00 02 00 00 00 57

Meaning I am sending:

  1. DstAddr: 0x7F1C
  2. DstEP: 01
  3. SrcEP: 01
  4. ClusterID: 0x0006
  5. TransID: 00
  6. Options: 0x10 (with ACK)
  7. Radius: 0x0F
  8. Len: 05
  9. Data: 00 02 00 00 00 (do not know what this means??)

But I get these msgs with error: 

ZNM-->PC:
FE 01 64 01 00 64
ZNM-->PC:
FE 03 44 80 F0 01 00 36

Moreover, I cannot access the codes because I need to use both default firmwares (coordinator and endpoints).

Could anybody guide me in how to build the AF_DATA_REQUEST msg in order to retrieve information from my sensors? Thank you very much!

  • 0
    TI__Guru**** 223087 points

    If you want to read the status of an on/off light then you would send a On/Off Read Attribute command.  It appears that you did this given the data structure {Frame Control, Transaction Sequence Number, General Command Frame, Attribute ID 1, Attribute ID 2} 

    FE 01 64 01 00 64 is a AF_DATA_REQUEST success response, meaning the message is valid to be sent over-the-air.
    FE 03 44 80 F0 01 00 36 is a AF_DATA_CONFIRM failure response with reason ZMacTransactionExpired.

    It doesn't appear that your sensor is actively awake and ready to receive the message.  If they are sleepy ZEDs then the ZC's read attribute command will time out after NWK_INDIRECT_MSG_TIMEOUT seconds of not responding a data request/poll from the ZED.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 575 points

    Thank you for answering. I have just added a sniffer to the network (CC2531) so I will keep trying.

    However, I would like to know where did you get this structure "{Frame Control, Transaction Sequence Number, General Command Frame, Attribute ID 1, Attribute ID 2} "? Is that ZCL right? so every sensor should be compliant with this?

    "It doesn't appear that your sensor is actively awake and ready to receive the message." this is probably true because I have just seen that one of my sensors answered me when he joined the network but then it just stopped answering and would just send its check-in messages.

    But doesn't ZigBee have a poll control (long poll, short poll, etc.) to avoid these situations? (with some seconds of delay of course). And anyway coud I be able to change polling time of the sensors sending them some "Write attributes" command maybe?

    Thanks!

  • 0 in reply to Tomas Varela
    TI__Guru**** 223087 points

    Yes, that is ZCL read attribute command structure from the ZC, I recommend you review the ZCL Spec for more information.

    ZEDs have a POLL_RATE and optional poll control cluster but this would require modification of device firmware: http://dev.ti.com/tirex/explore/node?node=AECfF3L5Mxn7z1WGqXZjYQ__pTTHBmu__LATEST

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 575 points

    Thanks, sad to know that it can only be change from firmware. However, I still do not understand something.

    First, as soon as the sensor joins the network, it answers my DATA REQUEST command and I imagaine that it is because it has a short poll time at the beginning.

    Then, if I write to the sensor at any time, it does not answer me and I understand that it may be because it is asleep and its polling time is too long.

    However, if I send the DATA REQUEST command an instant after or even before making a movement in front of the sensor (which means it sends me a Report Attributes command informing this movement), it does not work either. Shouldn't the coordinator make use of this asynchronous communication from the sensor to send that pending DATA REQUEST message to it?

    Thanks!

  • 0 in reply to Tomas Varela
    TI__Guru**** 223087 points

    You need to sniff the over-the-air communication and figure out if any data requests are sent from the ZED after the Report Attributes command.  It may help if this command requires a default response.  Provide a sniffer log if you continue to encounter difficulty.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 575 points

    When the sensor joins the network, the log looks like this:

    And you can even see my "Read Attributes" and the "Read Attributes Response". However I do not understand what is for the "Data Request" from the sensor at this point?

    Later, when the sensor is not answering my Read Attributes commands anymore (they do not even get to the air because my coordinator doesn't send them) the sniffer looks like this:

    Those Report Attributes are because I moved in front of the sensor. There is no sign of any data request here, not even from me or the sensor.

    Thanks for any further guide.

    Regards!

  • 0 in reply to Tomas Varela
    TI__Guru**** 223087 points

    During joining the ZED could be sending Data Requests until the F&B/permit join time expires or it is sure that commissioning has been completed.

    You will notice that before/after sending the Report Attributes, the ZED does not send any data requests to ask for information queued by the ZC.  This is something that should be modified by your ZED's application.

    Attaching a copy of the sniffer log file is more useful than screenshots.

    Regards,
    Ryan