Using Sprog with Decoder Pro for first time

[ITG]

Hi

Sprog arrived this morning, and ok linking it up to laptop and Decoder Pro. Successfully identified a loco address which somehow had ‘got lost’ when trying to renumber using Prodigy Advance2 ( which tbh, I have found clunky and intermittently successful when doing anything with addresses and cvs.)

But my question is this - having loaded up very basic details onto a roster of 3 locos, the Decoder Pro window displays them in a very compressed form - see photo. What do I need to do to expand this, or do I need to export to elsewhere? If so, how? And whilst I’m here, any other Sprog tips for a beginner?

[BoD]

I’m sure someone will give you a definitive answer, but if it behaves like a spreadsheet drag on the border between the rows.  Highlight all rows and drag one border to make them all the same height.

[woodenhead]

My Decoder Pro doesn't look like that, I would surmise as BoD states you need to drag them to your desired size Excel style.

[Tappa]

Best thing I did with my Sprog was to get a small cheap Netbook (or equivalent) and load DecoderPro onto that. I use that as a dedicated system for DCC. Much easier than having to lug a laptop around, especially if you exhibit your layout. I have a length of track on a piece of wood, a Netbook and the Sprog which means I can do programming anywhere. 

Just make sure it has the usb ports to connect to.

[ITG]

Thanks for the response, BoD and Woodenhead, but whilst it will allow widening of the columns in a traditional spreadsheet way, it won’t expand the rows - very odd. I’m reasonably IT literate, and very familiar with the likes of excel, but this has stumped me. Is there a way in which I can export to excel, as then it wouldn’t matter how it displays in Decoder Pro, would it?

Tappa - my laptop is always at hand at home so no problem to plug in Sprog and link to a length of track on a plank. 

[WIMorrison]

I would check the Java version and type that you are using as this impacts the display.

 

I no longer use Oracle Java for these reasons and use Liberica Java which overcomes the Oracle issues.

[Nigelcliffe]

Its a setting which is wrong somewhere.....   As Iain says, possibly the Java version, or something interacting between your display settings on the PC and the Java code.    

 

Could try the different "display" options in preferences within JMRI.  Mine is set to "metal" as that seems to give the least grief.  

 

 

There should be a sensible display, with things clearly separated into rows, not compressed like it currently appears.   

If it stays stuck, try asking on the jmriusers group at groups.io.   Someone who's been round this before might remember the solution.  

 

 

( There is an export to CSV files, but it won't really help you once you're into programming a complex decoder, except as a data exchange format with another user  ).  

 

 

The underlying GUI tools used for the code in JMRI are ancient and not very good - they weren't great some years ago when I designed the roster view, and they've not really changed.  

 

 

- Nigel

[ITG]

Problem resolved it seems. I closed the various windows, went off to do something else, then came back to it to follow up on your replies, and when I reopened Decoder Pro, the display of that roster was ok.

But one more quick question - why does this roster display every loco as DCC Address 3, when they are not? It’s the ID number allocated by me which I thought was the address.

[Nigelcliffe]

22 minutes ago, ITG said:

Problem resolved it seems. I closed the various windows, went off to do something else, then came back to it to follow up on your replies, and when I reopened Decoder Pro, the display of that roster was ok.

But one more quick question - why does this roster display every loco as DCC Address 3, when they are not? It’s the ID number allocated by me which I thought was the address.

 

Because that's what the system currently thinks you've saved for every loco.   You should be Reading the values from your locos, and that will populate the values held in the decoder.    The "ID " is just a user-comment field, as are several of the other columns, they don't reflect what's in the decoder.   

 

Select a row in the Roster table view,  then the "program" button at the bottom right.    Then select the "basic" tab on the decoder/loco window.   Do a "Read Sheet" for that tab, with the loco on the programming track outputs of the Sprog.   That will read the values in the decoder.     Then close the decoder window, saving its values as you go.    (Ideally, you;d also go through the other tabs, but one step at a time ). 

 

