VRbot is flaky, doesn't always work

[Admin]

The problem: Sometimes VRbot works, sometimes it doesn't do anything at all, and it appears to be entirely random. To try and narrow the problem down, I tried two entirely different setups.

Setup #1
I have it plugged in to a USB to 5V TTL adapter. USB power to Vcc, ground to ground, rx to tx and tx to rx. I'm running Hyperterminal on the correct port, and 9600 baud.

I send the character 'b', and it responds with either the 'w' character, or 'o'. If I get 'w' and then transmit 'b' again, it'll always give me 'o'.

But sometimes after plugging it in, it'll never respond no matter what. I'm keeping the setup exactly the same, but it seems so random.

Setup #2
In this setup I'm using an Axon microcontroller. Its running off a battery, regulated to 5V (I measured the battery, its fine), transmitting at 9600. I'm forwarding the response of the VRbot module to a separate USB so I can view it.

Now I turn power on. My mcu is programmed to wait 2 seconds after power up before trying to communicate with the VRbot module. Sometimes the module responds correctly with 'o'. Sometimes nothing. It's entirely random, and I'm changing nothing!

Theory
I have a theory . . . I then keep VRbot unpowered while turning everything else on. Then I plug in VRbot. It then almost always works! I get a very similar effect with my USB setup, too. This makes me think that it requires a very sharp/straight edge power up voltage signal, ie if power up is too slow it won't work.

Solution?
If my theory is correct, and it might not be, this means I have two possible solutions, A) a separate regulated battery which would be annoying, or B) modify the VRbot module by adding/removing components.

I've decided on B, but I can't find any schematics. Most components are SMD without part numbers. One part is labeled PaE7Q, but no replies here:

http://www.veear.eu/Forums/tabid/236/forumid/-1/threadid/239/scope/posts/Default.aspx

I need to locate the capacitors feeding into the regulator, and perhaps even remove the regulator if there is one.

Anyone with ideas?

ps - I also posted the problem here:
http://www.veear.eu/Forums/tabid/236/forumid/8/threadid/385/scope/posts/Default.aspx

[dunk]

i presume the module uses some sort of microcontroller or other processor.
rather than modify the regulator circuit it would be nice if you could identify a reset pin on the microcontroller then just reset after the voltages have stabilised.

dunk.

[TrickyNekro]

If what dunk suggest just doesn't work, why a seperate battery than a mosfet switch for power.... 

Solution is that simple... ;-)

Usually this modules capture what you say and then, turn that to some mathematical values with some polynomials, and compared to stored values...

Try looking at the microphone filtering circuit... Get some greater value filter capacitors, in case your voice sounds more bass than it must be...

Is recording available.... Try recording your own voice then use the module...

But I really doubt it can be rising time... How slow is your raising time for this to happen?

[Admin]

i presume the module uses some sort of microcontroller or other processor.
rather than modify the regulator circuit it would be nice if you could identify a reset pin on the microcontroller then just reset after the voltages have stabilised.

I want to bury the thing inside my robot, where I won't be able to reach it.

If what dunk suggest just doesn't work, why a seperate battery than a mosfet switch for power.... 

It only uses < 20mA, so a bit silly for a second battery. And of course I could add in another switch, which is pretty easy, but I'm looking for a more permanent 100% reliable solution.

But I really doubt it can be rising time... How slow is your raising time for this to happen?

Well, it rises fast enough for an ATmega to run fine . . . I did notice that if I plugged it into my original Axon it'll cause a quick power reset of the Axon, which tells me it's draining quite a lot of power to fill up capacitors.

[TrickyNekro]

Mosfet solution doesn't sound do "el tragic"...

From what I get this module is designed to run under serious noise. As biped robots carry lot's of servos...

So noisy power supply shouldn't be a problem... But from what you tell me it would be a could start to try remove some of the biggest capacitors at from the circuit...

Still again... Those capacitors should have a very low self resistance to cause a serious voltage drop at the power supply... What is the current the regulator can supply... Theoretically it's like connecting a zero volts power supply (short circuit) when powering up a capacitor... Remove the "big" capacitors from the power supply rail from the module as a first step...

An other solution to see if these caps drain such big currents at charging up is to power the module from a low ohm resistor and see the voltage drop across the resistor with a digital scope...

Then you can measure ESR of the capacitor to see if it fits removing it... Solutions many... But you have trial and error in front of you...


Best Regards, Lefteris
Greece

[dunk]

i presume the module uses some sort of microcontroller or other processor.
rather than modify the regulator circuit it would be nice if you could identify a reset pin on the microcontroller then just reset after the voltages have stabilised.

I want to bury the thing inside my robot, where I won't be able to reach it.

i didn't mean manually reset it.

