Bluetooth keyboard prototyping

[pomk]

Hi,

I'm putting an order in this Sunday for a small batch of PCB's and nRF51 controller modules.
Has anyone here experimented with BLE controllers in the past and would care to share some tips for developing the firmware?
Or would someone here like to participate in the firmware building process?

The initial PCB will support most 60% layouts and has an extra row on the right that can be removed (sawed off). With the extra row the PCB will support all white fox layouts.
The chip has a built in regulator for 1.8 - 3.7V input voltage, so I think that the easiest and arguably the best approach is to use 2 AAA batteries in series as it will minimize the number or external components and allows for a fairly long battery life. The battery life is projected to be at least one year with normal use and 1250mAh AAA batteries. A lipo module of the same size would be just 250mAh and it would also bleed around 7% of its charge every month making them less than ideal for a project like this. An additional power regulator would also have to be introduced to lower the battery's initial voltage of around 4.2V to the controllers upper limit of 3.7V.

If you would like to help in the firmware development phase, you will need to have access to an SWD debugging unit and have good embedded programming skills in C++.
My initial plan is to just make a simple firmware with a limited feature set from scratch and later figure out how to use existing layer handling etc. from TMK in a way that will not drastically affect the power consumption. Nordic has also made available a bootloader that supports firmware updates in an OTA fashion, which would allow the layout options to be changed without the need for an SWD debugging unit.

I have a background in embedded software development for the aerospace industry in Europe and I'm located in Finland/Helsinki.

[joey]

Very cool, look forward to the updates.

I want to look at adding BT to my own designs at some point, but time, money and skills are stopping me right now.

Twiddle has made some prototypes using the nrf51: https://geekhack.org/index.php?topic=62667.msg2039131#msg2039131

Although his method, and what I'd probably end up doing, is to use two ICs. The NRF51, acting as a dumb communication module, and another MCU that does all the matrix scanning etc. He also connects the SWD of the NRF51 to the SWD of the MCU, such that using OpenDAP or alternatives to flash the NRF51.

I have some basic firmware here in C++, if you want a base to start on? Haven't updated recently, been busy, but hoping to add some more stuff soon.

[pomk]

Very cool, look forward to the updates.

I want to look at adding BT to my own designs at some point, but time, money and skills are stopping me right now.

Twiddle has made some prototypes using the nrf51: https://geekhack.org/index.php?topic=62667.msg2039131#msg2039131

Although his method, and what I'd probably end up doing, is to use two ICs. The NRF51, acting as a dumb communication module, and another MCU that does all the matrix scanning etc. He also connects the SWD of the NRF51 to the SWD of the MCU, such that using OpenDAP or alternatives to flash the NRF51.

I have some basic firmware here in C++, if you want a base to start on? Haven't updated recently, been busy, but hoping to add some more stuff soon.

Thanks a lot! I will look through and see what I can do with it.

Using 2 IC's would be quite easy, you can buy a ready module from adafruit that would do all that, but the power consumption is pretty high for non power optimized IC's. The nRF51 has 31 GPIO's, so I dont really see any benefit of having 2 IC's in that configuration. If you want to have USB connectivity, you could have a serial output from the nRF chip instead. That way with a farily simple design the second IC would not use any power unless the USB cable is connected.

[joey]

Thanks a lot! I will look through and see what I can do with it.

Feel free to PM me any questions!

Using 2 IC's would be quite easy, you can buy a ready module from adafruit that would do all that, but the power consumption is pretty high for non power optimized IC's. The nRF51 has 31 GPIO's, so I dont really see any benefit of having 2 IC's in that configuration. If you want to have USB connectivity, you could have a serial output from the nRF chip instead. That way with a farily simple design the second IC would not use any power unless the USB cable is connected.

Hm yes, I guess you could do the opposite of twiddle and have the nrf51 do all the work, and just have a smaller IC doing the USB parts only. That might be a better idea!

[twiddle]

The primary benefit is complete end user programmability without external hardware. This was a key design requirement of the individual I'm collaborating with.
Power consumption on the interface IC s something I'm working on, but ATM I want to get the Bluetooth enumeration set up. I already have 2/3 of the keyboard side of the firmware written so now I'm on the BLE bits.

My big hurdle at the moment is the fact you can't use breakpoints once the soft device is active.  Have you bluetooth experience pomk? Curious how you deal with this issue as it is making things very difficult.

