LokProgrammer questions

[GaryHinshaw]

One of the local HO guys loaned me his LokProgrammer this week and I have been trying it out.  I have a few comments (C) and questions (Q) to blurt out:

C1. It is dramatically faster to read and write decoder data with this device than it is with JMRI.  It's also super easy to update firmware with it.  To that end, I updated a few of my LokSound 5 boards to pick up the new treble and bass control and the difference far outstrips any of my experiments with different speaker and enclosure configurations.  Boosting the bass and trimming the treble make a huge difference (for me) in the tolerability of N scale sound.  A very positive development.

Q1. I don't really understand the function of sound CVs.  The sound project I am working with (a GEVO project) has a separate sound CV for each of 8 throttle notches, but I have no idea what you can do with them, and the documentation I've seen so far doesn't really spell it out.  Is there a good reference or tutorial out there I could refer to?  I'm especially curious to understand if and how I could tailor the notches to specific speed ranges.

Q2. I would like to sync my LokProgrammer projects with my JMRI roster.  I see that I can export a CV list in the programmer, and I can import a CV list in JMRI, but the result is a funny roster entry in JMRI.   The entries in the JMRI panes are all highlighted in orange, a colour code I have not encountered before, and the Information tab is completely blank except for the firmware version.  Also, JMRI is expecting a CSV file, whereas my Window laptop exports the ESU data as a .txt file.  JMRI is able to read the txt file, but I feel like I'm missing something here.  Am I?

Q3. The LokSound and LokPilot manuals have the following warning about keep alive capacitors:

  Disconnect / remove the capacitor prior to programming with the ESU LokProgrammer!

Why?  What are the consequences of not doing that?  Ruining the decoder?  The programmer?  Other?  I have been able to program decoders with a keep alive connected using JMRI.  Is there something different about the LokProgrammer?

Thanks, -gfh

[kiwi_bnsf]

One of the local HO guys loaned me his LokProgrammer this week and I have been trying it out.  I have a few comments (C) and questions (Q) to blurt out:

C1. It is dramatically faster to read and write decoder data with this device than it is with JMRI.  It's also super easy to update firmware with it.  To that end, I updated a few of my LokSound 5 boards to pick up the new treble and bass control and the difference far outstrips any of my experiments with different speaker and enclosure configurations.  Boosting the bass and trimming the treble make a huge difference (for me) in the tolerability of N scale sound.  A very positive development.

Welcome to the world of RailCom — where bandwidth is plentiful and programming is reliable. This has been revolutionary for me in terms of what is possible with rapid decoder configuration and iteration.

RailCom also has significant benefits in reducing bandwidth consumption on a DCC bus because RailCom-equipped decoders can acknowledge receipt of commands. I will be purchasing a TCS CS-105 command station in the future so that I have RailCom on the main (the ability to read and write CVs on the main at speed is pretty damn cool).

The new tone controls are indeed very cool. I've spent the last week completely re-engineering my favourite three sound projects (SD40-2, Dash 9, and SD45-2) and the results are a massive improvement. I've finally got the treble and brightness under control, and I can tune the bass extension to exactly match a particular speaker+enclosure+sound file combination to the point that it gets messy, and then back it off a tad. We live in exciting times!

Q1. I don't really understand the function of sound CVs.  The sound project I am working with (a GEVO project) has a separate sound CV for each of 8 throttle notches, but I have no idea what you can do with them, and the documentation I've seen so far doesn't really spell it out.  Is there a good reference or tutorial out there I could refer to?  I'm especially curious to understand if and how I could tailor the notches to specific speed ranges.

SoundCVs are the primary CVs that can be used for conditional logic within sound slots. They are used to keep aspects of a sound scheme flexible without having to edit and reload the sound project to the decoder with a LokProgrammer.

At it simplest this can be something like changing SoundCV9 to trigger a different horn within a sound slot that contains several horns (often referred to by ESU as a template pack). Similarly some sound projects offer different air dryer sounds, compressors, and brake squeals that can be configured via SoundCVs.

