The NEC 8201 and 8300 were donated by a company called Runtime Services which operates a business of timing road races.
Here are some excerpts from emails received during my correspondance with them:
The amusing thing is that a couple of them are maked "Canada," which means that they've already been imported into Canada. They were used in my road-running race business (I'm a race timer) as timers, and although I've stopped working in Ontario, I used to cross the border with them all the time and had to be careful that I brought over only the "Canada" ones, on which I'd already paid duty (but not GST...this was before that).
The 8300 still has our timing software on it, and I'm leaving it on. It's in BASIC, of course, because if you've been researching the 8xxx series you know that there's a built-in BASIC interpreter.
I think that the timing software, which Philip wrote (though we talked about it together) solves some problems very very neatly. For example, a 8085 isn't a fast processor, and the overall circuitry in the machine doesn't let it respond all that fast to inputs. So if you tried to use, say, the RS232 port to send a signal from a pushbutton, where the pushbutton would be pushed every time a runner finished, you would not succeed. It would drop times, because in the simple-minded approach your program would say
If you tried to use the spacebar or any other key in the same way, it wouldn't work. (The "density" at a good-sized race can easily reach several finishers per second. You can read about density problems on my site in the "how it works" pages.)
So what our software does is to look for interrupts and, when each one comes in, look at the clock only long enough to see if it's still in the same second as it was when the last interrupt came in. If it is, just increment a counter. On any interrupt where the clock has ticked over to the next second, then write out the time plus the number of interrupts in that second.
So at most you get 1 line that has to be written for each second when something happened, and the NEC can keep up easily.
Some of my competitors saw us using the NECs, bought them, and tried the simple-minded version and could not get it to work. Of course I never told them how we did it and they never succeeded in figuring it out for themselves.
Another thing you'll notice in the data files is something that was important way back then, but of course not now -- serial transmission time. We always had to download the NECs to the main computer (PDP-11 first, then VAX, then a series of Alphas, although only the first Alpha ever had to interface with the NECs). At a large race there would be many times. Doing it the simple minded way would have meant downloading HH:MM:SS, 8 bytes plus the number of times or (if select times) the runner number.
So, what we did was to represent each section of the time (H,M,S) as the ascii character corresponding to the number because, obviously, no part of the time number can be greater than 59. Therefore the time takes only 3 bytes to store and transmit, not 8. In those days that was important.
Those damn NECs were really good. They worked in sub-zero (zero F, not C) temps -- I remember once in Burlington it was something like -10 F, big wind blowing...they were fine. Heat was not an issue. Zip-loc bags protected them effectively against rain and snow.
Here's what the 22,000 person finish line was like. A large tent, just for my operation. 16 finish lines, divided into groups of 4. Each group of 4 had its own timer (a "Time Machine") with a single keyboard for select times, and a cable I made snaking out and over to 4 push buttons, one for each of the sub-lines. So, 20 signals were arriving in real time on RS232 (16 buttons and 4 keypads). They dumped into a little Alphaserver through a 90L terminal server. My big Alphaserver (Compaq DS20) looked into the little AS to get the times, when I asked for them (DECNet). Another terminal server handled 6 barcode reading stations and 2 VT520 terminals. Each barcode reading station had its own little display to go with the readers. They could all operate independently. Then there were 2 printers -- 25 PPM and 45 PPM HPs. A couple of UPSs. A couple of laptops running as terminals; my X terminal emulator running on a PC...and on it went. What a setup.
This is an artical published by Runtime in which they mention the NEC machines:
In the last two issues of TacTimes, Jim Gallagher and Alan Jones give their views on using computers as timing devices. We think that their view of timing is too narrow and too focused on hardware specifications. A broader discussion of what actually happens when a race is timed is required. To us, "timing" is more than operating a timing device and generating a stream of time data -- it includes the entire process by which times are collected, adjusted, and assigned to different runners. It is in this sense that we use the word.
Let's begin with the end result. The runners, the race organizers, and TACSTATS/USA all want a list of finishers in order from first to last, with each finisher being assigned a finish time reported as hours, minutes, and whole seconds. There must be great confidence that the list is "correct", so that not only are finish places accurate, but the assigned times accurately reflect the actual elapsed times that the runners took to complete the race course.
The crucial issue is the manner in which this list is generated. There are at least two ways to generate this list and the method chosen determines how the times are collected and recorded. The two methods can be stated simply and in non-technical terms. Either:
A type 1 system need not concern itself with collecting time data to a resolution finer than that required for reporting purposes -- 1 second. A type 2 system will require sorting the collection of finish times, and will require high-resolution devices (as Gallagher describes) to ensure that they are returned to the proper order.
In every system known to us the time data stream arrives at the computer in ordered form (the first time is followed by the second time, the third, and so on) as does the ID data stream (at least within any chute). It's hard to see the need for disrupting a list that's already in the order desired, only to later re-order it, but it could be done. We do not know if Gallagher's or Jones' software is based on a type 2 method. We only have detailed "internal" knowledge of one other software package besides our own, and it is a type 1 system. Selecting the method is a design decision which is no one else's business -- but that's the decision that will determine the degree of precision and resolution that the actual timing device needs to have.
We have been developing and using race timing and scoring software and hardware for 10 years, using DEC PDP-11 and now VAX equipment. For the last 6 years we have relied on NEC PC-8201 and PC-8300 notebook portables to collect finish times and select times. These are battery-powered general-purpose diskless computers that run our timing programs, storing timing information internally. Any given NEC is dedicated to either finish or select times. This information is downloaded into our VAX as the race progresses; at any given time half the NECs (plus spares) are at the line and half are at the VAX, being unloaded. In this way it is not necessary for the VAX to be wired to the finish line. We typically have 5 NECs deployed at a single finish line race; all are synched electronically to the master NEC (whose clock was set at the start).
The way we use the NEC yields a 1 second time resolution, and a typical drift is less than 1 second per week, measured against WWV*. The NEC would be classified as a medium (?) resolution, low drift device.
Our software is based on the type 1 approach -- the order of finish is initially determined by the runner ID data stream. Even when we do multiple- finish line races the procedure is the same for each line internally (see below for more on multiple line races).
Jones mostly concerns himself with drift, but he does make a statement that troubles us: "Anyone who submits race results to TACSTATS should be able to prove that the times are accurate." No one could quarrel with that statement -- except to ask for an operational definition of "prove that the times are accurate." He seems almost to be saying that you need only establish that your clock has a low rate of drift in order to be confident of your times.
We believe that high resolution timing devices are not required in type 1 systems and in any case do not by themselves ensure high accuracy.
In support of this contention, we will give a more detailed description of the logic used in our timing system, an hypothetical example, and an actual example.
In our system, the NEC records in a file:
HH:MM:SS for any second in which at least 1 runner finished, and how many people finished in that second.
HH:MM:SS number/finished this second example: 00:13:02 4 00:13:04 1
(select times stored similarly, except the race number is recorded instead of the number of people)
The actual hand/eye/machine interaction is no different from that of a printing timer/pushbutton system -- the operator hits a key as a body crosses the line. Internally it is different. As we understand printing timers (and those computer-based ones that Gallagher and Jones describe) a button or key generates an interrupt and when the CPU processes that interrupt it notes what the internal time is, and stores that time value somewhere. Each interrupt generates a time value for storage; you have as many time records as you have button-pushes. This is a perfectly reasonable and workable technique, but it's not the only one.
It's equally reasonable for the interrupt to cause the CPU to look at the clock and if the clock has not yet changed to the next second, to store only the number of interrupts within the current second. That is what we do; among other things it dramatically decreases storage requirements and trans- mission times. There is at most one record for each second in the race. A modest bit of encoding stores all information about a second and what happened in it in 4 bytes.
The latest TacTimes listings of pending Masters records includes 7 for which our group did the timing. We have complete confidence in the accuracy of the times we supplied to TACSTATS/USA, but not because we used high-resolution timing devices (we didn't), or just because our NECs have low drift (they do).
Rather, it stems from confidence in an approach to data collection and analysis that was designed from the beginning to take into account the special feature of road racing -- the physical and logical decoupling of the time data and ID data streams -- and that owes more to the study of prehistory** than of physics. We would never claim that our approach is the only workable one, but we are certain that it is a valid one.
Assume that four events occurred at the finish line: runners #123, #234, #345, and #456 crossed the line. Assume for the sake of argument that it was (magically) possible by a single observation each to establish that #123 finished at 13:02.21, #234 at 13:02.29, and so on. (When will we get those transponder systems that make it possible?)
Event at Actual Absolute ID Relative VAX file Line Time Sequence Time Time MM SS in batch in second #123 crosses 13:02.21 123 1st 13:03 (includes TAC #234 crosses 13:02.29 234 2nd 13:03 round-up) #345 crosses 13:02.63 345 3rd 13:03 #456 crosses 13:02.68 456 4th 13:03
The actual absolute time stream gives us no useful information that cannot be derived from the combination of ID sequence and NEC 1-second resolution time. We do not need to know that #123 finished .08 second before #234 in order to know that #123 finished before #234, because we know the relative position of IDs #123 and #234 (1st and 2nd within that second).
It is easy to show that the time list and the ID list are unlikely to be aligned properly without STs, since no timing person can be expected to generate one and only one interrupt for every valid finisher. It is also easy to show that although the ID list will have fewer errors than the times list does, it will not be perfect. It is therefore a certainty that at least some assignments of the raw Nth time to the raw Nth ID will not be accurate. We may then ask whether the inaccuracies introduced through misalignment of the two data streams are greater than any possible inaccuracies introduced by low resolution or high drift. If so, we should attend to these large sources of error before worrying about smaller ones.
We maintain "archive" data files in which the data from NECs and from barcode readers are stored exactly as received. Programs read from these files to assemble ID..TIME pairs which, after being aligned via the STs, are used to score the race. Of interest here is that long after the race we can build the ID..TIME pairs exactly as they were when first merged -- before any editing/alignment of any kind had been done. We do not know whether other systems do this or not, but this archiving of the raw data seems to us to be mandatory if we are to have confidence in the (demonstrable) accuracy of our results. If I cannot show you what I started with, but only what I ended with, why should you believe me? At least the Chronomix operator has tapes. Sooner or later the racks of barcode tags are thrown out -- what's left to be the "audit trail" if there's a complaint or an error comes to light?
Several of the pending masters records mentioned above come from the 1990 Utica Boilermaker 15k. Scoring file reconstruction showed that 3,520 raw times were taken and 3,477 raw IDs were processed. The final ID count was 3,479 -- we got that by removing 3 duplicates and adding one missed tag (discovered via the STs). There were 41 extra times to remove. We typically find that we must make 10 to 20 times as many time adjustments as we make ID adjustments. (We'd be interested in knowing if other people have found similar ratios.) At the Boilermaker we had select timer teams at the left and right of the single finish line; they collected 759 STs for us.
At this race, Anny Stockman ran 1:07:13 for a pending F55-59 15k record. What do we actually know about her performance? Her ID was the 42nd barcode tag in batch (chute-full) #23. It was wanded (rather than being typed in) on our "Y" reader; the batch was processed between 9:46:15 and 9:48:11 AM. When batches 1-23 are reassembled in default order, her number appears at raw finish place 899. The raw 899th time is 1:07:07. There was no select time for her, but her tag was wanded immediately after tag 3291, which was associated with a select time of 1:07:13. Inasmuch as there were three 1:07:13s in a row before the next select time of 1:07:21, she was assigned to the second 1:07:13.
By 899th place, the timer had accumulated only 8 extra times (fewer than 1 per hundred), but the absolute error for finishers in that range was 6 seconds. Had we not had good ST control, and had we not had good ID control, Anny Stockman's time would have been wrongly given as 1:07:07, a serious error.
In what sense can we say that the timing device's resolution contributed to the "accurate" 1:07:13 for Anny Stockman? Probably not at all. Her time was made accurate by a combination of good physical and logical control over the IDs, a tractable list of finish times recorded by a top-quality timing person using reliable equipment, and the presence of sufficient STs. Though the nature of "proof" here is a little slippery (do STs qualify as proof?) we submit that if we're to talk about proving that times are accurate we're going to have to be able to show:
Timing device specifications relating to resolution play no necessary role here, though drift does. If we must use timing device specifications (which in any case "prove" nothing about anyone's time) then they must be keyed to the system's logic. If anyone does run a type 2 system then of course Gallagher's concerns are valid ones. But if the system does not use that logic then a resolution of 1 second is enough.
It follows from this, we think, that a good "timing system" can be shown to be good not just by showing high resolution/low drift on some hardware clock, but by showing the capability both in terms of materials handling and software to generate the requisite data streams, store them, and then manipulate then in accordance with many select times. Any type 1 system should have had a major programming effort put towards collecting, identifying, wanding, and checking barcode tags (or other ID) since that data stream is the primary ordering stream.
If TACSTATS/USA is interested in accuracy, then it should require assurances that the ID processing system is dependable and well-conceived, that select times are collected and actually used to make adjustments, and that the adjustments can be justified and accounted for by comparison with the raw data, which must be preserved as collected. And finally -- yes, the timing devices must have low drift and resolution appropriate to the ordering method being used. Only then does one have a timing system rather than just a clock.
Even with the 1 sec resolution the only problem within a given race will occur when people finishing in different lines are given the same 1 second time. When the lines are merged, (again, only trivially by time, since each line has been ordered internally by ID first) it will not be possible to state which of two runners in the same second but in different lines actually finished "first." This is an awards ceremony problem, not a TACSTATS/USA problem, because the times will both be as accurate and valid as if they had come from a single finish line race. Of course, this is only true if each line has independent select timing and is adjusted internally as a logical single line before the lines are merged (which is the way we do it). We have done two-line events many times and have never had a same-second awards ceremony problem. Still, it could happen.
Donald D. Mitchell is President of Runtime Services, of Buffalo NY. He holds a Ph.D. in anthropology from Harvard University and teaches at the State University of New York, College at Buffalo.
Philip F. Meyfarth is Chief Systems Programmer of Runtime Services. He holds a Ph.D. in mechanical engineering from M.I.T., and teaches at M.I.T.
Both have spent many years collecting and analyzing quantitative data (PFM in engineering; DDM in surveying, agriculture, and prehistory).
*We suspect that not everyone knows how to receive WWV/WWVH. These stations broadcast on 2.50, 5.00, 10.00, 15.00, and 20.00 MHz; in the Northeast it's often easier to receive CHU (Canada) on 7.335 MHz. If you hang around finish lines you'll meet amateur radio operators eventually; they can help you if you don't have a short-wave (HF) receiver.
Odd as it may seem at first, the techniques and concepts used in prehistory are directly relevant to road race timing. The hypothetical discussion above could pass for an introductory session on "absolute dating," (chronometry, or measuring time in quantitative units), "relative dating" (putting events in order without having absolute dates for them) and "cross dating" (combining relative and absolute dates from different sources); in both racing and prehistory we are confronted with imperfect data from which we must reconstruct unique events.