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.

CCS/CC1352R: Is the data transmission from the coprocessor-> asynchronous? What's the use of POLL in the context of sensor?

Part Number: CC1352R

Tool/software: Code Composer Studio

Hello,

I'm using:

- cc1352.

- sdk 3.10.01.11.

- sensor example project (as base for modifications).

- coprocessor project

I have 2 questions:

    1) Is the data transmission from the [coprocessor -> sensor] asynchronous (no need for poll from the sensor)?

    2 ) What's the use of POLL in the context of sensor?

The reason why I'm asking this questions is because from one experiment I did, I could infer that I can send data ASYNCHRONOUSLY from the coprocessor to sensor without having to wait the poll in the sensor.

The experiment was as follows:

- setup:

    * I changed the behavior of the sensor and the coprocessor so a specific config sent from the coprocessor will change the payload of the data sent by the sensor whenever it receives a specific byte in the config (the sensor is sending 300 bytes with with 0x0 as data each 100 ms. It will change its payload to 0x55).


    * CONFIG_POLLING_INTERVAL was set to 1000 (ms), CONFIG_REPORTING_INTERVAL was set to 100 (ms), NON_BEACON_MODE was selected (no frequency hoping).

- Results:
    * After having the coprocessor sending the config data, the sensor received and changed it's payload after aprox 200 ms.

  • Hi,

    As long as the sensor is a sleepy device (CONFIG_RX_ON_IDLE == false), its parent will hold messages for the sensor until the sensor requests this data.

    I believe CONFIG_POLLING_INTERVAL determines the maximum period between Data Requests sent by the sensor.

    It's likely that the smaller of CONFIG_REPORTING_INTERVAL and CONFIG_POLLING_INTERVAL determines how quickly a pending message passes from coprocessor to the sensor (due to the frame pending bit in the ACKs the coprocessor sends after it receives a report).

    Try setting CONFIG_REPORTING_INTERVAL to 1000 and CONFIG_POLLING_INTERVAL to 6000, and verify whether it takes longer than 200 ms before the sensor starts reporting 0x55 data. 
    I expect this to take around 1000-2000 ms (eg 1-2 x CONFIG_REPORTING_INTERVAL ).

    If you'd like, you can also check how quickly your sensor's payload changes when it's non-sleepy (CONFIG_RX_ON_IDLE == true).
    I expect this to be more quickly than 200 ms after the coprocessor sends your config command.

    Regards,
    Toby

  • Thank you , It was really useful your insights!