Possible Finish Line Controller?

DIY timing systems
User avatar
SlartyBartFast
Master Pine Head
Master Pine Head
Posts: 272
Joined: Mon Feb 12, 2007 11:30 am
Location: Montreal, Quebec

Possible Finish Line Controller?

Post by SlartyBartFast »

I really like the timer at http://derbytimer.com/, but recently came across this controller: http://www.arduino.cc/.

Anyone with electronics experience know enough to say whether the arduino board would be a good platform for a timer or not?

Seems to have a lot going for it. USB, open source, free IDE, etc.

Above all, it seems to be very inexpensive.

Thoughts?
User avatar
gpraceman
Site Admin
Site Admin
Posts: 4926
Joined: Fri Jun 20, 2003 12:46 am
Location: Highlands Ranch, CO
Contact:

Re: Possible Finish Line Controller?

Post by gpraceman »

SlartyBartFast wrote:I really like the timer at http://derbytimer.com/, but recently came across this controller: http://www.arduino.cc/.

Anyone with electronics experience know enough to say whether the arduino board would be a good platform for a timer or not?

Seems to have a lot going for it. USB, open source, free IDE, etc.
That seems like an interesting board.

They do have a forum, so you can try posting there to see if it can do timing to at least 0.001 secs, preferably 0.0001 secs.

The problem with a USB interface, is that you are limited by the cable length (max about 19 ft) unless you get an inline amplifier. That limits where you can put the computer. We put ours at the start line and our track is 48 ft long. It does look like you can add a RS-232 interface, which would free you up to use long serial cables (even if you have to use a USB to Serial adapter with your computer).

The other thing about a USB interface is that there is currently no race management software that will support it. Though, if there was enough interest, I would consider adding one to GrandPrix Race Manager. If it had a serial interface, GPRM could likely support it using the custom serial timer setup feature.

I wonder if the processor chip would have enough memory space to do timing, control a light tree and trigger a solenoid circuit. That is something else that would be worth finding out.
Randy Lisano
Romans 5:8

Awana Grand Prix and Pinewood Derby racing - Where a child, an adult and a small block of wood combine for a lot of fun and memories.
User avatar
SlartyBartFast
Master Pine Head
Master Pine Head
Posts: 272
Joined: Mon Feb 12, 2007 11:30 am
Location: Montreal, Quebec

Re: Possible Finish Line Controller?

Post by SlartyBartFast »

gpraceman wrote:They do have a forum, so you can try posting there to see if it can do timing to at least 0.001 secs, preferably 0.0001 secs.
That would be my primary concern.

The DerbyTimer uses a 20Mhz clock speed. The Arduino uses a 16Mhz.

Seems ultimately that timing resolution would be down to the efficiency of the code.

I'll look up the memory specs for the controller for the possibility of saving timing info.

As far as USB cable length limitations, why not just wire the finish line sensors remotely?
gpraceman wrote:I wonder if the processor chip would have enough memory space to do timing, control a light tree and trigger a solenoid circuit. That is something else that would be worth finding out.
IMO, a timing tree could be handled by an independent circuit and controller if not by the main controller. That circuit needs only signal to the main timer when the race begins.
User avatar
gpraceman
Site Admin
Site Admin
Posts: 4926
Joined: Fri Jun 20, 2003 12:46 am
Location: Highlands Ranch, CO
Contact:

Re: Possible Finish Line Controller?

Post by gpraceman »

SlartyBartFast wrote:As far as USB cable length limitations, why not just wire the finish line sensors remotely?
You mean having a long cable from the sensors to the board? Usually, you are only using 5V with the sensors, so you don't want too much distance between them and the processor. You would also have to be concerned about EMI. I think it would be better to keep the sensor to processor distance at a minimum.
SlartyBartFast wrote:IMO, a timing tree could be handled by an independent circuit and controller if not by the main controller. That circuit needs only signal to the main timer when the race begins.
It could be a separate board, but if the one board has enough memory space for all 3 functions, why not take advantage of it? That assumes the board has enough outputs (up to 6 for the light tree and one for the solenoid). You could get away with just using 5 outputs for the tree and not have the red lights or 4 outputs if there are no pre-stage or red lights, if need be.

As for when timing starts, I really do not think it should be triggered by anything other than the gate physically opening. Any inconsistency in the time from when the tree hits green (solenoid activated) until when the gate physically opens will show up in the times.
Randy Lisano
Romans 5:8

Awana Grand Prix and Pinewood Derby racing - Where a child, an adult and a small block of wood combine for a lot of fun and memories.
User avatar
SlartyBartFast
Master Pine Head
Master Pine Head
Posts: 272
Joined: Mon Feb 12, 2007 11:30 am
Location: Montreal, Quebec

Re: Possible Finish Line Controller?

Post by SlartyBartFast »

