So, BLE. Huge post from some guy making the energy-harvesting BLE bike speed sensor.
TL;DR: use lowest voltage supported by the hardware, provide that voltage using a buck converter (not LDO - because LDO will just convert all that extra voltage into heat - so for 5V->1.7V that's 2/3 of your battery energy wasted right there), spend most of your time with transmiter AND RECEIVER switched off because those things are super power-hungry.
Some interesting nuances:
1) Internal oscillators use less energy than external crystals, but take longer to start.
1a) You'll need watch crystal. More stable it is - more energy savings you'll get, because you won't have to spend less time with receiver on, waiting for the central to call you. You can just wake up closer to the time you'll be called. WCO will be active _at_all_times_.
1b) The crystal for the processor clock is optional. In fact, if you only wake up for really short periods of time, it may be more energy-efficient to use internal oscillator because you'll spend less time waking up that way.
2) Since you'll spend lots of time sleeping - selection of processor clock frequency is not as straightforward as it seems. Higher frequency may lead to less power consumption because you'll be done with calculations sooner and can get back to sleep faster.
I also tested altering the HID descriptor to allow for 20 bytes - 1 for mods, 1 reserved, and 18 for keys, and only providing boot mode. It actually works, so 18 KRO is achievable on BT4.0. Note: you really want to keep your data packets shorter - because max. L2CAP MTU for BT4.0 is 23 bytes - that leaves 20 bytes for payload. Not only that - the longer your packets are, the longer transmitter runs and the more heat it generates. I've read about problems with chip overheating and losing stability when sending large packets.
I also tested proximity sensor on the BLE module - looks like it is possible to wake up the keyboard when you put your fingers near it and quickly shutdown when you no longer sense those. That should save some juice too. Need to think how to hide the sensor wire in the case though - or if it possible to use the keyboard assembly itself as a sensor.
Since all of the above can't be bought as a prototype kit (It is possible to frankenstein together 2 kits - but even then you'll need power supply/battery charger (LTC3558-based, for example) - so total for parts will be like $50 and it won't look pretty) - I decided not to make this.
Although if enough interest is there - like, for example, something like model MF suddenly resurfaces - I will consider making a custom device. Won't be cheap though
