Power consumption

[Dakkaron]

The current implementation consumes around 60mAh (measured by the very inaccurate current consumption meter on my phone).

I calculated around 40mAh, not including DC-DC conversion losses and the power consumed by keeping the USB stack active on the phone's side. So ~60mAh in total sounds like the right ball-park.

If your phone usually has a battery life of 24h and a 4000mAh battery, that might reduce your battery life to around 18h.

With the keyboard backlight off, the consumption drops to around 40mAh. For the same calculation we are now up to a bit over 19h.

According to the schematic, the Arduino's power LED consumes around 5mAh as well. So removing that will put us at 35mAh.

If I read the datasheet correctly, I can also underclock the Arduino to 1MHz, which should give us another ~12-15mAh, which means, if we are lucky, we are down to 20mAh, which puts us at 21.4h battery life.

These are the no-compromises optimisations.

Additionally, the microcontroller can be put to sleep when not in use. This reduces the power consumption so far, that my phone's discharge sensor couldn't make out any difference. The problem is, that this also turns off the USB connection, so that the USB connection needs to reconnect when the keyboard wakes up from a key press. It then takes another second or two until it is ready.

What do you think, is the power consumption good enough?

What kind of power saving compromises would you be ok with?

Do we need to switch the chip to something with a more conservative power consumption?

[Dakkaron]

Power consumption is pretty much solved now. I learned about a different light sleep mode, that allows me to save around 40mA. This means, the power consumption is now about 20mA in idle mode. So we are at around 21.4h battery life without compromises (for our hypothetical phone).

And that's with the power LED still in place. With that gone, the power consumption would drop to 15mA, which would give us 22h battery life.

I'll still leave the hard poweroff feature as a configurable option, but I don't think it's necessary as a default option.

[Dakkaron]

Yeah, on the new PCB I just wouldn't integrate the power LED.

Honestly, I wouldn't even bother with underclocking.The sleep mode disables the microcontroller clock completely, so it would only make a difference while the keyboard is active, so maybe half an hour per day or so.

[dumblob]

underclocking.The sleep mode disables the microcontroller clock completely, so it would only make a difference while the keyboard is active, so maybe half an hour per day or so.

Ah, ok.

OTOH the "keyboard active time" is exactly the time when it draws basically all of the power, right? But maybe I'm wrong as I didn't take a look at the sleep mode you're referring to.

[Dakkaron]

Before I only used deep sleep (which is basically full power off) or active (everything is up and running, drawing full power). Since deep sleep turned off USB, I disabled the deep sleep mode, and ran it active all the time.

Now I am using idle power save mode, which turns off almost everything (including the microcontroller clock) except USB. So I can still keep USB active, while not drawing much power.

"Keyboard active time" means while the backlight is on and no sleep mode is active. It wakes up on key press and goes to sleep one minute after the last key press (configurable).

Off course, it's dependant on the usage, but I don't type for more than an hour daily, so the power consumption mainly depends on the idle time. You know, it's worse to use 30mAh for 20h than to use 60mA for 1h.

[dumblob]

I see, that makes sense. I'll take a look at the source to see how much effort it would be to add support for underclocking 😉.

Thanks for all the work so far - this project gives me hope I can get rid of my oldest phone - BB Q5 which I still use for phone calls and SMS every day (no kidding).

[Dakkaron]

Sorry, missed that message. Since the clock is turned off while the keyboard is on standby, underclocking wouldn't change anything there. Underclocking would only reduce the consumption during the active time.

