• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 562 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.

LPSTK-CC1352R: Adjusting example code to continuously send dummy data

Dylan OBrien
Prodigy 10 points
Part Number: LPSTK-CC1352R

Hello,

I am currently trying to adjust some of your example code that I've found on the resource explorer and in the SLA. In the SLA, the Zigbee project I've been using is "Zigbee fundamental project development". I have completed the tutorial (without the packet sniffer), and have realized that I am unable to verify that the raw data packet is actually sending without the sniffer.

I am wondering how I can change the code to display the message, or something similar, so that I can see that the raw data packet has actually been transmitted to the other device. It doesn't necessarily have to do this but that was my first thought on verification. At this time I am unable to set up the sniffer device for this project.

I am also trying to adjust the example code so that when I press the second button, the raw data packets are transmitted repeatedly. I figured I could put the code provided in the example into a while loop (which I assume will have to wait on some "ready to send" flag), but would appreciate confirmation on this/ guidance on how to do it properly.

Thank you for the help

  • +1
    TI__Guru**** 217727 points

    Hello Dylan,

    Here is a quick link to the Zigbee Fundamental Project Development SLA for easy reference.  The End-to-End Acknowledgements section of the Z-Stack User's Guide provides instructions for receiving zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND which would determine the status of the message sent over-the-air.  You can also modify the Common User Interface to display message updates through the UART terminal.  It is not advised to continuously send raw packets in a while loop without any formal delay, as this will likely fill the buffer faster than the messages can be sent out using the 250 kbps PHY, will congest network traffic, and trap the application from completing other tasks.  I recommend adding another UtilTimer_construct to the zcl*_initializeClocks API which sets up a periodic raw data packet transmission which begins when UtilTimer_start is called during processing of the second button press.  Another option is to receive zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND of the previous packet before sending the next one.

    Regards,
    Ryan

  • 0
    Prodigy 10 points

    Hi Ryan,

    Thanks for the response. I've followed your instructions and have been able to get that count working. I've noticed that the count, at least as I've implemented it, does not go up by 1 each time I press the button to turn the light on/off. What exactly does the APS_Count value represent? 

  • 0 in reply to Dylan OBrien
    TI__Guru**** 217727 points

    Hi Dylan,

    There may be old information in the User's Guide, in which case APS_Counter has been replaced with zcl_TransID as used in zcl.c during calls to AF_DataRequest or zcl_AF_DataRequest from zcl_SendCommandEx.  It represents the APS Counter in the APS header in Zigbee packets.

    Regards,
    Ryan