The software's Custom Serial Timer interface (Pro Version) does allow the software to work with several non-supported commercial timers or even DIY timers.  If your timer is a commercial timer, but is not on the supported list, check our downloads page to see if there are interface instructions for it.  If you want your commercial timer to be added to the supported list, let the manufacturer of that timer know.

Below are the specifications for the custom timer interface.

Communication Parameters:
• Baud/Data Bits/Parity/Stop Bits - Common communication parameters are 9600-8-N-1, but this can be configured if the protocol is different.

Software Commands:
Below are the commands that are currently supported. The Reset Timer command is the minimum expected, the others are optional.

Start Gate Status:
• Start Gate Check - Command that the timer will accept to have it check if the start gate is open.
• Start Gate Open Response - The response from the timer if the start gate is open. This can be a simple '1'  for open and '0' for closed or can be a letter or word.
• Timer Start Message - This is the message that the timer will send to the computer to indicate that the heat has started.

Timer Reset:
• Reset Timer - Command intended to reset the timer's display and ready it for the next heat.
• Ready Response - Some timers may provide a response back to the computer, when they receive the Reset Timer command, acknowledging that command.
• Response Read Delay - This setting is only needed if a Ready Response is set; otherwise, it will be zero. This delay is usually the same as the Read Delay in the Miscellaneous section, but will depend on the amount of time needed by the timer to reset itself and then indicate that it is ready.

Lane Masking:
• Mask Command - This is the command for masking a particular lane, so the timer will ignore that lane. This command will be combined with the lane number (or letter), so the timer knows which lane to mask.
• Remove all Masks - This command will tell the timer to clear all lane masks, so no lanes will be ignored.

Other Software Commands:
• Retrieve Data - This command is only used for timers that do not automatically send the results (the preferred method), but need to be "prompted" to send the results data.  This is not needed for timers that automatically send the results once cars have finished.
• Force Data Send - This command is used if you want to halt the timing (e.g. a car doesn't finish or there is an empty lane). Pressing the Escape key will prompt the timer to return whatever data that it does have. In this case, any cars that had not finished will be given the maximum time possible. This command is not necessary if the timer sends the data for a lane as soon as the lane has finished timing. If the timer doesn't support this command, then you must wait until the timer times out before the results will be displayed on screen.
• Trigger Solenoid - This command is if the timer has the ability to trigger a solenoid start gate and will accept a software command to do so. Some timers may trigger a solenoid gate, but may not accept a software command to do so.

Note 1: For any of the commands above, if your timer requires a carriage return and/or line feed to be sent immediately after the command, then do the following. For a carriage return, add a \r to the end of the command. For a line feed, add a \n to the end of the command. For a carriage return + line feed, add a \r\n to the end of the command.

Note 2: It is preferable that every command that the timer supports returns some type of acknowledgement.  This is typically a carriage return + line feed, but can really be anything.  It can also be helpful for the timer to provide some type of response for a command that it doesn't recognize, like a question mark.

Miscellaneous:
• Read Delay - It may take your timer a little time to respond to a command or for your computer to notice that the timer has sent data to the serial port. While testing the timer, if you are not getting a response from the timer or an incomplete response, you can try increasing this delay.
• Precision - This is timer precision, the number of decimal places that the timer reports the times out to. It is preferable to have a timer with the timing precision between 0.001 and 0.0001 seconds. At lower precisions, you stand a greater chance of having ties. Higher precisions are more likely to show "noise" in the times.
• Max Time - The maximum time that the timer supports.
• Lane Labels - If the timer data displays the lane labels as either numbers or letters. This needs to be set correctly for lane masking to work properly.

Data Specs:
• ASCII characters
• The lane number should precede the time for the lane.
• There should be either an equal sign or at least one space between the lane number and its time value.
• There should be at least one space (or a carriage return + line feed) to separate a lane number/time value pair.
• There should not be any alphabetic or special characters adjacent to the lane numbers or times.
• A time must be reported for each lane. For lanes that do not finish, a time of 9.9999 seconds (or whatever the timer's time out value is) can be reported.  A time of 0.0000 seconds may also be used.
• Avoid including any other numbers besides lane numbers and times.

The data format can be as simple as:

3 2.8820 1 3.5109 4 3.5134 2 3.6202

or for better clarity:

3=2.8820 1=3.5109 4=3.5134 2=3.6202

or it can be as verbose as:

Ready to Start Race
They're off!
Lane 3 3.2437 Win
Lane 5 3.6782 Place
Lane 1 3.6917 Show
Lane 2 3.8361
Lane 6 3.9216
Lane 4 3.9525
Race Over

Debugging:
All communication is written to the HardwareDebug.log file, located in the "Documents\Lisano Enterprises\GrandPrix Race Manager" folder. This will show you the raw data received from the timer, the filtered data and then finally the times that were extracted.