The SoundCV notch settings are used to define the speed step at which the prime mover file advances to the next notch. For example the prime mover sound flow from Idle to Notch 1 is based on the condition that the Requested Speed > Sound CV1. So if SoundCV1=2 and the throttle is opened to 3, then the prime mover will notch up. This is quite powerful, and with something like the ISE ProtoThrottle allows you to map throttle notches to Loksound notches perfectly.

SoundCVs can be used to achieve some pretty cool effects. I use SoundCV16 to define logic for consists where a loco can be set on-the-fly to be a leader/trailer/intermediate unit, facing forwards or backwards. This then defines whether front and/or rear lights respond, and whether horn, bell and coupler sounds respond.

Q2. I would like to sync my LokProgrammer projects with my JMRI roster.  I see that I can export a CV list in the programmer, and I can import a CV list in JMRI, but the result is a funny roster entry in JMRI.   The entries in the JMRI panes are all highlighted in orange, a colour code I have not encountered before, and the Information tab is completely blank except for the firmware version.  Also, JMRI is expecting a CSV file, whereas my Window laptop exports the ESU data as a .txt file.  JMRI is able to read the txt file, but I feel like I'm missing something here.  Am I?

You are 90% of the way there already. The trick here is to take an existing JMRI roster entry, and then use the Import ESU CV option. This will then update the roster entry with all the CVs exported from the LokProgrammer and avoid hours or reading on the programming track. Don't worry about the txt vs csv format — JMRI works fine with a txt file exported from the LokProgrammer. Also don't worry about the orange status in the JRMI roster entry — just save it, close and re-open and then you will be in sync.
I uses this "round-trip" very often: I do my sound editing and initial config in the LokProgrammer and load this on the loco. I then export all the CVs to a text file and import to a JMRI roster entry. I then fine tune speed matching and sound slot volumes with JMRI programming on the main. I then put the loco on the LokProgrammer track and read back the final config into the ESU project and save it. Then you have both entries in sync.

Q3. The LokSound and LokPilot manuals have the following warning about keep alive capacitors:

Quote
  Disconnect / remove the capacitor prior to programming with the ESU LokProgrammer!


Why?  What are the consequences of not doing that?  Ruining the decoder?  The programmer?  Other?  I have been able to program decoders with a keep alive connected using JMRI.  Is there something different about the LokProgrammer?

You can ignore this. I have more than 20 locos with ISE PowerKeepers and TCS KA-N1s and I've never had an issue with programming or loading sound files or loading firmware except with the one loco that I've wired up two PowerKeepers in parallel (I have to disconnect one to load a sound file).

I've reloaded an iterated series of sound files more than 100 times on a couple of my ISE-equipped locos and not had a single error.

[peteski]

Gary,  ESU's documentation, especially relating to advanced sound tuning and creating sound projects is sorely lacking.  Few years ago Phil Dunlop on https://groups.io/g/Loksound created a much more thorough "unofficial" manual.  I tried attaching it to this post but it is over the 5MB size limit for attachments.  PM me your email address and I'll email it to you.

If you are planning on getting into ESU sound decoders, I highly recommend joining that LokSound group.  It is a very helpful community of ESU decoder users.  I see you already joined.

As for the keep-alive warning, if left attached they will not damage anything but might impede programming.  But as Kiwi mentioned, most of the time it is not an issue when using LokProgrammer.  It sometimes becomes an issue when programming on a programming track of a conventional DCC system.

[GaryHinshaw]

Thanks Tim, lots to chew on there!  I'll likely be back with some follow-up questions.

A few weeks ago I did manage to use SoundCV9 to sample different horn samples, but the throttle notch CVs were eluding me.  Quick question: what are the units of speed steps?  To be concrete, I am using a 3-step speed curve with min, mid, and max values of 2,44,116 for my Kato units.  When choosing notch speed steps, should they be relative to 116 or 255?  I assume 255?

And RE SoundCV16 and consisting: what method of consisting are you using?  I've been using Advanced (CV19) most recently.