(  Now your Roster is displaying OK, it probably means the underlying preferences have sorted out.  No idea why it does this crap at startup, but its the ancient Java UI library in use.   That's due to change soon-ish when JMRI moves up a Java release version.  But JMRI tries to move Java releases very late because lots of uses have crap-ancient-PCs in their railway rooms, so tries to not drop them from support ).  

 

-  Nigel

Edited February 24, 2021 by Nigelcliffe

[ITG]

1 hour ago, Nigelcliffe said:

 

Because that's what the system currently thinks you've saved for every loco.   You should be Reading the values from your locos, and that will populate the values held in the decoder.    The "ID " is just a user-comment field, as are several of the other columns, they don't reflect what's in the decoder.   

 

Select a row in the Roster table view,  then the "program" button at the bottom right.    Then select the "basic" tab on the decoder/loco window.   Do a "Read Sheet" for that tab, with the loco on the programming track outputs of the Sprog.   That will read the values in the decoder.     Then close the decoder window, saving its values as you go.    (Ideally, you;d also go through the other tabs, but one step at a time ). 

 

(  Now your Roster is displaying OK, it probably means the underlying preferences have sorted out.  No idea why it does this crap at startup, but its the ancient Java UI library in use.   That's due to change soon-ish when JMRI moves up a Java release version.  But JMRI tries to move Java releases very late because lots of uses have crap-ancient-PCs in their railway rooms, so tries to not drop them from support ).  

 

-  Nigel

Ah, I’m learning. May I now ask why the ‘read type from decoder’ seems unable to find a DMU (decoder)  on programme track? I have no reason  to want to change anything at present, other than to add to roster. It’s an older Bachmann non-sound item that I bought pre-owned, which I suspect was converted from DC by previous owner. How do I then add this to roster, and/or amend anything if I wanted in future.

 

added later ..... found the answer, I think. Seems that the result of CV159 indicates it’s a Hornby Sapphire R8245 decoder, so when I manually selected that, I’ve been able to add the DMU to the roster.

I suspect I’m at the onset of a long journey as I discover what the Sprog and Decoder Pro can do for my locos.

Edited February 24, 2021 by ITG
Added

[Nigelcliffe]

47 minutes ago, ITG said:

Ah, I’m learning. May I now ask why the ‘read type from decoder’ seems unable to find a DMU (decoder)  on programme track? I have no reason  to want to change anything at present, other than to add to roster. It’s an older Bachmann non-sound item that I bought pre-owned, which I suspect was converted from DC by previous owner. How do I then add this to roster, and/or amend anything if I wanted in future.

 

added later ..... found the answer, I think. Seems that the result of CV159 indicates it’s a Hornby Sapphire R8245 decoder, so when I manually selected that, I’ve been able to add the DMU to the roster.

I suspect I’m at the onset of a long journey as I discover what the Sprog and Decoder Pro can do for my locos.

 

If "read type from decoder" results in nothing found, and no "chattering" noises from loco as its being read, then that suggests one of the following:   either loco not connected to track properly (push down on it a bit), or a decoder which doesn't support read-back (some old cheap decoders don't support reading, but they should be rare).  

If it does read the decoder, but can't find it, that's because the numbers being read don't match anything.   The reading sequence starts with CV8, which is the decoder manufacturer code.   Then it goes onto CV7 which (depending on decoder maker) may or may not give clues as to which decoder.   Thereafter, for some decoder makers, further CV's are read to identify the decoder - some of the best will identify down to specific decoder models and firmware version on the decoder.   Other makers don't provide such information, so all you get is a long list of possible matches.  

 

I don't know how you identified the decoder as a Hornby Sapphire (I'm not familiar with that decoder), though I would expect it to read, and be identified.  Maybe that's a correct identification, or maybe not.   If it is right, the CV8 (decoder maker) should match correctly.  

 

 

Earlier you said you were giving the decoder address as "ID" - I'd suggest you edit those to something else, such as "Thomas" or "Blue 37 with oily streaks on roof" or some other text which is useful to identify the locos.   

 

 

You can just manually create entries, by looking up a decoder from the long list, and giving the roster entry a name (ID), and saving it.     

The one thing you cannot do is change the decoder selected on a roster entry.   If you got the decoder choice wrong, the sensible way is to delete the roster entry and create a new entry with the correct decoder.   (There is a way to change the decoder, but it involves editing an XML file,  don't go there unless you're really sure you're OK with editing XML and not making mistakes......  ).  

 

 

 

- Nigel

( right, back to writing a revision to the decoder file for Swiss Mapping in Zimo decoders  ).   

 

 

[ITG]

1 hour ago, Nigelcliffe said:

I don't know how you identified the decoder as a Hornby Sapphire (I'm not familiar with that decoder), though I would expect it to read, and be identified.  Maybe that's a correct identification, or maybe not.   If it is right, the CV8 (decoder maker) should match correctly.  

Thanks, Nigel.  If I recall correctly, Decoder Pro displayed CV159, at the bottom of the window with the list of decoder types. The loco was twitching, but no decoder type was highlighted as would normally be the case.  I googled the CV159 indicator and found an answer on another forum which stated this indicated a (probably old) Hornby decoder, and recommended clicking in turn on the various Hornby decoders in Decoder Pro. Once I hit Sapphire R8245, the roster input window opened as normal, which I proceeded to populate as for other locos. 
On the DMU in question, there are no lights or sounds, but it is a good runner, so I don’t intend to meddle too much with it. As I said at the start of this thread, I found the Prodigy somewhat inconsistent at reading and/or changing cvs, whether on main or prog. Hence my purchase of the Sprog, which I’ll learn my way round with Decoder Pro as I go.

thanks again.

Ian

 

late amendment.... guess what, I refound that posting in another forum, and it was you! Here it is below, although on rereading it, maybe I misinterpreted what you meant. But it seems I might have got to the right answer?

 

I suspect you’ve stumbled over a bug, or unintended consequence.    

 

The “identify decoder” code has found it’s a Hornby, and is trying to identify which TTS sound decoder might be fitted (CV159).   But, if the decoder doesn’t reply to CV159 (I suspect some more basic, perhaps older, Hornby decoders don’t), then there is going to be an error.

 

So, for your side, my suggestion is that you do as you did -  manually find the decoder type (rather than “read type from loco”, go down the list of makers, expand Hornby, and pick the decoder you think is in the loco).    With other brands of decoder “Read type from decoder” should be fine. 

 

For the software development side -  there is code to identify TTS decoders automatically,  can it be modified so that a “no loco detected” means it stops trying CV159 and decides it must be one of the other Hornby decoders ?      Or, is a decision between automatically identifying TTS types (really useful to a lot of TTS users) and thus will fail on some other Hornby decoders, or does the automatic TTS identification have to be removed ?  

Edited February 24, 2021 by ITG
Added amendment

[Nigelcliffe]

Ian,

yes, the quote you found explains it. 

 

Decoder Pro has already read CV8 (Hornby) and CV7 (version number, but may not tell us anything if Hornby haven't said what their version numbers mean).   The software is now trying to narrow down further, and looks at CV159, which is trying to identify which TTS model is in use.  But, various other Hornby decoders don't have CV159, so it gets stuck.   Its a bind which might be soluble, but I wonder whether anyone has enough interest to delve into the guts of JMRI code to try to fix it.  (And its not helped by Hornby, who others have reported as re-using their TTS CV159 codes, so value X might be two different locos.... (Doh!) ).   

 

Whether its a Sapphire or not isn't clear.   The window just opens on whatever decoder you select (you could select a different maker if you wished).     Sometimes the only way to identify a decoder is to visually identify what it is. 

 

 

 

- Nigel

[Pete the Elaner]

CV8 was designed to be for manufacturer & they seem to conform to this (maybe they are obliged to?): You can find a list of these on the internet..actually 2 lists, 1 sorted alphabetically & the other sorted chronologically.

 

CV7 is a bit more random. I tried documenting these for my own benefit but soon gave up.

I have several Hornby decoders 10 appeared to be Sapphire, 132 for my TTS class 60 (although I remember JMRI recognising it as something else).

An R8249 was read back as 13, but I had more than 1 of these so I tried another. That was 131 

So I tried a couple of Zimos:

I tried a sound loco, one of the MX645 series. That showed CV7 as 37. I then read an MX618..which was also 37.

Maybe ESU are better. A Loksound 3.5 read back as 59, a Loksound v4 read back as 255. Although this was good that they were different, I am suspicious of 255. I found a Loksound v5 & read this into JMRI. That was also 255.

 

I may be wrong but I believe it was NMRA's intention that CV7 should be used to identify decoder type, but  it was manufacturer's discretion as to exactly how they use it.

I have noticed that my Lokprogrammer is able to identify decoders accurately & JMRI is often able to select a small range of types, one of which is usually correct so I wondered if there is also another type code hidden in other CVs?

[Nigelcliffe]

1 hour ago, Pete the Elaner said:

CV8 was designed to be for manufacturer & they seem to conform to this (maybe they are obliged to?): You can find a list of these on the internet..actually 2 lists, 1 sorted alphabetically & the other sorted chronologically.

 

CV7 is a bit more random. I tried documenting these for my own benefit but soon gave up.

I have several Hornby decoders 10 appeared to be Sapphire, 132 for my TTS class 60 (although I remember JMRI recognising it as something else).

An R8249 was read back as 13, but I had more than 1 of these so I tried another. That was 131 

So I tried a couple of Zimos:

I tried a sound loco, one of the MX645 series. That showed CV7 as 37. I then read an MX618..which was also 37.

Maybe ESU are better. A Loksound 3.5 read back as 59, a Loksound v4 read back as 255. Although this was good that they were different, I am suspicious of 255. I found a Loksound v5 & read this into JMRI. That was also 255.

 

I may be wrong but I believe it was NMRA's intention that CV7 should be used to identify decoder type, but  it was manufacturer's discretion as to exactly how they use it.

I have noticed that my Lokprogrammer is able to identify decoders accurately & JMRI is often able to select a small range of types, one of which is usually correct so I wondered if there is also another type code hidden in other CVs?

 

CV8 is manufacturer ID, and makers are supposed to follow this bit of the standard, using only their own allocated value.  Most do, but errors have happened. 

CV 7 is for makers to use to identify decoder versions, but not specified how.  

There are a vast number of CVs which are free for makers to use as they choose.  So, a maker can use those to give precise decoder identification. 

 

 

Below is how Zimo do it,  ESU is similar with different CV's used (though the 3.5's don't do this and are not easy to identify from CV reading).  

 

In Zimo, CV7 is the first half of the firmware version number, so its version 37.  

The second half of the firmware version is stored in CV65, so that might have a value of 12.    So, combining them, the firmware in the decoder is 37.12.  (Zimo have a common firmware setup, so different sized decoders run the same firmware.  The firmware determines which features are available.  Zimo decoders can be updated by the end-user to change the firmware if a new feature is needed, but requires suitable updating hardware.). 

CV's 250,251,252,253  give the serial number of the decoder, set in manufacture.  CV250 will give you the hardware of the decoder (eg. MX618, MX645, etc.), there is a lookup in the Zimo manuals.  Those four CVs (250-253) give a unique serial number for each decoder (ie. each MX645 you own has a different set of values). 
The serial number comes in useful for "load codes" (CV260-263) where end users put sounds onto decoders against that code.  The load code is calculated against the serial number, and is effectively a "unlocking key" to allow the sounds to work on that specific decoder.  It stops you getting a sound file from a provider and loading it onto an unlimited number of decoders, thus undermining the sound provider's business. 

 

JMRI uses the various sub-version CV's where the information is known.   Its different per decoder maker.   

For Zimo, it checks version (CV7), sub-version (CV65) and decoder model (CV250).   But, there is a possibility that JMRI hasn't written something for the exact combination in your decoder, so a bit of end-user "select the nearest" has to come into play (multiply number of decoder models by number of firmware release listed on Zimo's website to understand scale of problem covering every possible one).   

