Derby Talk

Derby Talk is a forum for Pinewood Derby, Awana Grand Prix, Kub Kar Rally, Shape N Race Derby, Space Derby, Raingutter Regatta and other similar races where a child and an adult work together to create a race vehicle and a lot of fun and memories

Traveling down memory lane, I remember preparing the circuit diagram for an expandable latching counter. Each sensor latched a counter for that lane. It was modular and simple. Can't remember if I did the same for a timer.

Something like the Swantech timers.

With a mux/demux and I2C support, I wonder if using a microcontroller/Arduino/Rasberry Pi purely for interfacing and keeping it simple for counting and timing might not be a good idea.

Keep the counting and timing out of the realm of software issues and interrupts.

Oh come on gpraceman! Re-inventing the wheel is what hobbyists and fanatics do best. :p

I read that post and it is why I started this thread. I've always been suspect of software controlled timing.

I'm a firm believer in using each thing to its strength and building modular. A timer such as the Swantech is unquestionably accurate. No programming errors, well tested, solid state. It just doesn't communicate.

If I can find my circuit notes for lane position counter, I'm really going to have to just build the thing. The plans have been gathering dust for a couple decades now. Adding a timer shouldn't be much more work.

Then, maybe I'll see about data acquisition...

Besides, if I'm going to go the microcontroller route I should use the AVR programmer I already purchased (although that is sitting in component pieces in a box awaiting assembly :p)

SlartyBartFast wrote:I read that post and it is why I started this thread. I've always been suspect of software controlled timing. I'm a firm believer in using each thing to its strength and building modular. A timer such as the Swantech is unquestionably accurate. No programming errors, well tested, solid state. It just doesn't communicate.

The only software controlling the timing is the timer's firmware, whether it be a serial port timer or one that has no computer interface. The only real difference firmware-wise, is that there is a bit of extra code written to take those timing results and send them to the computer. The computer itself just reads and displays those results.

When I think of software controlled timing (as in computer software, not firmware) that is with a parallel port type of system where the state of the inputs (lane sensors and start switch) are directly read by the computer and the computer does the timing. GPRM V6 and below supported this type of communications. With the advent of more layers between the software and the hardware with later versions of Windows, real time race timing from a computer became impractical. So, support for that was dropped. GPRM V7+ only supports serial port timing systems. Read and display. No timing on the part of GPRM.

Just revisiting, in the past I had a few discussions where people were concerned about the errors that might be induced by poorly written firmware and interrupt handling.

Taking a good look at the Swan-Tech timer I realise that even that is a PIC microcontroller based timer. Guess even when computer connectivity isn't an issue the go to is microcontrollers and not decade counters.

Kind of disappointed me that Swan-Tech doesn't have computer connectivity and scaleability.

My old schematic from years ago was just a set of counters. Each lane would produce a signal that would be counted by all counters (lanes) an the counter for the lane that generated the signal would be latched.

As I'm moving houses, I might come across it...

Meanwhile, I have found the various bits and pieces I had bought to recreate the DerbyTimer PIC based timer using an AVR. But now, you can just buy an Arduino and start from there.