ESU LokPilot v4.0 (54614) versus LokPilot Standard (53614)

[C855B]

I have an odd situation here, and could stand advice on whether to throw more money at it. 

I ordered LokPilot Standard decoders to put in my ScaleTrains.com turbines, and the vendor sent LokPilot v4.0. It didn't matter to me, I just thought they might have been out-of-stock, and they sent the "better" decoders to fulfill the order.

Problem is - one failed shortly after installation. So I sent it back, the vendor realized I was sent the more expensive decoders in error, and the replacement was the Standard. When he brought this to my attention, I told him that they were going in a matched set, and was concerned about control issues if there was a significant difference in dithering algorithms or other motor firmware between the two decoder types. The response I received was dismissive in tone, among other things stating they were "the same", just the v4.0 had more features.

Frankly, I seriously doubt this.

Given the annoying disassembly/reassembly issues with the turbines, I do not want to install the differing decoders only to discover a meaningful performance mismatch forcing replacement (and further disassembly). Sure, I'm certain one or the other could have parameters adjusted to better match, but more on that in a second. So the question now is whether I should spend the $25 plus shipping to buy another Standard, from another, more supportive vendor.


This is my first experience with ESU products. From reading here and elsewhere, ESU is the up-and-comer in the DCC decoder world. I don't doubt that, but my experience so far is the sophistication and advanced technology comes at a price - configuration complexity. One can get into trouble very quickly, just follow the "Turbines!" thread about @Mark W's issues as well as my own missteps.

No fool, I use JMRI Decoder Pro to configure. It takes nearly an hour for JMRI to read all the registers and sub-registers to populate the configuration tables in direct byte mode, and this is a non-sound decoder! Screw something up trying to, for instance, speed match or otherwise adjust performance curves, and you are in a world of hurt. You get to reset it all and start over again. Not fun.

This kind of thing is exactly what I retired from - configuring complex specialty electronics, and doing the constant dance of managing firmware revisions within a complex network. It wastes a lot of time. I am considering biting the bullet and scrapping or attempting to sell these decoders, licking my wounds, and paying more for 21MTC cards from a domestic company like TCS who may be less sophisticated in the deep-down code, but doesn't impose nearly as much configuration management overhead.

[Scottl]

Sounds like a dealer issue more than anything.  I suspect it won't be a problem to match up the different versions of the Lok Pilot decoders.

I have recently used a v4.0 Lok Pilot for the first time and the settings out of the box gave the best DCC performance I have seen (Kato, FVM, Atlas diesels).  The auto calibration was a feature I discovered in the manual and it improved performance further.  I can now get a FVM AC44 loco on step 1/28 to take 5 minutes/m of track.  You can barely tell it is moving (guess how I found out  ).

My only issue is the manual, which is really too comprehensive and most of the key features are not particularly highlighted.  I guess now that I have taken the trouble to read it and learn the quirks, my next effort will be minimal.  They need to generate a key features list for programming that cuts to the good stuff.

To date I had only used TCS decoders after some issues with NCE and Digitrax.  Now my go to will be ESU.  I have one waiting for install, but it requires hardwiring so I need to get in the mood.

[C855B]

Well, 'tween then and now I decided to minimize the hassle and expense, and found someone on eBay (who happened to be nearly local) with a good price on the v4.0 54614, with free shipping. In this isolated instance figured I'd be money and time ahead, and just keep the turbines all with the same decoders, using the same parameter set in JMRI. I suppose I can sell the 53614, maybe, or if all fails, give it to an HO'er  friend. I still cringe at the prospects of speed matching to the rest of the fleet, but if it turns out to be too much trouble, UP rarely m.u.'ed these with anything, so there you go.

> They need to generate a key features list for programming that cuts to the good stuff.

Yeah. I was hoping JMRI would help more with this. I guess the JMRI tab organization is not bad, there's just so much of it to page through.

[Scottl]

I need to get JMRI going at some stage.  Maybe my next purchase will be a DCC-USB interface.

[jdcolombo]

Hi Mike.

It appears that you've decided to simply get a second v.4, which is probably a good move.  For future reference, however, the LokPilot Standard is likely to have everything you need.  It supports all the lighting modes you are likely to want, including Mars light, alternating ditch lights, Grya light, strobe; function mapping; speed tables; programming on the main; and all the usual stuff.

