Scalextric Digital Control

Edit

Overview

The powerbase provides both power and digital commands to the cars via the track. The power sent to the track is not like the older analogue systems, in that it is no longer DC (‘direct current’) but now a type of AC (‘alternating current’). What happens with SSD digital is that the AC signal on the track actually carries the digital commands from the throttle to the car.

Edit

Track Signal

The signal sent to the track is balanced and in anti-phase – in other words, when one rail is at 0v, the other is at about 12v – and vice versa. By switching the rails, the digital command can be sent to the car, while power can be constantly supplied for the motor. The chip within the car decodes the signal and (using a simple bridge rectifier) provides power to the motor.

Edit

Common Powerbases

A range of powerbases have been manufactured over the years. There are 2 prime types, 6 car (PB6 C7030 and C7042) and 4 car (PB4).

PB6, 6 car, C7030 v1.2	PB6, 6 car, C7030 v1.5	PB4, 4 car, rev B	PB4, 4 car, v6.0	PB6, 6 car, C7042
PB6, C7030 v1.2, internal	PB6, C7030 v1.5, internal	PB4, rev B, internal	PB4, v6.0, internal	PB6, 6 car, C7042, internal

Edit

Data Format

If we attach an oscilloscope and look at just half of the signal on the track we will see that it’s sending a signal which is very similar to that used within the model train industry – Digital Command Control, ‘DCC’. For details, see NMRA site

Bit Format

This signal uses a bit time to distinguish between a one bit, which is short, (some 116-120 μS) and a zero bit that is longer than this, normally twice that length (nominal cycle time of 232-240 μS). The DCC protocol refers to ‘bit stretching’, and there is some evidence that the SSD car chips can cope with this, even if the SSD powerbases do not appear to perform this. Testing has shown that the zero bit state duration can extend considerably, and the cars will cope accordingly (albeit with a significant reduction in responsiveness, due to the much longer packet time and the consequential reduction in packets being sent).

Edit

Bit Times

The various powerbases (4 way / 6 way) produce slightly differing bit lengths for the zero and one bits. Whether this is by accident or design is unknown. Without a specification, its difficult to know the required accuracy and the permitted drift. However, the DCC standard defines a one bit as being a total cycle of 116μS, ±6μS

The zero-bit duration can also present somewhat variably on the PB4 rev B, possibly due to the lower quality drive circuitry, and extra RF suppression.


Edit

Car Chip

Scalextric have produced a selection of in-car chips, from the solder-in type to the Digital Plug Ready 'DPR' types.

While the obvious physical formats have changed, what has also changed is the code within the micro-controller on the board. This can be shown by the different responses of the chip to signals which are at the limit of the acceptable signal. In some chips, the motors stop; with others the motor performs at maximum speed; and others will continue at the last 'presumed' speed.

The following table shows the maximum bit-time limits which still show appropriate response to incoming packets (ie the maximum tolerance)

^{* The exact time was far longer than this, but exceeded the limits of both the generating and measurement test rigs.}

Edit

Packet Encoding

The packet structure follows the basic DCC protocol – that is lead-in, data bytes, terminator.

There are always exactly 8 data bytes (inc the checksum) in each packet. Each packet byte is separated with a zero bit. The last byte can be followed directly by the packet lead-in of the next packet, or can be padded with multiple one bits as required.

Bits	Function
10 or more	always '1' for packet lead-in
1 bit	always '0' (data separator)
8 bits	8 bits for packet command
1 bit	always '0' (data separator)
8 bits	8 bits for car 1 data
1 bit	always '0' (data separator)
8 bits	8 bits for car 2 data
1 bit	always '0' (data separator)
8 bits	8 bits for car 3 data
1 bit	always '0' (data separator)
8 bits	8 bits for car 4 data
1 bit	always '0' (data separator)
8 bits	8 bits for car 5 data
1 bit	always '0' (data separator)
8 bits	8 bits for car 6 data
1 bit	always '0' (data separator)
8 bits	8 bits for packet checksum
1 bit	always '1' (end of data)
0 or more bits	always '1' - interpacket fill

