Timing Equipment

[kyle.bowker]

Have you discussed switching to AXware for timing?
What type of timing hardware are you currently running?

//Start programming

AX-ware

http://www.axwaresystems.com/index.htm

//End programming

Our current timing system is LapTracker-Autocross/Pro from AutomotiveMETRICS. Last year we added wireless transmitters which was HUGE improvement, although there remains some development to be done to improve range and accuracy. Needless to say we're not fully satisfied with our current timing system. It is rather clunky. Accordingly, it isn't being used to its fullest potential. One of the biggest downsides is the way it handles multiple cars on course, the amount of manual intervention that is required, and how car info is input/output from the system. Now, car #'s are manually entered into the system. If a car gets out of line or changes order it messes up the order in the timing software. It is impossible to "pre-load" data from registration into the timing software because we never know who is going to show up or exactly what order they will run in.

We're hesitant to drop several thousands more dollars into upgrading our timing system with an off-the-shelf package offered by yet another vendor given our previous experience with AMetrics and our current investment into the website registration system and the wireless transmitters which might not be forward compatible. Cost is a big issue. Your're talking almost $7,000 for the Axware system including wireless transmitters and a display board. Many members have requested a display board but I don't think it's possible with our current system, not to mention they cost $800+. Some people have said that if you can't here the PA system then your car is too loud and need to install quieter mufflers! All this money for a system that might not be fully compatible with our desires.

We figured this club is full of enough bright, energetic scientists, engineers and computer nerds we should be able to develop a robust system that meets all of our needs and is 100% custom configurable. Our goal is to create a system that seamlessly integrates registration, timing, and scorekeeping. I believe we will need to implement barcode or RFID technology where each participant has a unique identifier that gets scanned before the start of each run and that information is relayed wirelessly to the timing control software. This way we know who was driving for each time that gets recorded. The software must easily allow us to add penalties for knocking down cones or DNF. The link between the registration data and the timing data is each participant's unique identifier. This will allow us to lookup their index, determine which run was their best run, and post the results with the simple click of a button. No more manual data entry by organizers, no more countless hours manipulating values in a MS Excel spreadsheet. The hope is that automation will reduce the number of mistakes and the level of effort. As soon as the last car crosses the finish line it should take no more than 5 minutes to compile the results in a format suitable for uploading to the website.

As we move away from the stone and chisel methods and into a completely digital, computer based system we're presented with new challenges. My biggest question is how will we handle people who switch cars? People register for events weeks in advance. Sometimes their car breaks down or is otherwise unavailable for them to use at the event. Or maybe they decide to run one car in the morning and one car in the afternoon. With the current system the participant just scratches out their old car info and pencils in their new car info. But if we go to a new index system that follows the driver AND the car we must track which car they are in when they do each run. This way the proper index for that particular car is used when calculating the results and the proper car info listed when we display the results.

[moxnix]

Can you give me more details on the current system?

I think the sensors (start/finish) send a signal back to a receiver that is directly hooked up to the serial port of the computer? The computer does all the actual timing.
Are the start and finish separate triggers or do you have to select the stop watch they go to?
What type of signal is sent to the computer?

Looking at the help file for your software it says.
--------------------------------------------------------------
Hook-Up Circuits:
For Devices with Discrete Normally Open (NO) and Normally Closed (NC) Contacts (e.g., Optex VR2-800):

Serial Port Pin Photo-Eye Connection
2 ------------------- COMMON (Common contact of device)
4 ------------------- NO (Normally Open contact with device in powered-on state)

For Devices with Common Normally Open/Normally Closed Contacts, Utilizing Light-ON/Dark-ON Functions (e.g., Optex VR-500):

Serial Port Pin Photo-Eye Connection
2 ------------------- Common Contact
4 ------------------- NC/NO Contact*
LTAuto/Pro - AutomotiveMETRICS
---------------------------------------------
So it looks to me like the trigger is the same no matter if it is a start or finish trigger? (example : You trip start twice and it is recorded as a start and a finish unless you manually switch the stopwatch in the program?)

