Adrian Olsen Posted January 22 Share Posted January 22 (edited) I’ve recently bought a new ESU Decoder Test-Board. I have been trying to (re)programme and/or reset several previously used ‘Rails’ Decoders (made by DDC Concepts), both 8 and 21 pin versions. My Command Station is a Digitrax DSC210+ with a DT602 Controller. I am reasonably familiar with DCC and its workings. I’m not a newcomer or novice. Now, here’s the problem. 1. When testing the said decoders on the ESU Test-Board for normal running (on the main), they all work fine. The controller’s commands are activated by the decoder, with the Test-Board motor running and the Function lights illuminating, all as expected. Write commands are actioned too (in POM mode). 2. HOWEVER, when I then switch to Programming Mode (with an appropriate switch of power leads from the command centre) and then attempt to Read/Write any of the CVs, the motor just runs at top speed, all the Function lights come on, and the CVs won’t read or write. It’s all very strange, not least given the significantly reduced voltages used in Programming Mode. 3. When I try exactly the same Programming exercise on a borrowed dRM Test-Board, no issues. Read/Write executed with no problems. So my questions are thus: 1. Can the ESU Test-Board only be used for programming ESU decoders? 2. Has anyone else experienced the same issue? 3. Is there any reason why an ESU Decoder Tester would NOT work with a Digitrax Command System? Any thoughts or comments welcome, with thanks. Edited January 22 by Adrian Olsen Link to post Share on other sites More sharing options...
WIMorrison Posted January 22 Share Posted January 22 A DCC signal is a DCC signal and whilst the quality of the signal varies between manufacturers it is still a DCC signal. I use an ESU decoder tester board with a Z21 and an old DR5000, and I haven't yet found a decoder that I haven't been to test and reprogram using the ESU board. Link to post Share on other sites More sharing options...
jaym481 Posted January 22 Share Posted January 22 As far as I know, and in my experience, the board is agnostic. I haven't used Digitrax kit, so I can't speak to it, but I've used Z21, NCE and now Sprog with the board and haven't observed any issues as you describe. Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 23 Author Share Posted January 23 (edited) Thanks for your relplies. Yes, this remains a mystery at present. I’m totally baffled by the behaviour of these decoders on the ESU Board. More investigation needed. Edited January 23 by Adrian Olsen Link to post Share on other sites More sharing options...
RMweb Premium Steven B Posted January 23 RMweb Premium Share Posted January 23 (edited) There's no obvious reason it shouldn't work with the Digitrax system. I've got an ESU decoder tester (51900? - previous version without Next18) and it works fine with either a Sprog or Digitrax Zephyr DCS52. The decoder tester provides an interface between the decoder socket (or wires) and the motor & LEDs fitted to the test board. As long as the decoder follows the standards it should work. Does the runaway motor issue happen with all decoders or just certain types or certain socket types? Are you able to try the ESU Decoder Test-Board with another DCC system? Steven B Edited January 23 by Steven B Link to post Share on other sites More sharing options...
RAF96 Posted January 23 Share Posted January 23 (edited) No x 3. You don't say which decoder pin configuration is at fault. Have you got the decoder in the socket correct way round. Check the sockets for stray or missing solder traces. I saw an advert which said the board had a coreless motor - is this significant. My boards all have normal motors. Edited January 23 by RAF96 Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 23 Author Share Posted January 23 (edited) 5 hours ago, Steven B said: There's no obvious reason it shouldn't work with the Digitrax system. I've got an ESU decoder tester (51900? - previous version without Next18) and it works fine with either a Sprog or Digitrax Zephyr DCS52. The decoder tester provides an interface between the decoder socket (or wires) and the motor & LEDs fitted to the test board. As long as the decoder follows the standards it should work. Does the runaway motor issue happen with all decoders or just certain types or certain socket types? Are you able to try the ESU Decoder Test-Board with another DCC system? Steven B Thanks Steven This motor runaway is happening with both 8 and 21 Pin RAILS decoders (made by DCC Concepts), indeed several of each ! I’ve also ensured that they’re connected to the Board the correct way around, so I don’t think that’s the cause. Indeed, when I run them ‘on mainline running’, they behave perfectly, its only when I try to READ the CVs in the Programming Mode (with the programming wires connected) that the runaway happens……as I say, its all very odd. I haven’t yet been able to try it on another DCC system, but that’s my next step. For the record my Test-Board is the 53900 version. Edited January 23 by Adrian Olsen Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 23 Author Share Posted January 23 (edited) 2 hours ago, RAF96 said: No x 3. You don't say which decoder pin configuration is at fault. Have you got the decoder in the socket correct way round. Check the sockets for stray or missing solder traces. I saw an advert which said the board had a coreless motor - is this significant. My boards all have normal motors. Thanks Rob, see my reply to Steven, above……. Someone else has mentioned the ‘coreless motor’ issue to me too, but then why would they run successfully when I switch them from Programming Mode to Normal Running Mode? I’ve also posted a question on the ESU Forum…..I’ll report back if I get anything from there. Edited January 23 by Adrian Olsen Link to post Share on other sites More sharing options...
WIMorrison Posted January 23 Share Posted January 23 Are you using Railcom? If you are not (and I suspect you are not because DCC Concepts do not support it) then I suggest you ensure it is switched off in the Z21. Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 23 Author Share Posted January 23 2 minutes ago, WIMorrison said: Are you using Railcom? If you are not (and I suspect you are not because DCC Concepts do not support it) then I suggest you ensure it is switched off in the Z21. No, Railcom not involved. I’m not using the Z21 either…my DCC system is Digitrax (DSC210+) 1 Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 23 Author Share Posted January 23 To provide a bit more explanation, I attach three photos featuring a RAILS 21 Pin decoder. The one on the left (showing Loco Address 3) is plugged into the Digitrax DCS Mainline connections. It is running perfectly, with the motor responding to controller commands. The middle photo is trying to read CV8 with the Programming connections attached to the ESU Board. As you can see, all the Function lights are illuminated, but what you can’t see (but is happening) is that the motor is running at max revolutions! Then the Read procedure times-out with an error message and no CV reading. Finally, the photo on the right is using exactly the same Read procedure but on my friend’s drM Test-Board. Result, a successful reading of CV8, reporting 36 (DCC Concept’s NMRA Code). As I say, all very odd, and not a little frustrating! Link to post Share on other sites More sharing options...
RMweb Premium JimFin Posted January 23 RMweb Premium Share Posted January 23 Maybe something wrong with the power in when using the programming connection - only one of the power LEDs is lit. Link to post Share on other sites More sharing options...
Nigelcliffe Posted January 23 Share Posted January 23 Its a puzzle. I have the earlier form of the ESU board, and that works perfectly on anything I've tried, which includes older Digitrax systems. One random thought, what happens if the track leads are swapped red-for-black ? It could be something odd about how the commands arrive at the decoder and how they are interpreted. - Nigel Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 24 Author Share Posted January 24 (edited) Ok, this MYSTERY SOLVED. Nigel’s suggestion came up trumps! I switched the polarity of the Programming leads into the Test-Board, and bingo! All fine now. 😃👍🏼 What’s strange is that I understood that Test-Boards were polarity agnostic. Anyway, all’s now well, and the decoders are now being Read with ease ! Thanks to all for the input (especially Nigel 👏👏👏) Edited January 24 by Adrian Olsen 2 2 Link to post Share on other sites More sharing options...
Nigelcliffe Posted January 24 Share Posted January 24 Glad its working again. Yes, things shouldn't be polarity dependent, but in this case it seems there is. Now, to try another test on the previously working drM Test-Board - does that misbehave with the decoders with the input wires reversed ? - Nigel Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 24 Author Share Posted January 24 I’ll try that and let you know, Nigel….stand by…… thanks again for the tip. it certainly wouldn’t have occurred to me to try it ! 😳 Link to post Share on other sites More sharing options...
NIK Posted January 24 Share Posted January 24 Hi, Your photo doesn't show what the wires coming out of the decoder to the left are connected to. What are they connected to?. Normally if the decoder is connected only to the decoder tester I would not expect the polarity of the DCC input to the tester to matter. The motor running at full speed is often a symptom of the decoder being in DC compatibility mode and mistaking DCC for DC. Regards Nick Link to post Share on other sites More sharing options...
Adrian Olsen Posted January 25 Author Share Posted January 25 Hi Nik, the problem was solved by swapping the polarity of the programming wires coming out of the DCC Command Station. I’ve no idea why that fixed it (I thought test-boards with polarity agnostic), but it did and all now working well Link to post Share on other sites More sharing options...
RMweb Premium Steven B Posted January 25 RMweb Premium Share Posted January 25 It'd be interesting to try the decoder fitted into a loco on a programming track to see if the polarity issue is linked to the decoder or the test board. Steven B Link to post Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now