Store: Scalextric
Scalextric US English $
M Menu
b 0 Items s

Dr_C

All Posts

Dr_C

297 posts

Very puzzling that the gap between the guide blade assembly and the DPR hatch is so large... I can see that the front axle would coincide with the hatch if it was further forward... but a betterdesign solution for compatibiity with the ARC PRO would, in my opinion, have been a split axle approach as used in the BMC minis.

 

To confirm this diagnosis, you could run the car by hand across the start line (and remember you need to cross the exit sensor too).

 

Then, temporarily extend the length of the blade using black pvc tape... and try again. The test here is bringing the rear edge of the blade closer to the IR LED... thereby improving the dual triggering of the lap sensor configuration.

 

C

Dr_C

297 posts

To function correctly with the standard lap sensors fitted into the ARC PRO there is a critical distance between blade and centre line of the IR LED that is important...

 

The distance between the back of the blade and the centre of the IR LED needs to be less than approx 19mm.

 

Also, this measurement assumes the IR LED is more rear-ward than the blade.

 

From the photos I suspect that the Monto Carlo does not meet, or is marginal, with respect to this distance requirement. This would explain why laps are being missed.

 

It would be helpful if Scalextric could check compatibily of the Monto Carlos with a DPR module fitted with the ARC PRO please? If not compatible using a DPR module then drilling 3mm hole and repositioning the IR LED may be necessary...

 

C

Dr_C

297 posts

From images on the web it looks like the blade assembly is a long way forward of the DPR hatch which might mean that the IR LED is too far back to function correctly with the ARC PRO. I wonder if anyone can confirm correct functioning of these cars with the ARC PRO?

 

For the ARC PRO to count laps two events need to happen simultaneously... the blade detect sensor needs to be triggered while at the sametime the IR LED on the underside needs to be above the IR detector (which is at the bottom of the slot)... for this to work correctly the rear edge of the blade assembly is usually just a few mm in front of the front of the DPR hatch.

 

I wonder if these large cars meet the ARC PRO design requirements? If not it may be necessary to reposition the IR LED in the underpan rather than in the DPR module...

 

C

Dr_C

297 posts

Just a few thoughts from me... apols if they are all too obvious or already considered and ruled in or ruled out...

 

1/ I cant see how doing the very straightforward Riko mod would be likely to cause any of the problems described... particularly if the mod was done by simply removing the six screws under the track piece and then reversing the two powerwires to one of the lanes. This does not require any access to the internal electronicswithin the powerbase... so no damage to the powerbase would be likely. I would envisage the worst kindof problem might be dislodging connectors to the sensor boards. I do however recognise that doing this mod is likely to invalidate the manufacturers warranty. In summary I dont see the carrying out ofthis mod as a likely cause of the problems experienced.

 

2/ I have found the use of the pace car feature can cause instabilities in the app from time to time... for example both a pace car and anon pace car registering laps under the same driver in the app. So if there are other issues you are seeking to addres I would recommend a fresh install of the app and then to avoid selecting the pace car function until you are confident that everything else is functioning correctly.

 

3/ with the clean app install I would then systematically look to see if cars perform identically both with and without the app running. i would ensure that profile C is used for all cars and thatthrottle is set to 100%. Remember, this driver nformation is only uploaded to the powerbase when you hit prepare to race... until that point old values remain in play. 

 

4/ I would look out for a rogue car with perhaps a failng motor, or intermittent pick-up, or poorly fitted decoder... as factors which might be creating a sense of overall inconsistency of the system.

 

just opinions/thoughts/observations...

 

Hope a solution comes into sight soon... this system is usually pure fun... so hopeyou get into that mode very soon... good luck!

 

C

Dr_C

297 posts

Hi Fatthinslim,

 

