Just made my first (failed) attempt to program a loco with JMRI Decoder Pro. Not sure if my problem was something I did wrong or if the problem was the Bachmann loco.
When I tried to pick a decoder, I assumed it was a Bachmann E-Z Command so when I selected that on menu, it gave me three choices (1, 2 or 4 function decoder). Nothing in the Bachmann literature said which was installed so I selected the 4 function. The JMRI files indicated all was well but after writing the files, the loco did not respond to the new address I gave it. However, it did continue to respond to the factory 03 address.
I went back and tried to read the decoder info via JMRI and it said the decoder was a "Massoth Elektronik GmbK" (mfg 123) and added a note saying that no info was available for that decoder. I messed around with it anyway but never got anything to work for changing the loco address.
Is it me or the strange decoder? Anyone have a fix for this?
Paul D
N scale Washita and Santa Fe RailroadSouthern Oklahoma circa late 70's
PED Just made my first (failed) attempt to program a loco with JMRI Decoder Pro. Not sure if my problem was something I did wrong or if the problem was the Bachmann loco. When I tried to pick a decoder, I assumed it was a Bachmann E-Z Command so when I selected that on menu, it gave me three choices (1, 2 or 4 function decoder). Nothing in the Bachmann literature said which was installed so I selected the 4 function. The JMRI files indicated all was well but after writing the files, the loco did not respond to the new address I gave it. However, it did continue to respond to the factory 03 address. I went back and tried to read the decoder info via JMRI and it said the decoder was a "Massoth Elektronik GmbK" (mfg 123) and added a note saying that no info was available for that decoder. I messed around with it anyway but never got anything to work for changing the loco address. Is it me or the strange decoder? Anyone have a fix for this?
Hard to say, but you should be able to change the locomotive address, no matter the decoder manufacturer. More information about your setup would help: what version of JMRI? What command station do you have? How is it connected to your computer?
Gary
JMRI is 4.10 (latest)
Digitrax DCS240 connected via USB
I have used JMRI on line with other stuff so I know the connection is working.
When I read the decoder and saw who the Mfg was (Germany with links to LGB), it told me the mfg was valid but JMRI would not offer any way to move frward since it did not have any info on the decoder.
I have been following the Bachmann forums for some years and the last I knew, Bachmann non sound on board are low end Lenz and problems at times. Sound are SoundTraxx which you do not have.
Sorry not much help. Many replace these decoders.
NCE went as far as producing the Bach-DSL decoder to replace this decoder. A much better decoder. About twenty dollars the last I knew.
https://www.modeltrainstuff.com/nce-524139-bachdsl-replacement-decoder-for-bachmann-dcc-equipped-diesels/
Rich
If you ever fall over in public, pick yourself up and say “sorry it’s been a while since I inhabited a body.” And just walk away.
Thanks. Will not be able to get to it until tomorrow. According to the Digitrax app, my CV29 should = 34. Hopefully that does the trick.
I have a link somewhere from the Bachmann forums that a company rep said to clip a 1k resistor across the rails when using a Digitrax DCC system for programming. A couple others there said the same but the answer you got already may work.
richg1998I have a link somewhere from the Bachmann forums that a company rep said to clip a 1k resistor across the rails when using a Digitrax DCC system for programming.
PED When I tried to pick a decoder, I assumed it was a Bachmann E-Z Command so when I selected that on menu, it gave me three choices (1, 2 or 4 function decoder). Nothing in the Bachmann literature said which was installed so I selected the 4 function. The JMRI files indicated all was well but after writing the files, the loco did not respond to the new address I gave it. However, it did continue to respond to the factory 03 address. I went back and tried to read the decoder info via JMRI and it said the decoder was a "Massoth Elektronik GmbK" (mfg 123) and added a note saying that no info was available for that decoder. I messed around with it anyway but never got anything to work for changing the loco address. Is it me or the strange decoder? Anyone have a fix for this?
I have two suggestions:
1) Check your DecoderPro connection preferences for anything marked as "internal" and change them to point to your command station. That should correct the mfg 123 issue, as well as the failure to properly program the decoder.
2) Let DecoderPro try to identify the decoder type instead of manually selecting it. That won't necessarily help to correctly identify the specific decoder model, because of the way many manufacturers handle their decoder firmware, but it should at least get you in the ballpark.
I did some more reading on use of Decoder Pro and I think I might have some answers. I tried to program on the main since I did not have a programming track set up yet. Apparently some decoders will not work that way and require the use of the programing track. Also found some other settings I may not have right. Will fix all that and report back in a few days when I have a chance to deal with it.
Something else that would be helpful here, "Randy (rrinker) (shouting out loud) stop in please!"
Mike.
My You Tube
You can't read decoders on the main, not without Digitrax Transponding or Railcom. And those Bachmann DCC on-board decoders will have neither. Mst can be programmed on the main, but often the limitation is if the decoder currently has a short address, like default 3, you can program a long address on the main but not another short address. ANd vice-versa. Way around that is to program it twice. However, any decoder that does not do programming on the main at all - toss it, it is either ancient and so low featured you cna do much better.
Interesting response it gives when it can;t be read. Normally you would get either 0 or 255 for a CV that fails to read, and the NMRA has wisely not assigned either value to a manufacturer. Guess it worked out, the single CV manufacturer ID only leaves room for 253 manufacturers. At some point, someone thought that wasn't the greatest idea so they reserved 238 as indication there will be another CV to read to get the actual id.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinker Interesting response it gives when it can;t be read. Normally you would get either 0 or 255 for a CV that fails to read, and the NMRA has wisely not assigned either value to a manufacturer. Guess it worked out, the single CV manufacturer ID only leaves room for 253 manufacturers. At some point, someone thought that wasn't the greatest idea so they reserved 238 as indication there will be another CV to read to get the actual id. --Randy
Actually, having a decoder incorrectly identify as a Massooth is a known (and intended) situation when you have your JMRI connection preferences set to Internal or to a Simulator.
You can read that directly from one of the JMRI developers here. (It's a public archive so you don't need to be a member or sign in.)
That's why, in my earlier post, I suggested that the OP double-check his connection settings.
Note the posted reference that JMRI v.4.11.2 will have presumptively solved this? The OP indicated he thought v.4.10 was 'current' -- this suggests he ought to consider uploading.
i note also that user 'Stevert' correctly ID'd the issue as JMRI returning 'code 123' and not 'it's a German decoder' ,but did not mention why this was critical to the OP's troubleshooting. This is not a 'fault' but an observation that sometimes an obvious technical detail is not obvious to everyone concerned...
Uggh, if I cared enough about java I would recode that - you NEVER return potentially valid data in an error condition. That's is really bad programming - and not just my opinion, I think if you posted to any number of programming forums that this is the behavior of the application, you 'd get a similar response. If it's an error, return an error code. Simulator mode should just prompt to pick a decoder from the list, saying it is in simulator mode - no abiguities that way. Keeps everyone happy - someone mistakenly configuring simulator instead of a proper connection would ne notified of such as soon as they tried to read a decoder, and someone actually having a problem would get proper no response or not detected errors.
Guess I never tried to read in simulator mode, just picked the decoder I needed and then made the changes and grabbed the changed CVs.
Yes, I've been fairly down on JMRI recently, and there's a reason I'm writing my own code for my system (never know, could end up using JMRI if I get lazy). More 'stuff' gets added but things that really need to be fixed or improved are barely touched - they seem to have fallen into the same trap as many commercial programs, add more features! People want more features! Trying to use tools like the Layout Editor to do automation is an exercise in futility - you can;t make a mistake, because deleted objects still show up, or throw off the order of things. Yes, *I* can fix that by editing the XML - but I thought the whole point was to avoid stuff like that because most people are NOT programmers? I still come back to my failed attepmt to script automatic operation of just 2 trolleys on a friend's layout. Thwarted twice by the Layout Editor (3rd try I got all 16 blocks definite eithout an error) and then the false reads just kept killing the script. OK, it's just reporting what Loconet sees, and an old BDL-16 doesn;t work with high frequency drives. So they say - there appears to be a lot more sensor discretion in RR&CO because the same hardwad, on the same track - my friend (NOT a programmer) managed to get FIVE (not 2) trolleys running and automatically stopping before running in to one another. Why does the BDL-16 work reliable with the software is other than JMRI? Same decoders, all Lenz with PowerPacks crammed in somehow, because the things are SMALL and plus being N scale the contact isn't the best, samd old BDL-16. Maybe RR&CO has some intelligence built in, such that if blocks 1, 3, 5, and 7 are occupied it's pretty much impossible for the next occupied block to be 10.
Anyway, enough bagging on JMRI, there are plenty of good things it does. I just wish some of the long-standing components would receive some love and attention, but since it's an all-volunteer effort and fixing code that's been around for years is not 'fun' I can understand why working on new things happens more often.
Most of the things JMRI helps you with, like remembering tons of CVs, I've solved by using only 2 brands of decoders for my entire fleet.
All is OK on my end. Initially I noted that I tried to program the loco on the main. After all the comments, I went ahead and set up a programing track. Should have done that in the first place but I was in a hurry. Put the loco on the programming track and the JMRI DecoderPro application worked like a champ.When I read the decoder, it showed up as a Bachmann with the factory 03 address. I then changed the address to a different two digit address as a quick test and that worked. I then change the address to the 4 digit address I really wanted for that loco and it worked fine.
Really liking JMRI so far. Much easier to check on and program stuff like my DS64's and PM42's. I initially set them up with a throttle but when I read them via JMRI, I discovered several errors in my programming via the throttles. Easy fix via JMRI. Setting up routes via JMRI is next on my list.
Overmod Note the posted reference that JMRI v.4.11.2 will have presumptively solved this? The OP indicated he thought v.4.10 was 'current' -- this suggests he ought to consider uploading. i note also that user 'Stevert' correctly ID'd the issue as JMRI returning 'code 123' and not 'it's a German decoder' ,but did not mention why this was critical to the OP's troubleshooting. This is not a 'fault' but an observation that sometimes an obvious technical detail is not obvious to everyone concerned...
Actually 4.10 is the "current production" version and is recommended for new users like me. The 4.11.2 version is still in the test stage so I did not want to trip over any bugs so I stuck with the recommended version.