Subscriber & Member Login

Login, or register today to interact in our online community, comment on articles, receive our newsletter, manage your account online and more!

JRMI to program decoders

1772 views
16 replies
1 rating 2 rating 3 rating 4 rating 5 rating
PED
  • Member since
    April, 2016
  • 483 posts
JRMI to program decoders
Posted by PED on Tuesday, March 13, 2018 1:55 PM

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

Washita and Santa Fe Railroad
Circa late 1970's in south central Oklahoma

  • Member since
    November, 2005
  • From: St. Paul
  • 470 posts
Posted by garya on Tuesday, March 13, 2018 2:11 PM

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
PED
  • Member since
    April, 2016
  • 483 posts
Posted by PED on Tuesday, March 13, 2018 2:39 PM

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.

Paul

Washita and Santa Fe Railroad
Circa late 1970's in south central Oklahoma

  • Member since
    October, 2006
  • From: Western, MA
  • 7,829 posts
Posted by richg1998 on Tuesday, March 13, 2018 2:51 PM

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

N

  • Member since
    May, 2017
  • 13 posts
Posted by rrbnsf on Tuesday, March 13, 2018 3:09 PM
There are some issues with programing a Bachmann DCC On-Board with a Digitrax programing track, primarily in that it fails to update CV29 on the decoder when switching to a long address. Update CV29 manually and it should work fine.
PED
  • Member since
    April, 2016
  • 483 posts
Posted by PED on Tuesday, March 13, 2018 3:54 PM

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.

Paul

Washita and Santa Fe Railroad
Circa late 1970's in south central Oklahoma

  • Member since
    October, 2006
  • From: Western, MA
  • 7,829 posts
Posted by richg1998 on Tuesday, March 13, 2018 5:07 PM

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.

Rich

N

  • Member since
    May, 2017
  • 13 posts
Posted by rrbnsf on Tuesday, March 13, 2018 5:35 PM

richg1998
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.

I've seen that same recomendation on Digitrax's site, so it's most likely valid. Something to look into if you're going to be programing Bachmann decoders a lot.

  • Member since
    December, 2001
  • 1,867 posts
Posted by Stevert on Tuesday, March 13, 2018 7:47 PM

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.

PED
  • Member since
    April, 2016
  • 483 posts
Posted by PED on Tuesday, March 13, 2018 9:09 PM

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.

Paul

Washita and Santa Fe Railroad
Circa late 1970's in south central Oklahoma

  • Member since
    May, 2010
  • 3,271 posts
Posted by mbinsewi on Tuesday, March 13, 2018 9:46 PM

Something else that would be helpful here, "Randy (rrinker) (shouting out loud) stop in please!"  Laugh

Mike.

  • Member since
    February, 2002
  • From: Reading, PA
  • 25,088 posts
Posted by rrinker on Wednesday, March 14, 2018 7:56 AM

 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.

  • Member since
    December, 2001
  • 1,867 posts
Posted by Stevert on Wednesday, March 14, 2018 10:28 AM

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.

  • Member since
    September, 2003
  • 6,367 posts
Posted by Overmod on Wednesday, March 14, 2018 1:06 PM

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...

  • Member since
    February, 2002
  • From: Reading, PA
  • 25,088 posts
Posted by rrinker on Wednesday, March 14, 2018 5:20 PM

 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.

                                                --Randy


Modeling the Reading Railroad in the 1950's

 

Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.

PED
  • Member since
    April, 2016
  • 483 posts
Posted by PED on Wednesday, March 14, 2018 6:11 PM

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.

Paul

Washita and Santa Fe Railroad
Circa late 1970's in south central Oklahoma

PED
  • Member since
    April, 2016
  • 483 posts
Posted by PED on Wednesday, March 14, 2018 6:19 PM

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.

Paul

Washita and Santa Fe Railroad
Circa late 1970's in south central Oklahoma

Subscriber & Member Login

Login, or register today to interact in our online community, comment on articles, receive our newsletter, manage your account online and more!

Users Online

Search the Community

ADVERTISEMENT
ADVERTISEMENT
ADVERTISEMENT
Model Railroader Newsletter See all
Sign up for our FREE e-newsletter and get model railroad news in your inbox!