autox
[Top] [All Lists]

Re: Autocross Timing/Scoring Software

To: <GSMnow@aol.com>, <autox@autox.team.net>
Subject: Re: Autocross Timing/Scoring Software
From: "GPSoftware" <gpsoftware@icehouse.net>
Date: Tue, 5 Oct 1999 22:52:59 -0700
Gary,

This is great stuff. What took you guys so long to "chime in"?

-----Original Message-----
From: GSMnow@aol.com <GSMnow@aol.com>
To: gpsoftware@icehouse.net <gpsoftware@icehouse.net>
Cc: autox@autox.team.net <autox@autox.team.net>
Date: Monday, October 04, 1999 8:19 AM
Subject: Re: Autocross Timing/Scoring Software


>Date: Mon, 4 Oct 1999 00:03:03 -0700
>From: "GPSoftware"
>
>As an embedded system programer (for fun on the side) I do understand what
>you are saying, and agree that there should be plenty of speed and
resolution
>to do the job more accurate than needed. There are many things in a PC
which
>need timing accuracies far beter then what we ask for. Try writing to a
>single sector of a 7200 rpm hard disk. With proper software setting up an
>interupt timer the resolution and repeatability is much better then needed.
>The "problem" as I see it has to do with Windows and perception more than
>anything else. People see glitches and crashes under windows and feel the
PC
>is too unstable. The good timing software I have seen for PC's runs in dos
>with no other app running since it used the system timers. Windows does not
>let you do that. The process you mentioned about polling a port pin 2300
>times a second using a timer is a very god idea and should give very nice
>.001 accuracy +- .0004 better than the latency error of many photo heads.


I tell people that Accucros turns you PC into an embedded controller. You
shouldn't be trying to do any other "tasks" while running Accucros, after
all your trying to run an event. Publishing to the web site (or whatever)
can be done later. As I pointed out earlier, my tests were run on an 8088
computer (old and slow) and even though almost 50% of the processor time was
spent servicing the timing interrupt routine, the trigger polling still
occurred at the correct rate. With 8088 hardware, saving even a small data
file took several minutes.

>
>My question is, Will your software run under windows and pass the info to
>another app? If it can it should fill the needs of most users. In our club
we
>use a JAC timer and hand type the times into a second PC running TS99. And
we
>have the timer operator hand writing the times on a log sheet with the car
>number and class. It is tedius, but we have a backup when the PC is behind
or
>times get entered on the wrong car # or class. The JAC timer does have a
port
>that sends the time out and I think the TS99 software can accept it, but
>there is that lack of trust, and the need to have someone pick the car on
>course to keep it up to date. When we used a PC based timing system before
we
>had several times where the operator did not keep up with the starter
>launching cars and we would have to hold start and get it straightened out.
>And we also had problems that we filled the data base on that one and it
>could not hold new cars without dropping old ones.


No, Windows won't allow the CTC to be re-programmed at the necessary rate so
you must be in DOS mode. However, you can enter the times into Accucros
manually but that isn't really the way is was meant to work. Too bad you are
having a "trust" problem, certainly the system you have will do the job.
With Accucros you register cars for an event, either by entering the data or
selecting from a driver database. The practical limit for number of cars
registered is around 250, but there is no hard limit.

>
>I think the fix is what they do at nationals. Grid the cars in class groups
>in number order, but in a small club all that does is waste time tht the
cars
>should be running. About 1/3 of our runners reg on site so we can't pre
>assign anything. How does GPSoft handle the database of drivers? How many
can
>it hold? What is the operator interface?


Check out the "screenshots" section of my web site. You can register at (and
during) the event by entering all the mandatory data, or speed things up by
entering something to search on and doing a "find" from the registration
screen. For instance, enter a first name of "Gary" and then do a "find". You
will be presented with a list of all drivers with a first name of "Gary"
that are in the driver database. The database is a disk file so It can get
huge. Anytime a car is registered with data not originally taken from the
driver database it is added to the database. I include a companion program
that allows you to clean up the driver database. You can also select from
different databases.

The run order of cars is not pre-determined by the program. If car "10"
comes up to the line, select car "10" from the staging list window and let
him go. If you know the next 4 cars in line, just stage them in order. If no
cars are staged, any triggers are ignored.

>
>We have changed systems so much that we only have a few people now who can
>run timing, we need to standardize and train more than we need more
equipment
>and software. Just 8 more members who can run timing smoothly will be a
great
>help with whatever we use. When we did it with just an old JAC and paper,
>almost any driver could work timing, Not now.


Usually I recommend two operators. One to handle penalty count and PA
duties, the other watches the staging area and runs the program. In one case
I had a user get the program on Tuesday, had his triggers working by
Thursday, and ran 100 car events on Saturday and Sunday by himself except
for when he gave someone five minutes of training so he could take his own
runs. Typically, people get trained during the event and can immediataly
start performing the timing duties.

Regards,
Gary

Gary Poole
GPSoftware
P.O. Box 421
Liberty Lake, WA 99019
Phone/Fax (509)532-1702
E-Mail: gpsoftware@icehouse.net
Web: www.icehouse.net/gpsoftware



<Prev in Thread] Current Thread [Next in Thread>