QDEC example with nRF Connect SDK v1.4.0

RE: QDEC example with nRF Connect SDK v1.4.0

Einar Thorsrud — Mon, 23 Nov 2020 08:11:33 GMT

Hi,

Good to hear. That is about what you should expect.

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Sat, 21 Nov 2020 16:23:32 GMT

Sorry for the multiple messages...
In fact 8uA of current consumption was due to USB still being plugged after programming the dongle. Without being plugged, my multimeter reports a consumption below 1uA :)

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Sat, 21 Nov 2020 14:55:28 GMT

I restarted from the beginning, and enabling things one after the other led me to this :
Before enabling or disabling the QDEC device I manually configured the QDEC pins as GPIO INPUT, and this seems to be the cause of a so high current consumption in System OFF mode.

Now I reach 8uA, that's far better :) But it seems to me that it is still too high for just sensing two pins for the potential wake up...
So maybe now I should dig into tuning RAM retention, or something else? If you have any clue...
Thanks

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Sat, 21 Nov 2020 13:04:24 GMT

Hi,
I switched to external power, and now the dongle stays in sleep or OFF mode 🙂

To enter Sytem OFF mode I call "nrf_power_system_off(NRF_POWER);" as I didn't succeed to call "sd_power_system_off();" (I can't include the proper header file)... But it seems to work and power consumption goes very low, around 1uA or less. But then I can't wake up the device with classic GPIO interrupts.
So I figured out that to be able to wake up the dongle from sleep or OFF mode I have to use the "sense" API.
So I call "nrf_gpio_cfg_sense_input" for the two pins of the QDEC device and it works: a rotation of the device wakes up the dongle.
But with this call to "nrf_gpio_cfg_sense_input" the power consumption is then far higher in OFF mode : ~100uA
Do you know what could be the cause of that? I tried pull down instead of pull up... but it is the same.
Maybe something must be deactivated ? I was wondering about RAM retention settings but I read that power usage should not be so different with or without RAM retention...

So just adding this call makes the wake-up from OFF mode work, but increases a lot power consumption:
    nrf_gpio_cfg_sense_input(
        qdec_pin[0],
        GPIO_PIN_CNF_PULL_Disabled, // I have external pull up
        GPIO_PIN_CNF_SENSE_Low);

Thank you

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Fri, 20 Nov 2020 15:05:15 GMT

Ok thank you for the precision !
In fact I just want to do have a rotary encoder that triggers BLE advertisements when rotated, and that then goes to the lowest possible power consumption mode. Rotating it again should wake it up, and so on. I may add some basic buttons too, that would send different BLE advertisement data.
This is a remote command device for a device I made.
So in the end I want to power the device with a cell coin, and I won't need USB at all :)

I was asking before soldering SB1 and cutting SB2 to switch to another power source because powering through USB is more convenient at the current stage of my prototyping...
So it seems I am obliged to switch to an external power source if I want to do real testing.

Thanks

RE: QDEC example with nRF Connect SDK v1.4.0

Einar Thorsrud — Fri, 20 Nov 2020 14:00:20 GMT

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?

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Fri, 20 Nov 2020 13:42:31 GMT

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

RE: QDEC example with nRF Connect SDK v1.4.0

Einar Thorsrud — Fri, 20 Nov 2020 13:09:09 GMT

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.

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Thu, 19 Nov 2020 22:04:29 GMT

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

RE: QDEC example with nRF Connect SDK v1.4.0

Einar Thorsrud — Fri, 13 Nov 2020 08:26:46 GMT

Hi,

[quote user="Coco cinelle"]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.[/quote]

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.

[quote user="Coco cinelle"]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").[/quote]

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

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Thu, 12 Nov 2020 19:55:02 GMT

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.

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").

Thanks

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Tue, 10 Nov 2020 18:19:44 GMT

Hi, I created a .overlay file with this content and there is no more error, thanks!

About CONFIG_SENSOR, it is because I have this warning:

