Problem with Set-Up of ESU Lokprogrammer

[Jbub]

When talking speedmatching, throw out the Accutracks.  Nothing even comes close to the ease of using the Boulder Creek Engineering Onboard Speedometer. It is by far my favorite and best ROI MRR accessory. 

I couple the boxcar to the locomotive and get a real-time readout of it's SMPH displayed on my phone.  After clearing the mainline, set the throttle to 50, adjust CV6 until the Speedometer reads 50.  Set throttle to 100, then adjust CV5 the same.  Dial the throttle down to 75, confirm speedometer reads 75, dial throttle to 35, 25, and 10 and you should see the speedometer read the same.  With ESU decoders, it's almost always right on the money.  TCS decoders will vary +/-3smph, but I think that's close enough.    And I think I've only ever had to adjust CV2 once.  The whole process takes as little as 30 seconds per locomotive, yes 30 seconds, and I am able to consist any unit with any other unit, including mixed decoders.   

I was hoping you would pipe in on this.
I saw Mark use this at the NSC train show and it blew me away.
Thanks for posting this mark because I forgot to ask you where you got it.

[jdcolombo]

OK.  That's impressive.  I'm sold!

John C.

[davefoxx]

Very cool!

DFF

EDIT: D'oh! The website says it's good for 3 smph to 200 smph.  The Accutrack II will display speeds less than 1 smph, and I like to use 1 smph as the starting speed (CV2) when speed-matching.

[Mark W]

Very cool!

DFF

EDIT: D'oh! The website says it's good for 3 smph to 200 smph.  The Accutrack II will display speeds less than 1 smph, and I like to use 1 smph as the starting speed (CV2) when speed-matching.

Yes, the RollBy works by counting magnetic field rotations, so going super slow is prone to variance.  But how often do you run at a constant 1smph?   I find as long as things match up at 10smph, momentum takes care of the slower speeds.   

[davefoxx]

Yes, the RollBy works by counting magnetic field rotations, so going super slow is prone to variance.  But how often do you run at a constant 1smph?   I find as long as things match up at 10smph, momentum takes care of the slower speeds.

Honestly, I use it often for coupling.  I have Sergent Engineering couplers, and, like the prototype, I like to bring the motive power up to the cut of cars; stop; align the couplers, if necessary; and then couple up using speed step 1, so I don't shove the cars into the next county.  Sometimes, I may have to back up and make a run at it to get the pin to drop, also like the prototype.  But, generally, I try to use reasonable car handling to make this as realistic as possible.

But, back to my initial point, I just like to use 1 smph as the starting point for speed step 1 for consisting.  I do like to see the power begin moving together and not bucking, or one unit not dragging the other.  This has worked for me.  YMMV.

DFF

[jdcolombo]

I don't actually try to measure the scale speed at step 1.  What I do is adjust CV2 (and sometimes I'll need to adjust the slow-speed BEMF parameters, although this is unusual) so that the engine just creeps as slowly as possible without any jerky motion at step 1/128.  I just measured a set of 3 of my Atlas GP9's (a mix of non-dcc-ready and dcc-ready engines that I previously speed matched) at 96 seconds over 1 foot of track, or a scale speed of about 1 smph (technically 1.14 smph), without any jerky motion from any of the engines.  Good enough.  Like Dave, I want to make switching moves as realistic as possible, and that means ultra-slow at coupling (if my MT couplers are properly aligned, they will couple perfectly at this speed; in fact, that's how I tell whether I've got them aligned properly or not). 

I credit the ESU decoders for their outstanding slow-speed control (Zimo is even better, IMHO, but ESU's sound decoders are a better choice for me, so I've standardized everything on ESU).  I could never get this kind of slow-speed performance from TCS or Digitrax (although admittedly I have not used the most recent iteration of Digitrax decoders; I quit on them about five years ago, when I installed my first ESU LokSound).

The thing I like about the Onboard Speedometer is not so much for speed matching, but to get a better sense of operational scale speeds.  One of the things I noticed about putting sound in my locomotives is that it immediately caused me to do everything more slowly.  Hearing steam engine chuffs, in particular, is a pretty good antidote to doing switching moves at 50 smph.  Similarly, hearing the diesel prime mover notch up and down keeps my speeds in check.  But it would be fun to actually measure the speeds I use for mainline running, switching, yard work, etc. and the Accutrack really can't be used for a lot of this (it's too big to fit across a single yard track, for example).

John C.

[RBrodzinsky]

I have actually found that, on some of my units, the Accutrax times out before the loco makes it through to the second sensor! The loco is moving nice and slowly (these are typically switchers, where I’ve set the max speed to about 50smph) so I don’t worry about it.

I got to play with Mark’s speedometer at last June’s n-Scale Convention in SLC, along with my Accutraxx. The two were in good agreement on scale speeds at normal operational speeds.

I agree with John, ever since I started adding more sound, I have found myself running at lower speeds. Makes opening up the throttle on those long stretches of FreeMoN country-side modules more fun.

[davefoxx]