You could underclock it quite easily though, just by setting the fuses. By default it uses the external 16MHz clock generator on the Arduino. If you switch to the internal clock generator (which doesn't generate such a tidy clock signal as the external one, but that should be ok regardless), you'd underclock it to 8MHz (since that's the frequency of the internal one, if I am correct). Then you could enable CKDIV8 to further divide that clock by 8 to get to 1MHz.

This would probably increase the key stroke latency. I have to do some measurements to see what the effect is. But all this can be done with just a cheap ISP programmer, without changing anything in the circuit.

[spARTacusFromCB]

Is the back light for the keyboard always on, or controllable for on/off via a specific key/sequence?

[Dakkaron]

Currently it stays on until a timeout (default 1 minute after the last keystroke). The backlight is turned back on by hitting any key. I usually use the shift key for that purpose, if it's too dark to see the keys, since it doesn't do anything on it's own.

I am considering making a companion app for the phone, which would also turn on the keyboard's backlight anytime a virtual keyboard would be visible (e.g. when you select a text input field).

[dumblob]

@Dakkaron some time ago I've seen such apps for Android (there were multiple) meant for externally attached keyboards (don't remember whether only USB or also bluetooth keyboards).

E.g. ensuring to not show the virtual keyboard any more by providing a "zero height blank virtual keyboard" (many apps are badly written and call the virtual keyboard to show up or vice versa many apps do not focus fields which were previously focused - e.g. when pressing the "Menu" key on Android and then selecting the very same app/activity - and I bet something like that happens also on iOS), providing some hacks for external keyboards (iOS & Android do not support/react_to all existing key codes), and maybe also some light control, IDK.

[Dakkaron]

Do you know any app that still exists?

The features I'd like to have in the companion app would be the following (I currently use a combination of apps to get some of those features):

• A virtual keyboard that shows (customizable) buttons/signs that are not on the PKB (e.g. TAB, { } [ ] € or stuff like that)
• Serial communication to the keyboard to e.g. turn the backlight on if a text input field is selected or turn it off when the phone is put to sleep
• Remap special keys that can't be sent over USB (Home, Back, Recents, Split Screen, ...)
• If root is enabled and the option is desired, automatically run wm size commands on connect/disconnect to shrink/enlarge the active screen area, so that the PKB doesn't overlap active parts of the display
• If the keyboard is connected/disconnected, automatically switch from/to the virtual keyboard.

For the first point, I currently use Gr8ly, which does the configurable keys thing, but sadly doesn't support TAB.

For the second point I use Key Mapper, which does the job beautifully.

For the last two points I currently use Llamalab Automate, which works fine.

Only for the 2nd point, I really don't have any solution.

So point 1 and 3 are the most important ones, the other points could be left as is, but it might be nicer to have everything in a single app, instead of having to install and configure multiple apps.

[spARTacusFromCB]

For 1, I assume you've already considered this but if those special keys are possible from a full keyboard, then couldn't the signals for those be mimicked and triggered with a combination of certain key press/holds at the Q10 KB?

For 3, I assume you have also considered this but is there enough spare capacity with the Arduino chip/board to basically also incorporate a home made "belt" like from on the BlackBerry Classic or the Bold, for a couple of specially buttons before the first keyboard row? Heck for that matter, could a USB mouse also be mimicked via a trackpad in that area?

[Dakkaron]

For 1, I assume you've already considered this but if those special keys are possible from a full keyboard, then couldn't the signals for those be mimicked and triggered with a combination of certain key press/holds at the Q10 KB?

Most of them, yes. But some I couldn't work out.

The USB HID protocol doesn't actually send the character that was pressed, but instead a Scancode, which then the operating system interprets as different keystrokes. That means, the keyboard layout, that was chosen on Android determines, which characters you can have on the keyboard.

Android 11 has a bug, that if you have any accessibility services running, the keyboard layout is forced to "US International", no matter what you choose in the settings. So characters that aren't on that layout don't work. So, for example, I couldn't get the €-sign to work.

Also, I tried adding more symbols, that are possible to send (like for example {, [, ], }, =, ^). But if you overload the keyboard too much, it becomes really hard to remember which button does what.

For 3, I assume you have also considered this but is there enough spare capacity with the Arduino chip/board to basically also incorporate a home made "belt" like from on the BlackBerry Classic or the Bold, for a couple of specially buttons before the first keyboard row? Heck for that matter, could a USB mouse also be mimicked via a trackpad in that area?

The Arduino is not the limit here. Especially with my new board, which has almost all of the unused ports available as solderable through-holes, there is more than enough capacity to attach extra pieces. The Arduino can also emulate a mouse or a gamepad without issue.

The bigger issue is where to fit these extra things. As is, the keyboard already takes away part of the screen. So adding more stuff to the top doesn't sound like a good idea.

I thought about adding a trackpoint and/or a dpad to the back of the keyboard case though. I'm not sure how good that works on the back, but I guess, it might be fine once you got used to it.

I even had the crazy idea to make a detachable top case (detachable like the bottom case is right now), that would hold a joystick and a few buttons, so that it could be used for emulators and games.

Let's see if I get to that^^