News

Digital I/O Touch Detection Code Improvements

Digital I/O Touch Detection Code Improvements

I have been working with the same basic approach to digital touch detection since the inception of the Keyglove. That process goes something like this:

  1. Pull all touch points to logic high
  2. Select possible combination [X, Y] from touch definition array
  3. Set point [X] low
  4. Measure the level of point [Y], and if it is low, then touch combination [X, Y] is active
  5. Increment test combination index and go back to step #2 until complete

At first, this method of scanning to detect connectivity between arbitrary I/O pins without mechanical switches seemed wonderfully functional and easily implemented. I used Arduino’s built-in digitalWrite() and digitalRead() functions, which was the simple solution. It was also plenty fast enough at the time. However, it has a couple of now-obvious shortcomings, plus another not-so-obvious one which I am hoping that I diagnosed correctly.
Read more

Controlling Glass via Bluetooth with a Bluegiga WT12

Controlling Glass via Bluetooth with a Bluegiga WT12

Here we are, one step closer to my ultimate goal of using the Keyglove as a wireless input device to control a wearable computer. For this installment of progress, the milestone is Bluetooth control of Glass, using a Bluegiga WT12 module and the custom HID descriptor that I wrote about earlier. I won’t go into detail about what that descriptor does, since it’s all documented in the other post, but the short version is that it provides a keyboard, consumer page control (e.g. media), mouse, and raw bidirectional 16-byte packet transference.

Read more

Complex Bluetooth HID input with iWRAP and the Bluegiga WT12

Complex Bluetooth HID input with iWRAP and the Bluegiga WT12

Thanks to Bluegiga’s workhorse of a class 2 Bluetooth module and the latest iWRAP5 firmware with custom HID descriptor support, I have now been able to achieve the wireless capabilities I always hoped the Keyglove would have. Keyboard, mouse with scrolling support, consumer page reports, and raw HID packets for arbitrary data transmission. It isn’t fully integrated into the Keyglove code yet, and I’ve only tested it with manual control so far, but the firmware setup is solid. It’s now just a matter of translating the manual control I’ve already done into my codebase.
Read more

Diving back in, and Google Glass plans

Diving back in, and Google Glass plans

The last seven months have been somewhat of an unplanned hiatus from the Keyglove project. As I mentioned in my last Kickstarter project update as well as a bit later in a post on my personal blog, my position at Bluegiga has been taking virtually all of my time. There is a lot more travel, and some odd hours due to the global nature of the business and the kind of support I need to do. This has been getting better over time though—the odd hours part, anyway—and I am absolutely determined to get back into working on the project, for a few reasons.
Read more

VIDEO: Prototype D Autodesk Inventor COM API Demo

VIDEO: Prototype D Autodesk Inventor COM API Demo

Keyglove #10 – Prototype D Autodesk Inventor COM API Demo from Jeff Rowberg on Vimeo.

This video demonstrates Keyglove Prototype D and the Keyglove Kit v0.4 PCB (v0.5 still pending design completion) along with the alpha Keyglove Manager app integrated with Autodesk Inventor using the COM API for true 3D input. This is just a sample of the kind of thing that can be done with the Keyglove. And, honestly, this isn’t even a very good demo due to the early stage of development of the Manager app and the loose mounting of the older revision of the PCB on the glove.
Read more

Keyglove Interface Options

Keyglove Interface Options

As I continue building the code to support all the necessary aspects of the configuration and control protocol for the Keyglove, I am also thinking about the various ways the protocol will be used, and how to keep everything as predictable and flexible as possible. There are both wired and wireless methods of interfacing with this device, but it turns out to be a little more complex than that.
Read more

ATTiny44 I2C Slave Feedback Module

ATTiny44 I2C Slave Feedback Module

Some time ago, I made the decision to move all of the feedback elements of the prototype Keyglove design to a separate I2C-controlled module, instead of using direct I/O pin connections. I did this because I also added three new touch sensors and better Bluetooth link and mode detection, and I simply didn’t have enough I/O pins to satisfy everything at the same time. The I2C bus was already being used by other modules anyway, so adding an additional slave device didn’t reduce the number of available pins anywhere else. At the same time, I freed up five whole pins for other functionality (Red, Green, Blue, Vibe, and Piezo). Not bad.
Read more

Actually, Here’s Keyglove Kit v0.4

Actually, Here’s Keyglove Kit v0.4

So, after extolling all of the electronic virtues of the v0.3 Kit PCB only a few days ago, I’ve gone ahead and created a new revision of the board already. It turns out that it can indeed be smaller, without sacrificing any of the existing functionality. In fact, v0.4 is a full 25% smaller even than v0.3, giving us a PCB that is now a mere 46% of the original v0.1 board’s size.
Read more

Keyglove Kit Progress

Keyglove Kit Progress

Good news on the kit PCB! I think I’ve got a winning combination of size, layout, and functionality. I just posted Keyglove Update #17 on the Kickstarter project page yesterday which discusses some of what I’m going to explain here, but I’ll summarize that bit again for those of you who don’t follow those updates, and include a bit more technical detail here and there.
Read more

Improved WT12 Bluetooth UART GPIO Breakout

Improved WT12 Bluetooth UART GPIO Breakout

While working on the iWRAP code library for the Bluegiga WT12, one of the issues I’ve come across is trying to create a good way to detect and manage active Bluetooth links. The iWRAP firmware, controllable entirely over a simple UART connection, has three different possible modes. As I mentioned in my last post about the Keyglove Kit board, the most efficient solution is to avoid the high-demand MUX mode and instead rely on regular DATA/COMMAND mode switching and active link detection using two GPIO pins.
Read more

Page 1 of 512345