either use an I/O pin on your main MCU to reset it
or use a capacitor to hold the VRbot in reset until voltages have stabilised.



TrickyNekro's solution wouldn't need a separate battery.
if you were willing to switch the VRbot on using a mosfet you could have your main MCU just keep power cycling it until it works.


dunk.

[Admin]

I resolved the problem for setup #1:
http://www.veear.eu/Forums/tabid/236/forumid/8/postid/395/scope/posts/Default.aspx#395

It turns out that it has a huge power drain during power up, randomly knocking out the Sparkfun FTDI USB adapter. The VRbot datasheet only specifies average current, but max current is at least 5x higher. I'm lucky it didn't fry my adapter!

So if you use the FTDI USB adapter with VRbot, make sure you don't use 3.3V, but instead take power directly from the USB 5V line.


But it's not yet resolved for setup #2, still working on testing that . . .

[Admin]

if you were willing to switch the VRbot on using a mosfet you could have your main MCU just keep power cycling it until it works.

I've found that if I manually turn it on and off about 20+ times it'll usually work sooner or later . . . this might be my only solution, although it feels like hiding the symptoms instead of finding a cure . . .

I also found that for some reason it's randomly deleting Indexes in Groups, randomly mixing up the training between the Indexes, and even moving trained Index numbers from one Group to another Group (ie randomly swapping/deleting/adding pre-trained voice data) - yet I'm not even commanding it to do anything like that.

Perhaps random noise during microcontroller bootup sent through UART would send commands like this? I already have the Axon wait for two seconds after bootup before it even sends a command . . . (I don't have an oscope on me right now to check)

The creator won't tell me anything about his circuit, so I have to reverse engineer it and guess what unlabeled chips do. As such t's very hard to figure out how it's negatively affecting my circuit . . . it'll work for ~10 seconds after unpowering it, and power it from my original Axon causes the Axon to power reset - suggesting it has unnecessarily large caps on it . . .

[Admin]

Arg . . . I figured it out . . .

It turns out that despite powering down the Axon II for several seconds, apparently it still somehow stores old UART data . . . I'm not entirely sure how, but . . .

. . . using the WebbotLib bufferFlush() command right after bootup fixes the problem . . .

I'll forward this to Webbot so he can resolve this issue permanently.

[TrickyNekro]

Arg . . . I figured it out . . .

It turns out that despite powering down the Axon II for several seconds, apparently it still somehow stores old UART data . . . I'm not entirely sure how, but . . .

. . . using the WebbotLib bufferFlush() command right after bootup fixes the problem . . .

I'll forward this to Webbot so he can resolve this issue permanently.

That's why reading the manual is always better than relying on ready solutions....

Ehhhh.... This topic never get's old anyways....

[Admin]

That's why reading the manual is always better than relying on ready solutions....

Well, in this case no manual could help here, just hard earned experience . . . I remembered when I had the same buffer problem with the BlackFin camera and thought "why not try flushing the buffer?".

[TrickyNekro]

From the datasheet:

Disabling the Transmitter
The disabling of the Transmitter (setting the TXEN to zero) will not become effective until ongo-
ing and pending transmissions are completed, that is, when the Transmit Shift Register and
Transmit Buffer Register do not contain data to be transmitted. When disabled, the Transmitter
will no longer override the TxDn pin.

So if the buffer keeps the data, on power down that means... It will send them no matter what...
You should check if data received empty is 1 to see if all the data are transmitted before issuing new send... ;-)
So flashing the buffer before initiating the transmitter is the good idea... :-p

[Admin]

I think this specifically refers to while powered up, and doesn't mention about how it retains data on the buffer register after power is disconnected . . .

[TrickyNekro]

Yup... not telling other wise... I just proposes indirectly that you should flush before any start up....

I'm not trying to prove anything... Just saying that reading the manual is helpful... :-p

[Admin]

I also found that for some reason it's randomly deleting Indexes in Groups, randomly mixing up the training between the Indexes, and even moving trained Index numbers from one Group to another Group (ie randomly swapping/deleting/adding pre-trained voice data) - yet I'm not even commanding it to do anything like that.

I fixed the last problem (as quoted).

Turns out to be some strange bug on the VRbot, but can be fixed by following these instructions:
http://www.veear.eu/Forums/tabid/236/forumid/8/threadid/397/scope/posts/Default.aspx

It basically requires wiping the memory using the GUI, doing a power reset for 5+ seconds, then re-configuring it from scratch.

If you're interested, this is the robot I quickly threw together. It was just a basic ghetto demonstration before I add it to my ERP. I noticed that I'm significantly more likely to yell profanities at my robot when it has a voice recognition module that isn't working all the time lol . . .

http://www.societyofrobots.com/sensors_voice_recognition_robot.shtml

Make a Voice Recognition Robot