It’s been a while, has anybody successfully tried a usb-to-bluetooth adapter on their Model01?
This is Alan from handheldsci.com. We are the maker of the Bluetooth Adapter for keyboard and mouse, the little dongle that converts a USB keyboard or mouse to a Bluetooth one. Our adapter works with most keyboards, including mechanical ones. See this page for the list: http://handheldsci.com/comp. As you can see Model 01 from keyboard.io is one of the very few we are still working on. Once we get it to work I will post update here.
What issues are you running into with the Model 01, other than the LED power draw? We’d be thrilled to help out.
Here is the question: is it possible to switch the keyboard to use the boot protocol instead of report protocol (without re-flashing a new firmware)? Most keyboards default to use the boot protocol. There are a few exceptions but those can all be switched using the “set protocol” call. However, this doesn’t seem to work with your keyboard. Our Bluetooth Adapter does not have the resource to parse the complete report descriptors which can be very complex. So we rely on using the boot protocol with the fixed simple report format.
We will be exhibiting at CES 2019 with most high end mechanical keyboards. We really want to include this one since it is unique and interesting. We can talk more offline (email to support at handheldsci dot com).
Can you try coming up to the 1.93 firmware? The boot protocol support in the factory firmware was nowhere near done.
Got it. Will try that.
Did the updated firmware work with the bluetooth adapter?
So, in case anyone else is interested: I ordered one of the handheldsci adapters. The vendor said it worked with the stock firmware and cautioned me they had not tested more recent ones.
My Model-01 had a locally built but otherwise unmodified 1.22, which did not work with the adapter. I built 1.94.0-beta (File>Examples>Model01-Firmware) and uploaded it to the keyboard. A few quick tests suggest that this works just fine.
Thanks for the heads-up. I created a video to show the Bluetooth Adapter working with Model 01 with stock firmware: https://youtu.be/7e-p36ixa94
I really appreciate Bluetooth not being a feature. I work in security and knowing I don’t have to worry about bt as an attack vector is really nice.
I got one of the handheldsci btle adapters on massdrop about a week ago, and set it up with my keyboardio. Unfortunately, it only sort of works. The manual claims it supports media keys, so I assume the model I have supports the HID report protocol, since I don’t believe boot protocol supports media keys at all.
However, trying to use the media keys (on my Ubuntu 18.10 desktop – I haven’t tried it with other operating systems) results in erratic behavior. Furthermore some standard keys (e.g., forward slash) don’t seem to get sent at all.
I tried using the key chord to switch to boot protocol mode, but the adapter freaks out and I need to power cycle it to stop it spamming keystrokes (merely unplugging the Model 01 won’t stop it). I haven’t yet tried flashing the firmware to start in boot protocol mode.
@handheldsci, if you’re interested, I’d love to work with you to solve some of these problems, if possible. I’d love to get this thing working properly, as finally removing the USB cable to my captain’s chair has been a priority for a while, and the few hours I’ve used it this way have been incredible.
@bjc Hello bjc, thanks for your report. We are certainly interested in fixing whatever problems if we can reproduce them. The Model 01 keyboard in our possession has the stock firmware. We have not upgraded it to any other version. When we tested it all the standard keys seemed to work. We will test again but it is odd that some keys work but not some others (e.g., forward slash which is a standard key). You are correct Boot protocol does not support media keys but how did you switch the keyboard to use Boot protocol? The BT-500 should support both so we will investigate why it stops working when the keyboard is in Boot.
Which media keys are you referring to? I think those are probably Consumer Control keycodes, which get sent in a HID report that’s independent of the Keyboard report, regardless of whether it’s using Boot or Report Protocol.
Ah, yes, those are consumer control keycodes, but they don’t seem to work when using Boot Protocol, at least on my Ubuntu desktop, so I assumed they were using the report protocol only.
@handheldsci I’m using the latest firmware (as of today). By default there’s a chord you can press – left fn + left shift + esc – that will toggle between boot and report protocols, which is what I was using to test. I have since recompiled my Model 01 firmware to start in Boot Protocol mode, while using the default settings on the bt keyboard adapter, and it failed to work (unending streams of the wrong character pressed until I toggled bluetooth on and off). I’ve also used the adapter’s command mode to specifically set the USB protocol to boot (
set protocol 1, IIRC), rather than auto-detect, and it still failed to function with the Model 01 set to Boot Protocol.
This could be an issue specific to the Model 01? I’ll try using some other keyboards I have laying about to see how they work with it.
Is it possible to deliver a firmware update to the BT adapter (either OTA or via USB?).
@bjc – Have you confirmed that the Model01 is working properly in Boot protocol mode when connected directly to the host over USB? I spent some time about a month ago trying to get boot protocol working on the two machines I have at home (an iMac and an old Ubuntu machine), and found that it didn’t work properly on either unless I made some changes to KeyboardioHID that I still don’t understand.
@merlin Yes, as part of testing today I had it plugged directly into my Ubuntu machine and everything worked correctly when either toggled via key chord, or directly booted into Boot Protocol. I also used it extensively in the past with Boot Protocol only on my FreeBSD host (since that is all FreeBSD supports).
Rats. (I mean, it’s good that it works wired, but I’m out of ideas. Good luck!)
@handheldsci I’ve tested a few more keyboards today, on Ubuntu 18.10, Windows 10, and macOS 10.13 and the results have been mixed.
The good news:
The bluetooth dongle I use for Windows and Ubuntu isn’t very good. Using my MacBook’s built-in bluetooth is very stable, though.
My Kinesis Advantage works perfectly, from what I can tell, including sending the forward slash key properly. I don’t know whether it’s using Boot or Report protocol, however. It’s an old keyboard, doesn’t advertise NKRO, and has no media keys, so I suspect it’s boot protocol.
I tried two other keyboards which basically didn’t function at all. First, the original Anne Pro, which the BT-500 seems to get garbage keystrokes from. Now I tried to use this keyboard on FreeBSD, and the keys I was seeing as responses to presses were similar to what I witnessed there, so I suspect the BT-500 is auto-detecting Boot Protocol support, but the keyboard is sending HID Reports. I didn’t try manually forcing the BT-500 to HID Report USB protocol, though, which may resolve the problem – I’ll have to try later.
[EDIT – I’ve tried this now, and the
set protocol function has no affect whatsoever that I can tell on behavior. While the
show command will specify that I’m forced into Boot Protocol mode, it, in fact, uses HID reports, as setting my Model 01 to Boot Protocol results in garbled keys, and putting it into HID mode results in the mostly-correct behavior reported above.]
Second, I tried my Niz Plum micro84EC keyboard, and it wouldn’t work most of the time even as USB passthrough – simply nothing got sent to the host from what I could tell, and when the BT-500 was in command mode I couldn’t talk to it there, either. Sometimes, after doing a factory reset of both the keyboard and the BT-500, passthrough mode would work, but never consistently. I could not get BlueTooth to work at all with that keyboard.
I have a Logitech “gaming” keyboard around here somewhere, which I need to find and test, since it should be using HID Reports, rather than Boot Protocol. I’ll get back when I do. But as of now, it seems like there’s something about the way the Model 01 reports the standard forward slash key that the BT-500 doesn’t like while using HID Reports, as well as Boot Protocol support with the Model 01 not working at all. Media keys do not function correctly from the Model 01 sent to any of the three major operating systems I tried.
Lastly, it appears as though hot-plugging keyboards into the BT-500 is pretty flaky. If I unplugged a keyboard from it while it was powered, and then plugged it back in, it never worked (not even delivering power to the keyboard). To get the keyboard to work, I’d have to unplug the BT-500 from power, plug in the keyboard, then plug them both into my battery pack or computer.
I found my Logitech G105, and the BT-500 adapter works perfectly with it. All keys work, including media keys, so this appears to be some kind of issue with how the Model 01 does things. So, at least it can probably be fixed with a firmware update on the Model 01.
At this point I don’t know how to go about narrowing the problem down in the Model 01 firmware. Does anyone have any advice about doing USB protocol debugging under Linux? I figured I could start with just seeing the differences in how the keyboards are doing things at a protocol level and working from there.
I really want this adapter to work!
Edited to add:
I’ve done some USB dumps with wireshark, and while I can’t see exactly what’s in the HID Report stuff, the Boot Protocol is very easy to understand. It turns out the G105 is using Boot Protocol, and getting media keys within that somehow.
So I went back and recompiled the Model 01’s firmware to start in Boot Protocol, and that keypresses are being sent that way with Wireshark. However, it still gets garbled keys when connected to the BT-500. It seems like the protocol negotiation doesn’t work on this adapter at all – or there’s something incompatible with negotiation between the Model 01 and the BT-500 – and changing the protocol with
set protocol 1|2 in command mode to try and force the issue does nothing at all (the G105 in Boot Protocol mode works with the BT-500 set to
report). Maybe this command changes the protocol that gets passed through to the host when used in USB passthrough mode, rather than interpreting the keyboard’s protocol?
As a side note: I feel like I’m starting to spam this forum. Should I move this elsewhere?
@handheldsci I believe I’ve figured out the problem, and from what I can tell, it’s with the BT-500.
It turns out, that when using report protocol, none of the keys with codes from forward slash (56) and up work. I believe that’s because they occur at byte 10 of the report. All of the keycodes before that point are transmitted successfully.
Here’s what the report looks like for ‘h’:
0040 08 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
Here’s what the report looks like for ‘/’:
0040 08 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................ 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
Here’s F1 (which also doesn’t work):
0040 08 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ................ 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
My strong suspicion is that the report processing uses an 8 byte buffer (like Boot Protocol does) after pulling out the report ID from the initial byte. So this adapter is broken for any keyboard that doesn’t use Boot Protocol.
I’ve gone through the boot and configuration sequence of the Model 01 using Wireshark and usbmon, and can verify that the Model 01 is correctly sending it’s descriptor configurations with the appropriate buffer sizes.
I have the protocol dumps saved in pcapng format for use in Wireshark if you’d like to have a look at them.