Wireless BLE Kinesis Advantage (Custom Controller)

Ran into connectivity issues again recently. This is the 2nd time in 4 months or so. I have a feeling it's to do with Mac OS' bluetooth not playing nicely with the nrf52 when it sleeps. But since it's such an easy fix and happens so sporadically, I'm not too inclined to investigate further.

Anyway, as promised I just implemented a key-combo to reset bluetooth pairing:

RIGHT SHIFT + LEFT CMD + ESC

The keyboard LEDs should flash three times to indicate all bluetooth pairings have been cleared.

Then just delete the keyboard from your computer's bluetooth and re-pair. 

A rest timer that uses the Kinesis' LED(s) to let you know when it's time to take a break. 

You're probably here because you own a Kinesis, and you probably own a Kinesis because you've run into some strain issues due to prolonged usage of your keyboard. As much as the Kinesis helps in reducing discomfort, it doesn't alleviate the need for frequent rests in between work. I've tried several timers, phone, software, sound alerts, haptic alerts on watches, but I haven't found the perfect timer that doesn't break me out of my flow while I work.

I wanted a timer that was:

- Easy and quick to set up

- Clear but unobtrusive

- Repeats

I've been thinking about building my own LED timer that syncs to my computer for a while, but yesterday I realized I could just build it straight into the keyboard! I've only been using this for a few hours, but this is by far my favorite feature of this firmware. I hope you guys find it useful too.

Settings

Everything is configured in config.h

It's on by default but you can turn it off by commenting out

#define REST_TIMER

You can set how long you'd like to work continuously for until a break

#define WORK_INTERVAL_MINS    20

Finally,  the keyboard assumes if you've been inactive for this long, you're already on a break so it'll reset the timer

#define WORK_TIMEOUT_MINS     5

Manual vs Auto Breaks

I originally had the keyboard assume we're on break if we need to take one and we were inactive for more than some time.

#define REST_INTERVAL_SECS    60

I realised this ended up cancelling breaks unintentionally, because believe it or not sometimes I went a whole minute without typing!  

That kind of defeats the purpose, so the default is to now require you to manually  enter break mode by pressing a key combo.  Of course you can uncomment this to bring back auto-breaks.

//#define REST_AUTO_BREAKS

Manually entering break mode:

Press DELETE + PROGM to let the keyboard know you're going on break. You can change this in the matrix of course. 

Summing Up 

The result of all this is a timer that is inherently always on, smart enough to track whether you need a break without knowing the time and get's out of your way when you don't want to break focus. Just look down every once in a while, and if your keyboard is blinking, take a break!

I already drilled a hole in my keyboard to install a power button from a previous project, but I realize some of you might be a little hesitant to do that but you still need a way to manually put your keyboard to sleep (to save power / reboot). You'd be glad to know that I just pushed a new version onto master branch for you guys.

New Key Functions:

- 'progm' key = shutdown (deep sleep)

- 'keypd' = show battery level (useful if timeout has expired)

Enjoy your super stealth Kinesis BLE! 

Totally slipped my mind that I could just PWM the led(s) to lower brightness. They were previously burning around 2mA each and we have 4 of them (8 + 3 = 11mA with everything on!). So even with a shorter 30 sec timeout, I still lost 25% (roughly) in about 3 days. Guess my keyboard was sleeping / waking more than I thought.

Now we're PWM'ing them for 10/255 (still bright enough to see in the day) and they only use 0.06mA each! All together, with the board on + blue power button LED + 4 battery LED(s), we're at around 3.45mA. NOT BAAAD.

3000 / 3.45   = 869  / 24 = 36 *  0.7 (safety factor) = 25 days of continuous use. 

Considering I have other stuff that keeps me away from the computer, like sleeping and eating, I'm expecting at at least 50 days of real-world usage until a recharge.

If the battery still only lasts 10-15 days, I'm definitely getting a new LiPo, because I'm out of ideas on how to further reduce power consumption.

