PTT is no more

I’ve finally gotten rid of the need to use a Push-To-Talk button. In addition to removing the code that actually waits for it to be pushed, I improved the utterance detection slightly, so that it doesn’t go off with small noises and feed garbage into the modules. In my relatively quiet office, it seems to work well, though it feels a litle rushed. I’m prompted to speak (by the beep), before I’ve finished forming my thought, but it seems to handle the pause–where I recover my train of thought, well. It remains to be seen how it would work in a noisy environment.

The other improvement that’s still needed is to handle the end-of-module more gracefully. The module exits and you’re immediately prompted to speak without the phone setting any context. I think this should be relaitvely easy.

Mixed success at #EBMF19

So the East Bay Mini Maker Faire was a mixed success. A few people were able to get the phones to work fairly well, and even played a few games, and the wifi worked reasonably well so I was able to administrate and monitor the phones.

However, the phones mostly were mishearing people in very frustrating ways. In the “Guess the Animal” game, it was fairly consistently hearing “yes” as “no”, which means that the first question “Are you thinking of an animal?” just kicked them out. It was also consistently mishearing the initial interaction as “Status”, which was bringing up the internal status message until I disabled it entirely, which was then misheard as “Repeat” for “repeat after me”, until I disabled that as well.

Additionally, some people were having trouble understanding the phones, so I switched the default text-to-speech module to Espeak, which, while robotic, is easier for people to understand.

Most confusingly, when the Animal module did work, the first real question–“Is it a mammal?” seemed to stump a fair number of people. I understood when the 9 and 10 year old kids didn’t know what a mammal was, but I thought most adults would. Maybe I should redo the database with clearer questions, but apparently I’m not a good judge of what would be well known to most people.

As for future directions, I think I’m going to have to start using the dials as an input device for simple choices. My wife also things I should have a small display that clarifies what the last thing the phone said, but I think that ruins the aesthetic.

East Bay Mini Maker Faire

This is a bit last minute, but I’m going to be presenting the phones at the East Bay Mini Maker Faire on Sunday, October 27th (3 days from now). It’s going to be held at the Park Day School in Oakland (California). I mistakenly believed that when when Maker Media folded (since sorta resurrected), that all the Maker Faires would cease as well, but it turns out that all except the Bay Area and New York maker faires were independent (but licensed), and will mostly continue.

I haven’t really done much new with the phones, other than minor code tweaks and additions to the animal database for the “Guess the Animal” game, but I’m hoping that it will be quieter there, and the phones will actually be usable, though I will have my test rig with headphones available so that people can try that if they aren’t.

Hope to see some of you there!

Oh No! Not Make!

I was dismayed to hear last Friday about Maker Media ceasing operation. I heard rumors at the last Maker Faire that it would be the last Maker Faire, but I didn’t think the demise was that imminent. The CEO/Publisher of Maker media–Dale Dougherty, is a former boss and acquaintance of mine, and he stopped by my booth as I was setting up for #MFBA19 and chatted with me. We chatted about the gruephones, old times and mutual acquaintances, but I never got the impression that he was worried about the future. Either he’s got a great poker face, or I’m notoriously bad a picking up subtle cues. (Probably the latter.)

I really hope he manages the minor miracle of resurrecting the various maker faires. I would be sad to think that those whirling maelstroms of creativity and madness would cease. I was hoping to show off the phones at the East Bay Mini Maker Faire in October, but that’s probably not going to happen now.

More chip computers

I wrote last year about the demise of, the maker of the CHIP computer inside the gruephone. I thought that meant that all future gruephones would be based on the Raspberry Pi series, mostly the Raspberry Pi 3B or 3B+.

So I was astounded to discover that you can still buy chip computers, though for double to triple the original $9 price. (I have speculated that low price was the downfall of the company.) I immediately bought 2 for about as much as I would have spent on a single Pi 3B+. I have since discovered that you can even get them on Amazon, though I suspect it’s the same company. I think they’re just selling old stock though, so when those are gone CHIPs may be scarce again. It’s an open-source design, so in theory some company could make more of them, but it doesn’t seem likely.

Don’t get me wrong, the Raspberry Pi is an amazing little computer, and for under $50. It’s got twice the RAM of the CHIP, and over 4 times the processing power, plus multiple USB ports and an ethernet jack. However, there are several things that make it less attractive for an embedded system like the gruephone. It also has a considerably higher power draw at idle, and combined with the lack of battery management on-board, makes it a bit more challenging to work with than the CHIP was. Also, when you plug the CHIP into a usb port, it not only charges the battery, but also provides a serial terminal, which is invaluable in debugging WiFi settings and such. The Pi is also relatively large as single board computers go, which is important when you’re trying to shoehorn it into a phone.

