I have a TCS M1 decoder in an Atlas S-2 switcher, which is set up for Rule 17 lighting. When the moves forward or backwards, the LED headlight in the opposite direction of travel flickers constantly ever so slightly. When the locomotive sits idle there is no flicker.
What causes the flicker? Is it a voltage regulator issue on the decoder PCB? The flicker does not occur when the decoder is set up for "regular" lighting effect - i.e. only the headlight in the direction of travel comes on. And none of my other TCS decoders exhibit the flicker using Rule 17 lighting.
Thanks for the insight...
Tom
https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
Flicker usually means power contact is being lost, even when it's not enough to stall the loco (motor inertia and the flywheel keep it going), the headlight can still flicker.
However, dimming LEDs in decoders generally uses PWM, so it's actually rapidly turning the LED on and off. More off time menas dimmer LED. Usually that's too fast for the eye to see, but if it's a different version of the decoder than the others, it might not be using a high enough PWM that keeps you from seeing it. There are other CVs in TCS decoders for lighting control that aren;t mentioned in the sheet that comes with the decoder - they are in the comprehensive manual available for download.
ALso if it doesn;t appear to flicker when standing still and dimmed but does when moving in reverse - it could be vibration induced by motion combined with the PWM frequency alloowing your eye to pick up on the flicker.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Correct - There is no visible flicker of the LED headlights when the locomotive is still and dimmed. It's only the LED headlight opposite the direction of travel that flickers and this happens in both forward and reverse. It is barely noticeable...but is noticeable.
I'll download and check the comprehensive TCS decoder manual you mentioned, Randy. I'll also check to see if the decoder lighting effects are set for LED or incandescent.
I think it may just be a combination of the PWM frequency and the vibration of the shell by the motor when running. Are the LEDs rigidly mounted to the frame, or are they on leads? I'm thinking if you can run it with the shell off and the LEDs suspended on their wires and see if they still apepar to flicker when in motion.
Is BEMF on or off? If not using BEMF on this one, it could be the drive frequency just so happening to correspond with the LED PWM frequency.
Basically - it's an illusion caused by the "perfect storm" of corresponding elements. Modify any of them and it should be offset enough to stop the flickering appearance.
The front headlight is an SMD-type (0805?) LED and is fixed to the chassis with foam and Kapton tape. It was the only way to fit a front LED headlight into the Atlas S-2 shell because of how close the chassis fits to the shell. Here's a pic:
IIRC, the rear LED is a regular bulb-type warm LED rather than a SMD-type and BEMF is on. CV61 should be set to "49".
[Yes, I just confirmed that on the programming track so BEMF is on and Rule 17 and opposite dimming are enabled.]
From the SBS4DCC site ....
"It is also possible to add an "anti-flicker" capacitor to your lighting circuit without making any board-level modifications to the decoder. Just remember that you have to do this to each function so space can be a big issue.
¡ uʍop ǝpısdn sı ǝɹnʇɐuƃıs ʎɯ 'dlǝɥ
My only concern with that is a 220uF or larger cap is probably going to totally defeat any PWM dimming. Great for lights that are either on or off, they shouldn't flicker with that circuit. But I think not so great for PWM dimming.
I think choosing the cap value so it ‘just’ sustains the dimmed voltage to the device is the answer here. As I understand this function there is only one ‘level’ of dimming to the LED and no flicker at ‘full gate’ so this should work. I don’t have the specs for the devices so I can’t give the specific cap value to provide; I’d be tempted to tinker and then report back what the range of effective values turns out to be. (Also where you package the cap in that unit!)