I just put a Rapido RDC-3 onto my layout and began testing it out. What I have found out is it doesn't want to stop. The manual indicates that F4 is the brake function which is a stupid idea to begin with. Even when applying it, the car takes a ridiculous amount of time to come to a stop. Even at slow speed, it is taking 8-10 feet to come to a stop. When it is traveling at full throttle I have no idea how long it takes to bring it to a stop because it runs into another train before it comes to a stop. It has moved at least 30 feet after throttling to zero and applying the brake.
I have read the manual and cannot find an answer to this dilemma. I have set CV4 to zero but that has not helped. I cannot stop this thing no matter what I do.
I had a similar problem with a WOW Sound decoder I installed in a Mikado last year but that had a feature that required applying the brake while throttling down. Fortunately, that function could be disabled and the decoder would behave like a normal one. I seen nothing in the manual that indicates I can do that. The manual says it is a LokSound decoder but doesn't give a model number.
Is there something I am missing? Is there a trick to get this to car to come to a stop in a reasonable distance or do I have an RDC with a defective decoder.
Do a factory default reset. No decoder of mine, across at least three different brands, coasts more than 8' after an F7 (not F4 on any of mine...so far..). It also depends, I believe on your CV3&4 settings, but I can't be positive about that. In any event, when I hit F7, the train typically brakes at about twice the normal rate, and if I hit the button once more, I can bring the train to a halt inside of about three feet.
Try a reset, and without any momentum/interia in those two CVs, peform the brake test from about 60 scale mph. Make sure it's the correct button, too. If it won't brake, I guess that you do indeed have a wonky decoder.
Something similar happened with my BLI PRR E-6 Atlantic - the 128 speed steps somehow became two - OFF or full throttle. Fiddling with the Cvs, I think it was CV3 or CV4 worked.
CV3 and CV4 are the defacto standards for acceleration and deceleration respectively and the ESU LokSound is no exception. I'll try resetting the factory defaults but I doubt it will make a difference because I had this problem right out of the box. Since then the only thing I have done is set CV4 to zero which theoretically should stop the loco as soon as the throttle is turned to zero. It's not working.
There is one other strange thing I'm getting with my Lenz system when using Program on Main to set CV4. When I just try to display the value of CV4, rather than display the number, the display reads "bIT". I've never seen that before and have no idea what that means.
I'm going from memory but I think F7 was the used for braking on my WOW Sound decoder before I disabled that so I control acceleration and deceleration solely with the throttle which is how all my other decoders work. I think requiring a separate braking action is just plain silly and an example of the decoder manufacturers getting way too clever. For as long as there have been electric toy trains, going back to the tin plate days, a throttle was used to start and stop the trains. That still works. If it ain't broke, why did they think that needed fixing?
If you haven't already, John, you might also try turning off dual-mode in CV29 to see what happens. It has been known to cause runaways when it's enabled. Since my DCC system is a Power Cab, I just disable dual-mode altogether when initially setting up CV29. My defacto value for it is "34" (addresses > than 128 & 28/128 speed steps) or "35", if needing to operate an RS-3 long-cab forward.
Tom
https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
Without knowing specifics, I'd suspect "bIT" means there is a bit error in the memory that stores CV4, and I'd immediately have the decoder replaced as defective.
tstage If you haven't already, John, you might also try turning off dual-mode in CV29 to see what happens. It has been known to cause runaways when it's enabled. Since my DCC system is a Power Cab, I just disable dual-mode altogether when initially setting up CV29. My defacto value for it is "34" (addresses > than 128 & 28/128 speed steps) or "35", if needing to operate an RS-3 long-cab forward. Tom
I did a factory reset and discovered CV29 has a value of 48. That means only bits 4 and 5 are turned on meaning it has the high speed curve (something I don't understand) and allows the extended address. That means it is set for normal direction, 14 speed steps, and analog turned off. CV4 had a factory value of 40 which I reset to zero. None of this had any effect on the problem.
Overmod Without knowing specifics, I'd suspect "bIT" means there is a bit error in the memory that stores CV4, and I'd immediately have the decoder replaced as defective.
I wondered about that but I tested this on several of my other locos that are working and got the same thing. I only get this when I do a Program on the Main. When I go to my programming track, I am able to display the CVs without problem. This might be a quirk with the Lenz system.
You can't read decoders on the main (with a few exceptions depending on decoder and DCC system).
Yes, reading CVs is only possible in programming track mode.
Now I am completely baffled. I noticed that at slower speeds, the car would stop according to the CV4 setting which for now is set a zero. At higher speeds, it would continue to go indefinitely although I discover that when I throttled to zero, I could stop the car with my finger and after a few seconds it would stop running.
I decided to gradually increase the speed to see how fast I could get it to go and still be able to stop it. My Lenz throttle displays the speed steps which are set to 28 steps for this car. Starting at speed step 8, it would stop immediately. The Lenz can increase steps either 1 at a time or 8 at a time depending on which button you push. When I took it to 16, it would go about 3-4 feet before stopping. At step 24, it would not stop at all.
I decided to work up one speed step at a time. I got it up to step 14 and it would stop immediately as it should. When I got to 16, it was more sporadic. Sometimes it would stop right away and sometimes not. I kept working upward and the more I did, the more it began stopping at once. I eventually got it stopping on a dime at step 24 and eventually all the way to step 28. Now it seems to be working as it should. I have no idea why. I've never had to break in a loco like this to get it to work correctly.
For now it seems to be OK. You can't be sure you've fixed a problem without knowing why it got fixed. For all I know, the next time I try to run it, the problem might start happening again. I have an email into Rapido asking for help. I don't know how long it normally takes them to respond.
John-NYBW I have an email into Rapido asking for help. I don't know how long it normally takes them to respond.
One of my Rapido F units was wonky and would not program. I wrote Rapido who gave me a link to the Loksound crew. I told them what was going on and they said bad decoder, Rapido replaced it.
Brent
"All of the world's problems are the result of the difference between how we think and how the world works."
The RDC in question continues to operate as it should. I'm still baffled as to why it didn't work right out of the box and what if anything I did that would make it work correctly. When I think of breaking something in, that usually applies to something with moving parts, not a decoder. When I first began running this, at low speed it would stop within a few feet but when trying to stop at higher speeds, it would run indefinitely. Even after setting CV4 to zero, the problem persisted at first. It was only after I gradually worked to higher speeds that it began to stop when the throttle was turned to zero. Finally, even at top speeds, it would stop immediately when I throttled down to zero. I still don't know what I might have done to cause it to start working correctly. I'd like to know the answer in case the gremlin reappears.
Does anyone have any ideas?
Perhaps it was the decoder automatically calibrating its BEMF settings?
All I know about this topic is that my older RDC manual recommended that you do an operation involving pressing buttons and then the RDC rapidly accelerates and then brakes to self calibrate BEMF settings. Then, for my new RDC, if I remember right, it said this was no longer required, as essentially the RDC would figure itself out during initial operation
speedybee Perhaps it was the decoder automatically calibrating its BEMF settings? All I know about this topic is that my older RDC manual recommended that you do an operation involving pressing buttons and then the RDC rapidly accelerates and then brakes to self calibrate BEMF settings. Then, for my new RDC, if I remember right, it said this was no longer required, as essentially the RDC would figure itself out during initial operation
That explanation seems to fit with what was happening with my RDC although I have no idea what BEMF settings are.
It stands for back electromagnetic field... It's a technique that the decoder uses to measure how fast the motor is spinning, without needing extra sensors on the axles or anything.
By knowing how fast the motor is spinning, the decoder can provide better speed control, especially at low speeds, where there's a fine line between not moving at all and lurching forwards at several scale mph.
speedybeeIt stands for back electromagnetic field.
Actually back electro-motive force.
Back Electromotive Force limits how fast the motor can go. Most dcc decoders can read this force and make adjustments to maintain the speed. ESU has an Autotune feature which calibrates the necessary values and sets the appropriate CVs for you.
Back EMF
betamax Back Electromotive Force limits how fast the motor can go. Most dcc decoders can read this force and make adjustments to maintain the speed. ESU has an Autotune feature which calibrates the necessary values and sets the appropriate CVs for you. Back EMF
Very interesting stuff, but I have to confess that this highly technical stuff makes my head spin. DCC has increased exponentially what is possible but with that comes an increase in complexity. I was a mainframe programmer in my working life so I am not averse to technology but in my retirement I prefer the KISS approach. I miss the days when you could just turn the throttle up to make your loco go faster and turn it down to make it go slower.
John-NYBW I miss the days when you could just turn the throttle up to make your loco go fasRichter and turn it down to make it go slower.
I miss the days when you could just turn the throttle up to make your loco go fasRichter and turn it down to make it go slower.
Rich
Alton Junction
richhotrain John-NYBW I miss the days when you could just turn the throttle up to make your loco go fasRichter and turn it down to make it go slower. That option still exists, and it is how I run all of my trains. Rich
That option still exists, and it is how I run all of my trains.
I'm guessing that's how it still works in DC although its been about 25 years since I ran a DC layout. DCC is a whole different game and many factory decoders have CV settings that do not allow for simple operation. CV3 and CV4 settings are often preprogrammed with values that greatly slows both acceleration and deceleration. Then there was the WOW Sound decoder I installed last year that required the brakes to be applied in addition to turning down the throttle. I had to disable that feature so I could stop using just the throttle. Now I've just been informed about BEMF which I don't understand and don't really want to. I don't mind decoders having these capabilities. I just wish they weren't the defaults. Let the users who understand them turn these features on if they so choose.
John-NYBW betamax Back Electromotive Force limits how fast the motor can go. Most dcc decoders can read this force and make adjustments to maintain the speed. ESU has an Autotune feature which calibrates the necessary values and sets the appropriate CVs for you. Back EMF Very interesting stuff, but I have to confess that this highly technical stuff makes my head spin. DCC has increased exponentially what is possible but with that comes an increase in complexity. I was a mainframe programmer in my working life so I am not averse to technology but in my retirement I prefer the KISS approach. I miss the days when you could just turn the throttle up to make your loco go faster and turn it down to make it go slower.
A lot of the features in a DCC decoder you don't need to mess with, they are just there. The only CVs that you really need to play with are the ones that set the address, and CV29. In many cases when you set an extended address your DCC system makes the necessary change to CV29 to activate it.
Most CVs can be left as is, unless you want to or need to make changes.
betamaxA lot of the features in a DCC decoder you don't need to mess with, they are just there.
You and I agree. ESU's latest decoders are a triumph of technology over reason IMHO. I acknowledge that there are some in the hobby that do use all those options.
Henry
COB Potomac & Northern
Shenandoah Valley
John-NYBWDCC is a whole different game and many factory decoders have CV settings that do not allow for simple operation. CV3 and CV4 settings are often preprogrammed with values that greatly slows both acceleration and deceleration.
The vast majority if my decoders are Digitrax, but I do have some TCS (non-sound), MRC (sound and non sound), NCE, Bachmann DCC On Board(non-sound), and BLI Paragon 2, 3, and 4, and I've never had one that didn't allow for simple out-of-the box operation. Some of them have had some slight acceleration/deceleration defaults, but none have been significant.
As one receives them, decoders are too loud and too unrealistic in their movement control...for my taste. Sounds are always going to be a subjective thing, but the way a locomotive moves, or should move, is another matter.
Right from my introduction to DCC, 17 years ago this month, I got into the books and read what DCC could do for my rails experience. When I learned about Master Volume, and what CV2 (V-Start), and what CV's 3-5 offered, I was in heaven. Now, my steamers all take time to lift a train, and they only come to a quick(er) stop if I press F7. When I slam the encoder knob (no, I don't really..) down to zero speed steps, my engines all take at least 6 feet to come to a halt if the starting speed is over 40 mph.
DCC is really very adept, and can greatly improve realism. However, it won't do a darned thing unless you put some effort into learning how to fine-tune motive power and characteristics, and how to tune individual volumes so that they don't become intrusive and annoying. Master Volume if always my third step after sliding the under-cab smoke switch to 'Off' and assigning the cab number as its address. From there, CV3 and 4, and reducing some other sounds like bell and chuff, which are often still too loud. My tastes, of course.