Voice Recognition Touch-Tone Phone

Project Logs

Collapse

PocketSphinx setup on RasPi
Anthony • 06/13/2015 at 22:23 • 0 comments
A good, general set of instructions on how to download/install PocketSphinx can be found on the Carnegie Mellon wiki for this project.
However some steps have already been covered here with regards to the setup of the Sabrent sound card and others, if not familiar with Linux are not completely explicit, so I will summarize here the process picking from the previous log post:
Install the CMUSphinx required 'Bison' and 'Libasound2-dev' libraries via the following:
```
   sudo apt-get install bison
   sudo apt-get install libasound2-dev
```
Download latest SphinxBase, links here.
As of the time of writing the most recent version can also be downloaded from the console via:
```
wget http://http://downloads.sourceforge.net/project/cmusphinx/sphinxbase/5prealpha/sphinxbase-5prealpha.tar.gz
```
Un-tar (i.e. extract the archive by):
```
tar -xzvf sphinxbase-5prealpha.tar.gz
```
Then:
```
cd sphinxbase-5prealpha
```
For my particular (clean) install of Raspbian I found the additional dev packages were required to properly make/compile. The important thing is after the make/compile process you don't see any error messages. If so, usually a short Google search will show what packages should be installed.
```
sudo apt-get install python-dev
```
Then, again, assuming no errors between steps, configure, make, install/compile:
```
   ./configure --enable-fixed
   make
   sudo make install
```
Now to install PocketSphinx:
```
cd
wget http://http://downloads.sourceforge.net/project/cmusphinx/pocketsphinx/5prealpha/pocketsphinx-5prealpha.tar.gz
```
Un-tar (i.e. extract the archive by):
```
tar -xzvf pocketsphinx-5prealpha.tar.gz
```
Then:
```
cd pocketsphinx-5prealpha
```
Again, for me at least on raw Raspbian I had to ensure to install the 'swig' library before proceeding:
```
sudo apt-get install swig
```
Then configure, make, build:
```
./configure
make
sudo make install
```
Note: The make step here might take awhile-- 10~15 minutes of building right on the Pi.
Alright, almost there, just one last thing in adding in our required paths:
```
 export LD_LIBRARY_PATH=/usr/local/lib 
 export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
```
Now test to ensure everything was installed okay by running:
```
pocketsphinx_continuous  -samprate 16000 -inmic yes
```
Once the 'Listening' prompt appears on screen you should see an output of recognized words spoken into the microphone.
Adding/Enabling a Sabrent (C-Media) USB Soundcard to the RasPi
Anthony • 06/09/2015 at 16:11 • 0 comments
Seeing as this is my first project working with a variant of the RasPi, I will admit I do have some gripes with it. This is especially the case if one has worked with, for example, the Beagle Bone Black before. While I didn't expect the Pi to be anywhere as capable of a board, I was rather surprised that even some standard features found on seemingly much more 'simple' boards (like the Arduino Uno) that either are not present on the Broadcom chip, or simply haven't been fully broken out to the GPIO.
Sound on the RasPi is a strong example of this. While I knew going in that only output and not recording capabilities were present, I thought going in that there might instead simply be the possibility of using the on-board ADC to create in software a basic recording program suitable for voice commands.... Only, unlike almost every other board out there, the RasPi has no on board ADC. So, okay, it is only a few bucks to add an additional one.
Yet the disparities tend to go further as one realizes the Pi, even for a chip of its size only has two PWM pins available (where the original model had almost an unbelievable single pin only). My original plan was to use the two PWM pins to provide the proper DTMF signalling combinations with a low-pass filter to facilitate dialing.
Only yet another issue crops up here, which is of particular sensitivity in this case. There are, in fact, other PWM pins on the Broadcom chip itself, but in this case they are being used to provide the sound output, and seeing as this is essentially a sound only application here, stories of issues cropping up with playing sound while working with PWM started to make this sound like a further 'no-go'.
Yes, one could always go out and pick up a DTMF Tone Generator IC.... But then we are really starting to add a good deal of cost, which was part of the reason why the PI was the development platform in the first place (it is cheap).
Thus, seeing as one can pick up a USB sound card at places like Microcenter for a mere $10, cheaper than any of the above two options, in this particular case I ultimately decided in this case 'simpler is best'. I would have liked to do all this work simply on the board, but at the same time I think in the end it represents something of that 'engineering trap', of wanting to add certain portions of additional hardware, and thus have a more 'advanced' design, when really in the end, a cheaper (not to mention simpler) option already exists.
In any case, having tested I can say the Sabrent (or some other variant of C-Media chipset) is rather quite easy to set up. Adafruit has already complied a rather excellent guide on ID'ing the chipset and initial configuration posted here, so rather than restating things, I would go through that guide first.
One thing they do leave out though is the recording features of this card. I have, in the past, heard stories of people having difficulty getting audio recording to work. However, with the build of Raspian (2015-05-05) it seems to work for me basically 'out of the box'.
Once audio out as per the Adafruit guide is tested and running properly, one can test the recording capability by running the following from the terminal:
```
arecord -vv -fdat test.wav
```
Where Ctrl-C will cease recording.
Then try playing the sound back via:
```
aplay test.wav
```
The one issue some people have run into is first one needs to ensure their mic/device is not muted in ALSA. The easiest way is via the mixer:
```
alsamixer
```
The important things to check here are then that 'Mic' is selected (and that it is the C-Media card you are using as in the upper left hand corner)-- Use the left and right arrow keys to navigate-- And that the second box in red reads 'OO', not 'MM' (which stands for 'mute'). A device can be 'unmuted' by pressing the 'M' key, and the volume level for each device is adjusted via the up/down arrow keys.
If you are having problem with recording, check these settings and try again.
Connection Options
Anthony • 06/06/2015 at 01:05 • 0 comments
At some point in this build one has to decide how to wire up the Pi to the actual phone/line before any magic happens.
In truth, there are two ways to go about this, so I will cover the 'safe', 'approved', way first, and then the (I feel) much more robust option with a word of caution.
Method 1: Place the device between the phone and the handset.
This is also the 'easiest' choice as it avoids having to play around with any of the high voltages of the incoming phone line itself, and at this intercept point, basically we are dealing with a small speaker and a mic.
Further, at least initial investigations suggest the i/o signal here in most cases should be at standard 'line level'-- meaning aside from splicing the audio signals from the PI (and more on this in another post), no other intermittent hardware is required.
One would need a pair of suitable 4P4C (RJ9) connectors like this, but otherwise here, not much else, beyond a second headset cord to bridge the connections, required.
Pros:
- Inexpensive/minimal wiring.
- Except for just a few components, a little bit of 'hacking', and a few 'off the shelf wires', no secondary external PCB required.
- No potentially 'high level' voltages involved, minimal danger to the Pi board itself, or personal risks of bad wiring pissing off the phone company.
Cons:
- While all of the above are, I feel, great pluses a big problem with the above design is that it simply 'doesn't work' if you have a cordless home phone system-- Or there is no 'headset' to plug into... So more on this, in the next section.
Method 2: Intercept the line.
Again, a disclaimer here, not because I am at all 'into them', but this is designed, fundamentally to be an assistive technologies type project, and not your 'casual hack', so I would not want to risk, playing with higher voltages, either 'troubles with the phone company', or if something isn't sourced or soldiered quite right, something burning up and starting a fire.
Let us presume none of the above, as PSTN is, today, very, very common-- But at least by way of my own searches, it seems somewhat difficult to find the exact standards for interacting with such devices, so if there are any 'tried and true' analog engineers that know my interpretations require a crucial correction, I would appreciate it.
In my own household today, I know we just have a separate device that just 'simulates' such conditions, and otherwise we're just VoIP.
With regard to resources, here is possibly one of the greatest resources on the subject I have found, basically a carefully curated archive of old 'UseNet' posts, and while I recall those days, I am not yet confident, still, in interpreting a circuit composed in ASCII.
So, 'ripe fruit' of this page (and other explorations), invokes 'two in mind' style of designs, either here:
For the needed interface circuit (though note a 'correction'-- the Bourns LMNP-004 is no longer readily available, unless being 'totally-retro' one wishes to sacrifice one's first born child for it. However, reasonably today, in either SMT or through-hole style, one can easily discover a suitable modern replacement (or for 'cliff-notes' assuming through-hole style, this should work, as a replacement, just fine.
Granted, an attentive observer would quickly realize there is no 'hook', or pick-up trigger here on this line.
I have, already, scoped out a few other potential design models (or that is to say 'circuits between jack and line'-- Many other projects are out there to gain power, an while yes, in an 'emergency' situation a good skill to know, not an 'everyday' practice I'd like to instill.
Lessons Learned (Part 2)
Anthony • 05/30/2015 at 07:23 • 0 comments

So, earlier this week the drill bit set arrived-- A couple of points, first, on that:
It really, for the cost, is not a bad set. That said, seeing as I do not yet have a full CNC setup and have never worked with such small bits before, a couple of things to point out.
For one, it is not even worth bothering trying to use PCB bits without a drill press-- in all of two seconds, they will just break. I knew this up front, but even with the sort of shaky drill-press I have (while the Y axis is tight, the X axis has a tendency to 'float' due to vibrations when the drill is 'on'), a couple of other experiences worth mentioning.
Typically, when using a soft bit into a hard material, you can (or may even need to, especially if the bit is not sharp enough) perform a series of successive presses into the material-- part of the reason being to remove any extracted material from the bit, to keep it from completely seizing up in the hole.
However, that just doesn't work in this case, either because of the strength of the bits themselves, or that the tolerances are just so small. Ultimately, it is sideways torsion, less than downward force that will cause a bit to snap, and out of the box I broke two testing this process (also, for that reason, always remember to wear protective eye-wear).
So, what I found is that while yes, it is key to 'steady' or support the PCB from underneath while on the press, unless you have some sort of uniform type of solid sacrificial support, such as engineering foam, regardless, under the pressure of the drill, with a large enough sized board, it will start to bend.
The immediate tendency then is to back off-- but don't-- Go careful and, as always, slowly and the bit won't snap and you'll have a nice drill out.
The Learning Process
However, unfortunately with the success of this step, I also had gained some confidence with re-soldering the cheaply attached rocker switch, and though everything functionally on the phone was working at that point, some wires had already started to come of the much larger 'bus' wire assembly, so I decided simply to cut, strip and rework that too.
Yet, this is/was/has proved to be a mistake. Good soldering truly is a skill which I take every opportunity to improve at. However, it rather is a 'lost art' in the similar sense that 'wire wrap' once was one-- Or in technology, if never 'Art', certain methods are rather obsolete, especially as more and more packages arrive on the market only in BGA, or in SMT, or 'surface mount', are already amenable to the much simpler process of reflow.
-- Enough of feeling 'slightly defensive'-- After the rework process, and not, I believe, because of the drill-out, unless there is some hidden ground plane unseen, the dial buttons on the keypad are no longer tripping by jumping the circuit as they used to.
Given this setback, I feel it was actually useful, as I have been able to consider both the project itself and it's ultimate goals. Originally I thought of this project as something any very 'young' budding RasPi 'engineer', could DIY, or go above making just another video game emulator, but the cutting and the drilling and the like....
So, yes, hunting around on the board, I am confident I could discover/find/resolve the apparent short connection-- But back for a moment in the learning process in all this:
As mentioned earlier, this board is a combination of through-hole and SMT, together really aimed at minimizing cost (or cents of cents on the dollar), in kind of an interesting way-- Hobby or low scale production products usually tend to be just one or the other.
However, almost all through hole applications are either plated through-hole, both for the sake of 'inter-board connections'-- And, while I have never quite been a fan, though this is definitely why the iPhone always costs, somewhat, so much, and though of course this is SMT, between the two obvious 'green' layers of chips on the front of the board, there are at least 14 additional layers, of power, ground,...
Read more »
Hacking, Design, Economics
Anthony • 05/19/2015 at 04:01 • 0 comments

While I am waiting for the drill-bits to arrive I thought I might point out a few points of caution to be observant of on this project, as well as a few general case observations as regards Electrical Design (at least as far as production).
First, this is, basically, a 'commodity' phone, sourced and made in China, likely transported by truck, boat, crossing oceans, and in turn, a vast logistics system such that, at least presumably, every party makes some profit on what ultimately is a $20 Walmart item.
I remember reading a few months ago a related tale from a third party related by Scott Rider, as part of his 'Mostly True Tales' segment on the Adafruit blog (found here in Part 1 and Part 2). The gist of the story being the experiences of an Engineer at Blackberry, and an example of on a 'high-volume' item (in this case ~3.5 million units a year), even the potential single part price difference on the order of fractions of a cent ($.01123) between parts can, potentially, result in many hundreds of thousands of dollars of cost savings over the long run.
The story is interesting both for that point, and for the way, well, things actually turned out (i.e. politics).
But I think part of the take home is the fact that whenever possible on a low margin, high volume item, corners will sometimes ruthlessly be cut.
Granted, also, these days, at least in the West, for a desktop phone (as opposed to say a cell phone), who goes to have it fixed/repaired anymore ?
So granted, the design here was never really intended to be opened or tinkered with, and if left on its own, likely would function just fine with no problems.
However, if one has to hack, change, reverse engineer one suddenly has to be aware of some of these design issues.
Point in case here relates to the structures of the bus lines within the phone. Below is the cable (or was the cable) for the rocker switch (or the button that determines whether the phone is on the hook or not).
The red arrow points to where it was connected. And very honestly, this came off very, very early on in the build, before the drilling stage, not because it became caught, or was pulled, it just 'moved' or bent a few times and kind of snapped right off.
Now on a more expensive item one might expect to see connectors here on either end, but again this is low cost.
Further, there is evidence that from production that they new the solder joints were not very strong as one can see the cable was further affixed with hot glue:
After removing the surface glue and sucking out the solder from the opposite side, I was able to reattach this connection with no wields between the contact points and a much stronger joint connection-- it can be pulled on now and has been tested working.
However, one might say, well, its only a three wire connection, not too much of a big deal...
Yet the much larger bus connection to the screen is rigged up in just the same way, and would take much, much longer to have to rework.
In any case, something to point out and a word of caution.
Possible Alternative to board drill-out
Anthony • 05/18/2015 at 10:53 • 0 comments

I am presently still waiting for the specialized PCB drill set I ordered to arrive, as it is required in certain very tight spots around the outer traces, especially the speaker button.
However, in doing research for this there is, perhaps another potential alternative to drilling for transistor placement: The silver conductive ink pen, a product offered by MG Chemicals and others.
Below is a brief video demonstrating their use. Skip to 47 seconds to go by the ads and other unneeded info.
These pens can be a bit messy, as can be seen in the video, and I am not quite sure how well they work on top of the solder mask (so one might want to use the fiberglass pencil to remove also, in addition to the pads, the planned traces one wants to make with the pen).
In any case, in the end, the result might not be all that pretty, but I think it could be a viable alternative to drilling to make transistor connections.
Transistor Placement
Anthony • 05/13/2015 at 02:02 • 0 comments
So that we have our pads/traces setup, the next question is how do we best connect our transistors ?
For a refresher on transistors SparkFun has a pretty good tutorial, including amplifier applications, so here just the basics we need for this project.
Also, keep in mind since we are only interested in the switching characteristics you could use either NPN or PNP transistors for this project. NPN just seem the more intuitive to me when used for a simple switching application.
Personally, I think some tutorials get into too many of the possibilities or potential uses of transistors up front (though the additional capabilities are well worth learning about), and it thus makes a bit confusing as one starts thinking, should I use NPN ? PNP ? What's the difference ? Base, Emitter, Collector !?! What does it all mean !
For a case where it is used only as a digital switch, either is type isfine, as long as it is oriented the proper way (more on this in a minute).
The way I choose to see it is rather like this:
1. First, do I want the switch to be 'on' (short-circuit) when the signal from my Raspberry Pi is :
- 'high' / 'on' / '1' / 3.3 V -- Then choose NPN - or read 'NPN' as 'on when positive'
- 'low' / 'off' / '0' / 0 V -- Then choose PNP - or read 'PNP as 'on when negative'
- Thus it is the 'middle letter' that determines the switch state 'on' configuration.
- Please note the above are only ways of thinking that I have found to be useful mneumonics: 'N' and 'P' above actually stand for 'negative' and 'positive', and thus the term 'bi-polar' transistor, as at least two poles are the same. Tech Note: For the particular transistors we will use in this tutorial, this also further simplifies in so far as of the three transistor legs, the 'switching (i.e. on/off)' or 'base leg', as we will get to the details on in a minute is always 'the one in the middle'. However this is not the case for every model of transistor, so always double check the datasheet.
[From now on this 'bubble' will signal a learning point, but also a total digression]
A very reasonable 'thought point' crops up here based on the above. If, simply speaking 'intuitively', when we think of switches, 'on' tends to mean 'it has power', or is at a positive voltage and thus at a 'high' state (more the terminology most commonly used with MCU's like the Pi because the actual output voltage may differ. For example, unlike the Raspberry Pi, or Beaglebone Black, an Arduino Uno has a 5V max switching output. In either case though, 3.3 V or 5 V, when the switch is 'on' it is considered the 'high' state.
So, okay, I am trying to design a circuit with a switch, why on Earth would I like to confuse myself by selecting 'PNP' (on when negative, or voltage zero, 'low' state, versus 'NPN' ?).
Well, PNP does have some additional properties that at the more advanced level are more suitable than NPN, but we can also bring this question right into focus with the RaspPi.
In this project we will be using an AC adapter to power both the RaspPi and the additional, call waiting, etc, functions of the phone that typically require batteries.
I mean, yes, you could use the in-built battery box to power the whole subsystem itself, but the phone itself has an ultra low power MCU on board, as after all it really doesn't have to be 'always on', or process natural language, only interpret some basic data to a low power LCD.
The RaspPi, however, while it certainly can be run off AA batteries, is decidedly more power hungry. Obviously, having to change out batteries < every 24 hours is completely unsuitable for an Assistive Technologies type device.
Yet, let's say we wanted to use the RaspPi for some other project and wanted it to run both continuously and on only battery power.
A couple of points here crop up, first and foremost is that the RaspPi, unlike most Arduinos, is only driven presently by a very narrow power supply range of 4.75 - 5.25 V, thus, admittedly for this conception to be a 'true reality' one should also look up the...
Read more »
Lessons Learned (Part 1)
Anthony • 05/11/2015 at 01:28 • 0 comments

While at first I had hoped this project to be every child's 'next step' type of project from just working on the Pi alone, or adding a few 'canned sensors', and though the general 'Hack-a-Day' community/audience does tend to be 'generally mature', it has come to my attention that if you fancy yourself a 'young hacker', for one, in the previous step, yes, 'DON'T BREATHE IN THE FIBERGLASS DUST', just carefully lean the board over and blow it out like 'fairy dust' into the trash.
On the net, I have seen some people wearing surgical gloves at this step, but that simply is 'too much', as long as you are careful and gentle with your etching it is really not that kind of scenario.
However, the 'next step' does require some 'adult' supervision-- Or, if you are a really clever kid, basically what we are dealing with here is some variation the game 'Battleship!', with a keyboard matrix circuit for the buttons and with that, the presumption that only one key will be pressed at any time. So thus these traces must be leading 'somewhere' and at the end point presumably to an IC for processing.... And so why all this 'nonsense' (to come), why not intercept the signal at the source and hack the IC ? Or better yet, place a very small DIP/SMT IC between the IC and the button sources to produce just the signal one wants ?
And, yes, these would all be more clean and 'advanced' solutions, if one wants to spend a great deal of time learning about 'this particular phone', but, in the end, that is not what either hacking or engineering is about.
For example, I cannot possibly imagine this phone is running some sort of ARM processor on its front end, so it is likely commodity and small.
On the other hand, the keyboard matrix layout is likely universal to any device and almost all such class of phones. Thus it is both the easiest point of access and 'most obvious' point of attack for this particular problem.
---
When starting on your own design, yes, within conventions, at least whether you want it to be 'comprehensible' (or sometimes not), you are free to design as you like-- But working backwards, always look for the 'open door'. As you get more skilled in electronics you will see more of them, standard circuits, etc.
This isn't 'being lazy', rather 'building your skill set'-- And just as a 'real' example I'd 'heard' of keyboard matrices and had some understanding of how they work, but never, before this, actually played with/constructed one myself, because in the end we all have *different* areas of expertise/experience (or I am 'more comfortable' with ICs, but I just said, in this case, let's try it).
Button Trace / Pads
Anthony • 05/08/2015 at 15:15 • 0 comments
Board Rework / Revealing traces
Anthony • 05/08/2015 at 02:40 • 0 comments
The transistors I ordered arrived a bit earlier than I expected, so the next step is to prep/test the board. While transistors themselves have many more much 'interesting' properties (i.e. serving as amplifiers, etc), for our basic use case here we will be using them in their simplest form, as basically 'digital switches'.
First order of business then is to remove the solder mask from the top side of the board to get at the copper trace. There are also 'chemical' means of doing this, but unless you aim is to strip the entire surface of the board, after using the fiberglass pencil I would say there is no better way to do it.
'Before and After', revealing several traces:
A couple of points to note:
1. For one, this phone's PCB makes it pretty 'easy', as all the button functions (i.e. numbers, etc) are listed clearly on the top silkscreen.
2. The goal of at least this project, as mentioned, is to preserve the functionality of the original phone, so I chose points in the matrix 'outside' of the black carbon touch points, but not 'too' far away as to be unable to be jumpered with a DIP transistor.
3. It does take a tiny bit of effort to take the mask of, but there is no need to press too hard. Just 40 seconds of gentle scrubbing not only reveals the underlying trace, quite cleanly, but also in contrast to other abrasive methods does not remove the copper.
4. As this was my first time using such a pencil for this purpose, I did make one mistake early on, I should have anticipated, but regardless here, also, is how to solve it. The pencil itself is of a reasonable width, which makes it great for the really 'wide' traces generally seen here. But a few of them on the board are either small, or in a tight corner beside other thin traces. If not careful you may expose other traces you did not mean to, which in of itself won't really 'effect' anything here, but will be a potential problem when we go to solder, as the solder mask is typically repellent. Easy way to solve this is just to use a piece of electrical tape to masque your circuit. A 'mistake', first seen below, and then the masque, in another use case:
One last thing is just to ensure we are using an 'appropriate' transistor for the application, also worth pulling out the multimeter and jumping a connection in just the same way so as to measure current flow.
As I had expected in a modern circuit like this, current draw is really, really small on the order of .08 µA or 'microamps'.
Thus a selection of NPN Bipolar PN2222 transistors should be just fine.