ScaleTrains Standard Turbine Tender Programming Problems

[robert3985]

Okay...I've spent the last three hours attempting to get the tender-mounted backup light working on my ScaleTrains Standard Turbines, reading and re-reading the included manual, which states NOTHING about programming the tender, just about how to turn off the engine's backup light if you're running a tender.

I've also gone online and located one short YouTube video about how to program a ScaleTrains GTEL Turbine Tender, but plain ol' programming doesn't work on any of my seven tenders.

I've tried running the engines with tender attached with the factory address of "03" or "3"...no tender backup light.  I've tried giving the tenders a new, two digit address...on my programming track where it says the programming was successful...but the light still doesn't work.

I then reset the tender back to factory default in case I'd done something wrong, tried it again on address 3...nothing.  I tried acquiring it as a locomotive using both 3 and its two-digit new number...nothing.

Spookshow and several other reviewers state that the tender indeed has a decoder in it, but never say how or if they programmed it.

And, I tried programming new addresses into both engine and tender at the same time...and that didn't work either.

Instructions say to use "Paged Mode" for programming, but I got no results on the tender using Paged Mode, or with Direct Mode.  I got confirmation of both resetting the tender back to factory default and its new addresses using Physical register mode....Ph...but it still didn't work. I also tried Ops Mode, which also gave me confirmation of the address changes, but still no backup light.

I am at the end of my rope soooo...if anyone has their Scaletrains Standard Turbine Tender's backup light programmed and working...I would sure like to know how ya did it!

I'm using Digitrax with a Soundtraxx Programming Track Booster on my programming track.

I'm posting this at "Product Discussion" also, where I thought it might get more reads than here.

Thanks in advance...

Bob Gilmore

[peteski]

Tender in this model uses ESU LokPilotFX (function only) decoder.  Due to the fact that these do not have the appropriate load connected to their AUX outputs (like a motor) for generating the ACK current pulse, they cannot be read out on programming track, and are also difficult/impossible to program using programming track on some DCC systems.  This is true of any brand function-only decoders.

The way to deal with this problem is using an unsupported method of programming.  Place the tender *AND* one of the locomotives together on the  programming track, then program the address and/or any additional CVs.  But remember, while you can program, you cannot read the FX decoder's CV. Well, while the command station will likely read CVs in that setup, they will be read out from the locomotive (not the tender).

I'm really surprised that when you tried the above method, it did not work for you. I have used it on NCE and CVP systems (and I think it also worked on Digitrax, but I don't use that system often).

OPS (main line) programming is one-way communication (only from command station to the decoder).  No feedback or acknowledgement of the process is possible).  The command station simply tells you that it blindly sent the packet out to the address you told it to use.

There should be a decoder in those tenders.  One thing to try is to observe the tender's light while lifting one side of the tender and placing it back on the powered track).  As you connect power to the tender, the light might flash very briefly.  Or if I recall, these are setup to support analog (DC) mode.  Connect a 9V battery to the tender wheels to supply power, the light should light up when the positive terminal of the battery is on the left side wheels (which would be the polarity when traveling in reverse).

As for the duplicate thread in the other forum section, seems like this is the better place for that type of question (regardless on the eyeball count). not sure why some members seem to do this.   This is a very specific DCC related question and problem.

[ridinshotgun]

Tender in this model uses ESU LokPilotFX (function only) decoder.  Due to the fact that these do not have the appropriate load connected to their AUX outputs (like a motor) for generating the ACK current pulse, they cannot be read out on programming track, and are also difficult/impossible to program using programming track on some DCC systems.  This is true of any brand function-only decoders.

The way to deal with this problem is using an unsupported method of programming.  Place the tender *AND* one of the locomotives together on the  programming track, then program the address and/or any additional CVs.  But remember, while you can program, you cannot read the FX decoder's CV. Well, while the command station will likely read CVs in that setup, they will be read out from the locomotive (not the tender).

I'm really surprised that when you tried the above method, it did not work for you. I have used it on NCE and CVP systems (and I think it also worked on Digitrax, but I don't use that system often).

OPS (main line) programming is one-way communication (only from command station to the decoder).  No feedback or acknowledgement of the process is possible).  The command station simply tells you that it blindly sent the packet out to the address you told it to use.

There should be a decoder in those tenders.  One thing to try is to observe the tender's light while lifting one side of the tender and placing it back on the powered track).  As you connect power to the tender, the light might flash very briefly.  Or if I recall, these are setup to support analog (DC) mode.  Connect a 9V battery to the tender wheels to supply power, the light should light up when the positive terminal of the battery is on the left side wheels (which would be the polarity when traveling in reverse).

