Originally Posted by howardcano

The first pass at software for calculating the transponder crossing times inside the decoder is done! I found the code to be fairly challenging given the small amount of RAM and processing power, but it certainly does eliminate the timing bottleneck of sending every transponder message to the PC; now the decoder sends only one message per transponder after it crosses the timing loop.

So now we are ready for all of you software enthusiasts to write your own scoring software on the PC. Several of our readers have already expressed an interest in doing so.

The communication from decoder to PC is similar to what I have already described in this thread, so please forgive me if some of this seems repetitious:

The decoder sends a message to the PC every time each “verified” transponder has passed through the loop. (The decoder verifies each transponder as it passes individually through the loop; the criteria for verification are three consecutive identical messages received from the transponder. No input from the scoring PC is required for this to occur.)

The decoder messages are logic-level asynchronous serial “RS232” at 115200 baud, 8 data bits, no parity, 1 stop bit, and no flow control. This may be converted to USB using an adapter cable. (I’m using a Sabrent SBT-USC6M USB to Serial Adapter Cable from Walmart.) Each message consists of 16 bytes: The first 6 bytes are ASCII hexadecimal characters representing the first 24 bits of each transponder transmission after the preamble, which we will use for the transponder ID. The next 8 ASCII hexadecimal characters are the timestamp, MSB first, in increments of 1/4 millisecond. (Zero time is when the decoder was powered-up.) The string is terminated with a carriage return and line feed. Here is a typical example:

CDFD4C00FFB6DA

And here is a message for the same transponder ID, but with the timestamp incremented by 10 seconds (a typical lap time):

CDFD4C0100531A

Here’s a synopsis of what the PC must do:

Before starting a race, all cars must individually cross the loop so that the decoder will recognize/verify their transponder IDs and send messages to the scoring PC. The PC then verifies that all of the correct cars are present. (This usually happens in the race “warm-up”.) Then all cars line up behind the starting loop, and the PC sounds a tone to start the race.

The PC receives messages from the decoder as each transponder crosses the loop, and stores the messages. When a second message is received for any given transponder ID, the PC examines all the timestamps it has received since the tone sounded, and determines which has the lowest value. The PC then calculates the finishing time for the race by adding the race length to this timestamp.

As each new message for any given transponder is received, the PC subtracts the current and previous timestamps for that transponder to get the lap time. The race ends when the timestamp for each transponder exceeds the calculated finishing time for the race (or manually if some cars have dropped out of the race).

Due to the separate tasks running inside the decoder, the message for each transponder may not show up at the PC in correct chronological order, but this is immaterial since the timestamps for each transponder will be correct.

Originally Posted by Lolok33Fr

Hello,
I'm french and i'm a software developer.
HowardCano and Payalneg, I want to congratulate you for this very good work !
I'm interesting by your decoder for my club (little club) because Mylap decoder is overpriced for it.
Could you confirm me that your decoder could decode mylap transponder ? RC4 ?

The solution of Payalneg to use decoder with an ethernet wifi interface is very interesting to communicate with a smartphone.

I have seen that you don't want to release source or hex files. I understand
So i would like to know what are yours conditions to obtain more informations or programmed component to assemble a decoder ? Could you send me a pm ?

Thank you
Laurent

Originally Posted by howardcano

For entertainment, and to satiate my curiosity, I have downloaded the Quartus II design software from Altera and entered a first pass of the decoder design to see how it fits into a CPLD. Reader Payalneg is correct, the design does go nicely into the Altera EPM3064, filling it to about 89% capacity.

While the CPLD would be a logical choice for producing the decoder in large quantities, I believe the 74HC logic is still best for our readers. It is available from multiple manufacturers and in most countries; it’s easy to troubleshoot and repair; it doesn’t require programming; and it’s all available in through-hole format, making construction much easier.

Originally Posted by mingoglia

I'm still very intrigued by this project. My father was an electrical engineer for DEC years ago and passed some knowledge on to me as a small child, before he passed away unexpectedly. Although I ended up going down the path of network engineering, I'm trying to teach those lessons, as well as others to my now 9 yo son. We've done simple projects like the DIY AM/FM radio and things like that. At some point I would love to do these transponder project with him. Would make it fun for him to do a project that's relevant to R/C racing since we race twice a week.

Mike

Originally Posted by howardcano

I have ordered a small number of prototype decoder PC boards. They should arrive in about 2 weeks.

I have also finished a layout for the loop amplifier. It's single-sided and measures 0.8" x 1.4", so it should cost much less than the decoder board.

While I was ordering components to populate the boards, I noticed that the price listed in the BOM was wrong for one component, the SN74HC74N. The BOM has $16, which is a bit more than the actual price of $0.49. Those of you that have received a BOM from me might want to make that correction, as it reduces the total cost substantially! (I also noticed that the CD74HC74E is even cheaper, at $0.33.)