View Full Version : A cheap & crappy homemade Arduino-based lap timer

2013.05.02, 12:27 AM
A local hobby shop has a small track set up every now and then. I wanted to contribute a bit of lap timing functionality to the venue and for such a casual environment it would be far too entitled of me to ask the owner to purchase a commercial timing system at this time. I tried building something cheap and simple out of my pocket and here's the initial version so far.

The system is infrared and is built on the Arduino platform. The main components are as follows:
-Decoder: Any Arduino hardware
-Detector: Demodulating IR receiver and 4081 AND gate, multiple detectors can be daisy-chained
-Transponder: Arduino Pro Mini 5V/16MHz
-Windows PC software

Development was done on officially licensed Arduino hardware (Arduino Diecimila, Sparkfun Pro Mini) but clones can be purchased from various sources which can bring the MCU cost for the decoder and transponders below $5 each. For convenience in mounting and USB connection though, a standard or mega footprint board can be used in the decoder. Construction notes for each component will be made in following posts.

The title says 'crappy'. The system is not robust at all - I have not done any kind of error checking or fuzzy detection, and the decoder will be confused if two cars go under the detector bridge at the same time. You can probably "win" a race by doing your first two laps faster than everyone else and then parking under the bridge. If you are running a club, you will be better off buying a commercial system such as Trackmate Iridium which isn't that expensive when you think about it.

Pictures and video will come in following posts.

2013.05.02, 12:27 AM
The bare minimum for the decoder: ONE input pin from the IR receiver chain. The only reason why I have two here is because an additional output pin is left over from when I tried making this as a standalone system with a buzzer. The enclosure can thus be made much smaller, as again I originally planned to run this powered by 2S 18650 Li-ion batteries and send serial communications via Bluetooth, but somehow my Bluetooth module interferes with the IR receiver, causing spurious detection at roughly 2.1s intervals. I don't know what's going on, but it means this system must be physically tethered to PC via USB connection.

I suppose with such minimal I/O requirements, this could indeed be built using a Pro Mini with an FTDI USB converter, and the decoder can be made about the same size as the detector.

The code is basically unchanged from Ken Shirriff's IRrecvDemo example in the IRremote library. All I changed were the input pin assignment and serial baud rate (115200), I think...

http://imageshack.us/a/img191/1701/decoder01inside.th.jpg (http://imageshack.us/a/img191/1701/decoder01inside.jpg) http://imageshack.us/a/img841/9366/decoder02outside.th.jpg (http://imageshack.us/a/img841/9366/decoder02outside.jpg) http://imageshack.us/a/img708/4255/decoder03back.th.jpg (http://imageshack.us/a/img708/4255/decoder03back.jpg)

2013.05.02, 12:28 AM
There is nothing fancy in the detector, although I have added the provision of daisy-chaining multiple detectors to cover a wider track lane. Daisy-chain connectors on both input and output are just standard JR servo leads with +5V, GND, and signal.

I don't have any schematic-drawing software, but I hope it is simple enough to describe. The output of the IR receiver goes to one input of the OR AND gate, while the input signal from an upstream daisy-chained receiver goes to the other input of the OR AND gate, with a 10K Ohm pull-down pull-up resistor. The OR AND gate output is sent downstream to another detector or to the decoder. An LED has its (+)ve lead connected to +5V and its (-)ve lead connected to the output of the IR receiver via a 470 Ohm resistor, so that you can see it light up when IR is detected.

Although the Sony SIRC protocol uses a 40KHz carrier frequency, I think there is a possibility that the IR detectors I purchased are actually 38KHz demodulating receivers. Still, it kind of works.

http://imageshack.us/a/img854/7089/detector01inside.th.jpg (http://imageshack.us/a/img854/7089/detector01inside.jpg) http://imageshack.us/a/img17/7862/detector02frontback.th.jpg (http://imageshack.us/a/img17/7862/detector02frontback.jpg)

After initial testing, the detectors will NOT work when daisy-chained. I am not educated/trained as an engineer, so it's not surprising that I don't actually know what I'm doing when I start using anything more complex than an LED and a resistor...

