Fun with Electronics and Code

Just another WordPress.com site

Project – Grand Prix (Pinewood Derby) Timer

Introduction

So let me set the stage for you (in case you didn’t do Awana Grand Prix or Boy Scouts Pinewood Derby as a kid). You are 9 years old – you and your Dad (or Mom) have just spend 2 weekends building a pine car. It is all painted; the axles and wheels have been polished and they are lubricated. You just know your car is fast. Now it’s your turn to race. Your car is set on the track along with 3 others. There is a count down and …. snap…. they are off. The cars go racing down the tack as all the parents stand over the finish line waiting to see who finishes… but wait!! It appears that 2 finish at the same time. Now all the parents rewind their video cameras and spend the next few minutes “discussing” who actually won.

Well there is an answer to this problem and it doesn’t involve replaying videos (unless you want an instant replay).  It is called a track timer. Now there are commercial units available out there but since the spirit of these events is to spent time with your kids I figure why not build one?

Our church had a track but it was damage a few years back and was so warped that we decided it was not worth repairing. Last year we borrowed a track from another church, but the timer didn’t work all that well as it only showed positions (1st, 2nd, 3rd, etc).  So after the race our Awana leader, Danny, decided to take on the task of building a track and I volunteered to build the timer.

In the following pages I will document the research, design, build and associated materials.  I also plan on posting all schematics, source code, and BOMs (bill of materials) for others to use on future pages. If you have questions or comments please ask.

Requirements and Assumptions

Working with Danny we laid out some of the basic requirements that we had for the new timer. Along with a few of the assumption that we made about its operation.

  1. Support for 6+ lanes – when we started discussing this project we had not decided on the lane count but we knew that it would be at least 6 lanes given the number of racers were estimated having and wanting to have the kids race more (>100).
  2. Provide times for each lane – our previous timer was just listing wining order and so the final list that went into the grand finally was not always the fastest cars, just that car that happened to beat the others in their heat. The separation in completing between these cars in the final heat was great.
  3. Use a trigger that does not depend on shape of car to work (IE Optical and not mechanical)
  4. Finish line should be easily detachable from the track and easy to set up.
  5. Optional: Ability to time races without a computer attached.

Hardware Selection

Given that my timetable was short, I started sourcing components before I had prototyped how everything should work. For all except for the IR LEDs this proved to not be a problem. Also since shipping in some cases costs more than the part(s) it is recommended to order all you parts at one from a single supplier. In addition, if you like to experiment, order double on the sub dollar parts. It saves you from having to place a second order if parts fails and can build up your part inventory for other projects.

Embedded Computer

Netduino

Netduino

I started with looking over the other designs that have been posted online for track timers. For my timer, I also wanted to know finish times. Most out there were for 4 lanes and were PIC based. After talking to Jon Ficks about the Track Timer he built. I realized the I really did not have the time to edit the PIC based C / assemble code based solutions out there to meet our requirements.

I then started looking into devices called Arduinos. They are open sourced embedded computers that are easy to use and use a variant of a modern development language similar to C++. They looked interesting but at this point I want to use Interrupts on each lane and most of the Arduino boards only had 2 or 6 Interrupts. I was looking for a version that had 8 or more and ran across the Netduino on sparkfun.  It is a .NET Micro Framework system that runs C#  and all of its ports have interrupts with hardware timestamps so it was my pick for this project.

User Interface

Nokia 5110 LCD from Sparkfun

Nokia 5110 LCD from Sparkfun