RE the Lok programming: the only oddity I have seen so far is that I occasionally get a write error message while writing new firmware (to a LokPilot).  But if I read the data back, it all seems fine and up to date, so I have been ignoring that.

Peteski, thanks for the offer.  My email is listed in my profile (let me know if you can't see it).  I'd love to see that write-up.

[kiwi_bnsf]

A few weeks ago I did manage to use SoundCV9 to sample different horn samples, but the throttle notch CVs were eluding me.  Quick question: what are the units of speed steps?  To be concrete, I am using a 3-step speed curve with min, mid, and max values of 2,44,116 for my Kato units.  When choosing notch speed steps, should they be relative to 116 or 255?  I assume 255?

Yes the ESU SoundCV notch values are in terms of 0-255, with 255 mapping to the maximum speed you have configured with CV5 in your speed table.

I've gone so far as to linearise my loco speeds with a custom speed table so that they always consist perfectly over the entire speed range.

The ISE ProtoThrottle has configurable notch speeds in terms of 0-127, so I've configured my ESU SoundCVs to be slightly lower than these values.

Speed tables and notch settings are definitely a matter of taste. Quite a few people on the ProtoThrottle group "expand" their low speed section of the speed table to allow for more control at lower switching speeds and require correspondingly higher notching (i.e. a non linear speed table). Personally I find low speed control to be excellent once your reduce the top speed to a scale 60mph or 50mph, and increased acceleration momentum combined with the startup delay makes it easy to get the characteristic notch up when switching.

I ended up making a table to keep track of all of this:

And RE SoundCV16 and consisting: what method of consisting are you using?  I've been using Advanced (CV19) most recently.

I'm using Advanced Consisting. You can get quite a long way just selecting and de-selecting which functions respond to the CV19 consist address.

However, the value of CV19 is not exposed as a logical condition within the LokProgrammer sound slot editor, and so I ended up using SoundCV16 as the configuration value to define consist status. This can be set on-the-fly via a simple ops mode programming step on the main when I'm creating, destroying, or reversing consists.

RE the Lok programming: the only oddity I have seen so far is that I occasionally get a write error message while writing new firmware (to a LokPilot).  But if I read the data back, it all seems fine and up to date, so I have been ignoring that.

I've only run into that issue when I have installed more than one keep alive. There are some settings in the LokProgrammer around baud rate and error correction that you can experiment with.

[peteski]

I've only run into that issue when I have installed more than one keep alive. There are some settings in the LokProgrammer around baud rate and error correction that you can experiment with.

Tim I believe those settings (baud rate and parity) have nothing to do with communication between the decoder and LokProgrammer. Those settings are for the serial (COM port) communication between the PC and the LokProgrammer.  Keep-alive circuit has no bearing on that part of the communication.

Unless you have discovered some settings I'm not aware of.  But baud rate would most likely relate to the COM port settings (not whatever protocol is used between the decoder and LokProgrammer). 

Gary: if there are issues programming with keep-alives then just heed the ESU warning and disconnect the keep-alive since it most likely does interfere with the data transfer.

[GaryHinshaw]

RE programming with a KA connected: the only issue I have had so far is an occasional write error message from the LokProgrammer during a firmware update.  But as far as I can tell everything updated perfectly when I read the decoder back.  So as long as I'm not damaging anything, I'm going to ignore it, as disconnecting the KA is a pain, so I'd like to avoid it.  (And FWIW, I'm confident this is unrelated to the headlight failure issue discussed elsewhere, which occurred before I got the LokProgrammer.)

[GGNInNScale]

I picked up a LokProgrammer when I started converting to sound months ago.  It works really well.  I echo the comments above about the new tone controls- it makes an audible difference.  I noted in the most recent files for new decoders in the ESU site that some of the notes are still in German- my German is a bit rusty, but I could figure out most of the information.  Oh well.  I had to figure out what some of the sound CVs did by experimenting on the programming track.  But, I have found that the ESU decoders work reliably over the past two years.  I did have a couple of older models that failed on the motor drive (it was the output transistors).  Frank at ESU-USA swapped them for me with no issues under warranty.

