Apr 17, 2017
Does anyone have experience programming an ESU LokSound Select Micro v4 (73800) diesel on JMRI?
Very easy to do, and well laid out. Dave Heap has done an excellent job in mapping all the options available. Note - you can only program the CVs with JMRI - if you want to load a different sound file, or update the decoder's firmware, you need to use ESU's LokProgrammer
Don't have a LokProgrammer. Does anyone have the CV list file for an EMD 567 for an F7 that can be imported with JMRI?
I can send you the import file for preloading the CV values into DecoderPro for any of the projects. Which sound file do you have (there are 3 different 567 files). I usually use the 567 B/C for my F units.
I've sent you a PM so you can send me your email info
Royal cluster. After loading the CV values, decoder became unresponsive. Looks like it's dead in the water.
Honestly, you should NEVER try to do this with a LokSound decoder (blindly programming a set of CV's someone has sent you). They are simply too complicated, and if JMRI misses a CV due to a read/write error (which happens more often than I'd like), you are completely hosed. And if the decoder has a generic sound file and you are trying to update the sound file, you CANNOT do this via JMRI, no matter how many CV's you program. Updating a sound file requires replacing the sound code in the dedicated sound memory area, and JMRI cannot do this.
Here's what to try now.
1. Do a decoder reset. You can do this via JMRI, or you can enter a value of 8 in CV8, then cycle power. See if this causes the decoder to come alive.
2. If the decoder comes alive, what exactly is it that you want to program? If you want to program a sound file, you can't do that via a set of CV's. The ONLY way to do it is via the LokProgrammer. Find someone in your area that has one. If you live near central Illinois, I have one. PM me. If what you want to do is change specific behaviors (e.g., the speed curve, the Function key assignments, the sound volume, the horn type, etc.), then do this individually. This you CAN do via JMRI. What you should do is select the decoder type manually when you create your roster entry. Select Electronic Solutions Ulm, then select the LokSound Select subfolder. In that folder you will find a number of different choices, organized by prime mover. Pick the file with the prime mover you have installed; if you don't know what prime mover you have, any of the files will do - the difference in these files mostly has to do with the default setting for bell/horn/prime mover sound in CV48. Then do your roster entry, save, and go to the full programmer screen. Before you make any specific CV changes, select "Read Full Sheet" for each programming tab and read the values. Save the file after each full sheet read. This will take you about an hour (honestly - there are something like 800 CV's in a LokSound file; reading them via JMRI takes forever, but this is the ONLY way to do this all safely). Once you have read all the sheets and have values for all the sheets, save the file one last time. Now before making any changes, duplicate this file (use the roster entry duplicate command), and make your changes to the DUPLICATE file. This way you can always check what the default CV value was for anything you changed, in case something goes haywire.
I love JMRI; they have done an incredible job with their ESU LokSound support. But the decoders are so complex that sometimes JMRI messes up.
3. If the decoder does NOT come alive, you'll need to find someone with a LokProgrammer who can reinstall the sound file from scratch.
Hmm... not wanting to start an argument, but how do you "hose" a decoder by setting the CV's incorrectly? You can indeed configure it to not do what you want.
Isn't there also a verify feature that you can use to make sure what you wanted to write actually got in correctly?
I'm also confused about "reinstall the sound file from scratch".... your statement implies that changing CV values can actually damage the sound file code. So how is this possible with JMRI? You cannot download and install the firmware or sound file via JMRI, but you can damage the code?
Again, not wanting to be argumentative, but this does not make any sense to me at all.
I've done a few ESU, a lot of Zimo, and many others and have never found a way to damage sound files from setting CV's... I have mucked up settings enough I had to reset the decoder.
And I have re-installed a sound file a few times when I really went nuts on changing things when I had situations where the sound file CV's did not reset with a decoder reset, but that's another story.
I have done a "write all sheets" from JMRI on ESU decoders, and had the process fail more than once. Sometimes the write failure only caused weird behavior, like the headlight becoming a Mars light or coming on only in reverse rather than in forward. But three times the failure has resulted in an unresponsive decoder. Once I was able to bring the decoder back to life by doing a factory reset, then I programmed CV's individually (using JMRI) to get where I wanted to be. The sound file itself was not damaged in this case. The other two times, the factory reset did not work, trying to reprogram via JMRI also did not work, but I was able to reprogram the decoder using my LokProgrammer via a complete file reinstallation from a file I had saved for the engine. I do not know if in these latter cases I could have simply asked the LokProgrammer to reprogram the default decoder CV's, instead of the complete sound file, and brought the decoder back to life that way, because I just used the complete reload option.
So, I shouldn't have implied (and didn't mean to do so) that the sound file itself was damaged; I actually don't know if that happened, and suspect that it did not. I only meant that in two cases where trying to "write all sheets" via JMRI, some failure (1) caused the decoder to become unresponsive; (2) a factory reset did not work and (3) the only way I could cure the problem was by reinstalling the complete sound file and decoder CV's via my LokProgrammer.
Got the decoder to come alive, following your advice. Doing the value 8 in CV8, then reading and saving each program tab did the trick. I went ahead and ordered a LokProgrammer so I can load an EMD 567 prime mover into the decoder in lieu of the test file.
Thanks for the help.
Thanks John, the detailed explanation makes sense to me, and matches my experience, although have not locked up an ESU yet, but have not done more than 4 or 5 (so there still "hope" so to speak).
It is a somewhat sad state of affairs that writing CVs can lock up a decoder, but clearly it happens.
Well, let's "hope" NOT!
I've quit trying to do a "read all sheets" or "write all sheets" via JMRI. These days what I do is use the LokProgrammer to get things where I want them, then save that file for that specific engine. This is all done in my workshop with a test track. After this, I take the engine to my layout, where I have JMRI set up, and I put it on the programming track and read each sheet individually. It's painfully slow, but that way I've the engine information in JMRI for both roster purposes (using WiThrottle) and in case I want to make any minor CV adjustments. And I have my LokProgrammer file in case the thing goes dead and I have to start over.
The LokSound has something like 800 CV's. Most of them are empty, and I suspect what happens is that occasionally JMRI writes a wrong value to something, the software sees a value in a CV that it doesn't know what to do with, and locks up. I've never had a problem as long as I'm dealing with a single sheet; it's the "Write All Sheets" command that has given wonky results occasionally (well, actually, more than occasionally).
I've done read all and write all with other decoders successfully... although I also use QSI in large scale and that's a lot of CV's. I have never counted but with the indexing it's a ton.
A decoder should never lock up if presented with an illegal value, it should refuse that value, i.e. just not change the value, or put in some default value.
But to be clear John, you are saying JMRI does not lock up, but the decoder does, this is what I am reading from your posts.
What I experienced was, when I did a factory reset, the decoder still didn't respond but all the CVs were reset. Following John's advise, when I then had JMRI read the CV tab, in programming track mode, it assigned totally different values to almost each CV. I went through each tab, reading and saving. It was then I went back to the Operations Track and the decoder was working again.
It would appear the factory reset assigned the wrong CV values to the 73800 decoder, although the 73800 may be different than what JMRI had in mind for a factory reset.
Yes - the decoder locks up. Won't respond to commands, and in two cases (out of maybe 40 sound installs I've done), I needed to reprogram the decoder using my LokProgrammer to get it back alive again. JMRI doesn't lock up; it just keeps on truckin' until it's done. It's just weird. Don't know why it happens, and it's never "bricked" a decoder - I was always able to recover the decoder via reprogramming.
Luckily you are doing this on decoders that have a firmware download option. If this process was repeatable, i.e. you have a "sheet" that always locks up a decoder, it would be perfect for the decoder manufacturer to debug the problem with their product. (yeah sure). Oh well, I can always dream.
BTW, decoder is performing beautifully now. Outstanding motor control!!!