Project Logs

Collapse

• V6 Gerbers Pushed

  Mike W • 03/21/2021 at 13:25 • 0 comments

  Recently had to swap my mac, and ended up losing the schematic files for V6. Luckily I could still download the gerbers for the first version that was made. Everything's tested to be working, but some of the silkscreen weren't updated, so there may missing labels.

• V6 coming soon!

  Mike W • 10/11/2020 at 05:12 • 1 comment

  Will be releasing a v6 of this board soon that will allow hot-swapping of the feather. This will allow you to re-use a board, and other components if the feather fails.

• V5 Board - nRF52840 - USB Hot-Switching

  Mike W • 03/11/2020 at 04:47 • 1 comment

  Recently required a USB keyboard, so I had to update the PCB (v5) in order to work with the nrf52840 Feather Express. The idea was to enable hot-switching from bluetooth to USB automatically when connected via USB, and back to bluetooth on disconnect. Everything has been updated, and tested to be working.

  You can find the pcb gerber files, and firmware on the github by downloading the latest release 1.x.

  Got a few spare boards, if you'd like one they'll be $30 each including shipping.
  

• New Firmware

  Mike W • 06/09/2019 at 06:15 • 0 comments

  So after getting tired of messing around with the delay & loop count and running into latency or key chatter, I came across Matt Vilim's Kinesis Controller project. His firmware could handle multiple key state changes, where previously I was sending a HID report per state change.

  After porting his firmware the keyboard latency was fixed without incurring any key chatter.

  However, I was occasionally getting stuck keys due to debouncing. Luckily I found Stapelberg's more recent project, KinX controller and ported the debouncing algorithm and that seems to have fixed it for now.

