Thanks Gerald for your helpful insights.
I reviewed the Adafruit tutorial in detail but they don’t get into details such as what the “percentage” difference is between the different gain settings. The 10db gain between 50db and 60db is higher than I thought then! I’m actually relieved to hear you use a lower gain setting than what is default when I leave the gain pin unconnected on the Adafruit board. It helps to explain why MOVI hears me almost “Yelling” even though I’m not when the Gain pin on the Adafruit mic board is left unjumpered. At first it seemed that MOVI liked this best from a recognition point of view, but then only when noise conditions were optimal; add noise and it becomes a serious problem with all sorts of buzzing and popping!
With the division I’ve done on my threshold settings after reducing the gain, I’m down to a few percentage point difference except for the difference between totally quiet (0 RPM - engine not running) and some engine noise (> 0 RPM). I’ll probably try just those two and see how that goes rather than rattling MOVI all the time with different THRESHOLD settings on-the-fly. Regardless, I do appreciate the transparency into how much disturbance it causes MOVI when a request to adjust THRESHOLD occurs, it helps me decide what paths are worthwhile exploring.
Thanks for the update about the FINISH command - that will be cool - often times I have to wait a long time for MOVI to decide it’s time to stop listening, even though I could have promised that long before it made the decision on its own. I’m still holding out for a way to control when sentence listening begins after the callsign so I can make my own externally generated sounds between callsign and sentence recognition. 
Dylan.
Dylan,
I’m still holding out for a way to control when sentence listening begins after the callsign so I can make my own externally generated sounds between callsign and sentence recognition.
Bertrand insisted on this feature as well. I might make that an example program. It’s a bit tricky but it can totally be done already.
Gerald
Unless I’m missing something, I figure the only way to interrupt the drop into BEGIN_LISTEN with the current API is with stopDialog() followed by restartDialog() after receiving CALLSIGN_DETECTED from poll() (I have an open question with you in my other thread about the missing CALLSIGN_DETECTED but that’s a different topic), and then sendCommand(“ASK”). While the sendCommand(“ASK”) bypasses the slowness of ask() by not dropping into say() as the ask() API does, I also found stopDialog() and restartDialog() unacceptably slow to complete for this purpose.
Is this essentially the method you are envisioning or is it something completely different?
Dylan.
Yes, stopDialog() stops the entire ASR system and restartDialog() will restart it. This is not the right method. Unfortunately, and that’s what I learned by having the discussion in this forum, there is no right method in 1.0. That’s why I implemented the low-level command “FINISH” in MOVI 1.1. FINISH will immediately finish the sentence recognition.
Having said that, in 1.0, you can by-pass call sign detection by immediately "ASK"ing. And then you can implement a keyword spotter and have it act as your own call-sign detector.
Ah, got it, FINISH will be the key for this problem as well. I shouldn’t need an example sketch to get going with that once MOVI 1.1 is released, I’m comfortable with the concept.
I’m wondering if I should go ahead and prove my guess as to why my sketch doesn’t (usually) see CALLSIGN_DETECTED as discussed in more detail in my other thread. To try it involves “hacking” the base Arduino library at least temporarily but it would be pretty quick to run a test. Would you prefer to look at my sample sketch without any further input, or would further (possibly red herrings though!) findings be better?
Dylan.
Well, I just haven’t had any time to look at it yet but any hints whatsoever that could cut down on the search would definitely help!
Let me put my findings in the other thread because this one should really be about the external microphone…
Dylan.
I hope this will be a relatively easy question to comment on, but I’m hesitant to think so based on the number of “quick questions” I have been asked in my career.
Anyway, I got to wondering if a bandpass filter between the amplified Adafruit external microphone and the attenuator might help filter out various noise and rumblings that do not fall in the voice frequency range. A circuit like this is what got me curious:
http://www.paulinthelab.com/2012/09/voice-bandwidth-filter-for-podcasts.html
Could that be helpful or does MOVI already do that kind of thing in its hardware and/or firmware?
Dylan.
Dylan,
I’ve been thinking about it: Adding a band pass is worth a shot.
But the results will be a matter of experimentation.
Gerald
I tried the Voice Bandwidth Filter circuit and the results are astounding but not without some effort and one open question. I imagine you won’t be able to comment too much without trying the circuit and seeing its impact on the input to MOVI, but I’ll wrap up with it in any case for your consideration.
The longer story - I tried the Voice Bandwidth Filter without any changes to my code and MOVI became less responsive initially with anything other than a quiet room (car). I put the microphone debug on and found that it was not hearing any engine rumbling, but it would tend to cut off my callsign about half way through. So I started dropping the tolerance. Once I got all the way down to 3, MOVI started to hear my complete callsigns and commands, but continued to “ignore” the engine rumbling at idle. I was encouraged so I moved on to the next trial using 3 as a fixed tolerance.
I was amazed to find that with the Voice Bandwidth Filter circuit in play and a tolerance of 3, MOVI would hear my callsign and commands quickly and accurately while driving up to about 50MPH. I even rolled the windows down at one point and still, MOVI was disinterested in the background noise, hearing and responding only to my voice (I wore only one earbud to listen to the microphone debug which in my understanding is legal!) After 50MPH, things got less reliable and I’ll need an assistant to really listen to the microphone debug to see if it generates any ideas, but I wouldn’t be surprised if it’s just too much convoluted noise to do anything about. Regardless, I’m very impressed with the results I have achieved and would consider it a success!
The open question I have is - would it make any sense to allow us to drop the tolerance below 2 (ie. 1,0) for those of us who wish to filter the signal externally with a filter such as this Voice Bandwidth Filter?
I should probably reiterate the pieces I have in my microphone circuit here because it’s quite a chain at this point:
ADAFruit 9814 Mic -> Voice Bandwidth Filter -> Line-to-Mic level attenuator -> Ground Loop Isolator -> MOVI
Dylan.
I am assuming with ‘tolerance’ you mean the value to the THRESHOLD command? Dropping that value to 1 puts the internal noise threshold at 1%. This means that some MOVI boards will become completely unresponsive as the noise induced by the AGC will be interpreted as speech most of the time. 2% is really the lowest we can safely go. In fact, there is a reason I made the default 5%.
Having said that, let’s look at your concrete problem. I haven’t tried your circuit yet (thank you so much btw., I will!) but I wonder if you should put a small amplifier after your circuit, or for that matter, adjust the Line-to-Mic level attenuator to not be as strong. What is the peak and average voltage you get after the bandwidth filter?
Gerald
Apologies, old terminology from my previous VR board, yes I meant THRESHOLD.
I don’t really want to change anything hardware wise just yet because I have it working so well. The question about the THRESHOLD limit was more out of curiosity than a need given that I was getting close to the minimum allowed. I actually tried 2 as a threshold and I didn’t like it at all, MOVI went back to being slow and unresponsive at times. It looks like 3 is my sweet spot right now.
I don’t have the equipment necessary to measure the average/peak voltages with any accuracy. That said, I did get to thinking that the attenuation may be a little strong with the Voice Bandwidth Filter and the Line-to-Mic attenuator together. I’ll wait for your findings once you try out my Voice Bandwidth circuit and if you have any strong recommendations at that time in terms of optimizing the input level then I’ll consider it again.
I’d like to make a new video sporting MOVI in action in my car, but I’d kind of like to have the new firmware first so I can combine MOVI’s beeps (to prove it’s MOVI doing the work!) with my custom audio callsign responses.
Thanks as always for your insights!
Dylan.
Dylan, Gerald -
I am very happy Dylan shared this thread with me, I think it will solve many of the problems I see. And the bandpass filter is probably what I will need as well. As the motors on the robot are a lot noisier than I would have first thought.
Speaking of the bandpass filter thou, the link Dylan gave is dead now, luck would have it thou that it was archived with "internet archive"
https://web.archive.org/web/20150928145045/http://www.paulinthelab.com/2012/09/voice-bandwidth-filter-for-podcasts.html
Looks like “Paul” moved from having his own .com to blogspot. No need for the “Way Back Machine” after all.
https://paulinthelab.blogspot.com/2012/09/voice-bandwidth-filter-for-podcasts.html
Dylan.
Dylan: Thanks!
No problem Gerald, just trying to help a fellow hobbyist find some success.
BTW. I ended up taking a new position in Las Vegas, NV. If you’re going to be out here for CES or some other show, let me know and I’ll drive my MOVI enabled 1987 Chevy “computer controlled” (early car computer!) car over to show you!
Dylan.
Sure thing!
Gerald
Dylan -
I can see the promo now - “Before there was the Knight Thousand, Before there was K.A.R.R. - There was The E.C.C.C. or Early Computer Controlled Car. Powered by Arduino and MOVI.”
Just need the sensor lights, and a few sound effects…
https://www.youtube.com/watch?v=bnjJ7bGbvts
(I’m going to change these to the black strips (to help blend into the grill), probably add more neopixels to see if I can’t get them to brighten up, and go with a 12v strip (the ones here were only 5v), probably go to a larger amplified speaker too) But it’s a concept at this point.
The wiring diagram is unusable – is there a better one?
Can you tell me the values for C1, R1 and R2? I am trying to connect the Adafruit 1713 external microphone to the MOVI.
I tried the sample circuit from the Adafruit website and this mic really is a sensitive far-field unit!
Thanks.
73, Doug
I have given up on trying to get the Adafruit 1713 working as an external microphone for MOVI. I have exhausted all the options I can think of, but no joy.
The software is version 1.10 and the onboard mic works quite well. When I connect the 1713 and run the ‘SerialMonitor’ example program, I can hear myself through the external mic However, the sound is obviously too loud. So I built an attenuator pad and tried various values for the resistors but no joy there. The mic is very sensitive (it’s a good far-field mic) but that means that it picks up room acoustics and trivial echos that you don’t normally think about, but they are present after you speak to the MOVI and it responds, I’ve tried adjusting the Threshold paramter, but that doesn’t fix the problem either (the problem being loud/soft/loud/soft echos that drive MOVI nuts).
73, Doug