warning: QDEC_NRFX (defined at drivers/sensor/qdec_nrfx/Kconfig:4) was assigned the value 'y' but
got the value 'n'. Check these unsatisfied dependencies: SENSOR (=n)

But for the moment I don't have any code that uses qdec, I just made a copy of a small sample project to begin...
Going into the real stuff now :)

RE: QDEC example with nRF Connect SDK v1.4.0

Einar Thorsrud — Tue, 10 Nov 2020 14:56:03 GMT

Hi,

[quote user="Coco cinelle"]When I enable CONFIG_QDEC_NRFX, and anslo CONFIG_SENSOR as this seems to be a required dependency[/quote]

There is a dependency on nrfx if you want to use sensor, but not the other way around if you only want to use nrfx directly.

[quote user="Coco cinelle"]then my build fails[/quote]

The error is because the zephyr drivers (like sensor) requires that pins etc. ar defined in the device tree file (or overlay file). So you can fix this by adding the qdec configuration to the device tree, either (quick and dirty) by putting it into zephyr/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840.dts if you ar using that target board, or by putting it in your own boar definition or in an overlay file:

&qdec {
	status = "okay";
	a-pin = <3>;
	b-pin = <28>;
	enable-pin = <30>;
	led-pin = <0xFFFFFFFF>;
	led-pre = <0>;
	steps = <24>;
};

RE: QDEC example with nRF Connect SDK v1.4.0

Coco cinelle — Mon, 09 Nov 2020 21:51:03 GMT

Thank your for pointing me to this.

When I enable CONFIG_QDEC_NRFX, and anslo CONFIG_SENSOR as this seems to be a required dependency, then my build fails, the first error being:

[78/185] Building C object zephyr/drivers/sensor/qdec_nrfx/CMakeFiles/drivers__sensor__qdec_nrfx.dir/qdec_nrfx.c.obj

FAILED: zephyr/drivers/sensor/qdec_nrfx/CMakeFiles/drivers__sensor__qdec_nrfx.dir/qdec_nrfx.c.obj
...

In file included from D:/ncs/v1.4.0/zephyr/include/arch/arm/aarch32/arch.h:20,
                 from D:/ncs/v1.4.0/zephyr/include/arch/cpu.h:19,
                 from D:/ncs/v1.4.0/zephyr/include/kernel_includes.h:38,
                 from D:/ncs/v1.4.0/zephyr/include/kernel.h:17,
                 from D:/ncs/v1.4.0/zephyr/include/init.h:11,
                 from D:/ncs/v1.4.0/zephyr/include/device.h:22,
                 from D:/ncs/v1.4.0/zephyr/include/drivers/sensor.h:23,
                 from D:/ncs/v1.4.0/zephyr/drivers/sensor/qdec_nrfx/qdec_nrfx.c:7:
D:/ncs/v1.4.0/zephyr/drivers/sensor/qdec_nrfx/qdec_nrfx.c: In function 'qdec_nrfx_channel_get':
zephyr/include/generated/devicetree_unfixed.h:1717:37: error: 'DT_N_S_soc_S_qdec_40012000_P_steps' undeclared (first use in this function); did you mean 'DT_N_S_soc_S_qdec_40012000_P_status'?
1717 | #define DT_N_INST_0_nordic_nrf_qdec DT_N_S_soc_S_qdec_40012000

Of course I will search more on my side, but I just tell this in case the solution is not so obvious...

Thank you

RE: QDEC example with nRF Connect SDK v1.4.0

Einar Thorsrud — Mon, 09 Nov 2020 13:04:08 GMT

Hi,

There are no QDEC samples in nRF Connect SDK at the moment. You need to enable it with remember to enable CONFIG_QDEC_NRFX in prj.conf. You can refer to the nrfx API if you want to use it directly. You can also refer to how it is done in the wheel module (nrf\applications\nrf_desktop\src\hw_interface\wheel.c). Here the Zephyr Sensor API is used, which is an abstraction on top of the nrfx QDEC driver in this case.