Derby Talk

Hello all,

Long timer lurker - thanks to everyone for the great information available on this board. Now that my son's council race is completed I thought I would clean-up and share the Arduino based track timer I built and a software utility I created for us to track his car's progress.

Here's a webpage for the timer/software: https://www.dfgtec.com/pdt (new website as of Sep 2018)

Features of the timer:

• Easily expandable from 1 to 6 lanes
• Lights indicate winning lane (default configuration)
• Supports (optional) solenoid start gate circuit
• Supports (optional) lane place/time digital displays
• Works standalone or can be interfaced to software running on a PC
• Supports lane masking, start gate status check, force end of race

The timer is currently compatible with the following software:

• Free PD Test/Tune/Track (PDT3) software utility
• The popular GrandPrix Race Manager software

The (typical) costs of the components to build the various pieces:

• timer (base 1 lane config): $40 ($1-3 per lane for additional lanes)
• start gate solenoid circuit: $10 (not including DC power supply for solenoid)
• lane place/time displays: $14 per lane

The following files can be downloaded:

• Hardware schematics
• Timer code (Arduino sketch)
• PDT3 utility

Thanks again,
David


Here are some pictures:

- prototype of the Arduino based timer


- start gate solenoid


- lane place/time display


- screenshot of PDT3 software utility

Very cool, and nice web layout!

How accurate is the arduino and its code for millisecond resolution? For example (not knowing arduino code, but just glancing at the program), it seems like lane 1 could have some sort of advantage over lane 4 - in that it checks them in order. Is the instruction cycle time fast enough to poll the inputs versus having to have some sort of interupt concept?

I am interested in using the arduino platform to make a new SoapBoxDerby timer system, with intergration to other features. We only have two lanes to deal with, but I still want the highest accuracy/consistentcy possible.

dna1990 wrote:Very cool, and nice web layout!

Thanks!

dna1990 wrote:How accurate is the arduino and its code for millisecond resolution? For example (not knowing arduino code, but just glancing at the program), it seems like lane 1 could have some sort of advantage over lane 4 - in that it checks them in order. Is the instruction cycle time fast enough to poll the inputs versus having to have some sort of interupt concept?

I did a little research on this while building the timer, here is what I could piece together: the 16Mhz Arduinos have a maximum time resolution of 4 microseconds (using the micros() function).

The complete loop time is probably on the order of 100 or so microseconds (I should do some testing) and the instruction cycle time should be much, much smaller. Since I am only using the millis() function to get elapsed milliseconds these small (microsecond) deltas shouldn't be an issue.

I plan on switching the timer to use the micros() functions (but still return only 3-4 decimal places) so I should do some testing to verify some of my assumptions...

As you mentioned interrupts would be the best way to go. The Arduinos do have that functionality but only on a small subset of pins, I think it is 2 pins on the Uno and 6 pins on the Mega2560

David

I worked some with a PIC based timer and using either PICBasic or MikroeBasic for the progrmming. Mikroe has some good debugging interfaces that allow you to count exact instruction cycles, etc.

I agree, for a PWD timer (expected ETs under 5 seconds, most under 3), there is not much likelihood of accumulating enough error to effect a millisecond.

I was working on one to time SoapBox (ETs around 30 seconds) and did find it important to keep the timing loop extremely tight and account for each instruction. What I wonder about it now, is the impact of heat/outdoors to the crystal - so that count-wise it is as accurate as I know how to make it, but the actual frequency in real time varies enough between races to let a millisecond creep in. ? To a big degree, consistency is more important that actual stopwatch real time measurement.

I am looking at the Arduino to maybe help add more features to the overall timing system, so your site is very informative. I can program OK, but really know so little about electronics themselves. When and why to use a resistor somewhere - is lost on me most times. I find I can get something working well on a development board, but then struggle to get it working in real life with real wires, switches, etc.

dna1990 wrote:I was working on one to time SoapBox (ETs around 30 seconds) and did find it important to keep the timing loop extremely tight and account for each instruction. What I wonder about it now, is the impact of heat/outdoors to the crystal - so that count-wise it is as accurate as I know how to make it, but the actual frequency in real time varies enough between races to let a millisecond creep in. ? To a big degree, consistency is more important that actual stopwatch real time measurement.

An easy approach to testing the environmental sensitivity is to build up duplicate timers controlled by the same inputs. But, one is left in open air and the other in a box with a lamp (for heat) or a couple glasses of ice cubes for cold / humidity. After letting them sit for 15 minutes or so, trigger the pair a few times and compare results. (Of course, do a "baseline" first to show that when both are in open air they give consistent agreement.)

dna1990 wrote:When and why to use a resistor somewhere - is lost on me most times.

