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.
I ran into a behavioral problem with the last revision of the kit PCB (v0.2), where anytime I plugged in the Teensy++ module, it simply stopped working. Not permanently, but as long as I had it plugged in. The blinking orange light that indicates the device is running would go off and stay off, even though it would work just fine with the USB cable connected but not plugged into the board. The really weird thing is that it would still do this even with no other modules or connections on the kit PCB.
There are no shorts or other components built into the kit board itself—it’s just a way to simplify connecting distinct modules together—so theoretically, plugging the Teensy++ into the kit board is electrically identical to merely extending the header pins by a few inches, give or take. And yet, this made it stop working. I checked for shorts across the power bus and found nothing. A visual inspection of the board also didn’t help. It just didn’t work most of the time.
I say “most of the time” because there were short spans of time when it would in fact seem to work right; when I touched some part of the Teensy++ module just right or…I don’t even know, really. I never figured it out, because I replaced it with a new revision of the board:
This board is about as small as it can be without sacrificing functionality or vertically stacking components. It no longer has the internal space for the lithium polymer battery, but if that gets mounted separately on the back of the hand, then the foundational PCB can afford to be smaller, which greatly increases the flexibility possible. The PCB is very rigid, and the v0.2 board was big enough that this rigidity was uncomfortable, even though it was otherwise a very convenient arrangement of parts. Even in kit form, I want this to be comfortable as well as easy, so that’s what the new revision is. Comfortable and small.
Another important technical change, which may possibly have had an effect on the behavior, is that the traces on the board are no longer look like a rats’ nets, full of vias and odd routes. My previous arrangement of touch sensor connections was based on alphabetical order and a very loose correlation of major ports (A, B, C, D, E, F) on the AT90USB microcontroller. However, this doesn’t make a whole lot of sense, because the sensors wires come to the board in finger or thumb groups that are not alphabetical at all: ABCMNO4, DEFPQR5, and so on. With a purely alphabetical pinout, this results in a mess of wires that cross over each other a lot. The v0.3 pinout instead uses the grouped approach. I have modified the pins.h file I’m working with to reflect this, and even included a handy little ASCII pinout in the code:
__|||||__
GND | USB | VCC
3 27 | | 26 Y
SCL 0 | | 25 Z
SDA 1 | | 24 a*
RXD 2 | | 23 8
TXD 3 | | 22 9
2 4 | 37.36 | 21 0
1 5 | | 20 A
LED 6 | | 19 INT7
7 7 | | 18 INT6
X 8 | | GND
W 9 | | AREF
V 10 | | 38 B
L 5 11 | 32 . 28 | 39 R C
K G 12 | 33 . 29 | 40 Q M
J H 13 | 34 . 30 | 41 P N
6 I 14 | 35 . 31 | 42 F O
U 15 | | 43 4
T 16 | | 44 D
S 17 |_________| 45 E
36=INT4, 37=INT5
I will try to create a more helpful graphic diagram with this information before long.
There are a few things to note about this pinout. First, there are three new sensors: a*, 9, and 0. These aren’t that new, exactly, but I consider them new since I’m just now getting around to modifying the code to support them. These three sensors go on the thumb; two are on the back side, behind the nail, and one is on the front side below the two that were there before. This provides a lot of possible functionality, should you choose to use it. Of course, any touchset may include or exclude any sensors you want, allowing you to sacrifice functionality for ease if you choose.
Also note the INT6 and INT7 pins, which are have no sensors connected. These are used for WT12 Bluetooth module management. Technically one of them doesn’t need to be an interrupt pin because it’s an output signal (toggling COMMAND mode when a link is active), but it made sense to keep them next to each other, and keeping the interrupt pin otherwise free allows for more future expansion possibilities. While one pin is used to control the device mode, the other keeps an eye on whether there are any active links, which is a very convenient bit of info to have without needing test which mode the module is in, and without running MUX mode all the time (which is convenient and does work, at the expense of more power required).
There you have it. I am very pleased with this revision of the kit board, and it’s already helping me with my prototyping efforts. I still need to fix one remaining oddity with the ATTiny44-powered feedback module (more on that in a later post), but after that, I have no immediate needs for hardware updates, and I can focus on bringing the embedded software up to speed so that it supports everything I have planned for the current round of features.
You can view a complete photo album showing off the v0.3 board here or below:
[fbphotos id=381152548585364]
Leave a Reply