QDEC example with nRF Connect SDK v1.4.0

[Coco cinelle]

Hello, sorry if this seems to be a basic or already asked question, but how could I have an example of QDEC usage with the nrf52840 (ideally the dongle) ?
I would like to plug a simple mechanical rotary encoder, and I found some posts telling there is an example in the SDK, but after having installed nRF Connect SDK v1.4.0 (on Windows and Linux), I don't find such example.
Maybe I should use a previous version ? Or maybe someone could point me to an old version of the example that would still be compatible with the more recent version ? (I found some posted links related to that but always targetting pages that don't exist anymore)

Thank you :)

[Einar Thorsrud]

Hi,

Coco cinelle said:

Hi, to be sure I don't make mistakes, what is the purpose of the "enable-pin" here? Removing the line triggers build errors, but I don't see the documentation of an "enable pin" for the QDEC device in the nrf product specification.

The enable-pin is a concept of the zephyr sensor driver API, and not part of the QDEC peripheral nor nrfx driver. Essentially it is just a pin that is asserted while the QDEC is active. You can see how it is set and cleared by calls to qdec_nrfx_gpio_ctrl() in the implementation in <NCS>/zephyr/drivers/sensor/qdec_nrfx/qdec_nrfx.c.

Coco cinelle said:

Also, I suppose low frequency GPIOs would be ok for a-pin and b-pin, so I plan to use for eg. P1.10 and P1.13 (As I saw somewhere in a forum : "0-31 correspond to 0.x and 32-63 correspond to 1.x").

Yes, that should be fine (and your understanding that P1 numbering is correct).

[Coco cinelle]

Ok, thank you.
So I try to mimic what is done in wheel.c . I also want to enter system OFF mode after some inactivity delay, like it seems to be done in wheel.c, but it seems the dongle wakes up directly after reaching the OFF state...
Could it be caused by the fact that I'm plugged in USB and the only way to stay in system OFF mode would be to enable external power ?
Thank you

[Einar Thorsrud]

Hi,

I do not see that wheel.c has any code to enter system OFF mode, but it would probably not belong there anyway. What is it i you refer to? Could it be that you mean system ON low power mode (which is the normal sleep mode)?

Generally, there are only a few possible wakeup sources from system OFF (GPIO, NFC or LPCOMP), and then if triggered, the device will wake up. There are no clocks running in system off mode, so any wakeup must be externally triggered.

[Coco cinelle]

Ok I was not sure of that. Because of the fact that in wheel.c the QDEC device is put in DEVICE_PM_SUSPEND_STATE after some inactivity delay I was thinking the device could even reach the system OFF state if there was no other activity... But indeed it is certainly system ON low power mode that I reach in my case, and I guess this behaviour is automatic since I don't call code to explicitely go into this state.

But my aim in the end is to go to system OFF mode to consume as less power as possible, with qdec pins being able to wake up the device, registering GPIO interrupts for that.
So if I understand correctly your answer, the simple fact that the dongle is powered through USB should not theoretically block the possibility to remain in sleep mode or system OFF mode? I wanted a confirmation especially because I read that "When in System OFF mode, the device can be woken up through one of the following signals" ... "4. Detecting a valid USB voltage on the VBUS pin (V_BUS,DETECT)."  here infocenter.nordicsemi.com/index.jsp

Thanks

[Einar Thorsrud]

Hi,

Sorry, I forgot to comment on system off and USB. I do not believe it is possible for the device to stay in system off mode while supplied via USB. I do not think that has been considered a realistic scenario, as also in system ON mode current consumption is very low, and typically anything with a USB host is not so low power.

May I ask a bit about your product, as this is something you see a need for?