I-M SD40-2 Decoder Info

[jrbernier]

  One of our club members just purchased an I-M SD40-2.  The provided info states that it has an ESU-Lok Sound decoder.  Looking at the current JMRI/Decoder Pro info, what decoder definition file is for that engine?  I tried the 645E file, but the download to the engine hung up.  I eventually got it loaded, but the engine runs poor in MU with other engines.  I reset it back to the default address 3 and if performs great.

  I looked at the I-M site this morning, but the web page is not available(404 error).

Jim

[cacole]

Forget Decoder Pro.  If a decoder reset corrected problems with the decoder, just program a new address and you should be good to go.

None of the sound files were changed when you did the reset, only the address.

Without a LokProgrammer you're not going to be able to do much more with it.

 

 

[Mark R.]

You can do all the basic settings for a Loksound decoder that you can do with any other decoder (address change / accel / decel / etc.). If you are attempting to do function mapping and other more elaborate settings, you will have to learn them (like any other decoder) from the manual. Funny how so many people have the assumption you HAVE to have the lokprogrammer to do anything with these decoders. Not at all true .... but it does make things much simpler ....

I'd be surprised if the IM file was listed in JMRI as it is a proprietary file made exclusively for IM for that engine. Although the sound file itself is identical to the regular production file, it is configured differently in how a number of the features work.

Mark.

[rrinker]

 While probably not worth it for one or two decoders, since I am using only Loksound for sound from here on out, a Lokprogrammer was a worthwhile investment. Also since you can read or write the entire decoder in a few seconds - the Lokprogrammer talks to the decoder with a proprietary method, whereas JMRI is limited to NMRA protocols. Even with 500 CVs - that's only 500 bytes of data and even with a realtively slow bit rate it doesn't take long But the standard DCC methods more or less involve the programmer asking the decoder if the value for a CV is a certain value, and the decoder responds or not. Then it tries the next value, and so on. This is where Direct Bit mode, when supported, is MUCH faster, because at most you only have to 'ask' 8 times per CV, while with Byte mode, you might have to 'ask' 256 times per CV. Times 500+ CVs and you can see how this might take a while - and that's not counting any overhead of indexed CVs or anything. You can also see how this is not an effective method for loading realtively large elements like sound files to the decoder - so far, all the ones that support user loading of sound files each has their own proprietary method of communication.

                             --Randy