Nice work... but I am surprised you found it necessary to use such a high value of resistor... something  around the 150 ohms, 180 ohms or 220 ohms should remove the dynamic brakng without causing the cars to humm... if the cars are hummng then their motors are being powered in a lightly stalled state with one of the windings carrying a fair bit of current.

 

 

500 ohms will put the throttle signal very close to the drive away threshold... and for magless drivng may even be enough to prevent the cars from coming to a stop at all. Might be worth trying resistance values lower than 500 ohms...

 

C

Dr_C

297 posts

With the Scalextric app the car needs to clear the exit sensor before the car is able to register a second lap. This is to avoid doublecountng of laps. The Magic app does not use this type of algorithm, instead it uses a programmed timng delay.

 

From what you describe either...

 

1/ the exit sensors are themselves faulty...(unlikely)

2/ where the harness plugs into the exit sensor board... might not be seated properly.

or

3/ the board can be fitted the wrong way around... in this case a car would need to clear exit on lane 2 before the next lap can be counted on lane 1.

 

I know of one example each of situations 2 and 3...

 

Either way probably best to contact Scalextric customer services...

 

C

Dr_C

297 posts

The above sf thread is an interesting find thanks for sharing... I remember when a group of us were briefly trying to slow down magless SSD McLarens on an ARC PRO powered publc event... as we reduced the power the powerbase became unreliable before we got to the point where the cars could be driven with heavy fingers without excessive deslotting. I think this whole subject deserve further investigation and reporting of findings... are you up for sharing-back what you find in terms of reliability as supply voltage is reduced?

On the subject of current, the ARC PRO has internal resistors which monitor current and which are designed to provide voltage signals to trigger power shut down in current overload situations. Do these circuits still function correctly when reduced voltages are used? It would be good to have a definitive answer from experts on this point... so again your question is great...

 

C

Dr_C

297 posts

Hi all, i havent tried the ARC PRO powerbase with any powersupplies other than standard 15V. I would recommend sticking with either one or two of standard supplies... then use the app to adjust power levels as advised in above post. For casual racing, brief use of the app to set power levels still makes sense... even if you are not planning to use the lap counting and more advanced race features.

 

C

Dr_C

297 posts

Thanks Woodcote for bringing us back on track (literally!). I totally agree with your comment... that the ARC PRO powerbase and wireless controllers provide a truely amazing entry-level/mid-level slot-car system... very impressive and huge fun :)

C

Dr_C

297 posts

@giovanni_russello

Dr_C I am a bit confused by your post: are you saying that dynamic brakes is the only option no matter whether the ARC PRO is used as stand alone or connected with the ARC/Magic App? So there is no way that we can have the behaviour where once the throttle is released the car coasts unless one presses the brake button? If the dynamic brake is backed in the controller firmware then I have an idea why this is the case.

 

Hi giovanni_russello,

 

Happy New Year and thanks for the question. So to clarify, the dynamic braking function is applied in the signal path before the data packets are sent over the BLE comms. These comms consist of a 6 bit throttle value, a bit for brake and a bit for lane change. The dynamic brake function is evident in these data packets. You are correct in challenging whether it is applied in the firmware in the hand throttles or whether it is applied in the powerbase at a point prior to communicating with the BLE device. Either way, neither the user nor any BLE app developer currently has control over whether dynamic braking is applied or not. I hope this helps...

 

C

Forum Rules

  • The Scalextric Forum is intended for discussion of slot-car racing. Primarily, a place for newcomers to ask questions and seek assistance from like-minded individuals, the Scalextric Forum offers users the chance to join an active and friendly community.
  • Discussion of other slot-car brands is allowed, however, active promotion or advertising of our competitors is not permitted.
  • Please keep in mind that the Scalextric Forum is a publicly viewable space and you should never post personal information (including email addresses).
  • While every effort is made to contact you before any censorship, we reserve the right to amend or remove any content without explanation.
  • All customer service enquiries should be directed to Scalextric Customer Services.

Useful Links

Forum Guidelines


Membership Restricted Product