Don't know if it was my mac that caused it but something screwed up the pairing for 2 keyboards. Bluetooth would show them connected after waking u from sleep but they wouldn't send keypresses unless I re-paired them.

Turns out you needed to clear the 'bond' list from the keyboard side (resetting your laptop's bluetooth 50 times doesn't work, I tried).

If you're unlucky (first time it's happened to me) enough to run into issues, here's the [solution](https://forums.adafruit.com/viewtopic.php?f=57&t=143309)

In the future, I may think about implementing a hard-reset via key combinations to do this. In the mean time, I'll assume since you're building this, you have enough basic Arduino knowledge to do it through code.

Looked a little harder and it turns out I wasn't the only one suspecting the ADC of preventing the feather from going to sleep. Anyway, the reason and fix for it is way over my head. Something to do with floats and the FPU?

The good news is after some copy-pasting ...

   #if (__FPU_USED == 1)
  __set_FPSCR(__get_FPSCR() & ~(0x0000009F)); 
  (void) __get_FPSCR();
  NVIC_ClearPendingIRQ(FPU_IRQn);
  #endif
  uint32_t err_code = sd_app_evt_wait();

We got sleep back!  Same as before, looking at 2mA without any LED(s). Aaand I think I'm finally done here! If anybody goes and builds this feel free to post if you run into any issues or even better have suggestions for the build.

So it turns out for some reason on the nrf52 Feather, sampling the ADC prevents the device from going to sleep afterwards! Even if you're only sampling once! I even tried to turn ADC off manually like so:

  NRF_SAADC ->ENABLE = 0;

But no dice, once you sample once, the current increases by about 4mA -- not cool.

Alright so, the temporary fix is to disable all battery / power features. ie. battery left, charge status etc. and then reach out  to the guys at Adafruit and/or Nordic to see if anybody has a fix for this.  

The worst part is since I already cut my traces, I'm not even sure if using the TX/RX pins was preventing the USB chip from sleeping! 

Ok, now some good news. The power consumption without all the other features and at 7ms delay (ie. 8ms debounce) is 2mA (without power button LED) or in other words, using a 3,000mAh LiPo and using the keyboard 12 hours a day straight would last 87.5 days. This made the whole jump from i2C to SPI well worth it.

Was still getting missed keys as I typed (110wpm), so had to reduce the debounce delay again to 7ms. Now we're at 87.5% sleep. Apparently, Cherry switch's debounce times required are 5ms so we're still being pretty conservative!

Ok, just cut the traces from the TX/RX pins and rewired from 2 pins that were being used for the RGB button. Haven't got a working multimeter so will have to check in a few days but this should allow the serial chip to sleep.

For anybody using a nrf52 feather just STAY OFF TX/RX pins, they behave unpredictably and they'll prevent your feather from going to sleep.

Uploaded V4 board that has the fix. If anybody does get one made, let me know how it goes. If anybody wants a v3 board, happy to ship them over, still have a few spare. You'll need to cut 2 traces and solder 2 wires like in the image above.

Ok, just noticed the board was draining unusually fast. A quick multimeter check revealed it was drawing 10mA. What?!

I suspect it's to do with using the TX/RX pins to drive LED(s) which in turn prevents the CP2104 Serial chip from sleeping. That chip has a quiescent current of about 7mA so that roughly adds up to the 10mA we're seeing.

I'm currently considering my options.

a) Re-wire the two led(s) to 2 of the pins currently used by the RGB push button.  We'll lose yellow and green colors, but at least we can still indicate charging status by flashing the LED(s) and still use them as a battery level indicator.

c) See if we can fix this via firmware. ie. only setting pin to output mode just before we need to light up a LED. My multimeter broke so will be a few days until I can verify this works.

I also tried Charlieplexing to drive 4 LEDS with 3 pins but that doesn't work since we're delaying the board at the end of the loop to sleep.