[Dr_C2]

While this looks like an ordinary Scalextric Lane Changer, it does have a few differences. I replaced the factory fitted PIC 16F with an ATtiny3224 in a SOIC14 package - which is generally pin compatible so not to hard. I then wrote some C++ code to implement normal XLC functionality. The result is that it works correctly.

The reason for doing this is to create a starting point for adding extra functions such as collision avoidance, pacers barred from pits, configurability of flipper direction when LC pressed and, maybe, some sector timings. Non of this is particularly novel but its fun to implement non-the-less.

c

   

[Dr_C2]

I recognise that so far I have only shared some photos of Hornby/Scalextric lane changers with a bit of red paint added.

So two bits of further background:

1/ one of the red stripes shows where the ‘standard’ Hornby/Scalextric sensors are located. The secondary or ‘earlier’ red stripe shows a pre-decision sensor location. This is all about collision avoidance - which done properly (IMO) needs two sensors per lane i.e. the ‘pre-decision’ sensor followed by the normal ‘decision-point’ sensor. Next I will show some photos of the standard Hornby XLC pcb with the upgraded ATting3224 in situ plus the extra wiring for the two lanes of ‘pre-decision’ sensors. 

So that’s a Hornby/Scalextric XLC (dual straight lane changer) which is controlled by a total of four sensors.

2/ the C++ code that I mentioned I have written includes capability to read in parallel the ID and lane change button status for cars traversing up to a total of eight sensors - let’s think of this code as an eight channel ID sensor ‘detector engine’. And parallel processing means that the system can handle all eight sensors being triggered at precisely the same time just as effectively as when only one sensor is triggered. With careful programming all of this is achieved in an eight bit microcontroller running at 16MHz i.e. nothing fancy.

So what does all of this mean in plain English?

First, effective collision avoidance is within reach for Hornby/Scalextric XLCs - in this case using a simple solder-in replacement microcontroller and some extra sensors.

Second, the ID detection ‘sensor engine’ can be applied to other applications for example start/finish line ID detection and pit-lane ID detection. Both of these further applications are in raceway trials at present - so absolutely definitely a subject to return to in due course :)

Now back to lane changers - and next up some photos of the hardware.

c

[JasonB]

I have so little understanding of this that it's difficult to know which questions to ask first. But it does sound interesting.

I guess the most important question is what's the end game, or where do you envisage it heading? I don't mean in terms of the electronics, but in terms of availability to other people. Basically I'm asking whether this is just a bit of personal experimentation for you, or whether you're aiming to make something more widely available?

It's fine either way, just asking.

[Dr_C2]

Thanks Jason.

I think there are three options.

First, I hope my experimentation encourages others to ‘have a go’ at extending the performance of their digital slot systems perhaps positively influenced by my trials.

Second, where forum users have expressed interest in the digital hardware/software I am developing I have often sent prototype hardware - example destinations include the USA, Australia and Scandinavia. So where readers are interested in trialing new hardware/software I often send kit free of charge in exchange for user feedback. I am likely to do the same with the above hardware for collision avoidance - but perhaps only to folk who can solder an SOIC14 chip onto a PCB.

Third of course is a commercial business model. This is in scope but so far not fully developed. Once there is evidence of demand at scale for a range of products it will make sense. So yes hopefully in due course a distribution model will exist that meets users requirements. 

Meanwhile, for now it’s sand-pit fun.

Clive

[Flux Capacitor]

I'm always keen to try new stuff, so if anything needs testing.........

[Dr_C2]

I'm always keen to try new stuff, so if anything needs testing.........

Hi Flux, would you be happy to try a couple of the ATtiny3224 microcontrollers coded up with my new lane changer firmware? As mentioned they in a SOIC14 package so straight forward to solder by hand.

Initially they would be without the ‘pre-decision’ sensors i.e. no collision avoidance. That could follow later on if you would like to give that a try too?

c

[Flux Capacitor]

Sure.

[Dr_C2]

   

Here is an ATtiny3224 fitted to a standard Scalextric lane changer PCB. This board has been under test at rug/carpet level hence the specs of dust. It’s functioning precisely as it should.

The ATtiny has a factory calibrated internal oscillator so the silver component in the foreground (known technically as a ceramic resonator) is no longer required. This frees up I/O pins 2 and 3 (and adjacent landing pads) for two additional sensors. As mentioned earlier these extra sensors are useful when implementing collision avoidance. I refer to these additional sensors as ‘pre-decision’ sensors since they are used to read vehicle position at a point in time prior to decisions being taken on whether to permit driver lane change requests or not.

Next the additional sensors need to be wired-in and the collision avoidance algorithms added.

This is a nice little project which has the potential to help avoid unnecessary collisions on Scalextric digital setups - improving flow and reducing damage to cars.

I believe previous versions of third party anti-collision firmware have used a single sensor per lane and retained the original PIC 16F630 microcontroller. Both the extra sensors and the upgrade to the ATtiny should bring some performance benefits and, at the same time, simplify the coding process.

c

[Dr_C2]

As mentioned, this is an experimental approach to upgrading Scalextric lane changers. That said, nothing is particularly novel here just some obvious next steps :)


What follows in this post is intended only for  those who are interested in the microcontroller technology in play here. Sorry to everyone else!

The standard Scalextric lane changer uses a 16F630 microcontroller while my experimental upgrade uses the ATtiny3224 - a far newer product so far more capable.

16F630 Key specification
===============

Program Memory = 1kwords i.e. 1k x 14 bits
Static RAM = 64 bytes
Flash Memory = 128 bytes

ATtiny3224 specification
===============

Program Memory = 32kbytes i.e. 32k x 8 bits
Static RAM = 3k bytes
Flash Memory = 256 bytes

So a huge increase in space for program code (x18) and variable arrays etc (x48) and a x2 increase in non-volatile memory space. The question of interest here is what can be achieved with all this additional microcontroller capability?

The ATtiny also has an arithmetic logic unit with fast multiplier hardware - so far better for number crunching too.

Finally, for this post, a graphic showing the pin-out which overlays the Scalextric lane changer perfectly. Extra pins in use are for the two additional sensors mentioned earlier and the hardware serial port. This port is useful for configuration of the lane changer, speed/ID read-out and a ‘black-box’ diagnostic read-out which should be useful as the anticollision side of things is developed.

Thanks for your interest in reading all of above.

c

   

[Dr_C2]

iA scenario which I am curious to explore:

1/ A large competition raceway with an XLC lane changer at the mid-point on a long straight.
2/ A Scalextric F1 car with a top speed of 7.5m/s running on ID6 traversing the XLC at close to top speed.

So we know the driver is very likely to deslot if he/she attempts a lane change at this speed. But what if the lane changer was previously left in the lane change position.

Q1/ Can a standard lane changer read the IR signal at this speed? If not the flipper would not be commanded to move to the correct position.
Q2/ If the flipper is commanded to move to the stay straight position, will it move fast enough to be in the correct place to avoid an accidental deslot?

Of course all of the above can be avoided by placing lane changers only at slower points on the raceway. But what if our track designers want XLCs on faster sections of track?

Maybe this scenario has already been addressed… but I don't think I have seen trials at the kinds of speeds mentioned above using Scalextric hardware as the starting point.

c