[Dr_C]

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