Decoder Pro - first day experiences - queries arising ...

[JulianHicks]

I've just been using my new SprogII with the latest [V3.8] DecoderPro on my XP / Java 1.7-71 laptop.  I have only three locos with DCC decoder to hand [out of 9] and I've already got 'two and a half' problems.  Accordingly I'd appreciate any help that anyone can provide please for the following quirks I've discovered using DecoderPro.

 

Loco 1 - Bachmann 'DCC 8 ready' Class 08 - Hattons MD4 '8pin direct' decoder added

 

When I scan the onboard decoder, I get the following message;

"Found mfg 79 ... version 11; no such decoder defined"

 

Q1 - So I suspect the decoder is very recent and I've worked out that I can read/write CVs using the special NMRA selection(s) together with the decoder manual, but that somewhat defeats the point of having decoders 'programmed in' and 'self selecting'.  How would I go about getting the decoder definition added to my / the distributed DecoderPro?

 

Loco 2 - Bachmann DCC 21 Ready' MLV - Bachmann 36-557 21pin decoder added

 

When I scan the onboard decoder, I get the following message;

"Found mfg 141 ... version 81; no such decoder defined"

 

I was a bit surprised that an 18month old decoder didn't have a definition and then this is where it got strange; there were no obviously appropriate CV tables for this decoder, but when I went into 'CV mode', I could change some variables but then started to get "301 no locomotive detected" messages.

 

Q2a - What caused the 301 messages?  [Tried this again - same result after setting some CVs]

 

Investigation showed some confusion about this decoder with Bachmann UK [wrong manuals on web site etc.] but it finally appears this decoder is a SoundTraxx MC1, in 21pin format, which I deduce has had an undocumented CV7 version code change from 80 to 81.  I forgot to look for an SoundTraxx DecoderPro MC1 definition but assuming it exists:

 

Q2b - How can I arrange for the MC1 definition to be 'cut and paste' so as to have its CV7 value 'tweaked' from 80 to 81 so it is recognised as the definition of the Bachmann 36-557?

 

Loco 3 - Bachmann USA GP9 DCC - unidentified Bachmann decoder onboard

 

When I scan this decoder, I get the following message;

"Multiple possible decoders detected - manually select ....."

"2 function Decoder 36-552"

"4 function Decoder 36-550"

 

Q3 Hmmm - strange: how can two decoders have the same identifier?  That is, unless they ARE the same, in which case shouldn't they have a single identifier "2/4 function 36-552/550" and definition.  If they're different, they should have different IDs.  How can I determine which is the right one - the decoder was pre-installed and I can find no documentation for it!  [This is Bachmann ATSF GP9 - running number 2876 - serial 62803].

 

All help and guidance appreciated ...

[Adrian Wintle]

Q3 There is no requirement for a manufacturer to have a different ID for each decoder. For Digitrax decoders the identity typically covers a wide variety of similar decoders (they all use the same undelying architecture), so you normally get a message like that. The reason there isn't a single identifier in Decoder Pro is that the 2-function and 4-function decoders will have different lists of supported CVs (extra to support the extra functions on the 4-function one)

 

Q2a. No locomotive detected would usually mean no acknowlegment pulse(s) from the decoder - possibly trying to change an unsupported CV?

 

Adrian

[Crosland]

Welcome to the world of decoder IDs

 

Manufacturers will sometimes use the same ID for multiple decoders, especially, as in your case,where only the  number of functions or the physical form of the decoder differ. The firmware in the decoder is the same.

 

Rather than using the identify function and letting DecoderPro choose, you can manually select the decoder type. This is invariably better than trying to use the NMRA pane as you will get the benefit of the GUI for setting bit fields within CVs.

 

Andrew

[Butler Henderson]

No loco detected can be down to mucky pick ups / wheels / programming track

[Tony_S]

For the Bachmann 21 pin decoder, I just use the 36-553 (8 pin 3 function) settings.

[Nigelcliffe]

Q1 - Hattons is an obscure buget UK provider. I doubt anyone has written the decoder file for it - those who write decoder files usually have their own preferred brands, and often towards the upper end of the market.

I think (from half heard conversations) that the Hattons decoder may be a rebadging of another design, so there may be something which is the same or close in an existing JMRI file.

To write your own files, there is guidance on the JMRI website, and/or join the Yahoo group for Jmriusers and assistance in writing is likely to be found.

[Jintyman]

I have seen some Hattons 2- function decoders that a friend of mine had, they still had the DCC Concepts logos on, although they were in Hattons packaging!!!

 

I have a Sprog 2 with v3.8 software and I find it great for programming things such as lighting functions, and altering which F buttons do what. My Sprog nearly always gives me a 'few' decoders to choose from, and I just select the nearest possible so long as I know roughly what it is.

 

