Yep' good question.
What really happens, operationally, is that 2 ordered lists are created,
from P1..Pn. One is created at the line, as each runner crosses. "Back
in the day", when it was entirely with paper and popsicle sticks - more
on those in a bit - coaches had a student-worker/"B"-Team
runner/some_other_volunteer_or_indentured_servant standing at the finish
line with a set of forms that actually contained columns of blank
minutes and enumerated seconds, for example, with P's 1, 2, and 3
filled:
MM : SS POS
---- ---- -----
[ ]: 00
[16]: 01 1
[ ]: 02
[ ]: 03
[ ]: 04 2
...
[ ]: 59
[17]: 00 3
-- *** NOTE: In a table, these would be something like FinishMM INT,
FinishSS INT, FinishPosition INT, etc. ***
-- *** : There would also be some sort of EventID column.
***
As runners crossed the line, a timer called out the race-time verbally
from a stopwatch and the recorder logged each time, either with a tick
or, better, with the finishers position; in fact, such a paper-based
system was probably a practical bottleneck for hosting some of the
large-scale meets that are so common today. The recorder only needed to
record the MM for the first finisher, then just advance through the rows
and columns as the seconds tick by.
At a typical XC event, there will be a funnel leading to the finish and
a chute after the line. Typically there are place-pickers at the line
to determine who beat whom and chute workers to re-sort the finishers as
necessary, per instructions of the pickers. As the runners reach the
end of the chute, they are typically handed a place-card on which they
write their name and their school/team name. Way back when, "in the
day", numbered popsicle sticks served this purpose. It was also
standard practice for each runner to give these to their coach, who
recorded on a form which of his runners finished where. The coach then
returned the form, with the validating sticks, to the designated meet
official/scorer for tabulating team results. This list might look
something like this:
POS TEAM ID COMPETITOR NAME
----- ------------------ -----------------------------------------
1 SAA A. Jackson
2 SAA D. Pirozzi
3 SAA C. Shea
-- *** NOTE: Although my SDS boys were/are GOOD, my SAA girls were/are
REALLY GOOD, ***
-- *** so, such a finish is not pie-in-the-sky thinking.
***
Results were then and are now compiled from these 2 ordered lists, the
one containing the times, sequenced by finish position, and the other
containing positions, team affiliation, and runner names, etc, also in
sequenced by finish position. The intersection (union?) of these two
lists then forms a comprehensive set of race results.
>From a database perspective, if these 2 lists are saved to their own
tables, maybe SEQUENCED_FINISHERS and SEQUENCED_TIMES. Each contains a
common value in a common column, Position. So, to pull these 2
together, we could run a query/statement along the lines of:
INSERT INTO FINISH_RESULTS (...) +
SELECT ... FROM SEQUENCED_FINISHERS sf, SEQUENCED_TIMES st +
WHERE sf.Position = st.Position +
AND -- whatever else we need to verify the EventID
Now, why 2 distinct but related lists? Certainly, it would be ideal to
have each runner uniquely identified, as is the case for many large
races, NYC Marathon, Boston, NCAA, Oly's, World's, etc. These also have
each runner's biographical data associated with their unique ID/bib#.
Such numbers could be 10-keyed as the runner approaches the line, but
what happens when a fellow competitor outkicks other runners and the
sequence is suddenly changed. IOW, the finish order is not pre-ordered,
so it has to be recorded at/or after the line. Of course, bib#'s could
be 10-keyed in the chute or, better yet, scanned if they have barcodes.
Regardless, of the method or technology employed for data
capture/acquisition, to this point, there will still be the two
sequenced lists of positions and times.
Many larger races now use something called "chip-timing". At
registration/entry, runners are given a radio-frequency chip, not
exactly RFID (which, based on my reading, is not at all practical at
this point as a supportive technology for managing running events) but
which transmits/responds with its identifier as runners cross a pair of
wires at the finish and, at least for longer races (with money), at
various intermediate "traps" to validate participation and provide
feedback to the runners about how their performance progressed/regressed
during the event. The chip is laced into their shoes with a locking,
plastic string and collected in a post-finish "box", akin to a big
chute, sans pickers/sorters. (If it's laced into the runners
shoestrings, the "cutters" just sever the laces as well as the plastic
tie.) Such devices even allow events to have an announcer at the
finish, if a trap is setup in advance of the line, the data for each
runner approaching the finish being displayed on a monitor for the
announcer, or with sufficient (multiplexed?) displays, for friends,
family, etc.
If it's not apparent, the chip system also enables the creation of one
comprehensive list, real-time results, and everything post-race that
otherwise requires 2 lists and lots of post-race, mostly manual
tabulation.
Of course, all this implies a lot of resources, planning, people/labor,
technology, money, lead-time (just for data entry of participant's
info). I am just a volunteer/parent coach of 4 Middle School XC squads
who run in the Parochial Athletic Association. All I would like to do
is move a step or two beyond paper and popsicle sticks, although these
continue to serve as real-world backup systems. (BTW, you should see
the DVD of our Fall 2007 season which I am just about to finish for our
kids and their families.)
That being said, if I am able to move forward on this, I would also like
to add real-time video input to the RBase form, including
image/frame-capture and storage, as each runner's finish is recorded.
Such a feature is mostly for the COOL-factor, but, given the attitude of
so many ("little league") parents today about the obvious supremacy of
their own children, it would also serve the utilitarian function of
settling such disputes with documentary evidence. Fortunately, XC is a
brutally honest sport, with almost no subjective interpretation by an
official, so such bad behavior is not a common thing, so maybe that's a
"Version 2" thing.
(I used to do baseball, too, but that's an entirely different topic for
another time.)
I'm sure I've left out a few things that might be important if you were
to volunteer to manage your own meet. For example, rain is not as big a
problem as sweat, as, if you can beat sweat, you can probably beat rain.
This is especially true when it comes to labels, forms, and any other
printed-on-paper race documents. IOW, it is UNWISE to use paper or ink
that is water-soluble.
Dare I also mention the issue of designating a master race-clock and
the issues of synchronizing other supporting devices therewith,
particularly in a non-networked environment? For instance, the start
line(s, as courses can vary) for our meets are typically more than 100m
from our finish line(s), where all the resources associated with event
management are located. Our master-clock (Seiko, I think, with a tape
printer attached to create our list of times) is battery powered and we
always have at least one coach/parent start their Timex Ironman or
whatever, too. Then, after the start, there's a walk back to the finish
tent to make ready for the end of the race. Any other race-clocks
there, in order to display the correct race time, must have the ability
to be pre-set, by advancing them to by a designated offset. Let's say
that it takes the official timer 2:00 minutes to return to the
officials' station. Then, any dependent clocks could be advanced to
3:00 but not started until the timer designated the "mark". (Actually,
this one is not too tough, but it is a real-world operational issue and
has to be factored into the design of the system, as it is with most
high-end race management systems and/or display timers.)
I hope I've been able to better inform you about how such events are
actually managed.
Now, if you have other questions or thoughts, just "take your marks" and
"go"!
Steve in Memphis
Aka Coach Wills
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc
Sent: Friday, April 11, 2008 5:17am 05:17
To: RBASE-L Mailing List
Subject: [SPAM] [RBASE-L] - RE: [SPAM] [RBASE-L] - Re: Blue-Sky Thinking
About an App' I'd Like to Try
Importance: Low
How would you select the runner when you push the button?
or will you just push it 4-5 times then assign the runners to the
times?
Just trying to get a picture of what you are doing.
Have fun
Marc
----- Original Message -----
From: "Wills, Steve" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, April 10, 2008 4:55 PM
Subject: [RBASE-L] - RE: [SPAM] [RBASE-L] - Re: Blue-Sky Thinking About
an
App' I'd Like to Try
No, truly, the clock doesn't need to be connected to the computer, but
it might simplify my learning/build thereof.
Yes, the exact official time must be stored in the app'. That I can
actually do already, with the press of [SPACE] or [ENTER] or
[LEFT-CLICK]. I extended/modified a couple of Razzak's FTE projects
(Form Timer, Stopwatch, Other?) to more closely approximate a good
stopwatch/timer clock. (Actually, I learned a fair amount of new stuff
about form controls & properties in 7.5-v8 that I had never been
challenged to do before.)
However, your approach, fundamentally, is what I did. Once the
race-clock is started, the clock/system-time is stored in a table and
maintained in a variable. As the clock runs, the elapsed time,
displayed as a string, formatted for display from the difference between
the current system time and the system time at start - thanks to Razzak
for givin' us some "starter" code, as it were - is shown on the
screen/form. Then, as runners finish, a [Record Finisher] button is
clicked (or, with focus, "spaced"), and the system time of the input (or
the elapsed time ... it's been a while since I looked at this
work-in-progress and I can't recall which of these) is stored in a
table, along with a finish position, 1..N, incremented by 1 for each
successive finisher.
This "finish-event-input" can be done with a keyboard. However, based
on my experience, it would definitely be a practical and surely a
best-practice to have a sealed/water-proof button (it can be hot||cold
and wet||dry at XC events) with a long-enough cord attached between it
and a PC in order to close_the_circuit/send_the_signal.
The easy is often (usually?) good. Sometimes the best. In this case, I
think I have a lot to learn. However, as I rather enjoyed my
experimentations with the Form Timer and the good launch Razzak provided
and as learning can be fun - oh my gosh, is that a line from Barney, the
purple dinosaur - I might have to do this one the hard way.
Thanks,
Steve
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc
Sent: Friday, April 11, 2008 4:19am 04:19
To: RBASE-L Mailing List
Subject: [SPAM] [RBASE-L] - Re: Blue-Sky Thinking About an App' I'd Like
to Try
Importance: Low
Steve
Do you really need the clock / timer connected to the computer?
Do you really need the app to store the exact official time?
What I am thinking is enter the runners in a region / grid.
Click a start button and the starting time will be updated for all the
runners.
then click a stop time for each runner as he / she crossed the finish
line
then
calculate the race time.
Maybe not exactly 100% official time but close enough for team stats and
charting progress through the season.
Just looking for an easy way.
Marc
----- Original Message -----
From: "Wills, Steve" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, April 10, 2008 3:37 PM
Subject: [RBASE-L] - Blue-Sky Thinking About an App' I'd Like to Try
Y'all, in the fall, I am a volunteer/parent coach of the middle school
cross country team - I Love XC - at my kids' school. I would like to
create an app' to:
(1) Manage Meet Results
(2) Interface (in some fashion) a Timer Display to the system
(3) Use some sort of button-pressin' thing to log runners crossing the
finish line
(Given) Standard A/C power is assumed to be available, even if it's by
generator or auto inverter. Yes, battery power would be the greatest,
but even if it's with a laptop or PDA/WinCE type device, a
proper-sized/arrayed timer display will probably require a fair amount
of electricity for any sustained operations.
Now, I have already done some work on (1) and that's not such a big
deal. Razzak might now be saying, "Aha! I knew there was a reason he
was asking so many questions about Form Timer functionality a while
back." He would be correct.
However, (2) and (3) are related, at least in the sense that we are
talking about external hardware devices, one of which, the Timer
Display, is an output device and the other, the "button-pressin' thing",
is an input device.
So, with regard to:
(1) I would like to ask if any of y'all have ever done anything with
sending strings/data via RS232/USB/Ethernet to an external display,
especially an array of 7-segment LED's or a scrolling LED board from
within RBase? I would like to pass the time in some fashion and/or the
position of the most recent finisher, perhaps freezing their time until
the next runner. Now, I'm doing a lot of info' gathering on
bashing/hacking my own clock - "professional" sports displays are quite
expensive, at least if they're any good -so I'm not asking anyone about
how to design/build the clock, just how to send data to such an output
device from Rbase.
(2) Has anyone ever used some sort of button which, on
keypress/depression, serves as an input, again, via RS232/USB/Ethernet
to RBase? This would be logically equivalent to [Left-Click] or
[Enter], to log an event, such as recording a runner crossing the line.
Again, I have found various information/sources on WWW that discuss the
construction and communications of such an input device with
microcontrollers and/or PC's, but I really need to learn how to make
sure that RBase "hears" such input.
I appreciate any help here and if nobody's ever done any of this, that's
cool. But I'm committed to makin' this mission, even if it I can't
timebox the project.
Thanks,
Steve in Memphis
J. Stephen Wills
Program Manager, Research Informatics
Office of the Vice Chancellor for Research
University of Tennessee Health Science Center
62 S. Dunlap, Suite 400
Memphis, TN 38163
Office: 901-448-2389
FAX : 901-448-7133
