Loksound Select Micro issue

[GM50 4164]

I'm in the process of installing a select micro in a locomotive and as I go though the install process, I check for shorts along the way. I had just soldered the motor contacts and rail contacts and wanted to test the unit. Unit does not operate on address 03. I've reset the decoder and still nothing. I've tried reading the decoder's info using Lokprogrammer but after about 4 minutes I get a error stating, "The detected decoder is not supported". Any suggestions folks? I've left the wrapper on but did cut a slit allowing me to removed the violet wire.

One thing to note is that while it is trying to read the info from deocder, the motor will spin multiple times before receiving the error message.

This is a brand new decoder.

[peteski]

I'm in the process of installing a select micro in a locomotive and as I go though the install process, I check for shorts along the way. I had just soldered the motor contacts and rail contacts and wanted to test the unit. Unit does not operate on address 03. I've reset the decoder and still nothing. I've tried reading the decoder's info using Lokprogrammer but after about 4 minutes I get a error stating, "The detected decoder is not supported". Any suggestions folks? I've left the wrapper on but did cut a slit allowing me to removed the violet wire.

One thing to note is that while it is trying to read the info from deocder, the motor will spin multiple times before receiving the error message.

This is a brand new decoder.

Interesting.  seeing the motor "twitch" while the decoder is being read to me indicates that the decoder is alive and it is "talking" back to the programmer.  Those twitches are caused by the decoder's processor energizing the motor for a split second to generate current draw which acknowledges the request it received from the programmer.  I would say that is normal.

Can the Lokprogrammer be used to just read various CV values out of the decoder (or any generic decoder)?  Try that. Or use your DCC system's programming track and read some CVs. Checking the values of CV8, CV29, and CV1 would be a good start.  Also, does the loco run on DC (with the decoder installed)?   A regular 9V battery is perfect to check that functionality.

[GM50 4164]

I did try a 9volt and it did make the motor spin. However, I do believe I'm capable in reading back what the CV's are. I'm using a older DB150 Empire Builder. I use a PR3 to interface with my netbook. JMRI is my go to for programming decoders. I have a toggle switch that can switch this setup to my Lokprogrammer. Using JMRI, I can start a programming activity and type in the engine number I want to assign to the motor but upon writing, the motor doesn't spin like its getting the info. PR3 is set to programming mode btw.

What should CV's 1, 8 and 29 be set to and I can attempt to write them using my throttle?

Thanks for your help. Really has me baffled.

[crusader27529]

The LOK Programmer doesn't cause the motor to twitch when reading CVs, as it doesn't use the motor current as a feedback mechanism.......it communicates directly to the decoder when reading the data from an ESU decoder.

I've no answer as to why the motor is twitching when you use the LOK Programmer to read CVs.

[jdcolombo]

Try this.

Disconnect the decoder from you engine.  Now connect the power leads (red and black wires) directly to the track output on the LokProgrammer.  If you have to, temporarily solder some extension wires to the decoder power wires (I use 2'-long wires with alligator clips at both ends for this kind of thing, but if you don't have something like this, just solder some wire to the black and red leads however long you need to get to your LokProgrammer).

Now see if the LokProgrammer reads the decoder type correctly.

I have gotten this message before, and it always has been the result of the LokProgrammer not correctly communicating with the decoder.  Usually it is because of some electrical connection glitch between the programmer and the decoder.  You don't need a motor load to program a LokSound; if the decoder is alive, then direct connection to the LokProgrammer should permit it to communicate correctly with the decoder.

It sounds to me like the decoder is "alive" but its firmware or software file may be corrupted.  If you can get the LokProgrammer to recognize the kind of decoder you have, then you can do a firmware update, and then reinstall your sound file with decoder defaults from scratch.   You may be able to "force" a firmware update, but I'm not sure how to do this.

John C.

[AKNscale]

Usually when I've seen this message it's the red and black power leads. Normally after I play with the power wires it fixes the issue. And yes, I will have the same twitch before the error message.

[GM50 4164]

Its just very odd as I have the power wires clipped and going straight to the track power.

[peteski]