I had an issue the other day with an ESU Loksound, I wasn't certain if it was a v3.5 or a v4.0, the Sprog gave me just multiples of the v4.0 to choose from (NEM 652, 21MTC,etc), so it will differentiate between decoders sometimes.

 

It's a great bit of kit, I'd stick with it.

 

JInty ;-)

 

Edited to say, JMRI doesn't always get DCC Concepts right, and the only 2 choices are Red and Blue wrapped decoders!!!!

[JulianHicks]

  Until two days ago, when my Sprog II arrived, I was a bystander in the art of CV coding.  As described elsewhere, my friend's son and I had been basking in the benefits of DCC with 9 locos on a small two loop track with nothing to worry about.  We never needed to know what the CVs were as the locos all worked 'fine', albeit at different speeds.

 

And then, along came a '8pin DCC ready' Bachmann Class 08, to which I added a Hattons 8pin decoder.  Worked fine on DC, really strange on DCC - took about 10 seconds to stop.  Hence the 'urgent need' for a Sprog to diagnose what was 'wrong'.  [i'd long fancied one but here, it became justified].

 

So now I 'participate' rather than 'bystand' and as someone who spent almost 40 years in 'Enterprise IT', I find the DCC documentation on the Internet is shockingly poor.  No wonder we need all the help we ask for ...

 

Examples

1) ID/version.  I find the Bachmann docs on the web and 'in the box' for my 36-557 21 pin decoder don't match each other or the values read by the Sprog.  Paperwork says 141/96, web doc says 141/80, decoder values are 141/81.  I'm still not sure what I've got and what CVs are available for it.

2) CVs 2,6,5.  Invariably described incorrectly in docs as 'start voltage', 'maximum voltage' and 'mid voltage'.  They clearly aren't, becuase they would all be 12V, as the motor circuit off the decoder is PWM DC.  The motor voltage never changes - it's the pulse width that changes - that is, 'the percentage of the time that the 12v applied'. [Just because DCC is a bit more complicated, doesn't mean we should use 'non truths' to describe how it works to beginners].  Note: the NRMA standards call this characteristic in these fields the "Voltage drive level" which is a bit vague but not incorrect!

 

Anyway; with that out the way, I'd like to thank everyone who responded.  Replies are doubly useful as they a) give answers or b) make you think about something from a different viewpoint.

 

I'll now try to respond to each appropriately, with the benefits of 2 days of hammering the Sprog and my Bachmann GP9 to pieces on the programming track ...

[JulianHicks]

Q3 There is no requirement for a manufacturer to have a different ID for each decoder. For Digitrax decoders the identity typically covers a wide variety of similar decoders (they all use the same undelying architecture), so you normally get a message like that. The reason there isn't a single identifier in Decoder Pro is that the 2-function and 4-function decoders will have different lists of supported CVs (extra to support the extra functions on the 4-function one)

 

Q2a. No locomotive detected would usually mean no acknowlegment pulse(s) from the decoder - possibly trying to change an unsupported CV?

 

Adrian

 

Thanks Adrian.

 

Q3 - To my mind you've explained exactly why you need different IDs when the CV capabilities are different!  In my case, when two options were offered, they were clearly for 2/4 function versions.  But how do I know what to select?  There's no doc 'in the box' to say which decoder was prefitted in my loco.

 

My view would be that using a single ID is fine for a 'set' of similar decoders as long as you use another 'spare' manufacturer field to indicate the subtypes.

 

Q2A - Understood, if I'd just put the loco on the programming track, but I'd already read CVs off it successfully when it started showing 301s...  And it happened again later.

[JulianHicks]

Welcome to the world of decoder IDs

 

Manufacturers will sometimes use the same ID for multiple decoders, especially, as in your case,where only the  number of functions or the physical form of the decoder differ. The firmware in the decoder is the same.

 

Rather than using the identify function and letting DecoderPro choose, you can manually select the decoder type. This is invariably better than trying to use the NMRA pane as you will get the benefit of the GUI for setting bit fields within CVs.

 

Andrew

 

Hi Andrew - thanks for the superb interface [and the 'fun' it's starting to give me!!!], as well as your comments.

 

1) Same Id - Physical form [i.e marketing name / layout differences] should NOT have different IDs - agreed; the code and CV data stack available should be identical.  But while the firmware is 'the same', I'm sure you agree that the potential 'paths through the code' must vary when some CVs are 'there' and some 'aren't' - that is, it's a different decoder when you want to 'set it'.

 

2) Selecting ANY coder definition I now realise is hit and miss as it relies on the definition being correctly defined.  Even more difficult if you don't know what you've got, as is my case! [Doc errors / no docs, for example].  The whole point of the definition is/should be, whatever decoder you 'detect' from the track, DecoderPro should identify it correctly and use a single definition with the appropriate [and correct] bit and byte definitions to allow changes.