One way to think of a resistor in a circuit is as a "current limiter". For instance, in series with a diode, spec. the resistor to keep the diode current within save limits as though the diode had negligible reisitance.

Another way to think is to consider it to set the "natural voltage of a gate that is not energized. Often this is a + voltage on the output of the gate that is pulled to 0 when the gate is energized. The resistance needs to be high enough to limit gate current and to be much larger than the resistance of the load.

dna1990 wrote:I find I can get something working well on a development board, but then struggle to get it working in real life with real wires, switches, etc.

Watch out for "cold solder joints". They can produce failed and intermittent connections which result in failed or intermittent operation of the circuit! The need to limit soldering iron heat from damaging delicate components can lead to inadequate heating of the parts so that solder does not flow sufficiently to guarantee conductivity. Good solder joints is a fine art when dealing with these delicate components on PC boards. Some practice with an iron and waste parts can help you develop the necessary "rhythm", such as "apply heat to all parts of the joint - count one - two - three - apply solder - one - two - remove heat." Once you have "the rhythm", cold solder joints are few and far between.

Indy wrote:The complete loop time is probably on the order of 100 or so microseconds (I should do some testing) and the instruction cycle time should be much, much smaller. Since I am only using the millis() function to get elapsed milliseconds these small (microsecond) deltas shouldn't be an issue.

I was curious about this and finally got around to doing some testing. I only tested with two lanes - here are the averages I got while in the racing stage:

main (outer) loop: ~40 microseconds
finish (inner) loop: ~12 microseconds

Note for those using GrandPrix Race Manager version 11:

For proper operation please download the latest version of GPRM and the latest version of the Arduino sketch (http://www.miscjunk.org/mj/pg_pdt.html)

Not to add anymore challenges but could wireless be added to send times and place to grand prix? Since there is so much interference that can happen between the timer and sensors, would there be less variables sensitive to interference if you could keep all timer operations close to the sensors. Of course, it would be nice if the timer would send status and error codes to your laptop since it will not be next to the computer.

msurebel wrote:Not to add anymore challenges but could wireless be added to send times and place to grand prix? Since there is so much interference that can happen between the timer and sensors, would there be less variables sensitive to interference if you could keep all timer operations close to the sensors. Of course, it would be nice if the timer would send status and error codes to your laptop since it will not be next to the computer.

Actually, you end up throwing in the possibility of wireless connectivity issues. I tried out a wireless Bluetooth device (part plugged into the timer and a USB dongle into the computer) a couple of years ago. It worked, but every once in awhile it would lose connection and times would not get transmitted.

gpraceman wrote:

msurebel wrote:Not to add anymore challenges but could wireless be added to send times and place to grand prix? Since there is so much interference that can happen between the timer and sensors, would there be less variables sensitive to interference if you could keep all timer operations close to the sensors. Of course, it would be nice if the timer would send status and error codes to your laptop since it will not be next to the computer.

Actually, you end up throwing in the possibility of wireless connectivity issues. I tried out a wireless Bluetooth device (part plugged into the timer and a USB dongle into the computer) a couple of years ago. It worked, but every once in awhile it would lose connection and times would not get transmitted.

Wondering if there is a trade off of outside interference when running wires to the computer vs losing wireless connections sometimes. Sometimes the best layout for track view isn't the best layout for connection to the timer, A/V equipment and protection of all the above from kids running around.

I've found an inexpensive (in both time and money) solution to the lane time display issue. Adafruit Industries carries a 4 digit, 7 segment display with included driver board (they call a backpack) for $10 each.

In the next week I'll release an update to the timer (new Arduino sketch, new schematics, etc.) that utilizes these displays.

http://www.adafruit.com/products/878

Our pack has an older Fast Lane line judge. It only determines the finishing order and does not have a computer interface. Has anyone used Indy's Arduino timer to interface an older Fast Lane judge to the computer for use with GPRM? I thought I would try this route, since we have the display and finish line electronics, we just need a way to hook it up to the computer.

Thanks,

jzarvey wrote:Our pack has an older Fast Lane line judge. It only determines the finishing order and does not have a computer interface. Has anyone used Indy's Arduino timer to interface an older Fast Lane judge to the computer for use with GPRM? I thought I would try this route, since we have the display and finish line electronics, we just need a way to hook it up to the computer.

Using an existing set of lane sensors can be done but you need to make sure that the resistor used with each sensor is of the correct value. The Arduino circuit will provide 5V. If your current system also supplies 5V across the sensor and its resistor then all is fine to use with the Arduino. If the voltage is different, you will need to change out the resistors to ones that will keep the sensors at their appropriate voltage.

Thank you gpraceman. I will post how this little experiment goes.