[peteski]

  But, I have found that the ESU decoders work reliably over the past two years.  I did have a couple of older models that failed on the motor drive (it was the output transistors).  Frank at ESU-USA swapped them for me with no issues under warranty.

While in the past ESU decoders were quite reliable, and usually damaged only by user errors, it seems that the LokSound 5 decoders seem to have much higher failure rate which doesn't appear to be contributed to user errors. More like possibly bad batch of components (likely the microcontroller chip which is the "brains" of the decoder).  There are current and older discussions of this issue on https://groups.io/g/Loksound

While I have no doubts that ESU will make good on repairing/replacing the faulty decoders, it is still a hassle to have to remove and reinstall them from out models. I'm not contemplating switch brands - just wanted to inform everybody that there might be some spontaneous failures in their decoders.

[kiwi_bnsf]

Tim I believe those settings (baud rate and parity) have nothing to do with communication between the decoder and LokProgrammer. Those settings are for the serial (COM port) communication between the PC and the LokProgrammer.  Keep-alive circuit has no bearing on that part of the communication.

Unless you have discovered some settings I'm not aware of.  But baud rate would most likely relate to the COM port settings (not whatever protocol is used between the decoder and LokProgrammer). 

Gary: if there are issues programming with keep-alives then just heed the ESU warning and disconnect the keep-alive since it most likely does interfere with the data transfer.

Okay, so I've waited to post a reply to this as I wanted to 100% check that my recollection was correct with some regression testing.

For my Lokprogrammer, I'm unable to reliably write sound files to locos equipped with basic Keep Alives if I have the "Use package pipelining (for good connection quality)" enabled.

This feature can be found under the LokProgrammer Tools Menu > Program Settings… > LokProgrammer   (it's enabled by default)

With this feature enabled, locos equipped with ISE Power Keepers sometimes refuse to accept a sound file. The same locos always accept the same sound file fine with the feature disabled, or with the capacitor disconnected.

This behaviour is reproducible across multiple ESU Loksound decoders (58741, 58721, 58828 in particular) in multiple different locos (Kato, Atlas, Scale Trains). It is also reproducible across both my laptop and desktop computers with different USB ports.

I'm really not a fan of having to disconnect Keep Alives for programming – as I'm currently in a phase where I'm loading and testing new sound files on an almost daily basis.

I hope this helps solve the problem for other users of Keep Alives and ESU.

Cheers

[GaryHinshaw]

Thanks for the info Tim.  I haven't tried to upload a new sound file yet, but I will definitely keep this in mind when I do (soon, I suspect).  I did try to disable 'Use package pipelining' prior to updating the firmware on a LokPilot that had a keep-alive connected.  Alas I still got the 'write error' message at the end of the update, but it seems to be a red herring: when I read the decoder info back into the LokProgrammer or JMRI it seems to have been updated successfully.  So puzzling but seemingly harmless.

As a slight aside, I took delivery of a LokTester board on Friday and I was able to try it out over the weekend.  (It's a great little board that lets you test and program a myriad of ESU decoders before installing them.)  The first thing I tried was to update the firmware on a LokPilot board before connecting the keep-alive and it worked fine.  No 'write error' message like I was getting with the keep-alive connected.  Going forward, I will update and program the LokPilots ahead of time.  On the other hand, I suspect I'll be tinkering with the LokSound boards for years to come... 

[Dwight in Toronto]

“Tinkering with the LokSound boards for years to come”.   Yes, indeed - exploring the extensive capabilities of the LokProgrammer is a spin-off hobby in itself. 

Wait until you click your way through to the sound project flow-charting area - when I stumbled into that the first time, I was expecting to see flashing red warning flags announcing “You should not be here”!  But in time, I’ve constructed a few simple flow charts to enable single-button sequential operation of multiple headlight effects, for example.

Super powerful stuff, and great learning fun awaits!