Scalextric Digital Control

(((<table><tr><td>[image||{UP}eyes.gif]</td><td valign=center>If you just want to build your own powerbase, go to [SSD_MyPowerbase|Build a Digital Powerbase] page</td></tr></table>)))

{Tabs:Overview}
===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.

====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.

====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).

<table border=0><tr>
<td>[imageauto|PB6, 6 car, C7030 v1.2|{UP}SSD_Control%2fpb6_1-2-S.jpg|SSD_Control_pb6_1-2]</td><td>[imageauto|PB6, 6 car, C7030 v1.5|{UP}SSD_Control%2fpb6_1-5-S.jpg|SSD_Control_pb6_1-5]</td><td>[imageauto|PB4, 4 car, rev B|{UP}SSD_Control%2fpb4-revB-S.jpg|SSD_Control_PB4_revB]</td><td>[imageauto|PB4, 4 car, v6.0|{UP}SSD_Control%2fpb4-v6.0-S.jpg|SSD_Control_PB4_v6.0]</td><td>[imageauto|PB6, 6 car, C7042|{UP}SSD_Control%2fpb6-C7042-S.jpg|SSD_Control_PB6_C7042]</td>
</tr><tr>
<td>[imageauto|PB6, C7030 v1.2, internal|{UP}SSD_Control%2fpb6_1-2_int-S.jpg|SSD_Control_PB6_1-2_int]</td><td>[imageauto|PB6, C7030 v1.5, internal|{UP}SSD_Control%2fpb6_1-5_int-S.jpg|SSD_Control_PB6_1-5_int]</td><td>[imageauto|PB4, rev B, internal|{UP}SSD_Control%2fpb4-revB-int-S.jpg|SSD_Control_PB4_revB_int]</td><td>[imageauto|PB4, v6.0, internal|{UP}SSD_Control%2fpb4-v6.0-int-S.jpg|SSD_Control_PB4_v6.0_int]</td><td>[imageauto|PB6, 6 car, C7042, internal|{UP}SSD_Control%2fpb6-C7042-int-S.jpg|SSD_Control_PB6_C7042_int]</td>
</tr></table>

{AddTab:Data Format}
===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 [http://www.nmra.org/standards/DCC/standards_rps/DCCStds.html|NMRA site]

[imageauto|Bit Format|{UP}SSD_Control%2fBitFormat.jpg]

This signal uses a bit time to distinguish between a one bit, which is short, (some 116-120 &mu;S) and a zero bit that is longer than this, normally twice that length (nominal cycle time of 232-240 &mu;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).

====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&mu;S, &plusmn;6&mu;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.

::{| border="1" cellpadding='2'
! Powerbase !! One bit !! Zero bit !! interpacket bits
|-
| PB6 v1.2 || 118 &mu;S || 233 &mu;S || &nbsp;
|-
| PB6 v1.5 || 116 &mu;S || 232 &mu;S || 16
|-
| PB4 rev B || 121 &mu;S  || 240 &mu;S || 16
|-
| PB4 v6.0 || 123 &mu;S  || 245 &mu;S || 16
|}


====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)

::{| border=1 cellpadding=2
! Type !! Minimum !! Maximum
|-
| '''one''' bit || 95 &mu;S || 137 &mu;S
|-
| '''zero''' bit || 185 &mu;S || &gt;411 &mu;S<sup>*</sup>
|}
<sup>* The exact time was far longer than this, but exceeded the limits of both the generating and measurement test rigs.</sup>


{AddTab:Packet Format}
===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.

<table border="1" cellpadding=2><tr>
<th> Bits </th><th> Function </th>
</tr><tr  bgcolor=#D7FDCE>
<td> 10 or more </td><td> always '1' for '''packet lead-in''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''packet command''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''car 1 data''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''car 2 data''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''car 3 data''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''car 4 data''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''car 5 data''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''car 6 data''' </td>
</tr><tr bgcolor=#F9F9A1>
<td> 1 bit </td><td> ''always '0' (data separator)'' </td>
</tr><tr>
<td> 8 bits </td><td> 8 bits for '''packet checksum''' </td>
</tr><tr bgcolor=#F9AFA1>
<td> 1 bit </td><td> ''always '1' (end of data)'' </td>
</tr><tr bgcolor=#D7FDCE>
<td> '''0 or more''' bits </td><td> ''always '1' - interpacket fill'' </td>
</tr></table>

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.

[imageauto|Packet Layout - click to enlarge|{UP}SSD_Control%2fscalex-S.jpg|{UP}SSD_Control%2fscalex.jpg]

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.



====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

{| border="1" cellpadding=2
! slot !! data byte !! running checksum value
|-
| (initial value) || &nbsp; || $FF
|-
| speeed command || $02 || $FD
|-
| car 1 (max speed) || $3F || $C2
|-
| car 2 (lane change &amp; mod speed) || $53 || $91
|-
| car 3 (braking) || $80 || $11
|-
| car 4 (stopped) || $00 || $11
|-
| car 5 (fast) || $21 || $30
|-
| car 6 (lane change &amp; slow) || $4F || $7F
|-
| '''checksum sent''' || $7f || &nbsp;
|}

====Packet Data====

=====Packet Command=====
The packet command byte will be one of the following values
{| border="1" cellpadding=2
| 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
{| border="1" cellpadding=2
| MSbit || 1 bit || Brakes on
|-
|  || 1 bit || Lane Change selected
|-
|  || 6 bits || Speed: $3F maximum, $00 power off
|}


{AddTab:Data Packet States}
===Data Packet States===

The powerbase sits in one of two states - 
* Race control, the usual state;
* Programming, to set the car IDs.

====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 &#0091;all 'one' bits&#0093; is better, as it takes less time to transmit, allowing more packets per second.)

====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&hellip;6

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

Car ID programming is complete.


{/Tabs}
"The important thing is not to stop questioning; curiosity has its own reason for existing." - Albert Einstein
ElectricImages.co.nz

Scalextric Digital Control