I think you need to ask yourself as a club.
1. Does this system do what you need it to? (you have already said no)
2. Can this system do what you need it to with minimal work? (If it does not have separate start and finish triggers it will be a lot harder since you either have to manually select or count on having a certain number of cars on course at a time and any start line issues will cause problems there)
3. What actual features do you need? (is wireless needed? Is display needed? what level of accuracy is needed? Barcodes needed? what type of scoring reports?)
4. How much is your time worth vs money?

I still think that AxWare would meet many of your stated needs but I can see how the cost can be a large factor since it is not cheap to switch the whole timing system. I have seen some custom coded systems and the main problem with them seems to be that the only person who really knows how they work is the guy who wrote them so he spends half the day fixing problems with the timing system at the event.

If you would like to see how AxWare works for registration and timing come on out to the DC SCCA event on the A lot at Fedex on Sunday and I can show you around.

[kyle.bowker]

Are the start and finish separate triggers or do you have to select the stop watch they go to?

No, start and stop send the same signal. They are not unique. So if a car crosses the start light and then 20 seconds later another car crosses the start before the first car has finished the timer will stop at 20 seconds.

What type of signal is sent to the computer?

I'm not really sure of all the technical details but I know it continually sends 4bit packets so long as the timing beam is tripped.

So it looks to me like the trigger is the same no matter if it is a start or finish trigger? (example : You trip start twice and it is recorded as a start and a finish unless you manually switch the stopwatch in the program?)

Correct.

2. Can this system do what you need it to with minimal work? (If it does not have separate start and finish triggers it will be a lot harder since you either have to manually select or count on having a certain number of cars on course at a time and any start line issues will cause problems there)

I don't know. JoeTR6 and Ed Chan are more familiar with the system than I. My hope is that we can continue to use our existing photocells (since we have 2 and spares as well) and just change the way the signal is encoded before it's transmitted to the computer so it can tell the difference between start and finish.

3. What actual features do you need? (is wireless needed? Is display needed? what level of accuracy is needed? Barcodes needed? what type of scoring reports?)

Wireless is absolutely necessary. We'd like display but we've gotten along so far without it. It's dependent upon cost. Precision to 1/100th of a second with accuracy better than 1/500th of a second. I think barcodes would but not absolutely necessary. How does SCCA do it? Does the starter radio the car number to timing control before they enter the course? We don't even know what kind of scoring system we will use next year since much is dependent on the outcome of the index discussion.

4. How much is your time worth vs money?

Both are in short supply, but I suppose we've got more time than money since the next auto-x season doesn't start until next March or April.

the only person who really knows how they work is the guy who wrote them so he spends half the day fixing problems with the timing system at the event.

Right now Joe is the only one who really knows the ins/outs of our timing system and wireless transmitters. This is why we must test and test some more and have spares of everything.

If you would like to see how AxWare works for registration and timing come on out to the DC SCCA event on the A lot at Fedex on Sunday and I can show you around.

Thank you so much for the invite. Unfortunately I must decline as I will be out of town.

[JoeTR6]

Our current software uses two pins of the serial port as a switch to trigger the timer. So yes, the computer does the actual timing and only has a single trigger. The optical sensors we use are actually quite good, and as Kyle mentioned, we have two spares. The wireless link is basically an RF switch that uses a relay to close the circuit on the serial port. It sends a minimum of binary data (4 data bits + 8 address bits). When the sensor outputs close, the transmitter sends a the bit pattern at least 4 times. The receiver decodes the signal and uses the four data bits to close the appropriate relays. The lag in this system limits its accuracy to 1/100th of a second, but measuring time on a Windows OS is the long pole in the tent. After the last Manassas event, I found that the voltage supplied to the receiver was marginal, and tweeking it up has helped. We had some failures at the last Harry Grove event, but I think that was more about range, signal occlusion, and multi-path interference than equipment.

2. Can this system do what you need it to with minimal work? (If it does not have separate start and finish triggers it will be a lot harder since you either have to manually select or count on having a certain number of cars on course at a time and any start line issues will cause problems there)

This is more of a problem at Bowie where we can safely overlap runs, but is an issue anywhere. The need to manually arm the timer is a huge PITA. I'm writing a prototype timing application that can use all four available signals and run multiple timers simultaneously with less user input. We also have the issue of passing data from online registration to registration at the event, timing computer, and back to the web results page.

