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 APB6 C7042) and 4 car (PB4).

PB6 v1.2 - 2004	PB6 v1.5 - 2006	PB4, rev B - 2008	PB4 v6 - 2009	APB6 - 2010
PB6, 6 car, C7030 v1.2	PB6, 6 car, C7030 v1.5	PB4, 4 car, rev B	PB4, 4 car, v6.0	APB6, 6 car, C7042
PB6, C7030 v1.2, internal	PB6, C7030 v1.5, internal	PB4, rev B, internal	PB4, v6.0, internal	APB6, 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.


Its noted that the APB6 One Bit duration is approaching the upper limit of the standard InCar chip, and is nearly 10% longer than the original PB6 duration. The reason is not clear for the large change.

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 optimum value is based upon the best midpoint between minimum and maximum.

^{* 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. If more or less than 8 bytes are sent, the chip will automatically switch into Analog track mode - where motor speed is defined by variable voltage or switched (PWM) track power.

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
speed 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. Only the lower 2 bits are used - all upper 6 bits in the packet command byte are ignored.

Standard Scalextric commands byte usual value Command xxxxxx00 $00 Idle packet – all car values will contain a car ID - does nothing xxxxxx01 $01 Program packet – set the ID of car(s) on the track xxxxxx10 $02 Speed packet – individual car throttle values xxxxxx11 $03 Reset packet – all car values will contain a car ID, car chip will reset and reboot

InCar-Pro additions byte exact value Command 11111100 $FC Auxillary packet - sets the car control lines, like HL, SP etc (from v4) 11110111 $F7 Old Auxillary packet - sets the car control lines, like HL, SP etc (Deprecated) 00010011 $13 Curve data – 6 bytes of data to be written as throttle curve data 00010100 $14 Program Curve – location block to actually burn the previously sent Curve data

Car Speed Data

The car throttle values are broken down into the following format, sent under the Speed Packet command $02

Scalextric speed packet size Action MSbit 1 bit 'true' when Brakes on 1 bit 'true' when Lane Change selected 6 bits Speed: $3F maximum, $00 power off

InCar-Pro speed packet when braking size Action MSbit 1 bit 'true' ie brakes on 1 bit 'true' when Lane Change selected 6 bits Braking level: $00 maximum (fully on brakes), $3f minimum brakes

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

PBs before the APB6

1. Send one or more Speed packet(s) with all cars set to stopped with brakes on
2. Send an Idle packet with all car slots set to the desired new car ID
3. Send one or more Program packet with all car slots set to the desired new car ID
4. Send one or more Reset packet(s) (to allow time for the value to be burned into the chip)

Older PBs Car ID programming is complete.

APB6

1. Send four or more Program packets with all car slots set to the desired new car ID

APB6 Car ID programming is complete.

Edit

PB6 Repair

The earlier PB6 units suffered from insufficient drive power. The upgrade details in the Powerbase Repair page discusses a repair option by replacing the master drive transistors with much higher capacity devices.

This upgrade is for those comfortable with electronics, and working on electronic equipment. See Powerbase Repair page.

Edit

PB4 Schematic

The circuit diagram for the 4 Car Powerbase (rev b) is detailed below. Note that the circuit will have copyright owned by Scalextric / Hornby, and I have drawn it up only to provide information to allow people to repair the PB4. Some component values are not known at this time, should anyone be able to expand on them, please advise.

PB4 Schematic v1.1 (click to download)

NB: Schematic v1.1 contains a correction to the power LED