Get the SoR Robotics Android App on Android Market for FREE. See this forum post for details.
0 Members and 1 Guest are viewing this topic.
If I put the decoder in "latch" mode, then the motor will run forever as soon as I hit the "drive" button (I checked, all the decoder outputs are frozen while the motor is running). If I put it in "momentary" mode then the motor keeps hiccuping off and on as it gains and loses the the signal!If I unplug the motor and put a multimeter on the header, it works perfectly, it seems like the problem only occurs while the motor is actually running.
At first I thought it was an EMI issue, but then I realized that if I'm in latch mode, I can get the motor to stop by turning the remote control (encoder side) off and on again (just off won't do it), which doesn't make sense at all. Maybe it can receive the first packet just fine but not any subsequent packet?
Hi,Quote from: pterrus on June 30, 2012, 02:44:43 PMIf I put the decoder in "latch" mode, then the motor will run forever as soon as I hit the "drive" button (I checked, all the decoder outputs are frozen while the motor is running). If I put it in "momentary" mode then the motor keeps hiccuping off and on as it gains and loses the the signal!If I unplug the motor and put a multimeter on the header, it works perfectly, it seems like the problem only occurs while the motor is actually running.An easy one then, as it's clear that it is caused by the motor and what remains is to find what "feature" of the motor is the culprit.Possible candidates:Noise injected into the power lines (cure: Filter the power lines).Noise radiated into the logic (cure: Shielding).Too soft (weak) power supply (cure: Add buffer caps or upgrade the supply's current capability).That's assuming that your circuit is designed (and build) in a sensible way - Always add the schematic when you ask questions about a circuit - we can't catch possible errors without a complete schematic, that is a correct representation of how you build it (not how you wanted or planned to build it, but how everything is connected up as is).
Quote from: pterrus on June 30, 2012, 02:44:43 PMAt first I thought it was an EMI issue, but then I realized that if I'm in latch mode, I can get the motor to stop by turning the remote control (encoder side) off and on again (just off won't do it), which doesn't make sense at all. Maybe it can receive the first packet just fine but not any subsequent packet?If it works fine without the motor, stop guessing about its ability to receive packets.From what you wrote so far, there's nothing excluding EMI (which can cover several aspects).I could shoot of my best guesses as to what's happening, but life's too short for trouble-shooting in the dark, so post the schematic and a couple of sharply focused pics of the setup. Add info on the motor (voltage and current) and your supply (does it happen with freshly charged batteries or only when it's semi-discharged?)
Test with a dummy load (power resistor or light bulb) equal in (dynamic) resistance to the motor and tell what happens (add an LED with a 470 Ohm series resistor for easy indication of when it's running).If the problem persists (with the dummy load), you need to beef up your supply with caps and if it goes away, you need to filter the power lines to the motor.
Twist the motor wires in any case (2..3 twists/inch should do) and make sure the motor encasing is grounded through a heavy gauge, well soldered, wire.If you have access to an oscilloscope, try it on the supply lines to the logic for starters.
I can find the motor resistance with just a multimeter across the leads, right?
The motor wires look plenty twisted, but I don't think the motor casing is grounded (see picture in my second post). I'll definitely try that first. I don't have an oscilloscope unfortunately.
I don't know if this helps narrow it down or not, but the base I'm using (including the motor) was originally an RC truck, and there was obviously no interference issue in its former life.
By "beef up your supply with caps", do you mean put a cap between my unregulated bus and ground?
That's easy to do, so is there a down side to doing this or should I just do it?
Oh, one more thing:
the motor driver worked just fine when it was just the microcontroller controlling it. Additionally, all of the logic seems fine even with the motor running. This suggests it's a radiated EMI issue, right?
At what voltage was it driven before the big snip?
[...] This time I moved the remote control around and noticed I could get it to work correctly in certain spots. Not sure if this is an improvement.
Here are some pictures of the setup in case it helps identify something I'm doing blatantly wrong
Seems like the next step is test with a dummy load. I guess I need to buy a 50 ohm power resistor?
[...] I've already included a big capacitor between unregulated and ground, what else can I do?
It does help if I get closer. The best seems to be when the transmitter antenna is close to the receiver antenna and tilted a bit, whatever that means.
The rest of the circuit (less the motor) draws 81 mA.Here's what's written on the Basic Stamp board's regulator:UTCLM2940L50EAUKA1
I haven't tried your filter from the right side of the pdf yet, can you recommend a part number for the inductor?
So it occurs to me that I'm going to have to hack the basic stamp board a bit to add these components, which makes me a little nervous.
I guess right now the plan is de-solder the Vin pin of the regulator, and carefully bend it up off the PCB, being super careful not to break anything. Then bridge the gap with the diode. Finally, solder the + lead of the capacitor onto the top.Is that the best way to do this? Any tips?
Now the weird part. I hooked up the motor directly to "Vin" on the basic stamp board. That's the unregulated voltage downstream of the diode. I could control the LED perfectly (even across the room) while the motor was spinning and this is the only way I've ever been able to do so. I didn't expect this to work and I still don't understand why it should. The only thing I can think of is maybe it has something to do with the length of the wires in the other configurations?
I couldn't get it to work with the motor controller no matter what I tried (wouldn't work with Vcc2 coming from either before OR after the diode).I could use some help interpreting these results.My current battery pack is a 6 cell Ni-Cd to answer your earlier question. It's the original that came with the truck.
I'm not using a PWM, all of these experiments I just described were done with flat DC. Is there anything else it could be?
I can post some updated pictures of the setup when I get home if that would help.
Do you have any floating inputs on the decoder chip? (If so, tie them to a rail (+5V or 0V) as appropriate. If you tied unused inputs via a high value resistor, then what's the value? (might help to tie them harder (= lower resistance).
Put at least 100nF over the receiver supply terminals.
From previous posts, it seems like you use OR gates to OR a pin from the controller with a pin from the decoder?I don't think that it will have much impact on your present issue, but I'd feed the decoders outputs into the controller and then let the controller output go directly to the L293D.
Try mounting the motor to the L293D with very short wires (2" max.) and a similar max. length from controller to L293D - in general, get your wires as tight as possible.
Is there a short wire from the motor shell to the negative terminal of the battery?
Did you try any shielding?
Solderless bread boards (SBBs) suck at high frequencies, at transient protection and at high impedance stuff, as each contact point is a very effective antenna for both receiving and transmitting (large compared to a small solder joint and with extremely sharp edges (which means that electrons are radiated easily)If possible, place an un-etched PCB, a copper plate or at least an aluminum plate underneath each SBB and ground well (make sure you don't short anything with it).
[...] but I have many unused outputs on the decoder that are floating. Is this bad?
Sorry for the quad post.
I'm thinking about buying something like this to troubleshoot the problem. Would the 200Khz bandwidth specified be enough to detect the noise I'm interested in? The TWS-434A transmits at 433.92 Mhz, so I'm guessing no?
Transmitter: TWS-434AReceiver: RWS-434