Re: QBASIC racetrack timer glitch
- From: "ehsratcliffe@xxxxxxxxxxxxx" <ehsratcliffe@xxxxxxxxxxxxx>
- Date: 18 Dec 2006 19:23:15 -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,
BTW, it's Mensanator.
I'm just back from my classroom with a BIT more information: The
voltage across the output from the sensor circuit (light
beam-to-phototransistor) reads 0V when the beam shines on the
phototransistor, and .3V when the light beam is blocked. I THINK this
fits with what you ask about above, but I didn't yet look at what the
"status port" reads (In fact, I'm not sure I know what the status port
is, but I think the end of the program has a way to test what you say,
which I'll do tomorrow, if I don't get called in for jury duty!
More later,
Bruce
Well, that doesn't quite match what I was expecting, but if
it's working, I suppose we shouldn't worry about it. But FYI,
here's what I was expecting:
+5 --+----------+-----------------+
| | |
R6 R7 R12
| | ______ |
| +-----[ ] |
| | [COMP1A]----+------- CONN1 (10)
+----------------[______]
| |
T1 R8
| |
GND -+----------+
The voltage divider R7/R8 puts a 2.5v reference voltage on
one side of the comparator input. When there is no light
shining on T1, it should not be conducting, so there should
be no current flowing through R6 which means no voltage
drop across R6 which makes the other side of the comparator
+5v which is >2.5v so the comparator should have a high
output.
When light shines on T1, it conducts causing current to
flow through R6 resulting in a voltage drop. I wouldn't
expect you to see 0v because there should be a small drop
across T1 itself (0.3 to 0.7 depending on what T1 is made
of). Regardless of what it actually is, it should be much
less than the 2.5v reference so the comparator should
then output low.
So what I was expecting was +5v when dark and <1v when
lighted. Make sure you measure the correct points in the
circuit. Best place would be the two comparatot input
pins 4 and 5 (for T1).
If we look at the S1 circuit (as drawn) we see
+5 -------------+-----------------+
| |
R9 R13
| ______ |
+-----[ ] |
| [COMP1D]----+------- CONN1 (13)
+----------------[______]
| |
S1 R10
| |
GND -+----------+
The reason I said it looks goofy is because when S1 is open,
what is the voltage on the comparator input? Technically,
it is none, but "none" doesn't mean 0. A floating input will
often look like a high to the circuit. It has to be working
like that since we know it goes to 0v when the switch closes
and presumably the comparator output changes otherwise it
wouldn't work at all.
As far as what "status port" means, keep in mind that the
original purpose of this hardware on your PC was to connect
to a parallel printer. The printer hardware has two I/O
addresses associated with it: a base address for writing
output data (888) (for which there is no use in this
application) and an address for reading printer status (889).
Your track sensors are wired to the connector pins
normally used for printer SELECT, PAPER EMPTY, BUSY and
ACKNOWLEDGE. The state of these signals is input to your
program whenever it does INP(889) and would be called
"reading the printer port status register".
Internally in the PC hardware, these connector pins are
wired to bits 4, 5, 6 and 7 of the status register and
are equivalent to the decimal numbers 16, 32, 64 and 128
respectively.
So, after you do INP(889) you AND with 16 to see if bit 4
is a 1 or 0. The result is 16 if bit 4 is 1 and 0 if bit 4
is 0. You can test each bit individually in this manner by
simply ANDing the appropriate value (called the mask).
Here is a summary of the printer port pin on CONN1 (pin),
it's printer status name (signal), what it connects to in
your timer circuit (connection), the bit in the status
register associated with the signal (port bit) and the
mask required to read that bit (value).
pin signal connection port bit value
--- ------ ---------- -------- -----
13 +SEL S1 4 16
12 +PE T3 5 32
11 +BUSY T2 7 128
10 -ACK T1 6 64
Dear Mensanator,
WOW! I can see how much I cannot see. Your knowledge base is so
much deeper than mine will EVER be, I hope this isn't too frustrating
to you. I DID basically follow your explanation of reading printer
port status register, INP(889), etc. But before I start asking
questions to clarify what I can't seem to understand, I have some good
news:
IT WORKS! I'm not sure why--I didn't make any program changes since
yesterday (and I DON'T have jury duty tomorrow. . .), but when I
started up the unit this morning, to my amazement, it started reporting
times at all three lanes. I tested it probably fifty times today, and
it worked every time.
The only irksome thing is that it doesn't give true ten-thousandth of a
second accuracy, even though it shows 4 places to the right of the
decimal. When I put my hands through two light beams, I'd get, for
example, 2.3487 seconds in one lane and 2.3487 seconds in the second
lane. Repeatedly. I know I'm not that good at precision
beam-interrupting. I guess I'll just cut the printout down to maybe a
hundredth of a second, as I hear that QBASIC has a pretty crummy TIMER
subroutine--not very accurate. But for my purposes (my students are
racing their home-built cars over a 10 meter track) hundredth of a
second accuracy should be fine.
Thanks for all you help. I learned a lot, and have renewed respect for
people that understand what goes on inside that nondescript metal case.
.. .
Bruce Ratcliffe,
Fresno
.
- 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: algorithm for detecting sort order
- Next by Date: Re: Which tools to use for early design stage of a programming project?
- Previous by thread: Re: QBASIC racetrack timer glitch
- Next by thread: Help me to understand BNF grammer
- Index(es):
Relevant Pages
|