[JulianHicks]

No loco detected can be down to mucky pick ups / wheels / programming track

 

Thanks for your reply.

 

I had appreciated this message is normally for electrical issues, contacts etc. but in my case I had already used the loco and track for 30mins without problems when suddenly, any attempt to make changes caused the 301s.  Possibly a bug in DecoderPro or an issue when CVs get changed incorrectly.

[JulianHicks]

For the Bachmann 21 pin decoder, I just use the 36-553 (8 pin 3 function) settings.

 

Tony; thanks for that suggestion.  I'll try that next time I've got the Sprog out ...

[JulianHicks]

Q1 - Hattons is an obscure budget UK provider. I doubt anyone has written the decoder file for it - those who write decoder files usually have their own preferred brands, and often towards the upper end of the market.

I think (from half heard conversations) that the Hattons decoder may be a rebadging of another design, so there may be something which is the same or close in an existing JMRI file.

To write your own files, there is guidance on the JMRI website, and/or join the Yahoo group for Jmriusers and assistance in writing is likely to be found.

 

Thanks for your comments Nigel.

 

After two days, I now realise that JMRI is in the hands of the 'users' and not everyone will be coding decoders such as the Hatton's one.  Notwithstanding that though, in theory [ha ha], all decoders should work as designed and it's just a case of matching what CVs the decoder offers and setting up the XML.  [Learnt that yesterday]!

 

I'm going to set it up in 'NMRA all CVs' mode; with almost 40 years of programming, binary, hex, decimal conversions and bit settings are relatively easy.  If I get round to it I might write the file and would, in that case, make it freely available to all ... 

[JulianHicks]

I have seen some Hattons 2- function decoders that a friend of mine had, they still had the DCC Concepts logos on, although they were in Hattons packaging!!!

 

...

 

It's a great bit of kit, I'd stick with it.

 

JInty ;-)

 

 

 

Thanks for your reply.

 

I think the Hatton's decoder I have is a 'new one' they've had made for them as the Manufacturer ID is a properly allocated one in the NRMA master list. "Hattons Model Railways".

 

As implied elsewhere, 'you only get what someone else has coded' with DecoderPro and the Hatton's decoder is rare enough that no-one's done that yet.

[Nigelcliffe]

Julian, 
 
the issues you've identified are correct.  
 
The decoders Ready-to-Run manufacturers fit to locos as "DCC fitted" are frequently old and poor performance designs.  The consistency of assembly and documentation from those makers can be shockingly bad as you've discovered.   Even the most enthusiastic JMRI contributor couldn't solve the mess created by the manufactures.    
 
In contrast, decent decoder makers usually have good documentation and the means to tell one decoder from another via CV queries.     I think you'd have far fewer problems were you to use mid-range or higher decoders from recognised DCC manufacturers, and fit them yourself to locos.
 
 
If you do start to decipher the XML for a Hattons decoder, then contribute it to the JMRI project.    The entire thing is a community open-source volunteer effort; what
individuals put in is all there is.  
 
 

The whole point of the definition is/should be, whatever decoder you 'detect' from the track, DecoderPro should identify it correctly and use a single definition with the appropriate [and correct] bit and byte definitions to allow changes.

 

Nice in theory, but won't work in practise.  The use of CV7/8 by makers is so shockingly bad that the resulting file would be of little use -  for example, there are makers who change CV7 values in manufacture but without documentation, they use sequential version numbers (undocumented) to refer to radically different decoder hardware (eg. an N-size motor decoder, followed by an LGB sound decoder, followed by an accessory decoder, ..., remember all undocumented except by end-user observation of what they got in a box), so the actual reliable identification in some cases is just "manufacturer".   This would mean a "single file" would have to cover several decoders, possibly with conflicting CV structures, and certainly with features only present in some (sound for example in some, not in others, same maker).   

Not to mention makers whose documentation doesn't match the decoder or the actual decoder features and actual CV behaviour.

To make matters worse, there are manufacturers who buy-in decoders from elsewhere, put their label on the packet, but don't change the CV8 or CV7 values, so those will appear under the "wrong" label - Bachmann have done this recently with some of their Soundtraxx sourced motor decoders, and this is far from an isolated incident.

 

There are "good" decoder manufacturers where its possible to identify the decoder, the precise model of decoder and the exact firmware loaded on the decoder, and this information is published.  If only all makers were all as well organised. 
 

 

- Nigel
  ( Designer of the DecoderPro-3 user interface, and writer of a number of decoder files  ).