As for the duplicate thread in the other forum section, seems like this is the better place for that type of question (regardless on the eyeball count). not sure why some members seem to do this.   This is a very specific DCC related question and problem.

Well that is strange because my sprog will read the decoder in the tender without a loco on the track.  It reads it as some unknown to me brand of decoder and I can't write any CVI.  Lokprogrammer won't read it at all by itself so next time I have it out I will see if I can at least reprogram it with a loco on the rack at the same time.

[robert3985]

Tender in this model uses ESU LokPilotFX (function only) decoder.  Due to the fact that these do not have the appropriate load connected to their AUX outputs (like a motor) for generating the ACK current pulse, they cannot be read out on programming track, and are also difficult/impossible to program using programming track on some DCC systems.  This is true of any brand function-only decoders.

The way to deal with this problem is using an unsupported method of programming.  Place the tender *AND* one of the locomotives together on the  programming track, then program the address and/or any additional CVs.  But remember, while you can program, you cannot read the FX decoder's CV. Well, while the command station will likely read CVs in that setup, they will be read out from the locomotive (not the tender).

I'm really surprised that when you tried the above method, it did not work for you. I have used it on NCE and CVP systems (and I think it also worked on Digitrax, but I don't use that system often).

OPS (main line) programming is one-way communication (only from command station to the decoder).  No feedback or acknowledgement of the process is possible).  The command station simply tells you that it blindly sent the packet out to the address you told it to use.

There should be a decoder in those tenders.  One thing to try is to observe the tender's light while lifting one side of the tender and placing it back on the powered track).  As you connect power to the tender, the light might flash very briefly.  Or if I recall, these are setup to support analog (DC) mode.  Connect a 9V battery to the tender wheels to supply power, the light should light up when the positive terminal of the battery is on the left side wheels (which would be the polarity when traveling in reverse).

As for the duplicate thread in the other forum section, seems like this is the better place for that type of question (regardless on the eyeball count). not sure why some members seem to do this.   This is a very specific DCC related question and problem.

Thanks Peter @peteski   I've sorta got the problem solved in that by giving the locos and tenders their new addresses while coupled together on my programming track, all but one of my six turbines now have working back-up lights on the tenders.  I don't know what the problem is with the one that won't work yet, but I'll spend some time trying to figure that out in the next couple of days when I've got some extra time.

Cheerio!
Bob Gilmore

[peteski]

Thanks Peter @peteski   I've sorta got the problem solved in that by giving the locos and tenders their new addresses while coupled together on my programming track, all but one of my six turbines now have working back-up lights on the tenders.  I don't know what the problem is with the one that won't work yet, but I'll spend some time trying to figure that out in the next couple of days when I've got some extra time.

Cheerio!
Bob Gilmore

Glad to hear you got the issue mostly resolved.  As for the one that you have problem with, did you happen to test it while it was still factory programmed with its address, and noticed if the backup light on the tender worked or not?

The other test I suggested was using a 9V battery to see if the tender light would work in DC mode.

If you don't know if it was working fresh out of the box, then the decoder could just be defective.

[peteski]

Well that is strange because my sprog will read the decoder in the tender without a loco on the track.  It reads it as some unknown to me brand of decoder and I can't write any CVI.  Lokprogrammer won't read it at all by itself so next time I have it out I will see if I can at least reprogram it with a loco on the rack at the same time.

Sprog or not, I would not trust anything *ANY* DCC system thinks it reads from a function-only decoder with insufficient electrical load on the functions. As you noticed, the results seem to be unpredictable.  I also have no reason to doubt that it is an ESU decoder. Why would they put a different brand of a decoder in the tender?  Seems not very feasible.

[ridinshotgun]

Sprog or not, I would not trust anything *ANY* DCC system thinks it reads from a function-only decoder with insufficient electrical load on the functions. As you noticed, the results seem to be unpredictable.  I also have no reason to doubt that it is an ESU decoder. Why would they put a different brand of a decoder in the tender?  Seems not very feasible.

I would say that it is entirely possible that they did especially if you see over in the other thread on this that they admit to looking for a solution to supply chain problems that resulted in them using a replacement board that didn't work as they hoped.  I can very well see it as a cost cutting maneuver and toss in some of the ESU issues I'd say likely hoping no one would really notice.  I mean it only has one function to control a light so they cheaped out.