deskthority

You can have up to 6 switches pressed at once and it will be like they were pressed all at the same time. 6 is a strict limit of Bluetooth.

Muirium wrote:Something worth a look / stripdown:

http://handheldsci.com/kb

I read about this some months ago (and mentioned it on page 1 of this thread) but still haven't investigated further. Looks like a way to get the components, already programmed too. Just in a bulky package.

Xwhatsit wrote:It's not necessarily terrible. My implementation wasn't specifically designed to run off a battery, so won't be particularly power efficient (I was more concerned about stuff on the 10mA scale rather than down to saving a few µA). That said, it won't be too bad. There will be a milliamp wasted here and there in voltage dividers; however the DAC should be pretty power efficient. My choice of the cheap and available LM339 as the analogue comparator isn't ideal; it's a very old-school part and isn't particularly efficient by today's standards.

The two main issues around power consumption of capsense vs ohmic are:

• Charging and discharging the caps uses more power than just hooking an output straight to an input (which will be really high impedence)
• The analogue stuff will necessarily use a bit of juice

I'm confident that with some careful design, both of those things could be managed to a level where you could pretty much ignore the slight extra bit of power. Clearly on a board where you're that worried about power consumption, whether ohmic or capacitive you're going to have to eliminate all of your Lock LEDs as that will suck an order of magnitude more power than anything else (each LED will use between 5 and 20mA).

Charging/discharging of caps—they're only a few pF, many of the matrix designs I've seen for ohmic keyboards would have more than that in parasitic capacitance between traces;

Analogues—if you pay a bit more and choose carefully, there's a wealth of low-power analogue DACs and comparators these days.

All that being said, I see HHKB in the title, and I will guess that the creators of that 30-gram-keyboard-snack didn't put too much design (or BOM cost) into keeping power consumption down. There will be, like with my controller, careless milliamps wasted here and there.

In terms of firmware—my firmware already spends a lot of time sleeping (between columns); it could easily be redesigned to properly sleep in a low-power state instead of busy-waiting like it does currently. Variable polling rate would potentially save a tiny bit of power. I agree that having diodes in a matrix would suck way more juice than anything else discussed here (0.6V drop with a non-Schottky, even at a few µA that's still way more power than charging/discharging a few pF). There's no reason (with my design at least, I don't know how Topre scan) why you need to scan more frequently or more regularly with a capsense board, although it does make debouncing easier and faster.