How 2 Get A Table Lamp to Always Understand "On" and "OFF" and "Dim"

[martys]

"And then I went on eBay and found:
http://www.ebay.com/itm/272729262971"

rstofer please note, you can download any or all issues of Popular Electronics and other similar magazines for free on the web.

[BrianHG]

Thanks again, BrianHG, your help is much appreciated and will help me organize my path to achieve my goals. I am carefully looking over the spec sheet for the PICC MCUs you recommend. 

I can easily see how this project can stay green by allowing the CPU to wake up from ULP sleep a few times each second to take a listen.

I get the idea of adding a trigger word to be said before a command to be used  to waken the  MCU(such as the word "lamp" that needn't be fully recognized, but can cause the MCU to make a waking decision based just on the length window of the sound heard by the MCU.)

Remember, you need not run those PICs at the full 70 mips.  Espicially the DSPIC as the main grouped multiply adds you will be doing for your DCT has a hardware DSP unit implementation cutting down CPU clock cycles/transform something like 5 fold, even another 10x more if you wanted to process everything in floating point.

Also, looking at CoolEdit96/Pro/2K, the spectrum display you see there is 5x or more defined that what you need for good speect recognition.  Only analyzing a selection of bands between 400hz and 4Khz, ignoring the rest, and only responding to the to 4-9 strongest peaks in that range will give you excellent performance.  Do not try to trace out and follow every minor peak in the waveform as some phonetics as you have seen can have even more that 30 between 40hz and 15Khz.  You will become so precise that you software will only respond to 1 person...

[CJay]

This got very silly very fast, there are off the shelf speech recognition chips out there.

If you want to do software speech recognition then be prepared for a steep uphill struggle, this is at least an order of magnitude more difficult than a simple kitchen timer.

Even 'the big boys' struggle to get this right, Dragon dictate, Google, Apple, all have prolems, every speech recognition device i've ever used was less than perfect (often much less) so it won't be simple even with only a few words.

One amusing aside though, I built a computer for a born again Christian friend and put Win XP on it (was current at the time), a few weeks or months later I got a phone call from him telling me he no longer wanted it and I should come and remove it immediately.

Obviously i was curious why, so after a little questioning he told me he believed it to be possessed by evil spirits.

Apparently it was typing satanic messages whenever he had MS Word open (Hi, you seem to be writing a black mass, would you like some demons to help with that?)

Turns out he and his wife have a bit of a thing for schlock TV like CSI and other such rubbish.

Their recent purchase of a webcam had enables Win XP speech to text, which was merrily transcribing portions of the script from said TV programs into open MS Word documents with rather remarkable accuracy given it hadn't been trained.

[martys]

Thanks again for the hints, BrianHG.

 Would I have to deal with the expense of buying a compiler license to work with these DSP chips?

The PIC24EP512GP202-I/SP looks very attractive, cheap enough, and I like it especially since it is available in SDIP and so can be breadboarded easily!

I would have to deal with my unfamiliarity and accept a learning curve to deal with the newness and  increased complexity of these chips. So far I have only learned to be very skilled with 18F PICC chips which are much more math compromised and slower.

On the very plus side, learning to use these chips gives me a potential ability to use higher MIPS in future projects.

Your ideas of voice spectrum limiting and only analyzing  peak voice burst intervals of the data stored sounds like sound advice.

As far as running these chips at highest MIPS, wouldn't the idea of  finishing the Voice Rec processing as quick as possible when a valid trigger word occurs be the fastest way to minimize MCU on time power use? A quick burst of MIPS  power usage would give the quickest result.

I don't know how long it will take learning about DSP to get to a place where I understand how to design code using the features available with a DSP MCU.

However, I must yet convince myself that switching to DSP is the simplest approach sufficient to apply to what now seems be an immodest goal.

(OMG! My Demons!)

[martys]

Thanks Clay for your funny story about voice rec.   Luckily, the only demons I have to deal with in getting this idea to work are my own, and I am enthusiastic about this project but not religious about it!

The big boys may have had trouble getting voice rec. to work, but a small chance at perfect may be achievable because I have a very tiny vocab goal.

In terms of enlightenment, a word to the wise is sufficient.

[Kjelt]

Ok since you are still going on with it,  another few hints:

You're device will be listening 24/7 so you have to trigger it with a start word that is not often used, that word will be the trigger for the software to analyze the following spoken words.
A good word might be Light or Lamp or whatever you want.

Then the second problem arises, the verbs On and Off are almost identical sounding at least the start. That might not be the wisest decision.

Do you only want one dimlevel? Otherwise you might have to mark two words DimUp and DimDown.

[BrianHG]

You're device will be listening 24/7 so you have to trigger it with a start word that is not often used, that word will be the trigger for the software to analyze the following spoken words.
A good word might be Light or Lamp or whatever you want.

This isn't too terrible.  You will already be using 2 words to begin with and you just need to give the lamp a little intelligence.  If the lamp has been OFF for over a minute or 2 and your speech decode has given a 50/50 +/- 10% possibility of 'Lamp On' vs 'Lam Off', just assume the command was 'Lamp On'.  Just reverse this logic is the lamp has been ON for over a minute or so.  If it has been less than a minute either way since the last command, only respond when the lamp has a better, clearer recognition of these 2 main commands.

[BrianHG]

martys, a few things.  On your PCB, make sure you wire up the RS232 com ports so that you can connect the PIC to a PC, with a little PC software, monitor plot and log your spectrum decoder + other variables during debugging.  Also, add a ceramic beeper or speaker to one or 2 of the PWM outputs so your lamp controller can make acknowledgement sounds.

The next step is how are your math programming skills?
Are you expecting to use someone-elses code, or, are you going to process the raw ADC yourself?
How are you powering this thing?

Note that even in ultra low power sleep, powering the electric MIC actually consumes more power than a sleeping MCU will use.
Having enabled at least 1 of the PIC's op-amps, 1 comparator and an internal voltage reference to have the MCU awake on a degree of noise thresh-hold will raise the power consumption from the high nA range to the mid uA range.  Doing some careful data sheet reading and tests, you may not want to use the deep sleep or comparator, just run the MCU at 32khz with ADC running at tight loop around 1khz waiting for the beginning of a spoken word, then jumping to high speed xx mips mode to process, then back to slow mode.  In any event, I would expect this method to consume power in the 100-50uA range.  (not good for 2xAAA batteries power supply, but fine for 2xC or 2xD batteries)  Your gonna need to decide how much power is appropriate VS code and responsiveness.  Powering up and down the MIC opamp and MIC itself might introduce effects you will need to work out.  External ultra-low power op-amps exist which may run at lower power than the ones in the PIC, but, then have very low bandwidths.

[martys]

Thanks Alex Eisenhut, I didn't know there was a cheap pre-fab board available before you sent me a link, but my intention was to try to get my own code to accomplish this goal, and the power requirements of this board and its size are also a bit big since a MCU and some kind of P/S and the on/off/dim triac type lamp power control must also be fit into a tight space in a table lamp.
I am sure this suggestion would work, and would be a good idea to add to any decent-sized robot,  but I am trying to find my own minimalist way to make sense out of only a few words and learn about solving such a significant software/hardware challenge.

[martys]

Very helpful advice on power, BrianHG, "Note that even in ultra low power sleep, powering the electric MIC actually consumes more power than a sleeping MCU will use"
My concept now on how green my mike machine will be means that it shouldn't use more than a watt or so when on and considerably less when idle and waiting for a trigger spoken word.

My yet to be realized idea is that the MCU would be mostly a lounge lizard, to be mostly in a snooze, standby or idle state and when periodically awoken by a WDT for a sample of sound, it would strobe on the power to the Mic and the required  associated circuits for signal conditioning.

I plan to power my circuit with a small valued 250VAC RMS rated capacitor feeding a bridge directly from the mains, since I don't like the idea that the lamp would have to be taken apart to replace batteries and even a small power transformer would be much bigger. Of course, while breadboarding this project, I would use a wall wart feeding a LM317 type regulator so no shock hazards. When finally getting to the point of shoving my hardware into the base, I must also be sure there can not be any shock hazards.

[martys]

Kjelt, I didn't have room in the post title to add  Un-Dim, but of course, what lights up, must lights down.

[Kjelt]

Ok so full dimrange it is. Then another suggestion: add scene command(s).
A lightscene is a fixed setting (usually for more then one lamp but hey you have to start somewhere) which creates the wanted ambience for a certain activity such as eating, watching tv, reading, etc.
So if you for instance can determine a few of these activities with the desired lightsetting than you could add the commands for instance "Light Reading" for the dimsetting required to read a book.
There are so many other possibilities, like Colourtemperature, mix 2700K and 6000K white leds with two seperate full dimmable drivers and you have tunable white lightsource.
Now to take it even a step further, if you replace the lightbulbs with "inteligent" tunable white ledbulbs such as the PhilipsHue that are Zigbee controllable from a single source (the bridge) you only have to build one voice controller that interacts with that bridge and the possibilities become endless and the benefit is that you have more room for your VC electronics.

So that are enough project ideas to keep you busy for awhile 

[BrianHG]

Very helpful advice on power, BrianHG, "Note that even in ultra low power sleep, powering the electric MIC actually consumes more power than a sleeping MCU will use"
My concept now on how green my mike machine will be means that it shouldn't use more than a watt or so when on and considerably less when idle and waiting for a trigger spoken word.

My yet to be realized idea is that the MCU would be mostly a lounge lizard, to be mostly in a snooze, standby or idle state and when periodically awoken by a WDT for a sample of sound, it would strobe on the power to the Mic and the required  associated circuits for signal conditioning.

I plan to power my circuit with a small valued 250VAC RMS rated capacitor feeding a bridge directly from the mains, since I don't like the idea that the lamp would have to be taken apart to replace batteries and even a small power transformer would be much bigger. Of course, while breadboarding this project, I would use a wall wart feeding a LM317 type regulator so no shock hazards. When finally getting to the point of shoving my hardware into the base, I must also be sure there can not be any shock hazards.

The battery example I gave was telling you how long you can power your circuit for 1 year straight before the 2 batteries would be dead.  Powering the mic means drawing 0.5ma.  Running your processor continuously at 32khz instead of deep sleep with adc running to monitor the sound before switching to high speed means drawing another 0.1ma.  You sort of see why deep sleep doesn't help much for power consumption unless you go to a 0 power coil magnetic type mic, which requires much more gain on your op-amp and is very sensitive to 60/50hz noise from the AC mains.

As for turning on and off the lamp, you can use a logic-level input mosfet & diode bridge rectifier.  This will draw 0 power to turn on of off your lamp, though some care will be needed to protect the PIC's io driving the gate and how you power the pic.  Your other choice is to use a opto-triac (draws a few ma to keep turned on) and freely power the PIC anyway you like with anonymity.  You can aslo use a latching relay, with a large enough cap of the PIC's power supply to pulse the relay on and off, still only requiring a low power PSP for the pic.