• Figured out source of keys getting stuck - Not the keyboard!

  Mike W • 05/15/2019 at 17:45 • 0 comments

  Turns out after creating a new board, modifying firmware & hours debugging hardware, firmware, and mac os, the issue was due to (Karabiner)[https://github.com/tekezo/Karabiner-Elements/issues/1828] and mac os clashing on keyboard control and not the Kinesis BLE's fault at all.

  I've since removed Karabiner and have fixed the issue completely.

  I suppose it wasn't a total waste of time, the debugging revealed that at the previous setting of 7ms delay, I could potentially run into key chatter if I type at upwards of what I assume to be 300wpm+ (me smashing keys as fast as I can). This is something I can't replicate at 2ms delay so I'll stick with 2ms delay and loop debouncing 3 times for now, depending on actual battery life (expecting a drop from 6 to 2+ months).

  Diving back into the firmware also let me fix a bug that resulted in inconsistent rest timer alerts.

• Eliminate Chatter & Increase Responsiveness

  Mike W • 05/13/2019 at 06:07 • 0 comments

  Noticed that I was still getting some key chatter intermittently during intense bursts of typing (130wpm+). Which was rare but still still resulted in stuck keys.

  To fix the issue:

  - Decreased the delay from 7ms -> 4ms per loop.

  - Increased the Debouncing loop count from 2 -> 3

  Resulting in a delay per key event of...

  1 + 4 + 1 + 4  = 10ms
  

  Where previously it was...

  1 + 7 = 8ms

  The decrease in delay inevitably means we'll see higher power consumption but since I'm running on 6 months without a charge (4,400mA LiPo), losing a few months for more consistent performance doesn't seem like a big deal.

  Estimated increase in power consumption

  1/4 = 0.25, where previously it was 1/8 = 0.125 -> 2x more power consumption.

  3+ months of heavy usage is fine, considering I have to charge my mouse (MX Ergo) every 2 weeks!
  

• V4 tested and a note on Adafruit nRF52 Arduino Board Lib Ver

  Mike W • 05/11/2019 at 16:31 • 0 comments

  Finally got around to actually building a V4 Board and it works. *master* branch requires no modifications.

  If you're building this board, note that you need the following:

  - nRF52 Feather Express (nRF52832 *not nrf52840*)

  - Install *version 0..8.6* of Adafruit nRF52 board lib for Arduino. Any later version contains API changes and a different bootloader version. So your best bet is 0.8.6.

  *Reason for building a V4*

  My previous V3 board worked flawlessly for 6 months and then decided to randomly start getting stuckkkkkkkkkkkkkkkkk keys. It was infrequent in the beginning, maybe once every 2 days but eventually turned into once every 2-3 hours. That's just  unacceptable. I would clean the PCB and that works for a while but it comes back after a few days.

  To make sure it isn't firmware related I decided to build a fresh board.

• Newer != Better - Stick with V4 & nRF52832

  Mike W • 04/28/2019 at 06:38 • 0 comments

  Just spent 3 hours converting a V3 board to work with the new feather (nRF52840)[https://www.adafruit.com/product/4062]. The conversion worked but it was utterly pointless.

  TL;DR - Stick with V4 board + nrf52832. 840 offers no extra benefit while consuming a ton more power.

  Pin Changes
  

  - Physical pin location change - A6 to AREF

  - Lost a second 3.3V OUTPUT - Only get one on the 840

  - Can't seem to use designated pins for GPIO - TX/RX, SCL/SDA etc. 

  The differences was enough to require changes in the firmware as well as cutting 4-5 traces and re-wiring the board. Unfortunately after all that, we still don't get extra pins when compared to the 832 because the 840 doesn't let you use all the pins as GPIO.

  At this stage, I invested a good 2 hours of my Sunday, so I may as well finish it and see if there might be any benefits in performance / power consumption.

  nRF52840 Eats A Lot More Current
  

  The 832 only used about ~2.4mA when powered (ready to type). Whereas the 840 used a mind-boggling ~4.1mA. Over 70% increase in power consumption. Looking at the forums (adafruit, nordic, nrf52 github), it appears that I'm not the only one puzzled (and annoyed) by this surprise.

  In other words...
  

  I wasted a Sunday morning so you didn't have to. Get your hands on the (old feather)[https://www.adafruit.com/product/3406] if you're trying to build this. 
  

• Battery Going on 118 Days + nrf52840 Update Coming Soon

  Mike W • 04/22/2019 at 10:14 • 0 comments

  TL;DR -- From this point forward if you are building *master* branch, use V3 board. 

  Keyboard has been working almost flawlessly for the past 6 months. Battery has exceeded expectations and currently going on 118 days since last charge. I've only plugged it in a few times (less than 10) to flash new firmware, without charging it for any extended period of time.

  No issues with key responsiveness / input delay. I can type at 120wpm without any skips. Unfortunately that's the upper limit of my typing speed so if anybody types faster, let me know!

  2 minor issues that have come up:
  

  • Keyboard pairing issue - Intermittently (once every 3-4 weeks) requires clearing nrf52 paired devices. I haven't had an issue with this since turning off FireVault on my mac. Nonetheless the combo key exists which makes this a 10 second process.
  • Occasionally keys get stuck - Happens maybe once every 2-3 days and I end up typing ssssssssssssssome key. Easily fixed by restarting the keyboard. I suspect it's due to my soldering or the hole in the keyboard (where the cable use to be) allowing air in.

  With those 2 issues in mind I've decided to upgrade to the recently released nrf52840 feather by Adafruit.

  nrf52840 doesn't require a separate USB serial chip so it should result in even better power consumption! This also means we get the TX/RX pins back so we get enough pins to get RGB for the power LED back!

  
  

• 4,400 mAh Battery going on 53 days!

  Mike W • 02/16/2019 at 08:52 • 0 comments

  This is currently the longest time I've gone without a charge and so far real life battery consumption is line with expectations.

  Although the battery measurements need to be re-calibrated. Currently it shows the battery losing the first 50% in a week or so but hangs on at over 50% for over a month. But even after calibration, the measurement accuracy would be dependent on too many factors anyway (battery capacity, temperature, make etc.). So the only take-away is that the battery consumption is accurately 1-2mA during usage.

  The keyboard has been under moderate usage (8-12 hours) per day and is currently still going.
  

View all 24 project logs