Any advice here from someone who actually has a clue will be most excellent!

- I think I may be wrong in the assumption that the IR receiver output is HIGH when IR is detected. I should have thought more carefully, since the visible LED shouldn't light up unless there is a voltage differential between its two leads. If it turns out that the receiver output is in fact LOW when IR is detected and HIGH otherwise, then the current setup when daisy-chained would constantly send HIGH and the decoder would think no IR was detected. So if this is the case then I need to change the IC being used to daisy-chain. AND gate with pull-up? 4081 should be a drop-in replacement although I will need to move the 10K resistor to +5V.

Update (May 02, 2013): The IR receiver outputs LOW when IR is detected. Using a 4081 AND gate with pull-up resistor now allows daisy-chaining detectors to function properly. Sweet! The width of coverage is not much so I may need to make one more to cover a 90cm lane width.

Also I am now quite certain that my receivers are TSOP1738 38KHz receivers. Depending on local availability, I will see if detection improves after replacing them with 40KHz receivers.

2013.05.02, 12:28 AM
The transponder is dead simple. The program code is basically a straight-up copy of the IRsend example from Ken Shirriff's Arduino IRremote library. The only changes I made were to ensure that PWM output would be sent to digital pin 3, and I added a little bit of code to make the built-in LED on digital pin 13 blink every now and then. The transponder ID is just a 3-character HEX code which is sent using the Sony SIRC protocol (40KHz carrier frequency) provided by the library, and you can change this to whatever HEX code you like.

The construction consists of just an IR LED on digital pin 3 with a 470 Ohm resistor, and power leads going to RAW/GND, drawing from either the battery terminals or the ICS connector. The ICS is unregulated as far as I can tell.

The Pro Mini footprint is kind of large, and with the height of the 3mm IR LED, it will not fit under some bodies.

I originally wanted to build the transponders on the ATtiny45/85 with external 16MHz crystal (or possibly internal 8MHz clock if precise enough) to reduce the footprint, but porting the sendSony() function requires setting the PWM period (25 microseconds) and duty cycle (1/4 or 1/3) involving some register-level code which I couldn't quite get working. I think it mainly requires just changing references from Timer2 (ATmega) to Timer0 (ATtiny) but I don't know how to map the output pin. Also manually pulsing using digitalWrite & delayMicroseconds is apparently too laggy to accurately reproduce the modulated signal. If someone with more know-how can help, I would be most appreciative!

However, if the footprint isn't an issue, then the clone Pro Mini gives a hassle-free transponder build for under $8, which is about the same as what an ATtiny build would cost using locally-sourced components.