gpraceman wrote:You mean having a long cable from the sensors to the board? Usually, you are only using 5V with the sensors, so you don't want too much distance between them and the processor. You would also have to be concerned about EMI. I think it would be better to keep the sensor to processor distance at a minimum.
But, the gate trigger and sensor are at the opposite end of the track. And I was considering a multi-sensor layout with other sensors the length of the track...

EMI can be managed/eliminated. No?
gpraceman wrote:It could be a separate board, but if the one board has enough memory space for all 3 functions, why not take advantage of it?
Multiplex the functions and only the memory limits the possibilities.
gpraceman wrote:As for when timing starts, I really do not think it should be triggered by anything other than the gate physically opening. Any inconsistency in the time from when the tree hits green (solenoid activated) until when the gate physically opens will show up in the times.
I think I agree with you there. Guess I have to play with the programming to see how much memory gets eaten up. ;)
User avatar
SlartyBartFast
Master Pine Head
Master Pine Head
Posts: 272
Joined: Mon Feb 12, 2007 11:30 am
Location: Montreal, Quebec

Re: Possible Finish Line Controller?

Post by SlartyBartFast »

Found a downside.

The Arduino code only returns values in .001 increments. But the more I look at AVR programming, the more I wonder if I'd really be saving myself that much hassle over just learning how to do it from scratch.
User avatar
gpraceman
Site Admin
Site Admin
Posts: 4926
Joined: Fri Jun 20, 2003 12:46 am
Location: Highlands Ranch, CO
Contact:

Re: Possible Finish Line Controller?

Post by gpraceman »

SlartyBartFast wrote:The Arduino code only returns values in .001 increments.
That is not necessarily a bad thing. At that timing resolution, you are less likely to have noise factors (environmental changes, track changes, track vibrations, etc.) showing up in the times. Fast Track timers and those from Intelligent Automation only time out to 0.001 seconds.
SlartyBartFast wrote:But the more I look at AVR programming, the more I wonder if I'd really be saving myself that much hassle over just learning how to do it from scratch.
DerbyTimer.com has a good solution for the Do-It-Yourselfer. Bert Drake has already done the hard part in designing the circuit and writing the firmware. You just need to assemble it.

However, that assumes he ever gets more boards back in stock. They have been on backorder an awfully long time.
Randy Lisano
Romans 5:8

Awana Grand Prix and Pinewood Derby racing - Where a child, an adult and a small block of wood combine for a lot of fun and memories.
User avatar
SlartyBartFast
Master Pine Head
Master Pine Head
Posts: 272
Joined: Mon Feb 12, 2007 11:30 am
Location: Montreal, Quebec

Re: Possible Finish Line Controller?

Post by SlartyBartFast »

gpraceman wrote:DerbyTimer.com has a good solution for the Do-It-Yourselfer.
I know. But I want more functionality. :)

I think my starting project is going to be a Xmas tree controller. And I've downloaded a library worth of tutorials on AVRs...
User avatar
Duane
Master Pine Head
Master Pine Head
Posts: 151
Joined: Mon Feb 01, 2010 10:25 pm
Location: San Jose,CA

Re: Possible Finish Line Controller?

Post by Duane »

gpraceman wrote:
SlartyBartFast wrote:The Arduino code only returns values in .001 increments.
That is not necessarily a bad thing. At that timing resolution, you are less likely to have noise factors (environmental changes, track changes, track vibrations, etc.) showing up in the times. Fast Track timers and those from Intelligent Automation only time out to 0.001 seconds.
Arduino's timer functions include both millis() with millisecond resolution, and micros(), with microsecond units and and resolution of 4 usecs. The timing accuracy with Arduino will be limited only by the rate that your code polls the sensor pins. And that can be helped by using inner loops that do as little as possible beyond checking those particular pins, and only occasionally going out to the code's outer loop where you do other bookkeeping like looking for resets and sending results to the laptop.

For sensors that are many feet away from the microcontroller, another small factor may be the time it takes for the sensor to drive the whole length of wire to the 0 or 1 logic level when a shadow arrives. Long wire runs will have slower rise times than short runs.
User avatar
gpraceman
Site Admin
Site Admin
Posts: 4926
Joined: Fri Jun 20, 2003 12:46 am
Location: Highlands Ranch, CO
Contact:

Re: Possible Finish Line Controller?

Post by gpraceman »

gpraceman wrote:Fast Track timers and those from Intelligent Automation only time out to 0.001 seconds.
This statement needs a little updating. The latest Fast Track timers now time out to 0.0001 seconds.
Duane wrote:The timing accuracy with Arduino will be limited only by the rate that your code polls the sensor pins. And that can be helped by using inner loops that do as little as possible beyond checking those particular pins, and only occasionally going out to the code's outer loop where you do other bookkeeping like looking for resets and sending results to the laptop.
Many timers will hold off sending the results to the computer until all lanes have finished. I'm sure they do that to keep their loops tighter for more quickly detecting a change in the sensor states.
Randy Lisano
Romans 5:8