I did try a 9volt and it did make the motor spin. However, I do believe I'm capable in reading back what the CV's are. I'm using a older DB150 Empire Builder. I use a PR3 to interface with my netbook. JMRI is my go to for programming decoders. I have a toggle switch that can switch this setup to my Lokprogrammer. Using JMRI, I can start a programming activity and type in the engine number I want to assign to the motor but upon writing, the motor doesn't spin like its getting the info. PR3 is set to programming mode btw.

What should CV's 1, 8 and 29 be set to and I can attempt to write them using my throttle?

Thanks for your help. Really has me baffled.

The CV readout in a DCC programming track was recommended to check whether the decoder is still "sane".
CV8 would be the manufacturer's ID , CV1 should be 3 and CV 29 would most likely be 2 or 6 (if the decoder was reset recently).

I just recently picked up the Lokprogrammer (delivered couple of days ago - I still have not had time to set it up).  As far as the motor twitching goes, I assumed that Lokprogrammer would use the same CV reading method as other DCC systems (in programming track mode).  But according to the other posts, that is not the case. So I don't know why the motor twitched.  Maybe if it cannot properly communicate with the decoder using the proprietary method, it reverts to using the standard programing track programing mode (with twitches).

When I upgrade the sound decoder firmware or upload sound files I prefer not to depend just on the wheel-to-track electrical contact. I use wire jumpers to solidly connect the programmer's output to the decoder's track pads (or the loco chassis).  That way I minimize chances of something going wrong (which could render the decoder useless).

[AKNscale]

Mine has always twitched briefly in the beginning when reading/programming decoders.

[peteski]

Mine has always twitched briefly in the beginning when reading/programming decoders.

Maybe in the beginning of decoder identification the programmer uses  the standard CV reading method (which needs motor load for acknowledgment pulses), then once the decoder is identified as an ESU decoder, the other communication method kicks in?

[RBrodzinsky]

Maybe in the beginning of decoder identification the programmer uses  the standard CV reading method (which needs motor load for acknowledgment pulses), then once the decoder is identified as an ESU decoder, the other communication method kicks in?

I think this may be correct. I always use the LokTester / LokProgrammer combination to test each decoder and load the sound project before ever committing the decoder to the install.

[jdcolombo]

Mine has always twitched briefly in the beginning when reading/programming decoders.

Yes, this is correct.  The motor will pulse briefly, then stop.  There is no motor pulsing when you program a sound file into a decoder. But I don't think you need a motor connection to program a decoder with a LokProgrammer.  I'm trying to remember if I've done this without a motor connection - I've have directly connected the red/black wires to the programmer before, but now I can't remember if I still had the motor connected or not.  I bought the LokTester about a year ago, and now I do what Rick does - connect the decoder to the tester with the 8-pin plug; program; check to see if it operates correctly, THEN cut off the plug and hard wire.

John C.

[peteski]

The motor is simply uses as an electric load  (like a resistor which draws the most current on the decoder) when acknowledging commands coming from the DCC command station or from the programmer (when using a standard DCC programming track program mode). Some decoders also briefly turn on all the function outputs to maximize the load.  But this type of communication is very slow. Good enough for programming single CV registers.

When uploading firmware or sound files, those are much larger chunks of data (in Megabytes). At that point it make sense to use some proprietary (probably bi-directional) protocol for communication over the power (track) connections.   Then Zimo decoders also have another high-speed bus (SUSI) which can be utilized for uploading sound files to decoders.  In that scenario the track connections are used just power supplying power to the decoder.

[AKNscale]

Yes, this is correct.  The motor will pulse briefly, then stop.  There is no motor pulsing when you program a sound file into a decoder. But I don't think you need a motor connection to program a decoder with a LokProgrammer.  I'm trying to remember if I've done this without a motor connection - I've have directly connected the red/black wires to the programmer before, but now I can't remember if I still had the motor connected or not.  I bought the LokTester about a year ago, and now I do what Rick does - connect the decoder to the tester with the 8-pin plug; program; check to see if it operates correctly, THEN cut off the plug and hard wire.

John C.

I'm pretty sure you're correct about that John. I believe that when you program a sound file that it reads off of the decoder first, hence the quick twitch in the beginning sir.