The differences between the V.4 and the Standard are not likely to be ones you need: for example, the V.4 supports the Motorola and Selectrix digital protocols; the Standard does not.  The V.4 supports several different kinds of "braking section" implementation, including Lenz, Zimo, and others; the Standard supports only the Lenz type.  The function mapping on the V.4 is more sophisticated, allowing conditional logic control, which the Standard does not, but I've never known a situation in which that mattered for me.  ESU is working on updated software for the V4 to make it more compatible with the Full Throttle features of ESU's sound decoders, but you don't appear to be using sound in your Turbine anyway, so that shouldn't matter unless you buy a second sound-equipped Turbine and decide to double-head them over Sherman Hill .

As long as you are not trying to use some sort of advanced function on the V.4 and expect to match that in the Standard, or as long as you are not trying to match a Standard to a LokSound (which has issues because of the Full Throttle features) you should be fine with having a Standard in one loco and a V.4 in the other. 

Now for your other point.  First, I agree that programming modern DCC decoders is way too complex.  But that is the result of antiquated user interfaces, not the complexity of the decoders themselves.  Modern smart phones are incredibly complex, too, but the manufacturers have managed to give us software that mostly hides the complexity.  The idea of end-users having to understand binary coding in order to program decoders is ludicrous.  JMRI is a major step forward, but even it is a bit clunky (the function-mapping table, for example).

And before I drop a TCS decoder in the Turbine, I'd consider that TCS has had its share of technical issues.  For example, I quit using the Z2 decoder from TCS because of a strange problem with speed tables, in which the decoder would SLOW DOWN between speeds steps 2-3 instead of speeding up.  Others have documented this issue, and at one time I think TCS even admitted it was a software problem with its speed table implementation (and by "speed table" I mean using CV's 2, 5 and 6, not just the 28-step table).  TCS also released a decoder for the Kato FEF that simply didn't work.  I've NEVER had any such issues with ESU's motor control or software implementation.

Through the 22 years I've been using DCC, I've tried decoders from Digitrax, TCS, NCE, Zimo, ESU, and Lenz.  My own view is that Zimo stands at the top of the heap for motor control, but if you despise complication, then the Zimo is not for you; the Zimo manual reads like a technical manual for a computer engineer, rather than an end-user manual for a normal person.  It is even more complicated in its programming options than the LokPilot.  ESU is a close second, IMHO, in motor control, and while its manuals aren't exactly models of end-user clarity, they look like "DCC for Dummies" in comparison to Zimo.

I understand your frustration.  I, too, have waited an hour for JMRI to read all the CV's in a LokPilot V4 or a LokSound Select.  But you only have to do that once, and I think that in the end, they are simply better at motor control than TCS (or Digitrax).  If you're not using a sound decoder, most of the complication of a LokPilot V.4 is simply in stuff that you will never use.  The basic stuff like speed tables, momentum, function mapping, lighting control, and so forth works pretty much the same with all decoders, so at that point the complexity issue is really the same for everything.

John C.

[C855B]

... so that shouldn't matter unless you buy a second sound-equipped Turbine and decide to double-head them over Sherman Hill . ...

Very funny.   One of those things was spectacular enough. Like double-headed Big Boys, it might have happened, but I've not yet encountered photographic evidence. Best I've found online is one picture with three SD24s trailing. It is possible they didn't allow it - a trailing turbine would be inhaling the exhaust of the leader, and lose quite a bit of power.

Thank you for the confirmation. All the fancy stuff is apparently... well... fancy stuff. But I figured for the small cost involved it was easier to be safe than sorry, and now that I've already endured the nail-biter of uploading the default param table to JMRI, I should be somewhat protected from future screwups.

(You're reminding me of the need to double-check the decoder in my wife's FEF. I think we escaped the TCS drama and it ran fine the last time we had it out, but I should be sure before taking it to a show in two weeks.)

Speaking of which, are you going to the Springfield show? I'll be with the StL N-Trak group, so look us up if you're there.

[peteski]

I agree that may of today's (even non-sound) decoders are getting way overcomplicated. The reality however is that will never have to touch or use about 99% of all those hundreds of configuration CVs .  The manufacturers put all those fancy features in because:
1. they can (due to the miniaturization of electronic circuitry)
2. to outdo other manufacturers
3. because few crazy modeler's demand all those features

The points 2 and 3 are just my speculations, but there might be some truth in them.  Also, in non-sound decoders, a large number of the CV registers is devoted to remapping functions and to all sorts of lighting effects (European railways  have all sorts of complex lighting schemes). Looking at the ZIMO manual which describes the Swiss loco lighting scheme makes my head spin.