Awana Grand Prix and Pinewood Derby racing - Where a child, an adult and a small block of wood combine for a lot of fun and memories.
User avatar
pack529holycross
Master Pine Head
Master Pine Head
Posts: 555
Joined: Wed Dec 26, 2007 4:25 pm
Location: Dr. Phillips, Florida
Contact:

Re: Possible Finish Line Controller?

Post by pack529holycross »

i am not finding information about fast track timers that time out to 0.0001 - where are you seeing this information?
User avatar
gpraceman
Site Admin
Site Admin
Posts: 4926
Joined: Fri Jun 20, 2003 12:46 am
Location: Highlands Ranch, CO
Contact:

Re: Possible Finish Line Controller?

Post by gpraceman »

pack529holycross wrote:i am not finding information about fast track timers that time out to 0.0001 - where are you seeing this information?
Their latest models K1F, K2F an K3F all time out to 0.0001 seconds. I had to add support for it into GPRM. ;)

I'm not sure offhand if the K3F actually displays out to 0.0001 seconds, but it should at least report times to the computer out to that resolution.
Randy Lisano
Romans 5:8

Awana Grand Prix and Pinewood Derby racing - Where a child, an adult and a small block of wood combine for a lot of fun and memories.
User avatar
Duane
Master Pine Head
Master Pine Head
Posts: 151
Joined: Mon Feb 01, 2010 10:25 pm
Location: San Jose,CA

Re: Possible Finish Line Controller?

Post by Duane »

Duane wrote:
gpraceman wrote: That is not necessarily a bad thing. At that timing resolution, you are less likely to have noise factors (environmental changes, track changes, track vibrations, etc.) showing up in the times. Fast Track timers and those from Intelligent Automation only time out to 0.001 seconds.
Arduino's timer functions include both millis() with millisecond resolution, and micros(), with microsecond units and and resolution of 4 usecs. The timing accuracy with Arduino will be limited only by the rate that your code polls the sensor pins. And that can be helped by using inner loops that do as little as possible beyond checking those particular pins, and only occasionally going out to the code's outer loop where you do other bookkeeping like looking for resets and sending results to the laptop.

For sensors that are many feet away from the microcontroller, another small factor may be the time it takes for the sensor to drive the whole length of wire to the 0 or 1 logic level when a shadow arrives. Long wire runs will have slower rise times than short runs.
Another limiting factor is the kind of LED signal used. Plain infrared LEDs and sensors use a steady beam of light. The sensor can have a hard time distinguishing that steady light from ambient background sources of infrared. So most consumer electronics with infrared remotes instead use a beam of light that is modulated with a square wave at 38Khz or so. (The remote's digital signal payload is modulated on top of that 'carrier wave' at some slower rate.) The receiver for these beams tunes out any steady illumination and pays attention only to infrared energy that arrives in 38Khz-or-so pulses. Those receivers also are constructed to ignore any apparent pulse train that is shorter than N complete pulses, where N is as small as 4 pulses for some receivers and up to 12 for others. All this occurs within the electronics hidden within the IR phototransistor blob, and can't be adjusted by the microcontroller. This waiting for N pulse intervals occurs on both the beginning and end of each carrier pulse train.

If the carrier is 38Khz and the receiver requires 12 pulses to confirm that the pulse train is over, then it can take up to 0.3 millisec for the receiver to signal the controller that the beam has ended. In a race track application, all car lanes will see a similar delay, so that is fair. But the inherent resolution of the timer is never going to be better than 1-2 pulses (say 0.05 msec) and possibly several times worse than that.

This graininess in the beam timing can be avoided by instead using the simpler steady LEDs and receivers, but then the gear probably won't work reliably outdoors, or under flourescent or LED room lighting, or when camera flashes are happening.
tnux
Apprentice
Apprentice
Posts: 14
Joined: Tue Jan 25, 2011 6:34 pm
Location: New Carlisle, Oh

Re: Possible Finish Line Controller?

Post by tnux »

Gpraceman is correct on the Fast Tract times. I have owned a K2 for about 5 years I think. It reports back to the computer at .0001 res.
User avatar
gpraceman
Site Admin
Site Admin
Posts: 4926
Joined: Fri Jun 20, 2003 12:46 am
Location: Highlands Ranch, CO
Contact:

Re: Possible Finish Line Controller?

Post by gpraceman »

tnux wrote:Gpraceman is correct on the Fast Tract times. I have owned a K2 for about 5 years I think. It reports back to the computer at .0001 res.
If it is that old, it should only time out to 0.001 seconds. With tiebreakers that the timer does factored in it can be down to 0.0005 seconds.
Randy Lisano
Romans 5:8

Awana Grand Prix and Pinewood Derby racing - Where a child, an adult and a small block of wood combine for a lot of fun and memories.
Post Reply