Scalextric digital lap counter/timer

[iambenb]

Hello

Having been lucky enough to get a rPi for my birthday, I'm thinking of a few projects to do with it.

My son got a Scalextric Digital set, which is pretty cool, so I was thinking of setting up a lap counter/timer system.

I've already seen the project that uses reed switches under the track, which would work fine for an analogue setup, as a single car will only be on a single track, but with digital you can have up to 4 cars running (up to 6 with an upgraded powerbase), and they can cross the line on either track (and if I expand the circuit in the future I may increase the lanes to 3 or 4)

So it needs to detect the specific car rather than just detecting that a car has passed.

Seems to me the detecting part is the hardest, and actually plugging that signal into the rPi to handle the race management is fairly trivial in comparison.

I'm thinking one of the following:

1. cannibalise the lap counter that exists, and try and grab the output from it.
2. mount some kind of transmitter into each car and set up a receiver of some sort
3. IR paint with a unique image on the roof of each car and a camera sitting above the track to read it

The first seems like it should be the easiest, but I have no idea what is inside that unit and what outputs will be available to me.

Any ideas?

[jamesh]

Do you know how the current system detects which car goes past? You might be able to add a sensor for that specific method. (I'd guess an RFID tag of some sort)

[iambenb]

Do you know how the current system detects which car goes past? You might be able to add a sensor for that specific method. (I'd guess an RFID tag of some sort)

No idea. I'll try and find out. I don't think it's RFID, as the chip that you need to buy to make a car digital compatible is the same, and you register the car to the controller by holding a numbered button whilst placing the car on the track. I'm not really clear how the controller gets the signal to the car - there doesn't seem to be a separate signal circuit, so it must piggyback on the power somehow.

The description for the upgraded 6 car powerbase states that it has an open source output which you can connect to a PC.
It's not cheap, but would need that anyway if I was planning to upgrade the existing 4 car powerbase to 6 anyway, so might be worth doing it that way.

[iambenb]

Just found this, from http://www.electricimages.co.nz/Default ... ic_Digital

the Scalextric protocol leverages a square-wave 12v p-p high current signal driven onto the track. The signal is balanced, such that each 'side' of the lane is driven in opposite voltage, allowing the car to rectify this waveform and recover (with some small losses) a DC voltage for the motor.

Inside the car is mounted a small decoder which recovers the control signal, interprets it, and drives the power back to the motor. Motor speed and braking is controlled via the decoder - unlike analog where the speed is directly controlled within the hand controller.

That doesn't really clear up how the existing lap counter detects a car though.

[PiGraham]

It seems people have worked out how to interface to SXC Digital.

http://www.virklund.dk/scx/

http://www.fi.muni.cz/~kas/scxreader/

I don't know how they work to count laps, but you may find what you need in there.

[iambenb]

It seems people have worked out how to interface to SXC Digital.

http://www.virklund.dk/scx/

http://www.fi.muni.cz/~kas/scxreader/

I don't know how they work to count laps, but you may find what you need in there.

Thanks, that's really interesting.
However, SCX is not the same as Scalextric. I will do some digging and see if the protocols are the same, but I doubt it.

Right now I'm leaning towards getting the 6 car powerbase and using the existing output from that. Even if the majority of the time we will only be running 2-4 cars, having the ability for 6 plus the output already available seems to be worth the outlay.

[iambenb]

http://www.electricimages.co.nz/Scalext ... hx#tab2563

Beneath the car is mounted a small Infra-Red LED which constantly pulses the car's ID downwards onto the track. Detectors mounted under the slot pick up the signal, and can decode which car is passing over them. The same signal carries detail on whether a car should change lanes or not, and when detected by a special lane-change track-piece, a physical 'flipper' will cause the car to move from one lane to another.

The car detection is also used for lap counting, as simple car-pass detection methods from analogue racing cannot be used as more than one car can be driving in the same lane.

Full details on the decoding of a car's ID are provided on the Scalextric Car Decoding page. This includes circuit diagrams and PIC12 programming code to decode and deliver the car ID.

For those who wish to review the detector circuit, and the micro-controller code, move straight to SSD Decoder page.

That makes sense, as just before the lane changer there is an IR detector.

So now, just for the geek of it, I really want to mount a couple of IR detectors under the track, and see if I can use that output somehow.

[iambenb]

So this looks interesting.
http://www.electricimages.co.nz/SSD_Decoder.ashx

Has a circuit diagram for a detector.
Guess I would also need a programmer to get the program onto the IC. Maplin probably sell one.

[jamesh]

That's quite interesting.

You could do this all on the Pi I think - you should be able to monitor a GPIO at 2.2Khz (or 4.4 really for Nyquist). Not sure how IR detectors are normally plugged in but cannot be too horrendous.

[Ravenous]

Try slotforum.com - one of the forums there is for Scalextric:
http://www.slotforum.com/forums/index.php?showforum=63

I haven't looked at this in detail, but race timers must be working from the ID the cars emit (by the LED on the underside).

(The lane changers do some sort of detection too, but I'm not sure if they need to identify the car - just the fact that it wants to change lane. Just saying these may work differently to timers.)

[iambenb]

That's quite interesting.

You could do this all on the Pi I think - you should be able to monitor a GPIO at 2.2Khz (or 4.4 really for Nyquist). Not sure how IR detectors are normally plugged in but cannot be too horrendous.

That woud be good.
I think the IC does some error checking and disregards noise from ambient light, so I'd have to deal with that in program somehow.

So, I could wire the output from the IR receiver diode to one of the IO pins on the pi and see what it reads.

[jamesh]

That's quite interesting.

You could do this all on the Pi I think - you should be able to monitor a GPIO at 2.2Khz (or 4.4 really for Nyquist). Not sure how IR detectors are normally plugged in but cannot be too horrendous.

That woud be good.
I think the IC does some error checking and disregards noise from ambient light, so I'd have to deal with that in program somehow.

So, I could wire the output from the IR receiver diode to one of the IO pins on the pi and see what it reads.

Probably. I don;t know how IR receivers work, whether they are analogue or digital or can be either.

[PiGraham]

That's quite interesting.

You could do this all on the Pi I think - you should be able to monitor a GPIO at 2.2Khz (or 4.4 really for Nyquist). Not sure how IR detectors are normally plugged in but cannot be too horrendous.

This is new to me (Scalextric digital) , but I suspect that the bit rate is a higher than that.

The car id and lane change status is sent over 2,200 times per second.

That would be a multi-bit packet of car ID and lane change 2,300 times per second.

The car generates its signal with a nominal bit time of 48µs, where a 1 state is LED on.
http://www.electricimages.co.nz/SSD_Dec ... hx#tab1347

That's 8 bits at about 20kBaud

[iambenb]

Not really sure what that means - does that mean I can't plug the output from the IR receiver directly into the IO pin on the pi?

[PiGraham]

Not really sure what that means - does that mean I can't plug the output from the IR receiver directly into the IO pin on the pi?

Using user code on Linux the timing cannot be guaranteed. There is a risk of missing a read, which would be a very bad thing for a lap counter.

The safest option is probably to use a cheap Arduino to read the IR code with no Linux issues to worry about. Talk to that from a Pi, if you want a fancy GUI or network functions. You could drive a simple display from the Arduino (you can also do some networking).

The SSD card pages give info on circuits and code (PIC, Assembler not Arduino / C / Wiring, but you might make some sense of it. Or maybe find a PIC 12F629 based board and use the code as-is.



It might be possible to use the UART or SPI interfaces to reliably read the data. Forum user joan might be able to advise on that.
Both interfaces have been used for output of timing-critical data to drive smartpixels.

[iambenb]

If I can get a cheap CMOS programmer, I might just make that circuit as is on a breadboard - looks fairly straightforward - and put their code on it, then feed the output to my pi.

[jamesh]

According to a doc I read linked above, the clock rate of the IR LED in the car is 2.2Khz, which I think is doable on the Pi GPIO. It only needs 6 cycles to transmit all it needs, which is quite quick (car ID and lane change request()

[PiGraham]

According to a doc I read linked above, the clock rate of the IR LED in the car is 2.2Khz, which I think is doable on the Pi GPIO.

As I pointed out earlier, the doc describes the packet rate as 2.2kHz. The bit rate must be higher, and 48us per bit is mentioned.

It's still within the capabilities of Pi/Rasbian to sample that data, but can capture be guaranteed. The data is not present for long and if it is missed the lap count is wrong. Linux latency is an issue for userland. A proper high priority kernel mode ISR could do it.

A useful calculation would be the minimum number of packets that would be received from a car at max speed, over what time?
If that exceeds worst case latency than it's reasonable.

Does anyone know what worst case latency is for Pi/Raspbian?
Maybe a realtime add-on could cope. 20kHz is not a problem.

[jamesh]

According to a doc I read linked above, the clock rate of the IR LED in the car is 2.2Khz, which I think is doable on the Pi GPIO.

As I pointed out earlier, the doc describes the packet rate as 2.2kHz. The bit rate must be higher, and 48us per bit is mentioned.

Ah, OK, missed that bit. Might be a bit tight then.

[ame]

Are the cars different colours?

[aTao]

http://www.electricimages.co.nz/SSD_Dec ... hx#tab1347

This is the page you need to read for decoding the car's signal.

Looks like:
Bit time = 48uS
Car transmits only 1 48uS pulse.
+ve pulse = no lane change -ve pulse = lane change.
car ID determines frequency (and since there is a fixed mark duration then PWM ratio too)

Excuse me that I think in discrete logic terms....
+ve edge starts timer, after 72 uS lane change = signal
+ve edge latches and resets counter on 48uS clock. car ID = latched count -3.

bear trap = car requesting lane change appears over sensor during gap after pulse (happens to be longest part of signal) best dump first reading.

[PiGraham]

It seems /32 scale Scalextric cars may run at 14mph or so. 6,25 m/s. (World record is 30.94 MPH).
Assuming the IR LED/receiver connects over 20mm (just a guess) then it is in contact for 312ms @ 6.25m/s.
At 2,200 packets per second transmitted that is one packet per 454ms so at high speeds watch out. On these assumptions you might miss a car ID. (These are only assumptions)

The standard lap counter seems to have two sensor positions, which may help, especially if partial packets can be combined.

So that may give two chances.

The car ID system, and therefore the lap counter, must have a speed limit.

[iambenb]

I'd probably set it up so that the start line was directly after a corner, so the cars would not be going at full speed.

I think I'll take a stab at the circuit in the linked article. Total cost will be quite low, depending on how much a programmer for the IC is.

I'll report back!

[rurwin]

eBay is a good source for very cheap programmers, like £5 cheap. However you do need to know what you are doing with hardware and software since they need a bit of fiddling. You should be able to get an Atmel clone compatible programmer for not much more.

[P_Monty]

PiGraham, at 2200 packets per second, isn't that one per 450 microseconds, not milliseconds? If so (and as I'm currently full of snot due to a rotten cold my brain may not be working properly) then quite a few packets could be received...