Serin problems

pdiefend

Hi all,

I am working on a robot that has BS2's as a transmitter and a receiver, and I am using SERIN and SEROUT to send the data from the transmitter and receiver. The robot is supposed to count how many times it cycles through a piece of code using the code listed below. I am almost sure that the problem is that the serin command is waiting until it receives the data instead of looping after not receiving any data. Any ideas here why the serin is waiting instead of looping back to forward the way it should?

forward:
counter = counter + 1
SEROUT 14, 84, [noparse][[/noparse]$80, 0, 0, 120]
SEROUT 14, 84, [noparse][[/noparse]$80, 0, 2, 120]
SERIN 7, 16468, 20, forward, [noparse][[/noparse]WAIT ("!"), x.HIGHNIB, x.LOWNIB, y.HIGHNIB, y.LOWNIB]

'at this point the code continues

Thanks
pdiefend

Tapperman

SERIN 7, 16468, 20, forward, [noparse][[/noparse]WAIT ("!"), x.HIGHNIB, x.LOWNIB, y.HIGHNIB, y.LOWNIB]

Well your instruction looks good ... although, you didn't mention which Basic Stamp? So the 20 above in the timeout could be a different amount of time?

And your list of variables and formatters that tells SERIN what to do with incoming data has me a little confussed.

What does WAIT ("!") do? Is it a formatter, or a variable? I guess I'm not familuar with that one?

pdiefend

The "WAIT ("!")" tells the code to not accept any data until it sees a "!", and both the x and y variables are Byte sized, so the x.HIGHNIB is the upper half of the code and the LOWNIB is the lower half of the code. The wait will tell the program to ignore the data until it receives the "!", but that should not tell the robot to wait at that command, the timeout should tell the robot to move on if no data is received in 20 ms.

Duffer

SERIN receives BYTES, not NIBS.

Use:

SERIN 7, 16468, 20, forward, [noparse][[/noparse]WAIT ("!"), x, y]··· 'Bytes

and then refer to the high and low nibs ( x.HIGHNIB, x.LOWNIB, y.HIGHNIB, y.LOWNIB)·of the bytes elsewhere in your code as you require.

Duffer

Tracy Allen

Where physical level AM radio receivers are concerned, noise is the rule not the exception, and any noise can reset the timeout value so that it sticks at the SERIN.

Sometimes people misunderstand what the timeout value means. In this case, 20 milliseconds means,
20 milliseconds of quiet on the line, it times out if and when pin 7 stays at zero volts for 20 milliseconds.
NOT it times out if it does not receive a "!" within 20 ms
NOT it times out if it does not receive a "!" and 4 bytes within 20 milliseconds

If you are working with a physical layer AM radio, the transmitter usually will transmit a dummy preamble, then the "!" and the data. The purpose of the preamble is to condition the automatic gain control in the receiver, so that it will slice out the subsequent 1s and 0s correctly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pdiefend

I understand how the serin command works and how the timeout function within the command as well as the wait part works. My problem is still why the code is sticking at that line of code waiting for the commands. I don't think the problem is noise because I have both moved where I am testing the robot, as well as I have tested the system with a different code and I am not getting noise in the system, meaning the data is clear coming into the receiver. I still can't figure it out why the code is sticking.

I have tried all of the mentioned fixes also, changing the x.HIGHNIB, x.LOWNIB to just x in both the transmitter and receiver, as well as testing the clearity of the system to no avail. Any other ideas.

Tracy Allen

What happens if you simply connect pin p7 to Vss instead of to the serial input?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pdiefend

nothing

pdiefend

I should add that there is an initial serin command near the beginning that holds the program and waits until a command is received at the beginning to start the motion.

Tracy Allen

With pin p7 held at Vss, not to serial input, what happens on the debug screen with this, stripped-down self-standing program?

forward:
  DEBUG "timeout",CR
  SERIN 7, 16468, 200, forward, [noparse][[/noparse]WAIT ("!")]   ' on BS2, BS2e or BS2pe, 9600 baud inverted, 200 mS timeout
  DEBUG "Got it!",CR
  GOTO forward

Is the serial input normally coming from the radio receiver? Is it normally low when not receiving anything?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pdiefend

timeout repeatedly

Tracy Allen

Ah, good, then what happens if you reattach the normal serial input?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pdiefend

timeout repeatedly until I send a signal from the transmitter, then it is timeout, Got it, timeout, then the program stalls. When I send another signal from the transmitter, I get the same timeout, got it, timeout again with another stall. Basically the program goes through the sequence once then stalls.

Tracy Allen

Well, I don't understand the time up to the first transmission, but after that it is exactly what I would expect from an AM radio receiver. The automatic gain control gradually (at an internally defined time constant) pushes up the sensitivity until it hears something, anything.

Do you happen to have an oscilloscope?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pdiefend

No, not here. I would like to point out that I am using parallax's transmitter and receiver in this project if that changes anything.

pdiefend

I think I've got something here. When I ran the subroutine you sent, it originally worked perfectly, so I attempted to modify it a little with the debug terminal showing the counter variable and it still worked within my program. When I added the serout commands that are under the counter = counter + 1, the program stalled. I think the problem is in sending the serout commands over and over again, which only needs to be sent once, but for simplicity's sake I just sent it over and over again. I think the problem is not in the hardware, but in the coding at that spot. I am going to modify my code and see if I can get it to work.