The packet end mark can be immediately followed by the packet lead-in of the packet following.

Data bytes are always sent with Most Significant Bit (MSB) first (directly after the '0' marker bit) through to the Least Significant Bit (LSB) which is sent last.

Packet Layout - click to enlarge

A packet will have a minimum (nominal) duration of 10.7 mS, while the longest duration will be 18.1 mS. This provides a packet refresh time of between 93 (of mostly 1 bits) and 55 (of mostly zero bits) packets per second. (Note that a minimum packet time, made up of all 1-bits, is fundamentally useless in real life, as this packet equates to all cars stopped with their brakes and lane-change on - so not much is going to be happening.)

Why is the number of packets per second important?

Get the greatest number of packets to the car as possible ensures the most responsive actions of the cars. When approaching a corner, for instance, you want to leave braking to the last possible moment. If the packet which contains the start of the braking is delayed, even by the smallest margin, then you will hit the corner faster then expected. Responsiveness is therefore key.

On average, a car command can be considered to contain 4 1-bits and 4 0-bits in it. This might be a packet where the car is travelling at about 2/3rds speed without any lane changing (or about 1/2 speed with lane-change). If 6 cars are doing this, then the system will be sending out about 65 packets per second.

You also need to consider how far a car travels in any period of time... a recent James May TV programme clocked the cars at 11 miles per hour at full speed. This equates to about 5 metres travelled per second. And with 65 average packets being sent in that second, then your car could have travelled about 7.5cm - some 3 inches. So if your braking command arrives just one packet too late, then it can make the difference between a record lap and an 'off'. So, we need as many packets per second as possible.



Edit

Packet Checksum

The checksum is created as a bitwise Exclusive-Or of all prior 7 data bytes in the packet, with an initial value of $FF.

eg

slot	data byte	running checksum value
(initial value)		$FF
speeed command	$02	$FD
car 1 (max speed)	$3F	$C2
car 2 (lane change & mod speed)	$53	$91
car 3 (braking)	$80	$11
car 4 (stopped)	$00	$11
car 5 (fast)	$21	$30
car 6 (lane change & slow)	$4F	$7F
checksum sent	$7f

Edit

Packet Data

Packet Command

The packet command byte will be one of the following values

0	Reset packet – all car values will be set to a car ID
1	Program packet – set the ID of car(s) on the track
2	Speed packet – individual car throttle values

Car Data

The car throttle values are broken down into the following format

MSbit	1 bit	Brakes on
	1 bit	Lane Change selected
	6 bits	Speed: $3F maximum, $00 power off

Edit

Data Packet States

The powerbase sits in one of two states -

• Race control, the usual state;
• Programming, to set the car IDs.

Edit

Racing State

The powerbase is normally sending out Speed packets. The base reads the values of each speed controller, converts the throttle, brake and lane-change buttons into suitable codes and bundles it into a type 2 - Speed Packet.

When a throttle is unplugged, or a 4-way powerbase is being used, the empty slots are filled with zero bytes (this is not the optimum value - a value of $FF [all 'one' bits] is better, as it takes less time to transmit, allowing more packets per second.)

Edit

Programming State

When a car is being programmed - by holding down the relevant button on the 4-car powerbase, or by selecting the option on the 6-car powerbase - the system sends out a specific reprogramming sequence. This 3 packet sequence commands the car(s) to set their internal ID to the value sent.

The car IDs are always 1 based - therefore giving valid ID values of 1…6

1. Send one or more Speed packet(s) with all cars set to stopped with brakes on
2. Send a Reset packet with all car slots set to the desired new car ID
3. Send a Program packet with all car slots set to the desired new car ID
4. Send one or more Reset packet(s) with all car slots set to the desired new car ID

Car ID programming is complete.