A Graphic Finish Line System
for Pinewood Derby Racing

by Stan Pope


This document describes a Local web-enabled Graphical adjunct to Pinewood Derby Race Management Software which provides an economical visual display of race heat results which can be viewed on a central display or on personal devices by attendees using a WIFI connection to a "Private" (i.e. not web connected) Local Area Network. Facilities include precision display of heat results including heat elapsed time and place for each race car, automatic identification of each race car, coordination with various race management software systems, and facilities for following specific race cars on personal devices.

The author does not claim to have resolved all technical issues or to provide detail electronic designs which would implement the concepts. Rather the author provides a conceptual overview of possibilities which, in his opinion, are feasible and which offer a vastly improved spectator solution to viewing Pinewood Derby racing.

System Components

Starting Line

The starting gate is "snap open", such as the gate provided by MicroWizard in which the gate is held closed by a latch and when the latch is released, the gate is opened by springs more quickly than the cars can react. An electrical signal is linked from the starting gate to the finish line electronics which indicates the precise time at which the gate started opening. (This arrangement should be familiar to users of electronically timed racing.)

Finish Line Sensors

The finish line is "photographed" at intervals of about 500 microseconds. I think that intervals ranging from 100 microseconds to 1000 microseconds are feasible. The "photograph" is 1 pixel wide by 1000 to 2000 pixels long which span the width of the track. The device used for imaging is a (CMOS) linear image (Line-Scan) array such as the Hamamatsu CMOS linear image sensor S11639 Recording of the finish line image frames begins when the start gate opens and continues until all race cars have fully passed the finish line (or the finish line judge signals heat completion.) Each finish line frame is associated to a specific interval during the heat.

Finish Line Data Composition

A microprocessor in the finish line module gathers each frame, associates its interval number to each, and disposes the result. Two options are viable:
1. The microprocessor acts as a USB device and sends the data, frame by frame to a host computer. This mode is viable when one track is being served.
2. The microprocessor gathers the frames into a large local memory and acts as a LAN node to send the completed race record via ethernet to a host computer. This mode is more usable when multiple tracks are being served.
In either case, the microprocessor can (and probably should) remove successive identical frames since for most of the heat duration, no cars are crossing the finish line!

Host Computer Track Service function

The Host Computer collects the complete heat image and after creating an identity for the image, stores it in long term memory, e.g. as a file on a local hard drive. The "identity" should include (1) the track on which the heat occurred, (2) the heat serial number on that track, and may include a time stamp for the heat.

Host Computer Heat Analysis function 1

If race car identification stickers are used, the host computer will decode the identification stickers and record the association of track id, heat id, lane id and race car id in a database. Stickers could be a 5X5 array of black/white spots which encode the race car number, including row and column parity checking. (The pattern of QR coding on a reduced scale might be used.) Depending on the race management software, if any, in use the host computer will check race car numbers in each lane against the scheduled heat participants and alarm on discrepancies.

Host Computer Heat Analysis function 2

Regardless of race car identification, the host computer will identify the frame interval in which each lane's race car first appeared in the finish line frame. From that frame number and the microseconds per frame characteristic of the finish line sensor, the host will compute the heat elapsed time for each lane. Optionally, the host will use the car length, wheel size or id sticker size to compute the speed at which the car crossed the finish line. Heat times will be recorded in a database. Optionally, depending on the race management software, heat times will be reported to that software. If both front and rear wheels are visible, a small bit of computation could measure the distance between them, compute average speed as each transits the finish line and, assuming 5 ounce weight, compute the coefficient of friction acting on the car during its finish line transit!

Host Computer Heat Display function 1

The primary display of heats will show race cars apparently moving left to right across the display in their lanes. Each lane will include the heat finish order, the race car number if available, the frame number in which the car first appeared at the finish line, the heat elapsed time, and the speed at which the car passed the finish line. Gaps between race cars, if any, may be compressed to maximize the detail in the displayed finish image. Note that fast moving race cars will appear in fewer finish line frames than slower moving race cars and will, therefore, appear shorter than slower moving race cars in the displayed image. This is a display that most users of personal devices would like to save to their device.

This looks like it might be a photograph taken as the first car crossed the finish line with some text superimposed. It isn't. It is actually a composite of hundreds of 1 pixel wide images of the finish line stacked side by side with some text superimposed. Note the slight elongation of the slower cars!

Host Computer Heat Display function 2

When heats are closely contested, the vicinity of the race car's noses can be displayed with a 1 pixel wide witness line appearing across the track corresponding to the nose position-time of each. In addition to the identity (or lane number) of the race car's involved, the number of pixels separating the witness lines and the corresponding heat time difference are displayed.

Host Computer LAN Service

