EditBackwards Compatibility
A core element of the upgrade is to remain backwards compatible with the standard Scalextric chips. By and large this has been achieved, but compatibility is only related to racing with the cars on the track.
On-Track programming of special features (like motor torque curve) into the car requires that only InCar-Pro chipped cars be on the track. While no harm will come of standard cars, unexpected results may occur should it happen.
In Summary, both the standard and InCar-Pro cars will work properly when raced against each other, and the additional features won't cause an issue.
EditHow it works
Ultimately, for InCar-Pro the data packets sent by the Powerbase to the track have been extended to enhance their functionality. For dynamic braking, unused data bits within the standard Speed packet are used, while for additional features, additional packet commands have been created.
This section assumes that you have read and understood the details about the On Track data protocol, as described in the
Scalextric Digital Control pages
EditChip Circuit Diagram
 Chip Circuit Diagram (click to download) |
EditVariable Dynamic Braking
Variable Dynamic braking is sent in the normal Speed packet, but reinterprets the throttle data bits when the Brake bit is set. This allows the braking level to be changed while driving, eg for every corner, and so give huge flexibility.
Normally a Speed packet (command $02) sends the following car data (using one byte for each of the 6 cars)
| size | Action |
|---|
| MSbit | 1 bit | Brakes on |
| 1 bit | Lane Change selected |
| 6 bits | Speed: $3F maximum, $00 power off |
This will utilise the values $00 thru $3F (0 thru 63), where $3F is maximum speed. However, when under braking only the $80 value is sent by the standard powerbases. This means that the throttle can be reinterpretted when the brakes are on.
So, InCar-Pro allows for:
| size | Speed |
|---|
| MSbit | 1 bit | $0 (brakes off) | | 1 bit | Lane Change selected | | 6 bits | Speed: $3F maximum, $00 power off |
| |
| size | Brake |
|---|
| MSbit | 1 bit | $1 (brakes ON) | | 1 bit | Lane Change selected | | 6 bits | Brake: $00 maximum braking, $3F minimum braking |
|
Braking information can be sent in every packet, and the InCar-PRO chip can apply the brake proportional to the value defined in every packet. The value can also be changed in every packet, should the RMS desire it (maybe to simulate rough ground)
Dynamic Braking Example Packet
The complete packet being sent will be, eg:
| byte number | Value | Decription |
|---|
| 0 | $02 | Speed command |
| 1 | $4F | Car 1 1/4 speed, changing lanes |
| 2 | $3F | Car 2 maximum speed |
| 3 | $80 | Car 3 brakes fully on |
| 4 | $8F | Car 4 braking at 75% |
| 5 | $E0 | Car 5 braking at 50%, lane change |
| 6 | $BF | Car 6 braking at minimum |
| 7 | chk | packet checksum |
EditMotor Torque Curve
To allow greater control over motor torque, the electronic drive to the motors has been enhanced. The standard Scalextric chip provides 64 levels of granularity to the motor through the PWM (Pulse Width Modulated) output. The InCar-PRO chip expands this to 128 levels of granularity, which are mapped from the throttle's 64 levels. This provides, effectively, an extra half-step of control, so that better torque curves can the defined.
Also the torque curve is programmed into the car chip itself. Instead of having to reset your throttles every time you change cars, you can pre-load unique and specific curves into the car's chip. In the club environment, this allows a much faster turn-around in racing as there is no need to adjust the RMS, and still everyone can have their own personalised, tweaked and pimped power curve
specific to each car. EditCurve plotting and PWM
The Pulse Width Modulation (PWM) of the InCar-PRO chip uses a granularity twice that of the throttle. This allows very fine sdjustment of the curve values within the car itself. The throttle values run from 0 (stopped) to 63 (maxiumu speed); while the PWM range that is mapped ranges from 0 (motor off) to 127 (full motor power).
The default InCar torque curve conforms to a slightly non-linear bottom-boost curve, where the bottom end of the throttle applies slightly more power than the exact linear throttle, smoothing to a standard linear. The exact values are:
| 0 | 0 | 4 | 8 | 12 | 16 | 20 | 24 | 28 | 32 | | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 54 | 56 | 58 | | 60 | 62 | 64 | 66 | 68 | 70 | 72 | 74 | 76 | 78 | | 80 | 82 | 84 | 86 | 88 | 90 | 92 | 94 | 96 | 98 | | 100 | 102 | 104 | 106 | 108 | 110 | 112 | 114 | 116 | 118 | | 120 | 122 | 124 | 127 |
| |
 Default Curve - green line shows loaded curve |