sam_sam_sam

Try putting a small···· Pause 10··· ·or more·so It dose not try to run to fast

The reason I say this is when I was writing some code using Two card reader I had to put a pause between the two reader so it would not hang

I also had used a wait command

This maybe the same thing where its doing a do nothing ·loop to fast

I hope this helps


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any··that you may have and all of your time finding them

·
·
·
·
Sam

Post Edited (sam_sam_sam) : 1/4/2010 2:53:31 AM GMT

pdiefend

I think I have found the problem. The serial device controlling my motors must have some kind of a feedback through the Vss line into the receiver. I moved the lines of code around so that the serial data being sent was not being looped but I was still having problems with the receiver, so I decided to remove the motor controller but keep the serial data lines in the code and the device worked perfectly (minus the not moving part). All I need to do now is figure out what to do with the motor controller so I don't have any more problems.

Any ideas? I have the motor controller going directly to the Vss bus, but it doesn't help any.

sam_sam_sam

Put a line at the top of you code with a ( DEBUG "START" PAUSE 1000)· put this before any·DO LOOP and in your·DO LOOP (DEBUG CLS)·to see if you having a brown out when your motor starting or stopping or·when it ·moving you should only see this one time unless you turn it on and off

Also try putting a 1000 uf cap· or larger on your power supply and see if this helps


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any··that you may have and all of your time finding them

·
·
·
·
Sam

Post Edited (sam_sam_sam) : 1/4/2010 3:11:24 AM GMT

pdiefend

The pause has not helped at all, and the problem is either with the controller or the motors, and after running tests it looks like the problem is only when the motors are running and not with the motor controller. The motors do have a capacitor on each to smooth out the PWM from the controller, but I think the motors are causing a brown out while they are running.

pdiefend

The problem might be the batteries are getting too low at this point also.

sam_sam_sam

Put a volt meter while the motors are running and see how low your voltage is going

Also are using one battery for the Microcontroller and one for the Motor controller or are they the same battery

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any··that you may have and all of your time finding them

·
·
·
·
Sam

pdiefend

Revise that last statement, the problem is in the motor controller, not a brownout from the motors. When I removed the motor controller from the circuit it worked perfectly, but when I removed the motors but left the controller, the same old problems can back, so the problem is definitely with either the motor controller or the placement of the controller on the breadboard.

pdiefend

battery voltage is getting low when the motors run (9 down to 8), but there is enough voltage for the logic circuits (5 across Vdd & Vss)

sam_sam_sam

Which motor controller are you using

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any··that you may have and all of your time finding them

·
·
·
·
Sam

pdiefend

pololu DC motor controller

allanlane5

It IS possible for a motor running to 'glitch' the ground lines -- perhaps enough for SERIN to 'see' this as a valid enough signal not to time-out.

Solutions to this are to put a capacitor across the motors + and - lines to reduce the noise coupled to the ground line.

Tracy Allen

Is the program stalled at the SERIN, or is it resetting to the top? (I'm confused by the different crossing ideas and test results). The
DEBUG "Top"
at the top of the program should distinguish those cases.

It is true that current spikes from the motor controller could reset the stamp, or they could hang up the SERIN command. A motor running with PWM may generate RF hash that the receiver might pick up either through the wires or through the air. Heavy currents for the motors should come from and return to the power supply near the regulator, and not have to flow through the breadboard.

But another point of confusion, did you say it does not work even if the motors are detached?

One thing that might help with RF hash might be to install a couple of clamp-on ferrite filters on the motor leads. (Or wrap the motor leads near the Stamp around a heavy iron washer to make a toroid choke.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

stamptrol

·Four or 5 posts back, you note that the problem disappeared when the motor controller was removed.

·It almosts sounds like the motor controller is briefly shorting the power supply. It could be related to having a Forward command overlap with a Reverse command.

·It can happen that a transistor base/gate signal is not dropping quick enough during a transition.

· I'm with Tracy and agree that the reset or hangup at SERIN have to be sorted out with appropriate DEBUG statements.

· Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

pdiefend

To clear up confusion, the program is not resetting to the top, it is getting hung up at the serin command, and the problems were occurring when the motor controller was connected to the circuit, not when the motors were. When I removed just the controller (which also removed the motors from the circuit) the circuit worked fine, but when I left the controller and only removed the motors, the program was getting hung up at the serin command.

Would it help to connect a second voltage regulator just for the motor controller (and motors still connected to battery)?

Also the Debug commands did sort out where the code was stalling. It was stalling at the serin

Tracy Allen

Another thing you might try is a capacitor of about 0.001 uF from the serial input p7 to ground, or 0.001 uF in parallel with 4.7 kOhms. The purpose of that would be to snub out the coupling of hash coming in through the "air" (capacitive or EMI coupling). That won't help if it is coming in via some kind of ground loop or power supply effect. A separate regulator for the controller might help. The effectiveness will depend on the ground and power paths to the battery. Sorry for all the "might be". Is this project built on a BOE?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com