The host computer will use software such as APACHE server management functions and to gather data from finish lines via ethernet (hard wired network). A 100 Mb ethernet should be sufficient to collect heat images from a dozen tracks each using 200 microsecond by 1000 pixel frame sizes. In addition, the LAN will include WIFI access points arranged in a pattern to minimize interference. For those portions of the audience in the immediate vicinity of the tracks, two techniques can be used to provide enough capacity to accommodate the audience needs. First, the separate access point channels may be separated by 5 or 6 channels numbers (signal width is substantially larger than channel width, and separating the access point channels will minimize adjacent channel interference. Second, the access point antennas can be fitted with directive reflectors, e.g. corner reflectors, which will cause the access point to be much more sensitive to those devices directly in front of the antenna than to those devices off to either side. Ideally, WIFI access points are on a separate ethernet than management and finish lines.

Host Computer Management functions

Management functions include (1) Track Configuration (adding tracks to or removing tracks from the network, (2) recording general information for display such as racing status, including which groups are racing and where they are in the competition and when the next group is expected to start racing, (3) displaying heat results (see "Host Computer Heat Display function 1") on large displays.

Host Computer Personal Device Service functions

The host computer can respond to anonymous personal device requests for (1) General information posted by the race managers, (2) Current status information, (3) Graphic for the last heat that involved a specific race car, (4) the next graphic for a specific race car after the last graphic displayed.

Permanent Record

At completion of racing, the files and databases comprise a comprehensive record of the event. These files and databases will be moved to a server on the internet from which displays comparable to those served to personal devices during the event!

Finish Line Camera Alignment

Since the Finish Line Camera has a one-pixel wide view of the finish line, alignment of the camera is both important and not apparent from a normal image. It is important that the camera be aligned correctly to the finish line at the start of racing and that each heat image show that the camera alignment has been maintained. A technique that supports both of these needs is to place a black triangle at each end of the finish line. The triangle dimensions could be on the order of 44 pixels high and 41 pixels wide at the base. The triangle has a 1 pixel wide X 4 pixel high white spot centered on the base and height. A triangle is placed at each end of the finish line outside the path of the cars with the 1X4 pixel white bar is carefully aligned to the finish line. When the camera is properly aligned both top and bottom of the frame consists of two 20 pixel black bars separated by a 4 pixel white bar. Absent the white medial bar, the bar height tells the direction of the misalignment.

The finish line microprocessor should include a switch for "Alignment Mode" and a push button which will cause the microprocessor to send a 10 frame burst to the host computer with the "Alignment mode" tag and track id included in the burst. Alignment mode must be automatically suppressed while a heat is in progress. The finish line must include a visible signal that the finish line is in alignment mode.

This aspect needs to revisited when I have better data on camera support stability.


As compared to typical race management displays, full implementation of this method tells which race cars actually raced and shows graphically and numerically how each performed. Mast race management records show only which race cars were supposed to race in each lane of each heat and the elapsed heat time for the race cars that actually raced. This method shows, for each race car, the identity of the race car in each lane, its actual heat elapsed time, its average speed for the entire heat, and its average speed as it crosses the finish line.

As compared to typical race management displays with video clips of the finish, full implementation of this method provides greater clarity of the actual finish. With 32 fps video clips, race cars move several inches between frames and may appear fuzzy in the display. With this method, race cars move approximately 0.01 to 0.10 inches per frame depending on the frame rate used by the finish line. The clearer image of finish is provided at much reduced data space, making individual display and data capture by personal devices feasible.


Here are some approximate size/capacity numbers assuming
250 microseconds interval for finish line images,
2000 pixels per finish line frame,
10 mph (176 inches/second) race car speed as it crosses the finish line,
7 inch race car length,
1.18" diameter wheels,
3 lanes per track, and
3.200 second heat times.

Uncompressed heat image size: 25.6 megapixels/heat
= 3.200 seconds/heat * (1,000,000/250) frames/second * 2000 pixels/frame

Compressed heat image frames, dropping redundant empty frames
(worst case with car separations exceeding 1 car length): 480 frames
= (7 inches per car / ( 176 inches/second * (250/1,000,000) seconds/frame ) + 1) * 3 cars per track) -1 frame)
This size suggests compressing the track width from 2000 pixels to 500 pixels for display, producing a 240,000 pixel images to pass around the WIFI LAN!

Compressed heat image size, dropping redundant empty frames
(worst case with car separations exceeding 1 car length): 0.96 megapixels/heat
= 480 franes * 2000 pixels/frame.
At 8 bit/pixel this is 0.96 MB of data per heat.
Further compression is possible within each frame. For instance, next byte in output:
bit 0=0: bits 1-7 tell next how many bytes are presented as data;
bit 0=1: bits 1-7 tell how many bytes to copy from corresponding positions in prior frame.
Worst case is 1% increase.

Speed computation granularity:
At 176 inches/second a 1.18" wheel occupies about 27 frames. A 1 frame difference in measured speed is about 4%. To make wheel speed computation based on wheels, the frame rate must be increased to about 10000 frames/second or 100 microseconds/frame.
At 176 inches/second a 7" car occupies about 159 frames. A 1 frame difference in measured speed is a more acceptable 0.6%

Originally Created: 3/10/2014

Copyright 2014 © by Stan Pope. All rights reserved.