EditAnti Wheel-spin
Anti wheel is achieved by reducing the speed at which the car chip can ramp up the motor. Unique to hi-torque motors, its possible to apply more power to the motor than the wheel traction can hold. By slowing the acceleration rate at the motor, the likelihood of wheel-spin is dramatically reduced.
EditPlanning Anti Wheel-spin Settings
By default, Anti Wheel-spin is not enabled on the InCar-PRO chip. However, it can be set as part of the general programming process for the chip.
The value set will cause a limiting of the climb rate of the PWM which drives output to the motor. In other words, if the user suddenly accelerates the car from zero speed to maximum, normally the PWM will apply maximum power to the motor immediately. Instead Anti Wheel-spin will limit each PWM cycle's power to increase only by the step amount set within the AWS.
Reductions in throttle speed are
not restricted by AWS, however, and PWM will
drop to the new level immediately when throttle power is removed.
Setting an AWS value of $ff turns off the AWS functionality.
 Anti Wheel-spin plot |
The plot shows the comparison between pure throttle curves with linear torque mapping (ie, no anti wheel-spin);
an AWS setting of 10, where the ramp up during acceleration is limited to 10 PWM units so slows the motor ramp slightly;
and an AWS setting of 5 PWM units, which shows a heavily slowed ramping of motor speed.
EditProgramming the Torque Curve and Anti Wheel-spin
The process of loading the curve and spin into the car requires sending specific packets to the car in a specific order. Each program packet sequence will load exactly 6 bytes of data into predefined locations (slots) in the chip. In total 66 bytes of curve data will be sent, which includes the 64 bytes for the curve, 1 byte for anti-wheel spin, and 1 reserved byte.
EditTorque-Slot Definition and Contents
Torque Curve data is 7 bit data, therefore data ranges from 0 (no power) to 127 (full power) to the motor.
| Slot | Slot ID | Memory Range | Data Usage |
|---|
| 0 | $?0 | 0 - 5 | Torque Curve bytes 0 thru 5. Note: curve byte location zero is ignored, and will be set as zero |
| 1 | $?1 | 6 - 11 | Torque Curve bytes 6 thru 11 |
| 2 | $?2 | 12 - 17 | Torque Curve bytes 12 thru 17 |
| 3 | $?3 | 18 - 23 | Torque Curve bytes 18 thru 23 |
| 4 | $?4 | 24 - 29 | Torque Curve bytes 24 thru 29 |
| 5 | $?5 | 30 - 35 | Torque Curve bytes 30 thru 35 |
| 6 | $?6 | 36 - 41 | Torque Curve bytes 36 thru 41 |
| 7 | $?7 | 42 - 47 | Torque Curve bytes 42 thru 47 |
| 8 | $?8 | 48 - 53 | Torque Curve bytes 48 thru 53 |
| 9 | $?9 | 54 - 59 | Torque Curve bytes 54 thru 59 |
| 10 | $?a | 60 - 65 | Torque Curve bytes 60 thru 63, then Anti wheel-spin byte, then 1 reserved byte (must be $ff) |
EditTorque-Slot Programming
The individual torque-slot programming process is thus: (This sequence must be sent for each torque-slot to be programmed)
| Action | Command byte | Packet content |
|---|
| Send stop speed to car | $02 | all car bytes set to $80 to stop the car |
| Send Idle packet | $00 | all data bytes $ff |
| Send torque Curve Data packet | $13 | 6 bytes of data, appropriate for programming into slot |
| Send torque Curve Program command packet | $14 | 6 bytes, all matching, defining the slot id of torque-slot to program |
| Send 3 Idle packets | $00 | all $f0 - timefiller to allow programming to complete |
7 packets will be sent in each torque-slot cycle; meaning that to program all 11 slots, a total of 77 packets will be sent in strict sequence.
EditExample Data Sequence
The following sequence shows the programming of
slot 10 (torque & AWS) to the chip (Note, its likely that the previous 9 torque-slots have already been sent to the chip. However, torque-slots can be sent in any order.)
| packet byte number | Value | Description |
|---|
| 0 | $02 | Packet 1, Speed command |
| 1 | $80 | Car 1 stop |
| 2 | $80 | Car 2 stop |
| 3 | $80 | Car 3 stop |
| 4 | $80 | Car 4 stop |
| 5 | $80 | Car 5 stop |
| 6 | $80 | Car 6 stop |
| 7 | chk | Packet 1 checksum |
| 0 | $00 | Packet 2, Idle command |
| 1 | $ff | |
| 2 | $ff | |
| 3 | $ff | |
| 4 | $ff | |
| 5 | $ff | |
| 6 | $ff | |
| 7 | chk | Packet 2 checksum |
| 0 | $13 | Packet 3, Curve data command |
| 1 | $79 | Torque PWM |
| 2 | $7b | Torque PWM |
| 3 | $7d | Torque PWM |
| 4 | $7f | Torque maximum PWM speed |
| 5 | $10 | AWS, max climb of 16 PWM units |
| 6 | $ff | reserved byte |
| 7 | chk | Packet 3 checksum |
| 0 | $14 | Packet 4, Curve Program command |
| 1 | $fa | Slot ID 10 |
| 2 | $fa | Slot ID 10 |
| 3 | $fa | Slot ID 10 |
| 4 | $fa | Slot ID 10 |
| 5 | $fa | Slot ID 10 |
| 6 | $fa | Slot ID 10 |
| 7 | chk | Packet 4 checksum |
| 0 | $00 | Packet 5, Idle command |
| 1 | $f0 | packing - must be $f0 |
| 2 | $f0 | packing - must be $f0 |
| 3 | $f0 | packing - must be $f0 |
| 4 | $f0 | packing - must be $f0 |
| 5 | $f0 | packing - must be $f0 |
| 6 | $f0 | packing - must be $f0 |
| 7 | chk | Packet 5 checksum |
| 0 | $00 | Packet 6, Idle command |
| 1 | $f0 | packing - must be $f0 |
| 2 | $f0 | packing - must be $f0 |
| 3 | $f0 | packing - must be $f0 |
| 4 | $f0 | packing - must be $f0 |
| 5 | $f0 | packing - must be $f0 |
| 6 | $f0 | packing - must be $f0 |
| 7 | chk | Packet 6 checksum |
| 0 | $00 | Packet 7, Idle command |
| 1 | $f0 | packing - must be $f0 |
| 2 | $f0 | packing - must be $f0 |
| 3 | $f0 | packing - must be $f0 |
| 4 | $f0 | packing - must be $f0 |
| 5 | $f0 | packing - must be $f0 |
| 6 | $f0 | packing - must be $f0 |
| 7 | chk | Packet 7 checksum |
EditCar Lights, SP and RC1 ouptut
The car lights can be turned on and off individually to each car through the powerbase. The powerbase is required to send a unique command packet to the track at infrequent intervals - about every 0.5 seconds, or
once every 30 or so racing packets.
EditSP output
The SP output is controlled alongside the Car Lights. Presently this can be just turned on and off via the powerbase protocol, however bits have been reserved to allow this to become another variable level output. Each car is uniquely controlled within the protocol.
The initial concept is to implement Vari-Mag - a means of changing the amount of down force under powerbase and RMS control. This would be suitable to simulate wet-weather situations, especially tropical-type downpours. With a high-quality RMS system, it would also be possible to simulate track specific items, such as oil on track, by timing the Vari-Mag, braking, and throttle response to a specific area of track.
The actual Vari-Mag concept is still in its infancy, and requires additional items to be installed into the cars to implement.
EditRC1 output
There is an unused pin on the CPU which is not carried off the main board. This pin can be controlled and used as another output. It could be used for suitable triggering of sounds, lights, horn, or any other function needed.
To make use of this pin, the AUX packet has another bit to allow the control of this line as necessary. This is exposed in build 2 or later of the InCar-Pro firmware.
EditSending Lights and SP command data
The packet command implemented is the Auxilary command and has the value $FC (v4 and later) ($F7 in versions 3.3 and below, and remains for compatibility). The packet byte content is thus:
| size | Auxilary |
|---|
| MSbit | 1 bit | Lights on |
| 1 bit | SP on |
| 1 bit | RC1 on |
| 5 bits | reserved, must be $1F |
Lights and SP example packet
The complete packet being sent will be, eg:
| byte number | Value | Description |
|---|
| 0 | $FC | Auxilary command |
| 1 | $9F | Car 1 lights on, SP off; RC1 off |
| 2 | $1F | Car 2 lights off, SP off; RC1 off |
| 3 | $FF | Car 3 lights on, SP on; RC1 on |
| 4 | $BF | Car 4 lights on, SP off; RC1 on |
| 5 | $DF | Car 5 lights & SP on; RC1 off |
| 6 | $FF | Car 6 lights & SP on; RC1 on |
| 7 | chk | packet checksum |
EditAnalog Mode
Following discussion with the user community, Analog mode has been removed from build 3.3 firmware and later. This means that the car, when placed onto an analog track, will not do anything.
InCar-Pro firmware only responds to valid SSD digital data on the track - If this is not detected, then the car sits idle.
The reason for this decision is that for analog mode to function, the car must immediately go to full-power mode until it detects suitable digital signals. This runs the risk of car run-aways, especially after passing over a power disruption point, such as a lane-changer or standard cross-over which can cause the chip to reset. It is also considered by the community that the InCar-Pro upgrade will be undertaken only by true slot-car enthusiasts, who will choose to swap out the digital chip to race with full analog functionality.