ESU has one the most thorough sound catalogs in the industry. They offer hundreds of unique sound sets that allow you to "super-detail" the sounds in your locomotive. It is not practical for a dealer to stock so many varieties of pre-loaded sound decoders. The expense would be astronomical. The solution is to ship a blank decoder, let the customer select the desired sound file, and then use a device (the LokProgrammer) to upload the sound.
A few distinct advantages to this arrangement are the ability change the sound file loaded on the decoder, create custom sound files, and update a sound file if an improved version becomes available after the decoder is installed.
When a dealer (or customer) gets a decoder from ESU it comes with a generic file that was loaded at the factory for testing. It may be a real file but it is not likely to be the one the end user wants. It is a blank decoder technically speaking even though it has this default file loaded onto it.
The dealer (or customer) then determines which file is desired, connects the decoder to the LokProgrammer via the LokTester, test track, or other method, opens the file with the computer software, edits any CV values they deem necessary, and then loads the file onto the decoder.
All decoders have two types of memory for storing CV values; volatile and non-volatile.
The active CV values currently used by the decoders are stored in volatile memory. When you tweak and tune a decoder, you are writing data to the volatile memory. This is true no matter what type of programming method you are using; Program On Main, Service Mode, etc. When a decoder gets corrupted from a short circuit or similar event, the values in the volatile memory have been modified or erased.
The default CV values that were predetermined by the manufacturer are stored in non-volatile memory. These values are copied to the volatile memory when CV8=8 (factory reset - consult you decoder manual for the proper CV and value as some brands do use other values) is written to the decoder. Some decoders will allow the user to overwrite the default values in the non-volatile memory with their own preferred values so that every time a reset is performed, volatile memory is restored to the users preferred configuration. Have no fear, non-volatile memory is not easily changed and typically requires a special device like the LokProgrammer to do so.
If a sound file is loaded correctly, the new CV values are written to non-volatile memory and these are the values that are copied when a factory reset is performed.
If a sound file is loaded incorrectly, the CV values from the original file used for factory testing are not are not overwritten in non-volatile memory. Since the default file and the user-selected file are likely to use different settings, the decoder will no longer respond the way it is supposed to.
The problem is not fatal, just annoying. The only good solution is to reload the original CV values from the sound file. This is not a big problem if you possess the LokProgrammer. It is an inconvenience if you have to send it back to a dealer for reprogramming.
So, you are now asking why wasn't this done correctly to begin with?
The process was not necessarily clear or intuitive and the key to the correct process is very subtle.
I will tell you I have done it wrong and continued to do so for several months after the problem was first identified by a customer. It took me a while to understand what was and was not happening.
When one reads the info on the dialog boxes in the LokProgrammer software, it is easy to think you are doing it right.
It is simply an honest mistake made by countless users and performed repeatedly a thousand times over.
