[Dr_C]

In Car Pro (ICP)
===========

A gentleman by the name of Ian Harding did some great work a good few years back creating third-party firmware for Scalextric decoders (in particular those using the 16F630 microcontroller such as the C7005/6 and C8515 revs F/G and the older version of the C8516).

The code is known as ICP v3.3 and it has several advantages over standard Scalextric firmware as follows:

1/ it removes analog mode thereby reducing power surges as vehicles traverse lane changers (or other dead-spots).
2/ when used with the APB it enables adjustable braking strength and control of 
vehicle lighting including functioning brake lights.
3/ it adds 7bit motor control via throttle mapping giving finer resolution at lower speeds. Standard SSD is normally limited to 6bit resolution.

Many APB users over the years have enjoyed the opportunity to upgrade their decoders to unlock these additional features. They, including me, all owe a big thank you to Ian.

With the introduction of ARC PRO and C8515 rev H decoder, both a few years back, I took a further look at updates to ICP firmware (building on Ian’s great contribution).

I transferred the firmware across to the later C8515 rev H decoders (which are based on the newer 16F1503 microcontroller) and I added the following:

1/ IR LED strobe timeslots changed from 48 microseconds to 45.75 microseconds to improve lap counting reliability across all other SSD powerbases (including ARC PRO). The v3.3 firmware was specifically designed and tested for use with the APB.

2/ the 7 bit throttle curve was modified for improved compatibility with ARC PRO internal throttle curves plus options were added for both ‘standard’ motors (A06) and ‘hot’ motors (A00).

3/ Improvements were introduced to suppress a noise related ‘non-power-up’ issue which affected some users and which was unique to ARC PRO when only lightly loaded.

This updated release is known as ICP v4.0.1 and it has been widely shared from 2019 onwards. All user feedback has been positive with the exception of two users who are/were operating braided/routed SSD tracks.

On this basis ICP v4.0.1 remains the latest release version but any new users should be aware it is not recommended for use with braided/routed tracks.  This applies both to release versions v3.3 and v4.0.1. Copper taped tracks are reported to be OK.

So does the ICP story stop there?- well no and yes.

Myself and fellow enthusiast Dave spent a fair bit of time looking into the braided track issue. We drew firm conclusions around the underlying cause. ICP v3.3 and v4.0.1 were found to have a vulnerability to electrically generated noise caused by braid-to-braid surface friction. We then proceeded to develop new firmware code which fully suppresses this noise characteristic.

The results have been highly positive and the learning will be applied to all future decoder firmware design in which we are involved.

That said, given that very few SSD users have braided/routed tracks there is no current plan to release an updated version of ICP.

It remains a possibility for the future.

c

[Drifter2]

Ian's work is awesome but that was a while back now.

Something new altogether would be good. New features, new thinking, new name to avoid confusion.

[Dr_C]

Hi Drifter2, I think you are right. 

That said, it was an extremely interesting challenge looking in depth at ICP to address the braided issue run-aways which I did in collaboration with my kind friend Dave. Over the months we looked into a whole range of potential causes. In the end, we pinned the problem down to electrical noise generated by braid-to-braid friction though there were some other contributing factors along the way too. We were then able to refine the firmware code appropriately and the issue was finally sorted. Literally a ‘game changer’.

Interestingly we saw similar issues with other brands of decoders that used track packets for communications. At times we used nRF wireless modules to telemeter the status of the decoder prior to, during and after runaways had occurred. This included telemetry of the number of ‘good’ data packet reads per second - typically 50 per second for SSD.

The conclusion of this work is that we believe we now know how to make rock solid run-away-free decoders which use track packet protocols.

So coming back to Drifter2’s point - yes probably the end of the road for ICP development but the learning along the way for sure will inform our future decoder designs - both hardware and firmware.

As mentioned elsewhere our focus is now on C++ decoder firmware rather than asm as used for ICP. Faaaaaasrrrrrrrrrrr easier!

Yes, time for new code, new features and new branding.

c

[flat4]

 C!

Even if something new, with new features, is hyping me, I have to say that I'd also love to see some updates to ICP, especially if it can help some folks like me.

I am actually really surprised to discover that ICP wouldn't be recomended for cars used on braided slot tracks.... as this is my situation, and as beside the huge improvement in terms of performance / tour, it fixed some problems, such like random ID change on cars which was very frequent (I would say easily 2 to 3 per hour for 4 cars running together).

I feel like I don't experiment car runaways, but maybe I misuderstand the term, may someone clarify me?

Anyway, ICP has been a game changer for me and some people I know but are nor forum friendly, and thank you very much what you've done to it

[Dr_C]

Hey Flat4, many thanks for the positive review of ICP.

C