[pomk]

The primary benefit is complete end user programmability without external hardware. This was a key design requirement of the individual I'm collaborating with.
Power consumption on the interface IC s something I'm working on, but ATM I want to get the Bluetooth enumeration set up. I already have 2/3 of the keyboard side of the firmware written so now I'm on the BLE bits.

My big hurdle at the moment is the fact you can't use breakpoints once the soft device is active.  Have you bluetooth experience pomk? Curious how you deal with this issue as it is making things very difficult.

Technically you can update the bootloader as well using the FOTA functionality. I don't yet have experience with bluetooth, but surely you can debug your own code by stubbing the bluetooth stack (soft device)? You could also follow the execution pointer intermittently and try to determine the problem area from there.

[twiddle]

Technically you can update the bootloader as well using the FOTA functionality. I don't yet have experience with bluetooth, but surely you can debug your own code by stubbing the bluetooth stack (soft device)? You could also follow the execution pointer intermittently and try to determine the problem area from there.

I ran into issues using FOTA and gave up on it a while back, on the nRF51 side of the documentation it was all focused around KEIL which was useless for me, and in at least some configurations you can brick the device with a FOTA upgrade that goes bad, so I didn't want that.

I can debug the keyboard portion of the device by stubbing the BLE transport side of things but its the actual BLE broadcasting I'm trying to trace. The behaviour is really odd and difficult to diagnose, both on my custom development board and the nRF51 DK.
Windows is rather hopeless at giving me explanations for pairing failures beyond 'That didn't work'.

It's difficult to verify the order in which user-defined event handlers are being run when the official documentation basically resorts to 'use Segger's proprietary printf support because you can't put breakpoints in'.

My next step will be to try to write a small logging function that tries to record an event ID and data into some large buffer I can access when I pause the application.

[pomk]

Sounds like I should be worried about the time this is going to consume   
I was hoping to use the provided hid sample program to get started and not have to use too much time with getting familiar with bluetooth itself.
It will take some two weeks before I get my boards and we will then quite quickly see if I run into the same difficult-to-get-over barbed wire.

[twiddle]

Unfortunately the samples all feel significantly over engineered and there isn't a single simple 'lets recreate the functionality one line at a time' tutorial.
The samples all require modification because they are written for Nordics dev boards and have extra layers of board support packages that have to be peeled away for it to work on a custom board.
In addition you probably wouldn't be able to open source firmware based on them given Nordics own license terms, but I haven't investigated that a lot yet.
I'm actually starting to look through the mbed code to see how they do things in the hopes of gaining further insight.

Just curious, how are you implementing an antenna? Do you have a network analyzer?

[pomk]

I'm using a module from Raytac with a built in PCB antenna. Comes with all consumer electronics radio communication certificates as well. (7,5$ /pc in small quantities)

[twiddle]

Ah right. I have a completely custom implementation based on Nordic's reference schematic.

[pomk]

It's been a long time.

I have the first board soldered together and I managed to run a basic connection test program and got it to pair with my phone, so at least I did not fry anything important 
Next would be setting up some sane compilation environment and purchasing a bt4 dongle. I will use J-Link to flash the chip, but any advice in choosing an environment would be useful. Or I might just try to use mbed to get something of my own running.

-- progress --
A sample program compiled using mbed tools can pair with my phone. I had some initial trouble with J-Link as the chip had rw protection set at the factory ...

[twiddle]

My standard setup is Visual Studio and VisualGDB, arm-none-gcc + J-link.
mbed always remains an option of course, but I personally wanted to learn the underlying hardware a bit better so I've avoided using it as the base for my own implementation.
Currently I'm dealing with Intel's wifi+BT card not working on Win10, on my new development workstation, so trying to get that sorted before I get back into things.

[pomk]

Almost there!



Now to set up matrix scanning and a function layer 

[MOZ]

Nice. Subbed

[pomk]

Capslock led and basic bt connectivity work now just fine. I will get switches and a case this week.

Some pcb porn for those interested:

[acid2000]

In case you haven't seen it
https://learn.adafruit.com/convert-your-model-m-keyboard-to-bluetooth-with-bluefruit-ez-key-hid/overview

[pomk]

In case you haven't seen it
https://learn.adafruit.com/convert-your-model-m-keyboard-to-bluetooth-with-bluefruit-ez-key-hid/overview

