The general form of wireshark use with bluetooth:
- Put the keyboard into pairing mode
- Run hcidump in terminal, using options tw: hcidump -t -w ./bt.log
- In another terminal type hcitool scan
- Start Wireshark, and open the bt.log file
On the previous page, mention was made of using the defaults. You know, the defaults are always what we use when we don’t know how it works. Unfortunately, sometimes they’re wrong. My use of the defaults seemed to work out OK, but each system’s defaults are not necessarily the same as any other system’s defaults. Each could be different. So, a note of caution is in order there. OTOH, people who absolutely don’t know what they’re doing sometimes do better with the defaults (because it might be assumed the authors of the system had a clue). More famous last word there …
Relative to the Wireshark debugging suggestion, it seems simple enough, but will be a bit of a project. Meanwhile, another idea popped into my head:
As I wrote that I don’t like to assume anything, another thought occured to me. Why not just make my own wireless keyboard?
It sounds far fetched, but in my mind I see a pretty easy hookup for this. I’d take an existing wired keyboard, mate the keyboard chip (are any of them still 8051?) to an Arduino, outfit the Arduino with an nRF24, and tuck all that away inside of the keyboard’s existing case. Should be doable. I’d have :
Junk keyboard ($0) + Arduino ($20) + (nRF24 or Moteino) (($13) * 2) = $46, not including my labor. It’d be more expensive than a purchased BT or other 2.4 GHz keyboard, but I’d like it more. I could do my own encryption. It’d be easy. And, I could make it WAY better than the stuff on the market. At least, that’s what I’d say. Actually, in the case of using a Moteino, I’d dispense with the Arduino and have only $26 in the HB keyboard (home brew).
The original PIN mode pairing keyboards used short PINs. That was the security broke-factor. The newer keyboards supposedly have that fixed with SSP pairing protocol, but how do I know that? I guess I could look at the specification (are they all built to be compliant with it, in exactly the same way?) Dunno.
But – I don’t need no specification. I can do as I like. I can have preshared keys without transmitting any pairing traffic, and I can make them a zillion bits long. OK, not a zillion bits. The Arduino wouldn’t be able to keep up with my typing at such a key strength. In that case, I could upgrade to a Pi. Now, there’s an idea! Doing it this way, I’d completely sidestep the obtuseness of bluetooth. No big protocol to memorize. Just a real simple, end to end setup, with little to go wrong (famous last words).
Back to the keyboard: why bother with the existing keyboard controller? I could just access the keyboard matrix directly! Maybe the Pi would be better suited for this, due to having more GPIO. Taking a look at the search results for “homemade wireless keyboard” – there are a surprisingly high number of items to be found on the internet. But – mostly they’re using the traditional parts for this latchup, and I’d be trying to avoid that. Stay tuned for this project!
So, I’ve added another potential project that would involve both hardware and software – to a growing list.
In figure one, the graphic shows a recent adaptive re-use acquisition. We needed a new bathroom exhaust fan, and so I removed the old one, and placed it in a pile destined for an eventual trip to the landfill.
This morning, staring at the pile, I realized that I was throwing away a gem. Homemade tablet number six was staring me in the face! Its dimensions would fit an eight or nine inch LCD easily, and it even has a ledge for retaining the display! The piece in question is actually the grill for the 1980s era exhaust fan.
A couple short pieces of plastic sheet stock (or similar) could suffice as the end pieces and bottom, making for a very inexpensive little enclosure. It’d be a bit larger than the two smaller tablets I have in the current Pi Platoon.
Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.
Sparkfun is a trademark of Sparkfun, Inc at www.sparkfun.com, and they have no relationship with this author or site. Odroid is a product made by Hardkernel at www.hardkernel.com, and they have no relationship to this author or site. “Raspberry Pi” is a trademark of the Raspberry Pi foundation, and they have no affiliation with this author or site. The Moteino is a product of LowPowerLab, at lowpowerlab.com, and they have no affiliation with this site or author.