All those shortcomings are not fatal, but there are trade-offs. The larger footprint is made even larger by the (fairly flaky) GeekWorm UPS hat for battery power and management[*]. The higher idle current means that I only get around 6-8 hours of battery life using a 2500 mAh lipo for my Pi based computers, vs. about 15 hours for the CHIP. (I’ve since replaced the 2500 mAh pack with a monster 6600 mAh pack, and that makes the CHIP almost 2 days.) The bigger footprint also means that I’ve focused so far on building the chest phones, which I thought would have more room, (though that might not be the case.)

Since I will soon have 2 more CHIPs, I plan on building the multi-line phone using one of them. We’ll see how that goes. One of the downsides of the CHIP computer is that it has fewer general purpose GPIO lines. It has plenty of pins, but they’re mostly reserved for the HDMI and VGA daughter cards, and those are useless to me. There are only 8 general purpose GPIO lines vs. over 20 on the Pi. Another major downside is that the CHIP only has 4G of flash storage, and that’s soldered to the board. When that FLASH memory finally dies, I can’t just swap in a new sd card the way you can with a Pi.

[*] Though I’ve bought 4 Geekworm UPS hats, I really can’t recommend it. 3 of the 4 have broken down in some way, though at least one of those was my fault–plugged it in offset by one set of pins, which shorted the power to ground. The other two have a problem where the microcontroller that manages the charge/discharge stuff becomes wedged, so that once you start discharging it, it has to drain all the way down until the protection circuitry kicks in and turns off the battery–which that causes the charge controller to reset and then it will charge again. It doesn’t cause the Pi to reboot, so I live with it, but it’s less than ideal in many ways.

Gruebox 2 lives!

I finally got Gruebox 2 (the grue-phone based on the rotary chest phone) assembled and sorta working. It’s put together, but I’ve redone the solder joints between the handset and the speaker and mic jacks several times, and they’re still really noisy and temperamental. I will likely have to pull it apart again for some further diagnostics, since most games are unplayable (and in many cases unlaunchable… since it can’t even parse the game names.) I have successfully played “Guess the Animal” and gotten the phone status, but Zork was painful, taking 3 tries just to quit the game.

A cap at a jaunty angle

The box-phones are coming together. Gruebox1 (the touch-tone one) is more or less complete, and Gruebox2 (the rotary one) is almost ready to be assembled, however I’ve noticed that the voice recognition is abysmal, which is strange because when I was using an old computer headset to prototype them the recognition was passable, if not perfect.

My first attempt at debugging was the enable the echo feature of the dial-a-grue code… where it echos back what it recorded/heard. Using the phone handsets there was significantly more background noise than using the headset. I blamed this on the old microphones in the handsets, which have significantly higher impedance (~5Kohm) than the mic on the headset (500-800 ohms). My thinking was that the impedance mismatch of the usb dongle I’m using and the mic was causing extra noise/poor signal.

However a little research leads me to believe that the impedance mismatch is unlikely to be the cause. When I posted about it on the Adafruit forums, Their local guru suggested that I create a simple filter using a smallish capacitor to filter out the high frequency stuff that was part of the noise. That sounded plausible, so I acquired a small set of caps in the range of 10nF to 100nF to try and filter out stuff above 3KHz. Unfortunately, the recognition rate was, if anything, slightly worse then with no cap at all, so I’m back go square one.

The only path forward I see at this point is to use different mics, though this is fraught with difficulties, not least of which is finding mics that will fit in the handsets and work better, without requiring much power. The chances that I can find suitable replacements before the Maker Faire are slim.

Notes for GrueBox 2 rotary mechanism wiring

This is the wiring block from the rotary mechanism:

Rotary wiring for GrueBox 2

The connections are as follows with the dial facing down with the wiring lugs at the top, from left to right they are yellow, blue, white, and red.

Blue, white, and red are open when the dial is at rest, and closed when the dial is rotated.

Yellow and blue are normally closed, but pulse open N times when the number N is dialed (10 times for a 0).

Blue and white are connected together by default, and will probably be used as a common ground point Since blue and white are shorted when the dial is rotated, the blue can act as a ground with yellow and red being used for GPIO connections on the Pi. White can remain disconnected.

I’m considering using the red line as equivalent of the push-to-talk button, since I don’t have a better solution at this point. The alternative is to either add a button to the phone (which will ruin the look), or remove the need for a push-to-talk button altogether, which is technically challenging, especially if I’m hoping to operate in the relatively noisy Maker Faire.

Miracle cure

There’s an old engineering meme about wd40 and duct tape. It’s really true. The dial mechanism on the rotary gruebox was slow and balky–running maybe 1/4 the speed it was supposed to, and one shot of wd40 and it’s running right as rain.

Contrary to popular myth, wd40 isn’t a lubricant exactly. It’s mostly a solvent with a little bit of lubricant. The solvent dissolves whatever’s gumming up the works, and the small shot of lubricant gets it running smoothly again. It’s not a replacement for proper lubrication, but it’s amazing stuff nonetheless.