Since this will be connected to a computer a UI was unnecessary, but I wanted to support independent operation, so I decided to use a Nokia 5110 LCD from Sparkfun. It is an easy to use display and only cost $9.95 US.  I started with individual pieces of 20 AWG wire connecting this to the NetDuino but the wire was too stiff and I want to be able to open the completed box quickly. So I changed it for a piece of 26 AWG Ribbon cable. I then wired that to a piece of Perfboard that the Netduino will plug into. You can find information on connecting this to your Netduino at their forums (http://forums.netduino.com/index.php?/topic/860-lcd-help-needed-16x2s-are-boring/).

Track Power

2.5mm Barrel Jack

2.5mm Barrel Jack

To give the Finish line power I used a cable I already  made up. It is a 2.5mm Barrel Jack attached to a piece of 20 AWG wire and then a piece of 1/4″ and 1/8″ shrink tube.

If you don’t have one then you can get one here and then solder it to some wire. NOTE: I usually prefer the all metal jacks to the plastic. First, the plastic ones tend to break easily and second is you get a better connection as the plastic ones just have this leaf spring on one side that pushes it against the plug and it does not hold it as well.

Signal Wiring

Keystone Jack - Wire End

Keystone Jack – Wire End

Keystone jack

Keystone Jack

The get the signal from the finish line and the start gate to the Netduino, I decided to go with ethernet cables. Their easy to find in long lengths and they (sometimes) have good shielding. To connect the ethernet cables to the finish line and the Netduino I got a bunch of Keystone Jacks and attached them to a 8″ – 12″ piece of Cat5. Two will be soldered to the perfboard which will then be attached to the Netduino and another pair to the Lane sensors on the other side. One additional set is used to connect the finish line with the start gate. I am using 24AWG wire and it is rated to handle .577 amps when transmitting power. Therefore once the Servo (rated 500 milliamp) is added to the start line, I should be able to use a single signaling pair to power it. However, I’ll use 2 pair to account for line resistance and voltage drop.

IR Emitter and Detector

Infrared Emitters and Detectors

Infrared Emitters and Detectors (pink)

There are many options when considering how to “trigger” your finish line. Some systems use mechanical switches, others use visible light, but most use Infrared light. This is the same type of light that comes out of your remote control. With each of these switch types there are pros and cons. For example: mechanical switch PRO: They are not bothered by any light sources in the environment. CON: the car has to actually “hit” the switch and they usually need to be reset by hand. After evaluating all the options, IR appeared to be the way to go for this project. once that decision was made the next challenge was finding a matched pair. That is a IR LED that emits that same light source needed by the IR Detector. Well this was made a little easier by Sparkfun. They have matched IR pairs that operate on 940nm center with a 50nm spectrum. The detector is basically just a NPN transistor that uses light rather than voltage to trigger.  After testing the pairs it appeared that they would only saturate when less than 4 inches away. Given that the sensors will be mounted at least 4.5 inched apart, I decided to use a high power IR LED. The new LEDs have a radiant intensity 10 times high then the matched pair but its center is 950nm, 10 nm higher then the detector. After testing the new IR Leds the performance was much improved. I was able to get full saturation on the Photo Transistors at over 5.5 inches. Since the voltage only needs to drop to less than 1.5 volt that means I could go to  8+ inches away without trouble.

Project Box

Project Box

Project Box

The box I used was from Mouser. It fits everything just about right. It came with mounts inside for easy attachment of a PCB or Perfboard.  I opened up 4 holes in it, 2 for the modified Ethernet keystone jacks, 1 for the Netduino Power, and 1 for the Netduino USB programming interface. For the FTDI USB to Serial Adapter I just notched the top of the box so that I could snake a USB cable under the cover. I am not fond of the faceplate so I also picked up a piece of Lexan from Home Depot and cut a new faceplate from it.

FTDI USB to Serial TTL

FTDI USB to Serial

FTDI USB to Serial

In order to have the Netduino communicate to the computer running the Grandprix Race Manager software the host computer needs a Serial port. Well most modern computers don’t have a serial port and this device solves that problem. It is a FTDI USB to serial interface that operates at TTL voltages and is self-powered by the USB. I added a 3 wire ribbon cable connected to the Ground, TX and RX pins.

Click Here to go to Page 2 – Design

27 responses to “Project – Grand Prix (Pinewood Derby) Timer

  1. Pingback: My first major project… « Fun with Electronics and Code

  2. Adrien Jean August 28, 2011 at 6:34 AM

    Hi,
    Are you willing to share the schematic diagram and the source code for the project?

    • jarrodsinclair August 30, 2011 at 8:06 PM

      Sure, I have been adding details to the project page as I have had time. However, work was very busy that last few months with a project that finished last week. I will work on posting the remain project details over the next week or so. The source code I am going to publish on Codeplex as open source. FYI- This design is only for Non-profit use. If you need it for some other reason please let me know.

  3. drhender August 31, 2011 at 10:55 AM

    Your project has inspired me. After last january’s Pine Wood Derby race, I told myself that I would build a timer system before next years race. With your pioneering effort, I should be able to pull this off!

    Your timer currently shows times to the hundredths of a second. Any idea if the interrupts are sufficient to provide a 3rd decimal point of accuracy? (For fun, the dads run a ‘hot-rod’ class of powered cars, and believe it or not, timing to the thousandths of a second is sometimes necessary.)

    Thanks for your efforts and willingness to share.

    • jarrodsinclair August 31, 2011 at 4:44 PM

      Hi David,
      I hope the instruction I am putting up help. I have been adding more details this week and should have the source code and wiring diagram up soon. The Finish line ended up being build quite different then the design i had created, but I will still upload that schematic.

      As for the precision, the system is already showing to the 10,000ths so it will show as X.XXXX seconds (current maxtime is 9.9999 seconds but I recommend you reduce it to what works best for your track). As for the need for all those digits, I can say that it is required. In my last race, with the top 8 finishers in the final round of the final heat; the 2nd and 3rd place finishers were only 5/10,000ths apart (3.1412 vs 3.1417) and that would have meant a tie had it not been for the precision. One important thing to keep in mind with the Netduino (or other interrupt driven timer) is that even though it will take sometimes up to 3 ms (0.03 seconds) to process an interrupt through your code, as long as you use the hardware timestamp from the interrupts (both start gate and each lane) to calculate the time difference, then there won’t be an issue. Do not try to use a separate timer to record the time or the quality of the timer will suffer greatly. Only use the timer to control when the race should stop.

      Also I would not bother going to less that 10,000ths (0.0000) precision because as at that point the alignment of the start gate to the finish line and the position of each LED and Photo Transistor will affect the times. Even at the level it is currently at, we ended up having to configure the Grand Prix Race Management Software to ignore the best and worst time from each car (that is a best practice anyway).

  4. Pingback: Track Timer – Additional Build Details and Source code « Fun with Electronics and Code

  5. drhender September 2, 2011 at 2:17 PM

    Wow! Sounds like your pioneering work is exactly what I need. One thing I didn’t find was a bill of goods. It looks like the Netduino board is about $35– what else do you have in the project, budget-wise?

    Thanks again for your willingness to share your work and hard-earned wisdom.

  6. Aaron November 10, 2011 at 8:51 AM

    Would you consider selling the project with the parts, loaded code almost ready to mount to a track? My pack is buying a new 3 lane track this year and we would like a timer. I am just a geeky dad and would love to have a system like this but my programming skills are very weak (more of a hardware guy). If you were to build the controller box with usb and provide the finish line parts so we could adjust to fit our track that would be awesome. If you are not able to build the project for us would you please provide a list of the part required and a link to the online stores. We plan to use a Windows 7 laptop with USB and GrandPrix Race Manager Software

    • jarrodsinclair November 11, 2011 at 7:58 AM

      Hi Aaron,
      Thank for the interest in my track timer and your message. I have had a few requests for this and therefore have been thinking about selling a complete unit or part kit that allows people to build it on their own but given that you only want to do 3 lanes this system would be quite expensive in comparison. Not many people need a timer for a track with more than 4 lanes. Also there are many systems already on the market that support 4 or less lanes with ease and would be cheaper. However, if you would still like to use my design, I can price out what a part kit would cost and then the labor to build and assemble it. please contact me at: jarrodsinclair(at)hotmail(dot)com for further information.

      If you want to source the parts yourself you can see them in the project page and posts in my blog. In most cases there are hyperlinks to the actual part. In other cases the ”part” is generic enough that I did not (like 28awg wire for example ) NOTE: the finish line was machined from aluminum channel and bar stock as well as some ABS plastic that I had. If you were to build one yourself you would need to either find someone with a machine shop or change the design of the finish line to match the materials your comfortable working in.

  7. Brian Powell April 20, 2012 at 12:37 PM

    What is the price for parts, kit and complete unit for a six lane track that can have up to 400 participants. Include trials right up to the final race. With everyone running on each lane taking the average of the lanes/races per car as being the final speed. A spec on each car i.e. indicating speed of each race with the final and a summary sheet of the works. Do you know of where I muight be able to get one. I would also like to be able to use it without a dedicated cpu please. Plesae reply to Brian Powell – Scouter/Scout Trainer bne@nb.sympatico.ca – 78 waterville Road, Waterville-Sunbury, New Brunswick, Canada E2V3R9 506 357-7013 Thank you

    • jarrodsinclair May 11, 2012 at 6:48 PM

      Hi Brian,
      Thanks for contacting me. Sorry it took so long to respond but it’s been a busy month. First let me give you an overview of what we built. This is an 8 lane system (there are enough GPIO ports on the embedded controller that you could add 2 more lanes) that was built to support our local club of about 70 racers. We didn’t really build this as a kit but I tried to document what I had done of the finish line and timer so others could reproduce it (there are not many 8 lane systems). Danny (the guy that built the track) has some drawings but I don’t know if he ever made assembly instructions. As for the Timer, you can look at the project page, but it can Operate separate from a computer and will display the top 3 winning lanes with their times until the start gate is closed (you could add a feature to show the remaining lanes by pressing the onboard button to switch pages). For Computer connected operation we used a software package called Grand Prix Race Manager (GPRM). It would talk to the Timer via a Serial to USB interface. GPRM is the one that controls the building of each heat and scheduling the races in each heat. We typically run with N rotation where each car races in each lane during a heat and then the worst time is thrown out. Then after all racers have races we will typically pick the top 8 (cause we have an 8 lane track) to do a Grand Finally. That heat is 8 races and follows the same rules for the previous. Then the car with the best average times wins. We have found this to be most fair as it rewards clubbers that build cars that can keep racing and not just do good in one race.

      As for buying / building your own track, we don’t currently make a kit but I could talk to Danny about it. However given the size, weight, and cost for shipping (from California) I would recommend that build one using local materials or buying an aluminum one from a closer supplier. Also if you really have 400 racers then you might want to look at a second. Cause if you do the math, 400 racers with multiple races (1 per lane) that is 6.6 hours or so without stopping.

      One other point of consideration is that if you don’t use it connected to a computer then you might lose track of which cars races which times. If you are only looking for 6 lanes there are commercial timers out there and they will likely cost less them this system. I am really happy with this timer as it has the features we needed (especially 8 lane support) but it was not cheaper to build. Then the other timers out there and if you look at http://grandprix-software-central.com/index.php?option=com_content&view=article&catid=20%3Agprm&id=1%3Agprm-info&Itemid=34 along the right side and there is a list of timers. Many of them support 6 lanes.

      I hope this helps. Feel free to e-mail me any other questions jarrodsinclair at Hotmail dot com

      Best Regards.
      – Jarrod

  8. John Lever May 28, 2013 at 10:11 AM

    I’m very intrigued by your design. I’m attempting to reproduce it myself. Out of curiosity, was there a specific reason why you chose to power the infrared emitters from the timer instead of powering them locally at the finish line? Simple convenience?

    • John Lever May 28, 2013 at 10:37 AM

      Actually, after closer examination, I believe I see that powering it at the finish line is exactly what you did. I incorrectly assumed that the wires in the second rj-45 jack was for powering the emitters, but instead it appears that most of them are unused. In our case, I plan on the servo and gate switch to be local to the netduino and display, at the start of the track, so I may just use a smaller cable for ground from the finish line to start gate. For connecting to the computer, instead of a USB FTDI adapter, we plan on using either a set of 2.4Ghz XBees or 900Mhz serial radios from 3drobotics. In this way, the laptop can be completely mobile. Do you see any problems with this?

      • jarrodsinclair June 3, 2013 at 8:50 AM

        Hi John,
        Yes you should be able to use an Xbee or other wireless serial device. Here are a couple points to consider though:
        FIRST: The software I am using (Grand Prix Race Manager) does not have any ability to support “bad” data. so you would have to make sure that the device you use has a checksum and that you enable it. If the GPRM is expecting to see 1 3.4454 (a race time) and instead it gets 1 3.^Z4 or some other weird char, there is no telling what it will do.
        SECOND: most environments are not clean so using 2.4ghz cause of Wifi and bluetooth. So you will really want to test.

        Best of luck and let me know if you run into any issues.

  9. Chuckles June 8, 2013 at 8:35 PM

    Could you post “Page 3”, to give a full accounting of your success?

    Also, could you be persuaded to sell “turnkey” hardware for a 4-lane track? The stuff our pack is aging and beyond repair, we need to start fresh with hood working stuff, and as a .NET developer and a Scouts dad your work has caught my eye.:)

    Thanks!

    • jarrodsinclair June 11, 2013 at 6:11 PM

      HI Steve,
      Thanks for looking at this project and reaching out. I am always amazed the people find this interested even after 2 years.

      I have the links to all the details for page 3 at the bottom of Page 2, but I will see if I can carve out some time to make it nice and pretty since there still is interest in this project.

      As for the “turnkey” solution, I could do it however I have a full time work right now so I would have to build this in my spare time. Also you can build this for much less then I can sell it. For Example: if you have to by all the parts it will likely cost you about ~$400 depending current cost of items, shipping and your access to machine shops tools. It will take you about 80 to 120 hours to build and test on your first time though depending on your soldering experience and machine shop skills. So for me to sell it I would most lily have to charge over $1k US (i would need to rerun the BOM to see what current costs are on them). However if that does not scare you away then please contact me using this e-mail jarrodsinclair(at)hotmail(d0t)c0m and we can talk about arrangements.

      – Best Regards

  10. John Lever June 11, 2013 at 4:41 PM

    So far, it looks like I’m getting good data across the XBees. I just have one little bugger of an issue that I can’t seem to sort out. It seems that the first time through the SerialPort_DataReceived handler, it can handle either a single byte input, or the multi-byte lane mask commands. However, if I try to issue another multi-byte mask command, the event handler triggers twice, once for each byte. It sees M2, for example, as two separate commands. Thinking that the buffer just wasn’t filling up fast enough, I put a Thread.Sleep(100) at the start of the handler in order to allow the buffer to fill. This initially appeared to work as I was just dumping the text to the console and everything was working. However, once I uncommented the code to process the command, I started getting unhandled exceptions. Again, the first time through, everything works as it should, but the next multi-byte command causes trouble. Single byte commands process correctly every single time. Any thoughts?

    • jarrodsinclair June 11, 2013 at 5:21 PM

      I will have to look at the code again, but I do remember having to do something to get the lane masking to work correctly given it was 2 characters. i thought i had put code in there specifically to handle that.

  11. John Lever June 11, 2013 at 5:56 PM

    I certainly appreciate it! To take the Xbee out of the equation, I’m going to try a USB TTL adapter. If it helps in any way, I’m using the latest non-beta firmware on the Netduino, 4.1(6). I’ve also tried sending multiple mask commands separated by a carriage return, and again, the first time through the handler, it works beautifully. All lanes get masked correctly. Things only break down subsequent times through the handler. Sometimes it reads both characters simultaneously, other times only a single character. And I get exceptions. Not making any sense to me. Thanks again for all of your work. I enjoy building hardware a whole lot more than code.

    • jarrodsinclair June 11, 2013 at 8:53 PM

      Hi John,
      I looked at the code and it broke loose a memory. are you using GPRM or a terminal like putty? I ask cause you can’t type fast enough to get both the characters sent at the same time. I tried Copy and Pasting the code into the terminal but that didn’t always work either. In the end I just downloaded the GPRM demo and tested against that and it worked well. BTW the GPRM is well worth the money. it has some great features for the price. it will even calculate stats for you track for each lane.

      • John Lever June 12, 2013 at 4:38 AM

        Yes sir, we bought GPRM and that’s what I’m using. But I’m using PUTTY for testing, doing a copy and paste. You’re right, I discovered early on that I couldn’t type the commands fast enough. I think I’ve actually “solved” the problem, but it involved rethinking the serial input. I used Hari’s SerialPortHelper class in Main() to grab an entire line of input, indicated by CR or LF: I’m hoping that I can configure GPRM to provide a \r after each command. If so, we should be good to go.

        while (true)
        {
        string SerialCommand = serialPortHelper.ReadLine();
        if (SerialCommand.Length > 0)
        {
        Debug.Print(SerialCommand);
        ProcessSerialCommand(SerialCommand);
        }
        Thread.Sleep(1000);
        }

      • John Lever June 12, 2013 at 3:15 PM

        Well I thought I was making progress using the new serial method, and it does in fact work better, but I was still able to throw an exception after a few races. So I went back to your method, and this time using a hard wired TTL adapter. Unfortunately, no change. This is a copy of the debug upon starting a race through GPRM (no putty this time):
        X
        M
        M
        4
        4
        M
        M
        5
        5
        M
        M
        6
        6
        M
        M
        7
        7
        M
        M
        8
        8
        C
        R
        False
        A
        T
        Start Gate was triggered: 128752417907556266
        True
        Lane_2 was triggered: 43250774
        Lane_2_Time:4.3250
        Lane_1 was triggered: 43355094
        Lane_1_Time:4.3355
        Lane_3 was triggered: 45659094
        Lane_3_Time:4.5659
        Lane_4 was triggered: 46202880
        Lane_4_Time:4.6202
        Lane_5 was triggered: 46683307
        Lane_5_Time:4.6683
        Lane_6 was triggered: 47148800
        Lane_6_Time:4.7148
        Lane_7 was triggered: 47680640
        Lane_7_Time:4.7680
        Lane_8 was triggered: 48478507
        Lane_8_Time:4.8478
        False
        Race Completed
        Sent race times

        So apparently the XBee was not the issue. Still scratching my head.

      • jarrodsinclair November 30, 2013 at 1:55 PM

        Hi John,
        Were you eever able to figure out this issue? If not let me know. I just got an xbee kit from a friend to play with and I can test this out. It would help if you could send a fritzing or diagram of how you have the xbee wired and then the madle and settings of the xbees.

        Thanks,

  12. MAC November 25, 2013 at 9:24 PM

    Has anyone tried this project using a netduino plus 2, just curious? Will the existing code Jarrod has written work?

    • jarrodsinclair November 30, 2013 at 1:48 PM

      Hi Mac,
      I have not been told if anyone has used the plus 2 but my understanding is that the pin-out is the same so it should work as is. If you want you can get the code from codeplex and breadboard it out. Then let me know if you run into any issues. You can just do jumpers instead of photo transistors if you don’t have them to test out the code.

  13. ross July 12, 2015 at 10:10 AM

    How much did this cost you to make?

    • jarrodsinclair July 20, 2015 at 4:24 PM

      It was about 400 dollars, but that was in 2011, the prices on the items have changed in the last 4 years. also try to get more shipped together. almost 1/3 of the cost was shipping of parts.

      Best of Luck!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: