Reading Decoders

[Ray H]

Apologies if this has been covered before but I've gone back a few years using the search facility and can't see anything.

 

I've recently purchased a SPROG IIv4, installed DecoderPro and connected everything up. I now have a roster of over thirty items of motive power and plan to start trying tweaks in due course.

 

I have two different types of decoder that DecoderPro doesn't recognise. They either have a Manufacturer's ID of 141 & Version No. of 81 - believed to be a (Soundtraxx (Throttle Up) OEM MCI - or Manufacturer's ID of 48 & Version No. of 131 - believed to be from Hornby. I can't find either in the JMRI decoder list and the DecoderPro Actions/Update Decoder Definitions menu item doesn't appear to work.

 

Is there a one size fits all process for updating all known decoder definitions?

 

Is there a way other than one CV at a time of reading decoders that JMRI doesn't have a definition for?

 

I have tried making assumptions about the decoder type for the above and DecoderPro returns a "No loco found" error message when attempting to read some CVs. Is this error message actually saying that the CV number is not used by the decoder being read?

[Pete the Elaner]

My Hornby R8249 & Zen (218 I think) decoders show as unknown.

I manually selected the Zen & could read back the CVs successfully. I have not tried this with one of my R8249s yet but I will try it.

It wouldn't read my APT-E either & that is a Legomanbiffo chip (Loksound v4 I believe).

[Ray H]

I've just downloaded the most recent version of JMRI which has an updated decoder list.

 

I've set the decoder choice to raw NMRA which allows the reading of the first 255 CVs. It isn't too fast but at least it will give me some CV values to look at.

[Nigelcliffe]

The Soundtraxx MC1 is the decoder which Bachmann used for some UK branded product in the past few years. 

 

Can't help much on the Hornby, using the raw NMRA is one way, though slow. 

 

 

What gets into JMRI is what volunteer contributors write as decoder files.   The missing ones are because no volunteer has written it (or necessarily even seen that decoder).  

 

 

For updating to cover new decoder files,  the easiest way is to keep updating JMRI as new releases come out (every six weeks or so for test releases, every six months for production releases). 

 

 

 

- Nigel  (sometime writer of JMRI decoder files ). 

[DAVE1562]

Apologies if this has been covered before but I've gone back a few years using the search facility and can't see anything.

 

I've recently purchased a SPROG IIv4, installed DecoderPro and connected everything up. I now have a roster of over thirty items of motive power and plan to start trying tweaks in due course.

 

I have two different types of decoder that DecoderPro doesn't recognise. They either have a Manufacturer's ID of 141 & Version No. of 81 - believed to be a (Soundtraxx (Throttle Up) OEM MCI - or Manufacturer's ID of 48 & Version No. of 131 - believed to be from Hornby. I can't find either in the JMRI decoder list and the DecoderPro Actions/Update Decoder Definitions menu item doesn't appear to work.

 

Is there a one size fits all process for updating all known decoder definitions?

 

Is there a way other than one CV at a time of reading decoders that JMRI doesn't have a definition for?

 

I have tried making assumptions about the decoder type for the above and DecoderPro returns a "No loco found" error message when attempting to read some CVs. Is this error message actually saying that the CV number is not used by the decoder being read?

A little bit of info..?....http://www.nmra.org/manufacturer-id-numbers

[Ray H]

A little bit of info..?....http://www.nmra.org/manufacturer-id-numbers

 

Thanks.

 

The problem seems to be trying to nail the version down to a specific set of JMRI data.

[Ray H]

I think that I've all but worked out which decoders are which, helped by finding paperwork for at least some decoders that I've fitted - I can't be sure that I've got the documents for each decoder.

 

I know that I've bought several Hornby decoders and I have read four that have Hornby's manufacturer ID of 48. However, the paperwork says the version number for the R8249 is 31 whereas CV 7's value is 131. I wonder if this could be a printing error.

 

I have found that reading the raw 255 CVs returns different values for some CVs compared to the values found when a different decoder type is used. For example, the Raw read doesn't return any values for CVs 68 to 94 - presumed to be the speed table - whereas setting the decoder as (for example) "NMRA standard CV definitions" does return values for these CVs. A check via my PowerCab matches the Raw read results.

 

The two reads also return different values for CV29 even though the reads were within minutes of each other and no changes had been made to any CVs in between. The value checked through my PowerCab matches the NMRA standard CV definitions read - the converse of the CV29 check.

 

Are all CVs stored on decoders in a standard format (and in a specific area of the decoder) or is each decoder's firmware potentially laid out differently?

[Nigelcliffe]

JMRI (and the Sprog) don't read any different data to your PowerCab.  They are accessing the same CV values, using the programming track.  

 

So, I can think of the following possible reasons to account for the differences in results:

 

• Choice of Decoder programming "mode".  Typically this can be "register", "paged", "direct".    It is possible that one mode is getting different results to others.   Both the PowerCab and the Sprog/JMRI combination will be able to set the mode.   Within JMRI, each decoder file usually has a preferred mode in the code (because different decoders might not work on some modes of reading).  I can't recall what the generic file you are using is set to as its default. 
• Errors on the programming track.  Miniscule loss of contact can get mis-read results.   Not a high probability, but should not be discounted.
• Errors from the decoder.  Might be more apparent with JMRI as the rate of sending instructions might, just, maybe, leave the decoder confused about things.   I think this unlikely to, but don't totally discount it. 
• Low quality decoders which don't reliably read back.  Something which has been seen in some decoders over the years. 

 

 

Printing errors in documentation which accompany decoders are rife, not just the model train makers, but also the "we're a decoder maker specialists".  So, a printing error for 31 vs 131 is likely.

 

CV structure on decoders is a mixture of things.  Some CV's are specifically described, and required, in the DCC standard.  For example, the address and the use of CV29.   Some CV's are described, but optional, in the DCC standard; if the decoder maker chooses to implement the feature, they should use the specified CVs for it, but they may choose to not implement that feature.   And the vast majority of CVs are not described, but are totally up to the maker to do as they see fit (hence the need for thousands of different decoder descriptions in JMRI, to cope with all the variations makers produce).   

 

 

JMRI's DecoderPro features are, essentially, a very quick sequence of button presses for decoder reading/writing.   All the software is doing is sending a lot of CV reads to a decoder and displaying the results in a tidy table with text labels and interpretation of the numbers which are read from the decoder. 

 

 

- Nigel

[Ray H]

Nigel

 

Thanks for that. In truth I'm not too worried about the cheaper decoders as I'm hoping to replace them in due course with noisier models :-)

 

I'm trying to enhance my understanding in the hope that it might make amendments easier.

 

I was aware that decoder manufacturers implement different features/use different CVs. I was more interested in the way the CV data is stored. For example, is it always in a particular format and using the pigeon hole example, would CVx always be found in the same pigeon hole on all decoders, is it encoded with an index on the decoder or is it a (say) sequential list of all the used CVs with the first in the list always found in the same area of all decoders?

 

I only ask this in case there's a generic way of reading any decoder to get (all) its CV values. Do JMRI's different decoder files cause DecoderPro to limit its reads to the known used CVs purely to minimise the overall read time (and to avoid decoder users trying to pump values into CVs that the decoders don't support)?

 

I had (unintentionally) used both Paged & Direct Bit programming options and noticed there were differences in the data read, the values of some of that data and the speed in reading.

 

Once again, thanks for your responses so far.

[Nigelcliffe]

Ray,

 

it doesn't matter how the data is "stored" inside the decoder.   The only way you're going to access it is by reading a CV value, one at a time.   So, the internal structure is "don't know and don't care".  

 

 

 

JMRI's decoder files do several things for you.  

 

Yes, the decoder files only have the CV's used by the decoder, so attempts at reading are only the CVs which exist (or are known to the decoder file).  In some cases its maybe ten or twenty CV's.  In some cases its around a thousand - LokSound decoders are probably the most complex, and an initial read of everything from a LokSound takes a long time.

 

The other thing JMRI does is to organise the results into a reasonably human-friendly manner.   For example, one decoder maker might have CV52 setting the brightness of the lighting outputs, and another might use CV52 to alter the motor characteristics.   Within JMRI, those will get appropriate human-friendly labels and will be put onto appropriate tabs in the interface (the former on something to do with lights, the latter on something to do with motors).    

This goes further, in that some CVs might do multiple things, for example a single CV might control if the lights are flashing in various ways (gyro-light, single flasher, etc.) and a couple of bits in the same CV might also control direction this applies (forwards, backwards or both).   The JMRI interface will separate those out into two different user-interface elements, perhaps two drop-lists, or a drop list and some check-boxes.      

 

 

But, ultimately, JMRI is just reading CV values from a decoder and arranging the results in a particular way on the screen.  Nothing that can't be done manually with enough time and a big-enough piece of paper to record the results and their meaning.   It just saves an awful lot of time and effort compared to manual methods.    

 

 

- Nigel

[Ray H]

Nigel

 

Thanks for the further insight (and thanks for being a contributor to the Decoder files that JMRI uses).

 

I agree about the time taken to read Loksound decoders.

 

At least now I hope I can respond to some odd questions that my fellow club members ask when we start looking at their locos.

 

Thanks once again.

[RAF96]

Try a download of Hornby Railmaster time limited free demo which works with Hornby kit obviously, but maybe could be conned into working with any other USB connected controller. That has a Decoder interogation facility which reads all 255 CVs sequently having worked out from CVs 7 & 8 which decoder it is so that it loads up the right descriptions for each CV.

Rob

Edited February 16, 2017 by RAFHAAA96

[Ray H]

Try a download of Hornby Railmaster time limited free demo which works with Hornby kit obviously, but maybe could be conned into working with any other USB connected controller. That has a Decoder interogation facility which reads all 255 CVs sequently having worked out from CVs 7 & 8 which decoder it is so that it loads up the right descriptions for each CV.

Rob

 

Thanks.

 

DecoderPro does that as well. The problem is that the decoder manufacturer ID and version numbers has to be known before any software can know which CVs to read as Nigel has indicated above. Alas, some ID/version numbers are not documented even on the paperwork that comes with the decoder. This is the problem that I've found with some of the cheaper decoders. A number of the more expensive decoders - possibly all - use far more than 255 CVs with the higher number CVs being critical to the performance of the decoder.

[Nigelcliffe]

Try a download of Hornby Railmaster time limited free demo which works with Hornby kit obviously, but maybe could be conned into working with any other USB connected controller. That has a Decoder interogation facility which reads all 255 CVs sequently having worked out from CVs 7 & 8 which decoder it is so that it loads up the right descriptions for each CV.

Rob

 

How many decoders have Railmaster covered in their software ?    

I really doubt they are anywhere near what JMRI/DecoderPro offers unless they've licensed the JMRI files (which some software has in the past, such as TrainController), plus as Ray indicates, have implemented reading of CV's above 255, and also reading of indexed CVs (where three CVs are needed to access one variable, a mechanism which extends the number of possible CVs into hundreds of thousands).  

 

- Nigel

[RAF96]

@nigel post #14

I have no idea of how many decoders RM has in its database, nor where they got their 'stock' from, but I do know a feature request has been lodged asking for access to CVs above 255 as many folk are using sound decoders requiring adjustment in those areas.

@ray post #13

RM will flag up an unknown decoder and pop up a dialogue asking the user to submit a spec for the decoder along with its manuf and version info. It has been known to fail to spot a known decoder at times.

Rob

Edited February 19, 2017 by RAFHAAA96

[Ray H]

@ray post #13

RM will flag up an unknown decoder and pop up a dialogue asking the user to submit a spec for the decoder along with its manuf and version info. It has been known to fail to spot a known decoder at times.

Rob

 

The problem that I had and I'd guess others will also have is that they have a decoder they they have forgotten the origin of. They may be able to supply the ID and version number by reading the decoder on their programming track but they'll not necessarily know what the decoder's scope is. The same would surely apply if they could read all the CVs. They'd know the CV value but outside the mandatory NMRA ones they're most unlikely to know what each CV is used for. Reading a decoder's CV value in whatever range, is only of use if one knows what those CVs do.

 

I can read any CV value using my programming track but it take a long time to read (say) a Zimo's 700+ CVs one by one. JMRI has the wherewithal using the decoder data that it has amassed through the band of volunteer "subscribers" to group the CVs into associated groups and to read those CVs far faster than I would suspect any individual could do.

[RAF96]

@ray post #16

That is why RM asks for the spec as they use it to populate the CV list with the correct associated description.

If they fail to recognise a decoder from CVs 7&8 then you end up with the standard NMRA/NEM set which as you say is no use to man nor beast.

I presume JMRI has done the same associative listing for all decoders in Decoder-Pro.

Rob

[Crosland]

I doubt very much that Railmaster will talk to a SPROG. Maybe to XpressNet hardware if you are lucky. (I am surprised that Railmaster is limited to CV 255. The NMRA specs have covered higher numbered CVs since the early 2000s when the SPROG was first designed.)

 

The CD-ROM supplied with the SPROG still has JMRI 4.4 if I recall correctly. It might be worth downloading 4.6 to see if your decoders are covered.

[john new]

Useful, if now an old thread. Finding that there are still chips not listed that seem to be common one's in use. Next 18 for example, I only see Next 25 in the list. Still very much on the DCC learning curve.

[melmerby]

On 06/12/2023 at 17:26, john new said:

Useful, if now an old thread. Finding that there are still chips not listed that seem to be common one's in use. Next 18 for example, I only see Next 25 in the list. Still very much on the DCC learning curve.

Are you saying you can't see any Next 18 decoders in JMRI DecoderPro?

It certainly can see Zimo Next 18s as I've used it to set up some.

 

Never heard of Next 25 - what's that when it's about?

[john new]

9 hours ago, melmerby said:

Are you saying you can't see any Next 18 decoders in JMRI DecoderPro?

It certainly can see Zimo Next 18s as I've used it to set up some.

 

Never heard of Next 25 - what's that when it's about?

I will do a screen grab but it will be a day or two as recovering from day surgery yesterday and can’t lift to get the stock box back out. From memory when it read the chip as fitted for me at purchase time it highlighted Gaugemaster and the only entry below was Next 25 which I hadn’t heard of either. Updates were saying my copy is up to date.

Edited December 9, 2023 by john new

[Izzy]

The only Gaugemaster I can find is DCC25 which I believe refers to the Gaugemaster product code of the particular one listed. You have to appreciate JMRI is not commercial and decoders get added by those able and willing to do the work involved, mostly I guess the ones they want/use. I’m just grateful it exists. I see the person that originated Decoder Pro before passing it on to JMRI, DCC guru Mark Gurries, has recently passed on. 
 

Bob
 

 

[melmerby]

As has been said, the decoder definitions are added by volunteers and by nature they are heavy on US decoders, with some of the non-US minor brands such as Gaugemaster poorly served.

You need someone who has used the decoder and has the time to write a definition, which with the paucity of info supplied by some manufacturers, not always easy.

[Nigelcliffe]

Further to the above,   the only Gaugemaster decoder in JMRI is the DCC25 as Izzy reports above.     

 

It's partly for the reasons Keith mentions; Gaugemaster are a small local supplier to a little island off the coast of Europe, not an international player.    And if the people who write decoder files don't use their products, they're not that likely to be written up.   
Most (all?) Gaugemaster decoders are rebadged from other makers, some current ones being rebadged Digitrax items, so the matching decoder in the Digitax listing will do the job.    And, because of that, it would be pretty quick for someone who wanted to add the Gaugemaster Ruby range to do so - find the relevant Digitrax file (its XML, so readable in any decent text editor), change the handful of parameters which identify the decoder as "Gaugemaster" rather than "Digitrax", and its probably done - submit to JMRI and the person has become a new contributor to the JMRI project.  

 

 

Sorry to hear the news about Mark Gurries that Izzy reports, I hadn't picked it up elsewhere.  

 

 

 

- Nigel

 

[john new]

9 hours ago, Izzy said:

The only Gaugemaster I can find is DCC25 which I believe refers to the Gaugemaster product code of the particular one listed. You have to appreciate JMRI is not commercial and decoders get added by those able and willing to do the work involved, mostly I guess the ones they want/use. I’m just grateful it exists. I see the person that originated Decoder Pro before passing it on to JMRI, DCC guru Mark Gurries, has recently passed on. 
 

Bob
 

 

That probably it, my post was from memory.