QDEC SAMPLEPER and REPORTPER relationship

[Keith Richeson]

Does anyone have additional information on the relationship between SAMPLEPER and REPORTPER in the nRF QDEC?

I understand that the SAMPLEPER sets the base sample period such that the QDEC will sample the inputs every SAMPLEPER time. Will this also generate the SAMPLERDY event every sample period, or only if there was a change in the inputs?

I see the REPORTPER register is used to set the number of samples to be accumulated before the REPORTRDY event is generated. However, the REPORTRDY event is only generated if the accumulator value is not 0. My question is, if the accumulator is 0 after REPORTPER samples, does the sample count get reset such that another REPORTPER samples must be taken before REPORTRDY gets generated? Or will the next sample that changes the accumulator trigger the REPORTRDY event?

For example, assume we're using REPORTPER = 10 samples/report and starting with a cleared accumulator (ACC = 0). After 10 samples, no motion has been detected, the accumulator is still 0, so the REPORTRDY event is not generated. Now assume sample 12 detects "forward" motion and increments the accumulator (ACC = 1). Is the REPORTRDY event generated immediately after sample 12, or does the REPORTRDY event not get generated until sample 20?

Thanks in advance for everyone's help with these questions.

[Håkon Alseth]

Hi,

First of all, I am very sorry for the late answer. I had some time to look at the QDEC, and tried to answer your questions. If there is anything that I have misunderstood or gotten wrong, please correct me :)

I understand that the SAMPLEPER sets the base sample period such that the QDEC will sample the inputs every SAMPLEPER time. Will this also generate the SAMPLERDY event every sample period, or only if there was a change in the inputs?

“SAMPLERDY” will fire every time there is a new sample, even if there is no change. Meaning, you will get this event every “value of NRF_QDEC->SAMPLEPER”. I verified this by toggling a GPIO in the event. In my case, it toggled every 128us (SAMPLEPER value I set).

I see the REPORTPER register is used to set the number of samples to be accumulated before the REPORTRDY event is generated. However, the REPORTRDY event is only generated if the accumulator value is not 0. My question is, if the accumulator is 0 after REPORTPER samples, does the sample count get reset such that another REPORTPER samples must be taken before REPORTRDY gets generated? Or will the next sample that changes the accumulator trigger the REPORTRDY event?

The REPORTPER is, as you say, used to set the number of samples. A period is then REPORTPER * SAMPLEPER. The event REPORTRDY is generated if accumulator value has changed since last REPORTPER*SAMPLEPER. If you do not clear the accumulator (NRF_QDEC->TASKS_READCLRACC), you can get into conditions where this will then report 0 (as the last value of acc != 0).

For example, assume we're using REPORTPER = 10 samples/report and starting with a cleared accumulator (ACC = 0). After 10 samples, no motion has been detected, the accumulator is still 0, so the REPORTRDY event is not generated. Now assume sample 12 detects "forward" motion and increments the accumulator (ACC = 1). Is the REPORTRDY event generated immediately after sample 12, or does the REPORTRDY event not get generated until sample 20?

I checked this with an oscilloscope, and it will only generate event after 10*SAMPLEPER in your case.

Best regards Håkon

[Keith Richeson]

Håkon,

Thank you for your reply. My follow up question is related specifically to the last example. As I noted, in this case after 10SAMPLEPER, no motion has been detected so the REPORTRDY event does not get generated. So then my question is, once motion is detected on sample 12, does the REPORTRDY event get generated immediately (at 12SAMPLEPER) or does it not get generated until 20SAMPLEPER (the next multiple of REPORTPERSAMPLEPER)?

Would it be possible for you to show the oscilloscope data you used to verify this behavior?

Thanks, Keith Richeson

[Håkon Alseth]

If it occurs after 12SAMPLEPER, the event will not be generated before the 20'th. So all events reported back to the CPU will be in the next multiple of REPORTPERSAMPLEPER. If you see the attached image, the lowest line is the EVENTS_SAMPLERDY, while the above is EVENTS_REPORTRDY. It's around 5.1 ms between those two samples, which is 5100/1280 = ~4. Theoretically, it should be 5120 us, but I guess there is some jitter in my cursors.

Are you seeing something else?

Best regards Håkon

[Keith Richeson]

I haven't measured via oscilloscope, so I can't say for sure, but I had seen some behavior that caused me to think the REPORTRDY event was firing sooner than I expected. If possible, could you add your encoder inputs to the screen shot above so that I can understand the timing relative to when the inputs change? Also, please confirm, I assume you're clearing the accumulator on every REPORTRDY event. Thanks!!!

[Håkon Alseth]

I uploaded two more pictures. Hope they make sense ;) D4 (pin B) and D5 (pin A) are the inputs of the encoder.

Yes, I am clearing the accumulator on every report-event.

Best regards Håkon