Home-built lap counter

[Lasp]

Very good start.
Running without timetaking isnt fun.
Too bee better and improve, You need a good system for timing.

I have Ask WesR about the protocoll and Hi says its belongs too the electric company.
But I have tested with the Carrera system an can see some numbers.

But this is a great start too do a good system.
Its important too se counting and display as two different things.
Each IR should report Place, Id and TS (timestamp)
Then its up too each owner to present the result in an audi format or to a computer platform.

But I will try to make a better describtion, and be better to presentet it on english
I start with testing this. Many Thanks from Lasp

[steellynx]

Each IR should report Place, Id and TS (timestamp)

My plan for these things are to configure the software running on the PC to handle placement of the IR sensors as well as timing. That way I can minimize the time spent transmitting data over the serial bus. Serial communication is horribly slow compared to the frequenzy the LEDs are blinking with. Besides, each sensor doesn't in itself know where on the track it's located so it has to be configured anyway.

As for where to do the timing, I want to keep that in one, and only one place. Since I plan on supporting several sets of sensors through several different arduinos. Since each arduino currently only support 8 IR sensors and you need one for each track/wire that means that one arduino can support a two track/wire racetrack with a start/finish line (2 IR sensors) and three separate sectors (3 x 2 IR sensors). If people want to do 3 wire tracks or include IR sensors in the pit lane (which they should!) you quickly run out of available sensors. And if you did the timing in the arduinos they will have to be synchronised somehow. If timing is done on the PC then the arduinos can be seen as simple slave devices that just report "sensor X has seen car Y" which will work.

I have quite specifically not looked at which protocols the different commercial lap counter systems work because I don't want to get caught up in some kind of battle with the people making those systems. The only thing I've done is to look at a blinking LED and then decided how I want to decode that signal.

[Lasp]

Thanks for a very good and describing post!

I agree about lot of sensors, I can also agree about the synchrony .

But the visible thing, in other word, display its not important with tousends of seconds.
If you present the result within a tenth of a second, its good enaf (spelling)

I will build an test.

[WesR]

Re lap counting for 3 lanes and/or pit lane, for a road circuit I find that you cannot have correct racing lines with 3 lanes and even our Nascar oval, which originally was built with 3 lanes, has now been converted to 2 with the inner lane providing pit entry and exit. Re, lap counting the pit lane, the problem is that sometimes it is quicker to drive through the pits!. This is the case with our Nascar oval. We propose, when we get back to racing, to have compulsory pit stops, i.e. cars must come to a stop, but even this would not loose much time so to also loose one lap would be better and would probably mean a change of lead.
So I am saying that, personally, I would only build a two lane counter.

[steellynx]

Really good points, Wes, especially the one about the pit lane being faster. What I'll most likely do with the PC part of the software is to allow users to configure each sensor to work in different modes, e.g. start/finish line, sector X, pit and so on. Then it will simply be a matter of having different options for the different types of sensors so when you save a track setup it would know how to handle the pit lane.

On your oval track it could simply cost a lap to hit the pits, but you could still keep track of which cars had been there and that would actually make it possible to force all cars through the pits a certain number of times during each race. One way of handling this would simply be to have two lap counters, one for laps and one for pit entries. A car would not be able to win until both counters were over a certain number, e.g. 50 laps and 3 pit entries.

Does that make sense?

As I think I've mentioned at some point I've never done slot car or r/c racing so I don't really know precisely what makes sense

But the visible thing, in other word, display its not important with tousends of seconds.
If you present the result within a tenth of a second, its good enaf (spelling)

I think it would have to be one hundredth of a second or better since the cars seem to be going at somewhere between 1-3m/s or faster. At those speeds a tenth of a second would be 10-30cm and while the events would still arrive chronologically in the PC end (i.e. the order of the cars would be preserved) it would still give some results where cars that were far from each other would get the same time.

Somewhere at the back of my mind lurks the idea of splitting the software into two components where one is a simple datalogger that can run on a scraped down real-time system and simply ensure that the timing is kept as precise as possible. Then the other part of the software could run on a different computer and connect to the first system and pull the race's status from it and display it in whichever way seems good. This would also make it a lot easier to e.g. make a system that displays race data on a publically available webserver.

But that's a little bit out in the future. For now I'll stick to working on something that will simply display the order of the cars, their lap count, their fastest lap time and their last lap time. It should also store all lap times, of course, and make it possible to dump the results of the race so they can be read again later on.

Would that be a decent goal for a first release of something you guys could use?
Or would you prefer to wait until I have things such as storing individual drivers, keeping track of their races and so on?

[Lasp]

Testing and using is improvment!
So its all for run and adjustment!

When I wrote tents of a second it was for communikation too the display.
Laps should be counting in tousends of a second.

And my Idea with many points (positions) is just too make it easy too set speedtraps in Pitlane, measure Pitstop and even set phase to 60 instead of a pacecar. As the new thing on LeMans

Så just start using, make reports and we will learn to get a good system.

Then we can put up a databas with cars, drivers and tracks.

But we need a strong system for laptime in the bottom.

[steellynx]

When I wrote tents of a second it was for communikation too the display.
Laps should be counting in tousends of a second.

Right, that makes a lot of sense

But we need a strong system for laptime in the bottom.

That is definitely also my main focus at the moment, and also the reason I've only worked on the arduino part of the project. From the event I held at work a couple of months ago I know that a simple "which car is in the lead" style score board can be made in a few hours.

[Joel, LeNoir]

Any updates.....?

[steellynx]

Any updates.....?

Does "my brain has melted in the summer heat" count as an update?

From next week I start a four week vacation which should give me time/energy to finish the pc software for showing lap counts and times.

Have any of you started experimenting with the sensors and arduinos?

[WesR]

Not sure if the attached photos are any help. This counter seems to work well
with only the single sensor per lane . They are approx 4mm below the track and
the aperture was gradually reduced to a size much smaller than was expected.
Most of the compnents shown are not necessary I believe. Just happened to be
on the boards! If you really need to know more technical info, let me know
exactly what and I will try to find out.

Lap c0unter 033 (640x480) (2).jpg (246.55 KiB) Viewed 40671 times