Haha!  I cheated last night.  I put each locomotive on the tracks to see how the updates to the decoders on the LokProgrammer changed the running characteristics.  As expected, they were off, as CV2, CV5, and CV6 were essentially restored to factory defaults.  But, I pulled up the JMRI files (from my Mac) on each locomotive and used the numbers in the CV settings saved there, restoring the speed matching immediately.  They all worked out perfectly with no further tweaking necessary.

Speed step 1: 1 smph
Speed step 63: 35 smph
Speed step 126: 70 smph

Today, I hope to download JMRI to the new laptop, so I can easily import the new information from the LokProgrammer files.

DFF

[davefoxx]

I have had much success with the LokProgrammer, with one exception.  I have reprogrammed an SCL GP40, C&O GP40-2, A&R GP38, and SCL U36B.  They all consist well with speed-matching, and I have even modified horn and bell settings to try to match the prototype.  I may have to tweak these settings due to some educated guesses for horns and bells for these units in the mid-1980s.  I have set them up, so that Mute (F8), Drive Hold (F9), Independent Brake (F10), and Dynamic Braking (F4) all work in a consist.  Notably, I set up A&R #400 (without dynamic brakes) to go to Coast when the other units in a consist go into dynamic braking.  It's cool to hear all of the units throttle back and then the fans kick in, except on No. 400, which stays in idle.  Excellent!

The one problem that I haven't yet figured out is on my U36B, which has a Mars light in the nose.  It flashed fine before I reprogrammed it.  Now it's on all of the time (when I press F6), except when I activate the horn.  Then, the Mars light flashes, but it goes back to "steady on" after a number of seconds (like it's set up for ditch lights).  I have to figure out the setting that will allow it to flash all of the time when F6 is pressed.

DFF

[jdcolombo]

Hi Dave.

You probably need to set the "Function Outputs" configuration correctly for whatever auxiliary function you are using for the Mars light.

First, determine what auxiliary function is controlling the Mars light via the Function Mapping screen.  You know it turns on when you press F6, so look at the function mapping for F6 and see what it is turning on.  Probably Aux1, but it might be something else (the choices would be head light, rear light, Aux 1, Aux 2, Aux 3, and Aux 4).

Once you determine what auxiliary function is controlling the Mars light, go to the Function Outputs screen on the LokProgrammer software, select that function from the list (for example, if Aux 1 is controlling the Mars light, select Aux 1 from the list).  Now in the Output Mode (effect) drop-down list, select Mars Light.  Set the brightness (I use full-on, or a setting of 31), and deselect Rule 17 and Dimmer.

Write the changes to the decoder.  Now try F6.

John

[davefoxx]

Thanks, John!

That was the instruction that I needed.  I determined that it was set up for AUX 1 and AUX 2 as ditch lights.  I changed that to only AUX1, and that controlled the light on and off.  What I didn't know how to do was to then go to Function Outputs screen.  That was a part of the puzzle of the LokProgrammer that I was missing.  There, I changed the function to Mars Light AND turned off the Grade Crossing function (that's what was making it flash only if I honked the horn).  It works!

I then changed AUX1 to Gyra Light, which actually better represents the light fixture in the prototype SCL No. 1776.  I was using "Mars light" generically, which I shouldn't have done.  But, my ignorance of prototype railroad operation shows.  Again, the Gyra light on Aux 1 with the brightness setting of 31 nails the look of what the light did before the upgrade to the software.  I couldn't have done this without you.  As always, thank you for your time and expertise.

DFF

[jdcolombo]

Hi Dave.

You're welcome.  ESU has a variety of different lighting effects; finding the right settings to properly employ them, however, is not exactly intuitive.  This is one of the areas that I think JMRI actually does better than the LokProgrammer.

But once you understand that all this is "hidden" in the Function Outputs pane, it's pretty easy to access from the LokProgrammer.

John C.

[davefoxx]

Hi Dave.

You're welcome.  ESU has a variety of different lighting effects; finding the right settings to properly employ them, however, is not exactly intuitive.  This is one of the areas that I think JMRI actually does better than the LokProgrammer.

But once you understand that all this is "hidden" in the Function Outputs pane, it's pretty easy to access from the LokProgrammer.

John C.

I have learned a ton since I started playing with the LokProgrammer just a few days ago, and I'm sure that I haven't even scratched the surface on what it can do.  However, as I become more comfortable with the LokProgrammer, I am now finding much and much less use for JMRI.  I haven't even bothered to download JMRI to the new laptop yet.

DFF

[RBrodzinsky]

The best thing for JMRI use is all those tweaks that can be done with PoM in real time: sound and volume adjustments on the different sound slots (with immediate feedback); lighting functions and brightness adjustments; momentum; speed tables; etc.  Then, when everything is just how you like it, go back to LP and read the decoder back into its project, and write again, with “set as default” checked. Then, a decoder reset gets you back to YOUR base settings.

[davefoxx]

. . . and write again, with “set as default” checked. Then, a decoder reset gets you back to YOUR base settings.

I didn't even know that this was a thing!  Good to know.

Thanks,
DFF