As for features we need, I'd say wireless, capability to run multiple cars, and data inport/export are must-haves. Nice to haves include a barcode reader and large display. We could also use a backup wireless system, a better PC, a new truck for towing, and our own paved lot.

Right now Joe is the only one who really knows the ins/outs of our timing system and wireless transmitters. This is why we must test and test some more and have spares of everything.

I can answer questions and provide wiring diagrams if you want them. Our current system certainly has flaws, and it would be nice to have one with microprocessor-based timers on a wireless LAN at the start and stop with dual sensors to ensure we don't drop a single event. I can't say what the priorities will be in the off-season, but at a minimum the trailer needs electric brakes and we need to replace some of our cones.

If you would like to see how AxWare works for registration and timing come on out to the DC SCCA event on the A lot at Fedex on Sunday and I can show you around.

I'd like to show up, but the wife has my time tomorrow. I'll definitely come to another event.

[BugBomb]

That new timing program that Joe created is SLICK. I have a feeling that timing and results are going to see fantastic changes next year.

[JoeTR6]

If I get a few kinks worked out (like making up a decent serial cable instead of jamming paper clips into the receiver) we can use it for the next T&T event. I also need to test the unique start/stop sensors before we try it at Bowie. I may even try to import the registration data so we have driver/car info displayed next to the times. It's easier seeing car make and color of a car on course than the numbers. Over the winter, we can work on processing the data into a web page automatically. We may end up using paper as a backup for some of next season, but I think we can do everything on the computer.

BTW, the company that the original wireless hardware came from now has new prototype boards using a longer range receiver chip. I may order one and give it a try, because that receiver is supposed to have a range of 1000 feet. Another thing I'd like to do is hook a bright LED or buzzer up to the sensors so that we can tell whether a timing failure is the sensor or wireless link. We still had a failure rate of 1 in 40 runs or so on Sunday, but it seemed fairly random. Sometimes start, stop, or both didn't work.

[BugBomb]

Joe, have you thought about making some simple dishes that can slip onto the antennas? I have seen people make them out of household items, and it has done wonders for their wireless signal when it is concentrated in one direction. You would just have to make sure that they can't be moved by the wind.

[FamilyTruckster]

Serial cables? I can make those. Whatcha need?

[bearda]

Really old topic, but if you're still having timing issues and/or are looking at playing with the serial signals let me know. I don't know a lot about Autocross, but if there's anything I do know it's embedded systems and serial interfacing. There are a couple of third-party serial libraries you can link in that interface to a virtual serial port driver and can get you a lot better timing accuracy.

[JoeTR6]

If you're at one of the events, swing by the timing tent and we can discuss this. I'd like to be able to run our timing software on Windows(tm), but have written it for Linux just to be able to access the serial port at a low level. I'm basically looping the DTR pin back through the CTS and Ring indicator pins, then checking the status of each pin (at a fairly high rate) in a high-priority background thread. On Windows, I assume you need to do some sort of interrupt.

I suspect our malfunctions last year are fixed, as I had the receiver working with a fairly marginal voltage. We also might still have problems with RF interference and the sensors themselves. It would be nice to put some sort of buzzer on the sensor switch so that we could tell whether the sensor registers a start/stop.

[kyle.bowker]

I think the cure for the sensor issue is to raise them up off the ground 12". Until we have handshake between transmitter and receiver, radio interference will always be a threat.

[JoeTR6]

I still think the best answer may be to store the sensor events at the sensor on a PC and transmit them back to the timer computer via WiFi. I'm not sure what the max. range of WiFi is, but it's at least 200ft. This may not be the most cost-effective method, and the power requirements would be a hassle. The cost of someone wiping out the stop garage go up too.

Another thing that may help is trying parabolic reflectors on the transmitters to boost the signal at the receiver.

[bearda]

I'm planning on at least stopping by the event in Bowie this weekend, so I'll touch base with you there.

On Windows we used a pretty slick serial driver library that basically timestamps and buffers all serial data/events coming in on a given port. The driver is grabbing the data and timestamp in an ISR, but the application is still reading data whenever it gets around to it. The data's already been timestamped though, so you're not loosing any precision by delayed processing. There are a couple other ways to swing it, but our system had a good deal of background load and a scheduler from hell.