Not really applicable. No bt firmware and zero effort on power optimization.
Thanks for the tip anyway.

I'm currently building my case so that I can solder my switches in at some point and start testing the keyboard in action.

[pomk]

The firmware is almost complete as far as my own use case is concerned, and I'm writing this post using the keyboard. I combined some features from I0x0I's firmware (https://github.com/I0x0I/DIY-A-BLE-Keyboard) with the sample firmware from Nordic. I'm happy to see that there is no discernible lag from the BT4 interface, TBH it feels quicker than my ergodox  . I will do some tests on the latency later.

Right now the board is still getting power from the SWD programmer, so the next step is to figure out the AAA battery holder. After all the electronics are sorted out I will lacquer the wooden case.

I posted some pictures of the case I made to Shadovved's PBT thread:
https://geekhack.org/index.php?topic=78563.msg2168234#msg2168234

Once the basics are sorted out I will most likely start an IC thread in order to ask what kind of features people would like to have and if someone would be interested in buying something like this. I already have the electronics on hand for four more boards.

 

[twiddle]

Thanks for the update - I'm still running into some serious issues with my own prototype, even just using stock Nordic examples, now that I finally have working BTLE under Win10.
The device advertises fine, but when a connection attempt is made the device resets during the pairing process after claiming that pairing isn't supported (I suspect a problem with the pstorage driver running using the internal oscillator, despite Nordic claiming it should work). This causes windows 10 to claim that connection was successful, then give me the unhelpful message 'Driver Error' and refuse to do anything further.
Are you using the 32k external oscillator as well as the 16mhz crystal on your prototype?

Unfortunately I haven't had the time to do a lot with diagnosis recently, being asked to write a book will do that to ya... I posted about the above issue to Nordic's forums, but no response.
I'll check out the project that you've linked and see if I can do a comparison between that and my firmware, presuming that I can get it working.

Have you considered using LiPo or LiFePo3 batteries? I have a functional USB-lipo charge/lipo power switching setup on one of my other development boards that works quite well.

[pomk]

I'm using an external 32k. I also designed a usb-lipo-charger combined with a low q voltage regulator, but decided against using it due to the space requirements of the battery pack. I'd rather have one year of uptime and use disposable batteries than one month with a lipo that fits into the same space. The charger circuit would also add about 10-20€ to the total cost and would not allow for the case design that I wanted to have.
If there is something that I can help you with, just ask.

[pomk]

I just managed to do some power consumption analysis and got the following figures with my initial firmware:

matrix scanning at 100Hz (BT4 max rate) : 190uA
typing at my mediocre typing speed (approx 8 letters per second): 290-300uA
sleep mode (wake up and re-connect takes 1 second): 600nA

I'll implement more automatic power management, but even with these numbers you should be able to write non-stop at my mediocre rate for at least 170 days or have it sitting on your desk always ready for 270 days. In sleep mode it will outlast the bluetooth standard  ).

I think that with some interrupt tinkering I can get the standby current to be closer to the 600nA figure than the current matrix scanning current consumption of 190uA.

The batteries used in this calculation are a standard duracel AAA battery pair (1.5V * 2).
The current consumption figures are taken using a 3.3V power supply, so the actual consumption will be even lower as the voltage drops.

[pomk]

I was pulling hair on getting the power consumption to be in a sane margin, but my problem with the idle power consumption was a problem with my bluetooth host. With my iPhone 5s the idle consumption was at 120uA, but with my friends android phone we got just 11uA !! This means that my power saving routine was correctly set up after all.
(the connection interval is set by the BT host, not the peripheral. the peripheral just gives some preference that the host can ignore as it wishes)

So the current figures are as follows:

Code: [Select]

Sitting on the desk:       11uA or more depending on host (max. 17,8 years of battery life)
typing at mediocre speed: 300uA (170 days of battery life)
So in practice if you type actively for around 6 hours every day, the resulting battery life would be around 1,7 years. (calculated with the android phone figures)

The keyboard automatically goes to the idle mode in less than 0,01 seconds if no keys are pressed.
It can manually be forced into the deeper sleep mode, where it does not consume electricity in any practical quantity.

As the bluetooth and power saving problems are now solved, I'll finish the case and then open a IC thread after I've taken some pretty pictures