NCE Bachmann board replacement decoder odd issue?

Model Railroader Electronics and DCC
1

I received (second hand) a Bachmann GP38-2 (HO scale) locomotive that included the NCE DCC Bachmann board replacement decoder (Not the Bachmann DCC Onboard unit) that has a puzzling issue. It would not respond at all to the long (4 digit) address. (2 digit address had full control.)

I did the NCE factory reset, reprogrammed the decoder long address to the cab number, and reprogrammed the lighting to include rule 17 (dimmable) front light and seprerately controlled rear light. Got confirmation that the programming took, and tested the unit on the main… And got zero response to the long address. Short address (03) worked, but with the lighting correctly programmed - Rule 17 front, rear controlled seperately by F1… When I placed the loco on my programming track, the address read back as long 5814 (Cab number.)

So, I reprogrammed CV29 to be long address, 28/128 speed step mode, analog off, with customizable speed tables. (To upload values from my other 4 axle units via Decoderpro, to attempt to speed match them.) No zero response from short address. Lighting responded correctly to long address, but I lost all motor control. (Accel/Decel was not active yet, programmed at “0”)

So, Factory reset number 2.

Reprogrammed long address, and lighting (Again). Again long address zero response, but “03” full control, with correct lighting. Address read back was again the long address 5814. Zero response on long address, but short address full control, including motor. So, I again reprogrammed CV29, and lost all motor control, and lighting would respond on long address only.

So, factory reset 3.

Reprogrammed all the same, save for this time I did CV29 as Long address, 28/128 speed step, analog off, factory speed table, and reprogrammed both long and short addresses. (5814, read back fine, and 14, read back fine.) No

2

Other than CV29 not getting set automatically, everything else seems exactly as it should. The first time you tried setting CV29 manmually you set it to use a speed table which had not been loaded yet. So likely all values were 0. Loco won’t move. When you redid it to not use a user speed table, then it worked fine.

The only puzzler is why CV29 is not getting set. What DCC system do you use? Are you correctly responding to the prompts to configure the loco for long address?

–Randy

3

Digitrax Zephyr Xtra with a Locobuffer II to use DecoderPro.

Thats why I am really puzzled over the whole issue…

I might try it with my PR3 in stand alone mode instead.

4

This may be a case of the Zephyr being too fast again - happens with QSI too. I use to have plenty of NCE decoders, they were my go-to decoders for my fleet since they were like $11 each in packs of 10. Never had a problem programmign them, but by the time I was putting DCC in more of my locos, I had a DT400 throttle to use with my Zephyr and that solved the setting of CV29 with QSI decoders, and so maybe I just never noticed the same problem with NCE decoders. On a DT40x throttle, after you put in a 4 digit address the throttle then prompts for a yes/no to activate the 4 digit address, only after you press Y does it send the value for CV29, so there is plenty of delay. Using the Zephyr console, Once you start down the Ad4 path, you put in the address you want to use and it bang bang programs CV17, CV18, and CV29. I suspect this causes problems with some decoders. When I first got my Zephyr, I got a few Digitrax decoders, the board replacements for P2K locos since those were the first ones I wanted to try. No issues setting them up with just the Zephyr. Later on I had a new QSI loco and it wouldnt take a long address, everyone said it was just the lack of power ont he program track, but after some fiddlign around I discoverd CV29 not getting the proper value. So I tried setting a 4 digit address, and then before taking the loco off the program track, manually set CV29 to the correct value - and it worked.

The thing is. JMRI emulates a throttle. So it ought to be pushing out the correct value for CV29. Since everything works on address 3 - are you setting the right boxes in JMRI to make the long address active? After you write it for the first time, read it bac and see if the buttons change back to short address - if so, just set it to long address and write changes (not the full sheet).

–Randy

5

Could be it’s just setting things quicker than the decoder can handle… As the thing that tipped me off was the long address would read back, so I started down the “read everything” path and noticed a low number in CV29, and figured it out that CV29 wasn’t setting for some reason. Once I reset CV29, I started down the no motor control path… So I knew something was certainly going wacky now.

The thing that was really puzzling was my normal procedure is to write, then read back to see if the changes took. (Once I had one programming not take on a loco, and spent over an hour troubleshooting it, when it just didn’t take the full programming and just needed a couple CV’s done. I think it had actually timed out though…) The read back was the new 4 digit address, yet it wouldn’t respond to this out on the main until I manually changed CV29…

I will attempt to change the speed tables and report back, and hopefully, just going one CV step at a time, it will take it.

Just so long as it will work, no harm no foul I guess. Just still seems odd…

Coincidentally, I have never had a problem with QSI programming, but I have always used DecoderPro for programming… So I never had experienced the “too fast” issue.

6

The second aprt of your issue, with the speed tables, is, as I mentioned in my first reply, perfectly normal behavior. If you set CV29 to use a user defined speed table but you’ve not loaded one in, it won’t default to the “no speed table” setting, it will blindly do what you told it to do and try to follow the user defined speed table. Which after a decoder reset is probably all 0’s. I would expect it to behave exactly as it did.

The only other thing I can think of, since CV29 isn;t getting set, it that there is a mistake in the decoder definition file such that you are picking the options for long address but DP is setting it for short address. You could possibly try selecting a different NCE decoder like a D13SR and using that - they are all pretty much the same other than number of functions, plus for the basic stadard NMRA CVs like 17, 18, and 29 ANY decoder will be the same - another option, pick something from a different manufacturer, like TCS. Just read and write the basic page, not the full decoder - definitely don’t do Write All with a different brand decoder selected or you will have to end up resetting the NCE again.But just the Basic pane, with the short and long address and active address selection, is the same for ANY decoder. Or should be - 1, 17, 18, and 29 are all strictly defined by the NMRA standard. It may all turn out to be a simple bug in the BACH-DSL definition in JMRI.

–Randy

7

Well, it seems to be working… Went just one speed step at a time, and it seems to have taken.

I think what threw me off the most was the whole having to change CV29 Manually thing, as I have always just changed address, speed tables, accel/decel, disable analog and let decoderpro put in the correct CV29 value, which for some odd reason (too quick?) didn’t work this time…

Thanks Randy!