If the system is robust enough (it isn't) to justify the cost, you may be able to reduce the transponder size with a Femtoduino, but at the price of $18 each you are approaching the price of a Trackmate transponder and you might as well pony up for their system since the decoder/detector/software package is just a one-time cost and the Trackmate system has performed flawlessly in the sometimes chaotic frenzy of my local club.

http://imageshack.us/a/img42/7348/transponder01mounted.th.jpg (http://imageshack.us/a/img42/7348/transponder01mounted.jpg) http://imageshack.us/a/img11/406/transponder02close.th.jpg (http://imageshack.us/a/img11/406/transponder02close.jpg)

2013.05.02, 12:29 AM
This is just a basic race standings display coded in Visual C# and .NET for Windows PC. It's not quite ready for a code release since there are a lot of dirty things left over from when I was still trying to bruteforce Trackmate :p Not to mention sloppy coding in general, so maybe I will never release the code :o Timings are not entirely accurate for countdowns and beeps and such, and due to needing a physically large detection window, I would estimate that reported lap times could be off by 100ms or more. I would be happy to share the executable for anyone who feels inclined to build the hardware and wants to give it a try though.

Two race modes can be chosen:
Qualifier - ranking based on fastest lap
Main - ranking based on number of laps, then by shortest total duration

A minimum lap time can be set so that a racer cannot count laps by driving back and forth under the bridge.

Race duration in minutes can be set.

Drivers/transponders can be added via the program itself or by editing a tab-delimited plaintext file. The format is just the driver's name followed by the 3-digit HEX code of the transponder. When a race is started, drivers will be automatically added to the race when they pass under the bridge for the first time as long as they exist in the master list file.

Up to 8 drivers per race. Sorry guys, I'm just lazy and I want information to be readable when used with old projectors (assuming 1024x768 resolution) or in the worst case a subnotebook's built-in display (1366x768). Besides, where I plan to use it on a small track with 3-second laps, it would be a nightmare having more than 5 drivers on track.

Text-to-speech announces personal/track records and leader change, and announces race standings periodically and at the end of a race.

Basically, the program reads a line from the serial port whenever something gets sent from the decoder. It could be a 3-digit HEX string matching one of the transponders in which case it does its lap counting thing, or some garbage string which can happen if a car is driving too fast (seriously!) or the transponder just isn't shining at the right angle in which case too bad, your hot lap won't be counted.

I think that's it for (buggy) features.

Video of initial test:

Sorry, the detection typically isn't as bad as it is in the video, it's just that holding the detector and car freehand can lead to poor angles for detection. When testing off-camera, cars can actually be quite close but I think there still need to be at least 50 milliseconds between them in order for the detector to pick up both.

2013.05.02, 12:42 PM
looks and sounds cool, unfortunately, all well over my head :p there are several members here that i'm sure understand the details.

2013.05.04, 01:46 AM
Heh, I wasn't quite sure if I wanted to write it more as a construction log or as a demo of a finished thing, but it is very much a DIY in-progress so I went with the former with some more technical details.

That said though, aside from the detector units, there is actually very little construction involved, and very little coding too if you just want to use the system, although of course some prior experience is needed. Most of the physical work was just making those enclosures which are not really necessary but I just did it since I ought to try making my project look nice and clean to you guys :p The detectors should be covered and have a window, but you can just do that with cardboard from a cracker box or something.

The vast majority of the programming work was on the PC software, which I have done so you don't have to ;)

Unfortunately I can't help with the construction, but I do hope someone is interested to try building this, even if it's just so I can validate my existence... :o Arduino is fun...

I'm currently dragging my feet in building an overhead bridge, but once I do I'll ask my friend to come help me test it with two actual cars on track.

2013.05.04, 01:57 AM
It's interesting as My son is getting into arduino for his university course,
He's going to try & go with rfid shields (he still at the reading up stage I'll post details {if/when} he has any progress, this may take some time.

2013.05.29, 12:02 AM
A little update, after not having worked on this project for a while.

I made some changes to the decoder - moved the receiver to a different pin and added serial communication over Bluetooth, so now the system can run wirelessly with a BT-enabled PC as long as the timing system has its own power supply. Not bad for $8.20. I used some 3M Dual Lock strips to stick 2x18650 Li-Ion batteries to the outside of the decoder, and it stands up rather stably now. I added a connector for balance charging the batteries without having to remove them from the holder.

Minor software change to the decoder - now it only sends data when a valid SIRC code is detected, so the serial port doesn't get flooded with invalid codes. Minor bugfix to PC software where drivers entering qualifiers partway through would appear in 1st place due to 0-second best lap :o

http://imageshack.us/a/img838/4993/decoder04btinside.th.jpg (http://imageshack.us/a/img838/4993/decoder04btinside.jpg)

Some members of my club have been talking about systems with sector split times. I haven't started working on this but I can probably add this functionality without too much trouble. The decoder software may need a small change to send one additional 'sector' field in each transmission, which can be anything at this point. Each sector's decoder can connect to different serial ports on a kind of relay unit, which sends the info to PC with a more meaningful sector field depending on which serial port the info came from.

The PC software would need to be modified to read the additional sector field and also include settings for one or more sectors. This way I think I would be able to connect a single decoder to PC without the relay unit as it is done now and just ignore the garbage sector field, and also connect multiple decoders to a relay unit without having to do any reprogramming when switching between configurations.

I don't know if I will have much time to work on it over the next while, but the idea is there at least.

2013.06.01, 12:57 PM
A little video running a single car.


It drops quite a few laps :(
Maybe it will be better if I angle the detectors slightly. The transponder tends to stick on with a bit of a forward angle. Things might be better if I can get a flat SMD emitter instead of a plain 3mm emitter also.

Today will be the first big test at a local hobby shop. Stay tuned for an update!

-Rather than continue working on my PC software, I wonder if it might be better to make my system compliant with Flipside on the Robitronic protocol documented here (http://www.flipsideracing.org/projects/fslapcounter/wiki/RobitronicSerial). Can anybody enlighten me how the checksum is generated?

edit: Not enough people showed up today at LHS so I could not get any good footage of multi-car racing. Dropped laps are a big problem. I may initially try widening the windows on the detector unit to get the system working more reliably for fast cars.

2013.06.01, 10:56 PM
What IR detector are you using for the bridge? It seems like you are using a very low height on your bridge and unless you are using a very wide field of view lens then you are not covering the whole area of the track. Basically, the beam angle and the reception angle really play a big factor in the detection.

Second, A 3 character hex code in sony format seems like it's going to be quite a long time to transmit. The pulse train is probably longer than it takes for a car to drive under the dectector. How many uS is the complete message?

2013.06.01, 11:31 PM
Thank you for the comments. It is very likely a combination of all those factors. Evidence seems supportive, since my own car today with a 70T motor was detected more reliably than my friend's car with a faster motor.

No fancy optics on the detector - just a bare receiver in a box with a rectangular hole cut out - which I may end up enlarging.

A single message takes a maximum of 24ms to transmit. Add this to the killer of I think another (necessary) 23-35 ms gap in between transmissions, a fast car (let's say 10m/s) with the bad luck of entering the timing window partway through a message will leave the timing window before another message begins to send. So it's already orders of magnitude slower than microsecond messaging. This is a limitation of the SIRC protocol which isn't meant to be used in such a way. Perhaps I could make modifications to both the transmission and detection to shorten the necessary pulse durations - this actually hadn't occurred to me until now.

Otherwise it looks like I can start just by raising the height of the bridge? Possibly add one more detector unit to reduce the lateral reception angle. Might be good to give those a try. Even reducing the burst length by a factor of 2 or 4 might be worth a shot. Thanks for the ideas!

2013.06.06, 08:09 PM
Some more small updates.

I reduced the mark and space durations of the SIRC protocol by a factor of 2, and made a more exact calculation of the repetition delay on a per-ID basis. Now a complete message will take on average 10.5ms to transmit, and messages are repeated every 22.5ms start-to-start. During initial tests holding the car in my hand, the timer seems much more responsive. I will give this the same small "L" track test later, but I hope it should count all laps for a slow car and most if not all laps for a faster car as well. I tried reduction factors of 3 and 4, but the decoding became unreliable, even worse than unmodified SIRC.

I got some pipe couplers and raised the height of the bridge by around 7 inches, but I will see how the faster IR transmission does without the added height. The bridge which my local club uses with Trackmate is also quite low, about the same as mine initially.

I finally got some working IR code for ATtiny85 on its internal 8MHz oscillator. I threw together a quick prototype on perfboard, but it seems like transmission is much slower, or perhaps much sloppier so it takes more time/tries to send a clean message that the decoder can recognize. I probably will not pursue this any further and just keep using Pro Mini boards for the transponders. The size is not ideal but they are cheap and easy to build, and easily reprogrammable, which the Tiny board is not.

Size comparison: ATtiny85, Trackmate, Arduino Pro Mini
http://imageshack.us/a/img844/3213/transponder03comparison.th.jpg (http://imageshack.us/a/img844/3213/transponder03comparison.jpg)

edit: No new video, but I did a quick track test with the new faster program. It works better with the increased height, so I may make some new vertical posts that don't use the heavy metal couplers.

It works pretty well with a 70T car, but still fails miserably with a 50T car and even an 8ft straightaway is enough to see the system fail.

I believe it should be working well enough for stock-class driving, but for me to support it for anything faster is approaching the realm of sunken costs that I should just purchase a commercial system. For now I will probably not be making any new developments in that direction unless I can come up with some radically different protocol.