[Dr_C2]

For anyone interested…

The precision speed measurement and display is being readout using 4inch LED 7 segment displays I showed elsewhere on slotracer.online.

The high speed cars are based on brushed motors (e.g up to King Evo 50) and a two part decoder which places high power MOSFET control directly at the motor. Again, shown elsewhere on slotracer.online.

Alternatively the high speed cars may be based on SENSORED brushless motors if that workstream proves successful in the coming weeks.

Thanks for reading.

c

[Dr_C2]

I’m going to call the configuration of digital slot car racing described in this thread ‘System-D’. The ‘D’ stands for development as the system is more of a development platform rather than being aimed as a commercial product.

Key features of this system:

1/ IR signalling for lap counting and lane changing using the Mark/Space timing method with signal inversion for lane change. This is designed for up to 36 cars.
2/ Enhanced track sensors for reading the IR signals which use 4 phototransistors in a row for increased performance on high speed tracks.
3/ Wireless communications from throttles to a central wireless hub which onward broadcasts the throttle data to the cars in a single multi-car packet refreshed every 10ms.
4/ Fast USB over-ride of packet data for advanced simulations and smart pacer cars.

Thanks for reading this overview post about the digital slot car racing configuration I am calling ‘System-D’.

c

[merkit the grof]

I’m going to call the configuration of digital slot car racing described in this thread ‘System-D’. 

I think "System D" is totally appropriate for this project.
But hasn't the whole thing been rendered obsolete by the new Carrera Hydrid system which allows for up the 30 drivers on track and anywhere lane change/overtaking?

Joel

[Dr_C2]

I’m going to call the configuration of digital slot car racing described in this thread ‘System-D’. 

I think "System D" is totally appropriate for this project.
But hasn't the whole thing been rendered obsolete by the new Carrera Hydrid system which allows for up the 30 drivers on track and anywhere lane change/overtaking?

Joel

Hi Joel, what a great question!

Perhaps the answer is that the current Carrera offering is more of a toy with some great characteristics but also a few limitations compared with digital slot cars - the latter including:

- relatively low car speeds.
- cars are battery powered.
- lack of customisation/tuning options.

However, the idea of cars being guided by electronic sensors rather than physical slots is exciting, and as you say it offers lane changing anywhere.

So looking into my crystal ball… perhaps the future of digital slot cars will retain the ‘slot’ for electrical power pick-up but allow cars to transition between slots at any point, guided by sensors until they reach the adjacent lane’s slot where they next pick up electrical power? Just a thought.

If so, System-D would be a useful development platform to start to explore this.

Meanwhile I’ll wait to see if, and how, the enthusiast digital slot car community chooses to engage with the new Carrera Hybrid system. Also, let’s see whether ‘user demand’ drives commercial activity in the ‘technical solutions’ domain for hybrid systems.

As I say, great question :)

c

[Dr_C2]

So a little more clarification on System-D:

System-D uses two separate communications methods respectively for car control and lap counting.

Car control is via frequency hopping 2.4GHz communications with high bandwidth from throttle to wireless-hub to cars and lower bandwidth for the return path. The latter is for telemetry i.e. car status reports.

Lap counting is via a car to track-sensor InfraRed signalling method which is hardwired back to a sensor hub. This signalling uses the Mark/Space Timing method with signal inversion to indicate lane change requests. IDs 1-6 follow the Scalextric Sport Digital (SSD) Mark/Space Timings i.e. IDs 1-6 are FULLY compatible with SSD powerbase lap counting. IDs 7-36 are proprietary to System-D but broadly follow the SSD scheme - but with an interesting twist. This helps to overcome the limitations observed by third party developers in and around 2007-2010. Connoisseurs of debate are welcome to discuss whether this is an ‘extension’ of the SSD protocol or not. This of course depends on the ‘rules’ of the discussion so I am happy to leave this to others to debate (but not on this thread please).

IDs 1-14 correctly trigger standard SSD lane changers without any firmware/hardware changes.

All IDs 1-36 can be made to correctly trigger SSD lane changer hardware but this currently requires a microcontroller swap-out inside the lane changer electronics and upgraded firmware.

The sensor-hub designed for System-D has 8 sensor input channels. Typically 4 are used for Lap Counting (i.e. up to 4 lanes) and 4 are used for pit lanes (i.e. 2 pit lanes each with separate entry and exit sensors). The current sensor-hub firmware is compatible with PC LapCounter USB protocols.

Gentle reminder: this is a development platform not a product.

As a development platform it is hugely flexible for trying out new ideas - a developer’s sandpit!

c

[roguejackal]

I understand your statement 'development platform not a product',
but boy o boy this would sell like hotcakes at the right price I would think.

[Dr_C2]

I understand your statement 'development platform not a product',
but boy o boy this would sell like hotcakes at the right price I would think.

Thanks Roguejackal for the kind words which I appreciate.

My thinking is that I would need to find another 999 (or more) potential users with that same view and then I would have a truly viable business model.

Till then … it’s back to the sandpit ;)

c

[Dr_C2]

Technical background to the ID sensing method used in System-D

   

Here is a photo, as shared earlier, of the 8-channel Sensor Hub and a 2-lane start/finish high speed ID sensor board. In this case the sensor board is set to the lane pitch for Ninco track.

This is a 36 ID detection system.

The ID sensors use the 4-phototransistors-in-a-row technique to extend the ID read window. This is important for ID reading of high speed vehicles.

The Sensor Hub itself is programmed in C++ to read the 6 SSD IDs and the 36 proprietary IDs used in System-D. I’m also currently ‘refining’ the software to add full compatibility with the Slot.it variant of SSD IDs 1-6 as used in Oxigen wireless decoders. The Sensor Hub outputs to PC LapCounter via USB cable. 

In comparison to Hornby (SSD) ID detection algorithms, I wanted to extend the system response for higher speed cars. This is achieved with both hardware (as above) and more advanced firmware algorithms.

APB C7042 (firmware v0.85) requires 5 pulse reads for a successful ID detection.

APB C7042 (firmware v1.009) requires 3 pulse reads for a successful ID detection.

ARC PRO also requires 3 pulse reads for a successful ID detection.

Scalextric Lane Changers require 4 pulse reads for a successful lane changer instruction.

In comparison the Sensor Hub only requires  2 pulses for vehicles travelling at high speed. Both of course must match. For vehicles travelling at lower speeds the algorithm selects 3 adjacent pulses at the mid-point of the pulse stream. This method is designed to maximise reliability of ID reads across all anticipated vehicle speeds from very fast to extremely slow.

And, one additional point, the ID sensors use ‘black encapsulated’ phototransistors. The black material is designed to ‘filter’ visible light thereby improving ID read reliability where the ambient room lighting is either:

- strong sunlight 
- fluorescent lighting 
- or LED lighting

As a result, these sensors (even without the Sensor Hub) provide a speed upgrade and better tolerance of interference from ambient lighting. The sensors have been in use as simple upgrades to:

- APB C7042 ID sensors (Lap counting)
- ARC PRO ID sensors (Lap counting)
- SSD Lane changer electronics
- Slot.it Lane changer electronics
- and Carrera Lane changer electronics

Note: In the case of Carrera it is to increase speed response only as Carrera already use a visible light filter in their sensor design.

I should also add one final point to this post. And for the avoidance of doubt, adding the above sensors to the APB C7042 or the ARC PRO will not increase the number of cars that can be detected. Both use Hornby SSD firmware for ID detection and this firmware has been set to a maximum of six. For 99.99% of users worldwide six is plenty.

Thanks for reading!

c