Re: QBASIC racetrack timer glitch
- From: "mensanator@xxxxxxx" <mensanator@xxxxxxx>
- Date: 16 Dec 2006 15:24:18 -0800
mensanator@xxxxxxx wrote:
ehsratcliffe@xxxxxxxxxxxxx wrote:
mensanator@xxxxxxx wrote:
ehsratcliffe@xxxxxxxxxxxxx wrote:
I have built a 3-lane, computer-timed drag race track for my physics
students. They build electric cars from scratch, learn kinematics!
The program, in QBASIC, that I use is found at:
http://www.geocities.com/Yosemite/Trails/7471/pwdtrack.htm
After some troubles last year, we finally got it running right, with
some minor changes in the program. Then my computer crashed. Now I
can't remember how I fixed it! The problem is that LANE 1 triggers the
instant the timer starts. LANES 2 & 3 work correctly (triggered to
report time by photogate interruption). Does anyone see the problem in
the orginal program?
This doesn't look right. When a sensor is conducting, it reads
as a 0-bit on the status port, right? At the start, all lane sensors
should be 0 (because they are conducting since the light is not
blocked) and you should stop timing when the sensor reads 1
(light is blocked) on the status port bit.
IF (INP(889) AND 64) = 0 THEN GOSUB 1000
IF (NOT (INP(889)) AND 128) <> 128 THEN GOSUB 2000
IF (INP(889) AND 32) <> 32 THEN GOSUB 3000
But the first line stops timing on 0 instead of 1, so Track 1
timer stops the instant it starts.
The second line makes no sense either. Why are you inverting
the status input and reversing the logic with a <>?
And are you sure Track 3 is working? Here you reversed the logic
but didn't invert the status input, so Track 2 and Track 3 can't
both be correct.
Try this:
IF (INP(889) AND 64) = 64 THEN GOSUB 1000
IF (INP(889) AND 128) = 128 THEN GOSUB 2000
IF (INP(889) AND 32) = 32 THEN GOSUB 3000
Thanks,
Bruce in Fresno
Dear Mensana,
I checked the cables coming from the photogates for lanes 1, 2 and 3
yesterday. They all showed a change of voltage. But I forget if they
are zero when the light hits the phototransistor, or zero when the beam
is occluded.
The voltage at the comparator should be 0 (or very low)
when the transistor is conducting just like the start switch
when it's closed.
I'll check it and get back to you. And thanks for the
suggested code changes. I'm weak in BASIC, but I know enough to see the
logic in your analysis. I'll try them too.
If you get it working, there is one other thing. Your program
is biased towards Track 1. Suppose there is an EXACT tie,
i.e., sensors T1 and T2 close simultaneously. Since you
check and update the screen successively, it is entirely
possible that the clock could roll over before you get around
to updating Track 2 and thus, falsely report that Track 1 won
by a millisecond when, in actuality, it tied.
Since it has been my experience that screen updates
can be slow, I think the potential clock rollover is not to be
dismissed.
Let me know if you get it working and then we can discuss
a simple fix for this potential problem.
One other thing, the circuit shown on your link appears
to be somewhat goofy. It may be that the diagram is
simply drawn incorrectly. First, the voltage divider R9/R10
provides the reference voltage for 3 of the comparators
and a seperate divider R7/R8 provides the reference for
the fourth comparator (connected to sensor T1). Why does
T1 get a seperate reference voltage than T2 & T3? Sure they
are the same but also notice that when S1 is open, the
comparator it's connected to is floating (bad design although
I suspect it may work anyway).
I would have thought that the T1, T2 and T3 comparators would
all have a common reference voltage and that there would be
a pull-up resistor connected to S1.
But maybe your physical circuit is connected differently than
what is shown in the schematic.
Bruce
.
- References:
- QBASIC racetrack timer glitch
- From: ehsratcliffe@xxxxxxxxxxxxx
- Re: QBASIC racetrack timer glitch
- From: mensanator@xxxxxxx
- Re: QBASIC racetrack timer glitch
- From: ehsratcliffe@xxxxxxxxxxxxx
- Re: QBASIC racetrack timer glitch
- From: mensanator@xxxxxxx
- QBASIC racetrack timer glitch
- Prev by Date: Re: QBASIC racetrack timer glitch
- Next by Date: Re: is there any FAST ALGORITHM about Forward Maximum Match of string?
- Previous by thread: Re: QBASIC racetrack timer glitch
- Next by thread: Re: QBASIC racetrack timer glitch
- Index(es):
Relevant Pages
|