Battery draining very quickly

[jhbruhn]

I am trying to use the interphase keyboard, but having issues with the batterylife being only a couple of days. I have compiled the code myself becauseI have built the PCBs inverted (to be easily able to access the components).

In the code, I am not seeing a line which puts the device in a very low power mode, like for example the redox does it: https://github.com/mattdibi/redox-w-firmware/blob/master/redox-w-keyboard-basic/main.c#L138

Is that perhaps missing from the code pushed here?

[Durburz]

The code in the repository is okay and all builds that I heard of are working fine so far.
I don't know if redox wireless is using a different version of the SDK or if there is another difference to save even more energy.
In my code the low power mode is entered here: https://github.com/Durburz/interphase-firmware/blob/master/interphase-keyboard-basic/main.c#L251-L253
https://devzone.nordicsemi.com/f/nordic-q-a/10932/can-someone-explain-to-me-how-nordic-nrf51822-sleep-mode-works
Is there may be an electrical change or fault, that an input is permanently active?

[jhbruhn]

Interesting. I'd guess that using the aforementioned System OFF state could potentially save even more energy, but perhaps not working together with the matrix scanning. Maybe I'll get a chance to test it sometime.

I don't think there is an electrical fault as I have the problems with both sides, but maybe I have to doublecheck the components I used.
I am currently using two NiMH batteries, so perhaps they're cutting of earlier than they have to, but I also tested it with normal batteries, which did not have much better performance.

[Durburz]

Yeah, I just also read further down the thread and yes you are right this might save even more energy but would most likely need some sort of persistence handling, though the matrix scanning should be fine as this is also just based on a GPIO interrupt.
I am afraid I can't help you any further with this issue

[jhbruhn]

Another theory: Is it maybe due to the different types of the MCP1640 that exist? https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP1640-Family-Data-Sheet-DS20002234E.pdf

I seem to have used a MCP1640D, but maybe a MCP1640 or MCP1640C would have been better suited?

[Durburz]

Yes, this is indeed possible. I am using MCP1640C in my keyboard myself

[jhbruhn]

That indeed did the trick. I switch to a MCP1640C and am getting a sleep-current of ~0.1mA, instead of ~2.5mA before that! I'll see how this performs and perhaps try to implement the System OFF state if I am still dissatisfied.