JMRI does something similar for ESU for decoders above version4, again identifying to a fairly high degree of accuracy  (but it gets stuck with a v3.5 because ESU didn't offer anything useful for the v3.5 decoders). 

And it does similar things on some other makers, such as TCS, Soundtraxx, and others.  

 

 

ESU's LokProgrammer does something similar for identifying ESU decoders.  But has the advantage of using a proprietary connection mechanism, so may have access to other data not visible or published to anyone else.    

 

 

Unfortunately, Hornby's information is hard to collate.  Their use of CV7 seems random.  They have used CV159 to identify TTS models, but there is no clear published list (what's been used in JMRI is pieced together from numerous individual manual sheets for different TTS decoder releases, plus owners reading values from locos), and there is some evidence of Hornby re-using values on different decoders.  

 

 

- Nigel

 

[john new]

Hope it is OK to add this here, as it is related to newbie use, rather than starting yet another new thread.

 

I am a new user and as a test I have added my first loco to the roster file using JMRI. I did it on my desktop MAC with connected SPROG III. I also have a MacBook laptop for obvious portability. 

 

Numpties question though - having created the new loco roster for this first entry two immediate queries arise as there is no obvious new file dated today in the JMRI folder:-

(1) where is the roster file stored?

(2) can that be ported by a thumb drive or by using the cloud/my network so either computer can access a common roster file?

 

If the answer to (2) is no then I will just use the MacBook laptop with JMRI to build the roster file as I can use that anywhere, unlike the desktop Mac.

 

 

 

Edited April 3, 2021 by john new
Minor reword for clarity.

[Nigelcliffe]

3 hours ago, john new said:

 

Numpties question though - having created the new loco roster for this first entry two immediate queries arise as there is no obvious new file dated today in the JMRI folder:-

(1) where is the roster file stored?

(2) can that be ported by a thumb drive or by using the cloud/my network so either computer can access a common roster file?

 

 

1) in the place specified in the preferences settings, section labelled "file locations".  Within that is a folder called "roster" and the entries are inside that.   There are two types of file - the overall "roster.xml" file which is the list of things you have, and the individual loco files which contain the actual CV settings.   

 

2)  Yes, by putting the files (above) within the shared drive (or changing the preferences so your profile is in a different location).  I'd suggest a cloud synchronised location rather than a memory stick, then its always done, rather than relying on carrying a stick around.  

 

 

 

[john new]

3 hours ago, Nigelcliffe said:

 

1) in the place specified in the preferences settings, section labelled "file locations".  Within that is a folder called "roster" and the entries are inside that.   There are two types of file - the overall "roster.xml" file which is the list of things you have, and the individual loco files which contain the actual CV settings.   

 

2)  Yes, by putting the files (above) within the shared drive (or changing the preferences so your profile is in a different location).  I'd suggest a cloud synchronised location rather than a memory stick, then its always done, rather than relying on carrying a stick around.  

 

 

 

 

Thanks for that, in line with (2) I will put it into a new sub-folder in the cloud. I have a set of several such in an umbrella railway modelling  main folder. 

 

Edit - Files now on my one-drive folder, for some reason the i-cloud is not visible to DecoderPro. [Guessing that is due to the java interface or similar.] Will load JMRI onto the laptop tomorrow and then learn a bit more.

 

Edited April 3, 2021 by john new
Added the edit note.