A new AlphaGripper, Yann, is attempting to build a prototype of a
Bluetooth-enabled AlphaGrip. He's been explaining his efforts in
emails to me. Here are some highlights:
Yann: I just had an alphagrip input device ordered. I am interested
in adding wireless capability to it, and thinking this would most
easily (though not cheaply) be done by a microcontroller (possibly the
one already in the device) and a bluetooth module like RN-42-HID
($17). A more direct and cheap solution would probably be BCM2042, but
it's not publicly documented - although some have succeeeded:
http://www.keyglove.net/2011/03/15/interfacing-with-a-bcm2042-bp20422-bluetooth-hid-module/
If you think it's a worthwhile endeavour, I'd like to build a
bluetooth enabled prototype.
Mike: ... that would be great, but I think the major hurdle is
getting power to the AlphaGrip, which currently gets its power from
the host computer through the USB cable....
Yann: Power is not such a complicated problem. USB logic is powered by
5V but operates at 3.3V, so your current controller probably has at
least a linear regulator. A common Li-polymer or Li-ion battery
provides a nominal 4V, which can be similarly lowered as a crude
solution. Even quicker, a common USB battery device - which contains a
Li-ion battery, charger, and 5V step-up switching supply - would do
for a proof of concept that doesn't even alter the power path within
the alphagrip.
A proper redesign might have as little as 1 AA powering a step-up
converter, and you'll likely want a power switch anyway. Just let the
"off" setting allow USB power, and we've got a minimal change. For the
rechargeable setup, I already have power management chips which
control the switching supplies and charging; but the design gets more
complex then.
Having a refurb unit for the laborations would be great. An important
question is how much space is still in the alphagrip, as the module
and battery are fairly large components. Another is what the control
circuitry looks like, as it might be able to operate off even lower
supplies when USB is not required. I'll see when I can.
Mike: Sounds more doable than I thought. If there isn't enough room
inside the Grip, you may be able to fashion something that sits atop
the Grip. In addition to the two USB ports on the top back of the
device, there's a hole in the top front (inside the logo), which could
be used to "attach" a Bluetooth module....
Yann: That hole would be the ideal place to put the bluetooth module
itself, as it's the least enclosed (by either metal or user) spot for
the antenna. With a bit of luck, a battery might fit within the handle
sections... I've ordered a RN-42-HID module from Bluetooth. The
chipset inside is the same as the Playstation 3 Sixaxis controller
uses (they use a module resembling RN-42-N).
[Yann actually ordered a Bluetooth SMD Module - RN-42-HID x1 from
SparkFun Electronics]
Yann: There's plenty of space in the grips, including access to the
bottom feet,
where one could put an extra connector (it's a good place for charging
in a
stand). I can start out putting a power source in one grip and the
bluetooth
module in the other.
As for power, it turns out the microcontroller used actually runs off
5V. This
is not unexpected, but it seems incapable of running from lower
voltages. That
means I'll be using a step-up converter to power the device. For a
redesign,
another microcontroller might be chosen.
For communication, this microcontroller has no UART. That will have to
be
implemented in software. It also has very few external interrupt pins,
so I'll
probably have to reuse the USB pins; a double pole double throw switch
could
permit USB capability, by having the microcontroller check for a high
level on
the D+ pin. It will be tricky soldering but possible.
I don't know what model optical trackball chip is used in this device.
It
appears to be powered from a separate chip (U3), which may well be the
3.3V
regulator I want for the bluetooth module power. If I can't find out
what the
trackball chip is to read its datasheet, I'll have to reverse engineer
the
protocol (presumably going through CN4A).
The LEDs are a fairly sloppy design. Raising them from the main board
rather
than connecting them from the top board costs one PCB, three distance
interconnects, and one plastic restrainer, as opposed to four more
connections
between the two boards (judging from the 3 9-pin connections in place,
someone
thinks those are cheap). Moreover, they are connected using series
resistors,
even though the microcontroller used has four 10mA LED direct drive
pins.
Getting rid of those resistors could free a reel on the pick and
place
machine, so it may be more than a BOM cost. Putting the LEDs in the
top board
could mean moving them a few millimeters externally, bending their
leads, or
using a plastic waveguide. The waveguide option has the nice feature
that you
could use cheaper surface mount LEDs. As the top board only houses 20
keys, a
4*5 matrix would suffice to detect them, so there are way more cables
going
between top and bottom boards than necessary.
The USB hub is probably one of the larger costs in the design, as it
involves
a fairly large QFN chip with two inductors, plenty of capacitors,
resistors, a
crystal, and probably a current limiter on the downstream port, with
its hand-
soldered type A connector. The stated reason to support a mouse on the
same
cable just doesn't seem that necessary when there's already a decent
trackball
in the alphagrip. On the plus side, it's a high speed hub, so odd
hosts that
do not support low speed (like the Pandora console) work with it, and
it seems
to be a properly designed (robust) hub with current limiting. It's a
nice
feature while on cable, but for the bluetooth configuration, it won't
work at
all (and we'd prefer to use that space for the antenna). Also, its
routing is
a bit awkward, with usb traces going all over the place and the
crystal off to
the side.
I've traced the connections for the ISP (in system programming)
connector, the
LEDs, the intraboard connections (CN[345]A) and 16 of the buttons
(it's a
fairly tedious task). Next will be mapping the rest, making a
programming
adaptor for the ISP connection, and analyzing the trackball protocol.
As for getting used to the keyboard itself, I'm making some progress.
I took a
look at the Yaarg remap (the graphics for the Andersen one don't work,
and I
don't run windows), and I'm not so sure I like that because of all
the
chording. For now, I'm learning the layout as shipped, but I really am
missing
easier access to Ctrl, and Shift keys that work (for things like shift-
del,
shift-click etc). I'm also a frequent hotkey and emacs user, so a
layout where
ctrl+[ckyl] is hard to do is not good enough (those are interrupt,
kill-line,
yank and refresh controls in common unix systems).
[We had some discussion regarding the AlphaGrip's USB hub]
Mike: I believe the USB hub was included to allow the trackball and
keyboard to "connect" to the host computer through a single cable.
Yann: That may be the idea, but I think somehing got lost in
translation, because
that's not how it works. Take a look at this lsusb output (for
Windows, the
equivalent is found under Device Manager, show by connection):
|__ Port 5: Dev 15, If 0, Class=hub, Driver=hub/2p, 480M
|__ Port 1: Dev 16, If 0, Class=HID, Driver=usbhid, 1.5M
|__ Port 1: Dev 16, If 1, Class=HID, Driver=usbhid, 1.5M
The hub is device 15 here, and the microcontroller is device 16 -
which
presents two HID interfaces, keyboard and mouse. Even that is not
strictly
necessary but helps by being compatible with the boot protocols, so
the
keyboard works in BIOS as well as modern operating systems.
The second port of the hub (note hub/2p) is simply routed out to the
other
connector. It's not necessary for the built in trackball.
Yann: ... Yesterday I found out about openag5, and thought I should
join in.
The new model has redesigned boards, probably to accomodate the
optical sensor
and its 3.3V power supply. There seems to be a regulator on the main
board,
and with a bit of luck, it will be able to power my bluetooth module
too
(RN-42-HID). The optical sensor itself seems to be an ADNS-35330
(unconfirmed).
I traced a bunch of button connections which I shall cross-check with
your
list. With any luck, the keyboard matrix is unchanged.
Yann: ... While [the OpenAG5 project] appears to have stalled, it
provided good detail on the internals for the AG5; it looks like the
iGrip has the same controller and keyboard matrix. The optical
trackball was added and the programming connector has been extended
(OpenAG5 shows a few vias in random places for PTA1 and PTA3; the
iGrip has them in the ISP
connector).
The trackball sensor appears to be an Avago (formerly Agilent, why do
companies keep renaming themselves?) ADNS-3530, with a default
resolution of
500cpi switchable to 1000cpi. It is connected using four GPIO pins for
SPI and
the IRQ pin for motion detect. This chip is powered by 3.3V, which is
supplied
from the main board via CN4A; this can probably power the bluetooth
module
directly as well. Incidentally, there just might be enough space for
that
module below the USB ports.
I have also found three unused pins, PTE0-PTE2. These can be connected
to the
timer function, which is actually near optimal for my purposes (I was
planning
to use the timer for baud rate generation anyway). This allows
connecting RX,
TX and CTS to the bluetooth module.
Just to turn this into a good news/bad news post, the keyboard matrix
decides
which keys are good for shift controls, and the right lower thumb
group of
keys are simply not.
I now have all the information needed to start writing a new firmware.
I'll
also need to build a programmer to put it into use, but this is pretty
good
for the first week.