开云体育

Locked JMRI / DCS240 set up question and why so slow?


 

I have the latest JMRI installed on a Windows 10 64bit system, brand new USB cable, new Digitrax DCS240, and less than two feet of wire to the programming track.

It takes like 25-30 minutes to "read all sheets" from a LokSound Select decoder-equipped locomotive.? We're not talking a 50GB download at 1.5Mb connection.? Small amount of data being retrieved, but it takes way too long.? Am I doing something wrong, or is this just how fast the Digitrax processor can work??

While attention is here, how come it is so confusing to set JMRI preferences with the DCS 240?? The latest digitrax system JMRI offers in the selection list is DCS200.? DCS240 has been around for a few years.? Why not include it??? I understand the DCS240 has an integrated PR3 or PR4, but it would be a lot easier just to select the system I have when selecting the system I have.? Kind of frustrating.

Thanks for your thoughts!!? I am not normally grumpy.


 

开云体育

Tooooons,

What version of JMRI are you on? ?My guess it is to old to have the DCS240. My club uses a 240 and it is in the selection.?

And Loksound taking a long time is normal in my opinion given its complexity. Though later versions do better.?

David Klemm
Xs Max


From: [email protected] on behalf of tooooons@...
Sent: Saturday, December 8, 2018 17:53
To: [email protected]
Subject: [jmriusers] JMRI / DCS240 set up question and why so slow?
?
I have the latest JMRI installed on a Windows 10 64bit system, brand new USB cable, new Digitrax DCS240, and less than two feet of wire to the programming track.

It takes like 25-30 minutes to "read all sheets" from a LokSound Select decoder-equipped locomotive.? We're not talking a 50GB download at 1.5Mb connection.? Small amount of data being retrieved, but it takes way too long.? Am I doing something wrong, or is this just how fast the Digitrax processor can work??

While attention is here, how come it is so confusing to set JMRI preferences with the DCS 240?? The latest digitrax system JMRI offers in the selection list is DCS200.? DCS240 has been around for a few years.? Why not include it??? I understand the DCS240 has an integrated PR3 or PR4, but it would be a lot easier just to select the system I have when selecting the system I have.? Kind of frustrating.

Thanks for your thoughts!!? I am not normally grumpy.


 

Thanks for replay David.? This is a brand new install, all the latest.? JMRI 4.12, DCS240 latest firmware.??

I also wish that I wouldn't be given 20 different options of decoders when I do "detect".? This system really can't tell the difference between a LokSound and LokPilot?? I'd think by now the decoder manufacturers would have ID codes embedded that positively identify exactly what decoder it is and that JMRI could read such data.?? I would prefer not to crack open my models to see exactly what's in there.? I literally am given 25 decoder options ranging from LokPilot 2 to LokPilot 4 and the various LokSound versions.??

On another model, auto detect shows it's a TCS decoder and gives me 12 options to pick from.? A1, A1X, DP2X, Function, MX series, 150 series, Tx series, V51+, X series, Z2, X w/BEMF, Mx series.? How does this help?? It shouldn't be this hard.

Kinda grumpy, but not always.? Just venting, I guess.


 

开云体育

The detect is dependent on the manufacturer identification and as you found not all use different values so JMRI only can do so much with limited data.?

David Klemm
Xs Max


From: [email protected] on behalf of tooooons@...
Sent: Saturday, December 8, 2018 19:23
To: [email protected]
Subject: Re: [jmriusers] JMRI / DCS240 set up question and why so slow?
?
Thanks for replay David.? This is a brand new install, all the latest.? JMRI 4.12, DCS240 latest firmware.??

I also wish that I wouldn't be given 20 different options of decoders when I do "detect".? This system really can't tell the difference between a LokSound and LokPilot?? I'd think by now the decoder manufacturers would have ID codes embedded that positively identify exactly what decoder it is and that JMRI could read such data.?? I would prefer not to crack open my models to see exactly what's in there.? I literally am given 25 decoder options ranging from LokPilot 2 to LokPilot 4 and the various LokSound versions.??

On another model, auto detect shows it's a TCS decoder and gives me 12 options to pick from.? A1, A1X, DP2X, Function, MX series, 150 series, Tx series, V51+, X series, Z2, X w/BEMF, Mx series.? How does this help?? It shouldn't be this hard.

Kinda grumpy, but not always.? Just venting, I guess.


 

开云体育

I have discovered that hitting read all sheets is basically fatal on ESU , all you can do is hit the write? the page and leave it at that .this was the solution given last time ESU was discussed?



Sent from my T-Mobile 4G LTE Device

开云体育

-------- Original message --------
From: David Klemm <davidklemm7511@...>
Date: 12/8/18 4:14 PM (GMT-08:00)
Subject: Re: [jmriusers] JMRI / DCS240 set up question and why so slow?

Tooooons,

What version of JMRI are you on? ?My guess it is to old to have the DCS240. My club uses a 240 and it is in the selection.?

And Loksound taking a long time is normal in my opinion given its complexity. Though later versions do better.?

David Klemm
Xs Max

From: [email protected] on behalf of tooooons@...
Sent: Saturday, December 8, 2018 17:53
To: [email protected]
Subject: [jmriusers] JMRI / DCS240 set up question and why so slow?
?
I have the latest JMRI installed on a Windows 10 64bit system, brand new USB cable, new Digitrax DCS240, and less than two feet of wire to the programming track.

It takes like 25-30 minutes to "read all sheets" from a LokSound Select decoder-equipped locomotive.? We're not talking a 50GB download at 1.5Mb connection.? Small amount of data being retrieved, but it takes way too long.? Am I doing something wrong, or is this just how fast the Digitrax processor can work??

While attention is here, how come it is so confusing to set JMRI preferences with the DCS 240?? The latest digitrax system JMRI offers in the selection list is DCS200.? DCS240 has been around for a few years.? Why not include it??? I understand the DCS240 has an integrated PR3 or PR4, but it would be a lot easier just to select the system I have when selecting the system I have.? Kind of frustrating.

Thanks for your thoughts!!? I am not normally grumpy.


 

If you are reading a LokSound V4 or Select decoder in Paged Mode, it will take 25-30 minutes. It should be about half that in Direct Mode.

These decoders have around 1,000 CVs and there are physical limitations on the speed of the NMRA CV access protocol, the speed of the decoder and the command station. We're not talking about anything like a 1.5Mbps connection, something more like several CVs per second.

Read All Sheets with some decoders (ESU included) can cause random read errors, due to a known but as yet unfixed issue in JMRI. Read Full Sheet on the CVs pane is a lot better as it avoids this problem. When done, sort by Status descending and keep hitting Read Changes on Sheet until no red entries remain.
--
Dave in Australia

On 9 Dec 2018, at 8:09 AM, tooooons@... wrote:

It takes like 25-30 minutes to "read all sheets" from a LokSound Select decoder-equipped locomotive. We're not talking a 50GB download at 1.5Mb connection. Small amount of data being retrieved, but it takes way too long. Am I doing something wrong, or is this just how fast the Digitrax processor can work?


 

I don't know who told you that, but it's very untrue. Most DCC systems are fine with ESU decoders. See my other posting.

Your solution is a sure recipe for disaster with ESU decoders!
--
Dave in Australia

On 9 Dec 2018, at 12:04 PM, Alfredo Escalante via Groups.Io <alfredo_escalante2001@...> wrote:

I have discovered that hitting read all sheets is basically fatal on ESU , all you can do is hit the write the page and leave it at that .this was the solution given last time ESU was discussed


 

I forgot to mention that there were some serious speed issues with reading ESU CVs on the DCS240 when it first came out.

My memory is that it was finally resolved and may have involved a DCS firmware update.

Someone else may be able to recall the details...
--
Dave in Australia

On 9 Dec 2018, at 1:09 PM, Dave Heap <dgheap@...> wrote:

If you are reading a LokSound V4 or Select decoder in Paged Mode, it will take 25-30 minutes. It should be about half that in Direct Mode.

These decoders have around 1,000 CVs and there are physical limitations on the speed of the NMRA CV access protocol, the speed of the decoder and the command station. We're not talking about anything like a 1.5Mbps connection, something more like several CVs per second.

Read All Sheets with some decoders (ESU included) can cause random read errors, due to a known but as yet unfixed issue in JMRI. Read Full Sheet on the CVs pane is a lot better as it avoids this problem. When done, sort by Status descending and keep hitting Read Changes on Sheet until no red entries remain.


 

When you say "detect" returns numerous options for loksound, I am not sure what you are doing.? You should use New Loco then? Auto Detect Decoder. And let it finish - dont jump the gun thinking it is finished when it may not be.... For Loksound, it will return the exact decoder you have. I have never had it give me a whole list of options. (What I dont know is if your command starion will be influencing that or not) That said, there are many - most - manufacturers especially older decoders that do not have identifying information in them. Sometimes you get a family of decoders to choose from. This is getting better with newer stuff.?

Also, when you say you have "all the latest" - 4.12 is older. The latest is 4.13.5 and very soon to be 4.13.6... yes 4.12 is considered the official production release. But enhancements and bug fixes and new decoders and new equipment definitions are constantly being added.

Loksound v4.0 and Select do take a long time to read and write. They have 1000 plus cvs.? Its the nature of the beast.

Tom Wilson
Colorado Springs, CO

On Sat, Dec 8, 2018, 6:23 PM <tooooons@... wrote:
Thanks for replay David.? This is a brand new install, all the latest.? JMRI 4.12, DCS240 latest firmware.??

I also wish that I wouldn't be given 20 different options of decoders when I do "detect".? This system really can't tell the difference between a LokSound and LokPilot?? I'd think by now the decoder manufacturers would have ID codes embedded that positively identify exactly what decoder it is and that JMRI could read such data.?? I would prefer not to crack open my models to see exactly what's in there.? I literally am given 25 decoder options ranging from LokPilot 2 to LokPilot 4 and the various LokSound versions.??

On another model, auto detect shows it's a TCS decoder and gives me 12 options to pick from.? A1, A1X, DP2X, Function, MX series, 150 series, Tx series, V51+, X series, Z2, X w/BEMF, Mx series.? How does this help?? It shouldn't be this hard.

Kinda grumpy, but not always.? Just venting, I guess.


 

You certainly have some setup-specific issues.

JMRI will uniquely identify any modern ESU decoder, except the Essential Sound Unit (because I can't complete the definition for it until ESU gets the time to address issues/queries I have reported). So all the V4/Select range will uniquely identify if you have the latest JMRI test version (I think I've added a few newly-released ProductIDs since V4.12).

It can't uniquely identify older decoders (V3.5 and earlier) because there's no way to do that using decoder CV reads.
--
Dave in Australia

On 9 Dec 2018, at 12:23 PM, tooooons@... wrote:

I also wish that I wouldn't be given 20 different options of decoders when I do "detect". This system really can't tell the difference between a LokSound and LokPilot? I'd think by now the decoder manufacturers would have ID codes embedded that positively identify exactly what decoder it is and that JMRI could read such data. I would prefer not to crack open my models to see exactly what's in there. I literally am given 25 decoder options ranging from LokPilot 2 to LokPilot 4 and the various LokSound versions.


 

Thanks for the replies.?? It turns out I had installed an older version, 2.14 unknowingly.? The user experience of the download page has some serious confusion for first time users.? I've since made a recommendation on the language.

As for slowness, it's still slow with JMRI 4.12 and Digitrax DCS240 selected. ? If the internet was ever this slow it never would have taken off.? I mean, reading/writing millions of bits in a matter of seconds over thousands of miles of cable is where we are at today.? The JMRI/Digitrax set up takes almost 10 seconds to read and display a page with only 8 settings with two total feet of conductor wire.

Digitrax was always slow to respond when programming directly with the controller, meaning no JMRI involvement at all.? So I guess this may be just a Digitrax thing.? These command stations could use Atom processors or something if computer-operated setups are going to thrive and grow.

Happy holidays everyone.


 

I think I now understand better why you have trouble with the logic of the download page instructions. Thanks again for the suggestions.

As to speed: Yes, there are hardware limits to how fast CVs can read. Since DecoderPro is software that uses that same hardware, it’s not any faster. You shouldn’t expect it to be.

Instead of trying to use DecoderPro in ways that it can’t improve, please think about how to use it in ways that work well: keep track of those values so you don’t have to read them from the decoder. Many people only ever do a full read of page once; some do it never at all. Instead they just write the things that they’ve changed.

Depending on the decoder, you might be able to use other programming modes that are faster. (You’ve assumption that the time is due to processor speed is wrong; it’s due to the time it takes to communicate over a slow DCC signal, so different forms of DCC packets can speed that up) For example, if the decoder can handle it (most do), Direct Mode is almost always faster than Paged Mode.

Bob

On Dec 21, 2018, at 11:28 AM, tooooons@... wrote:

Thanks for the replies. It turns out I had installed an older version, 2.14 unknowingly. The user experience of the download page has some serious confusion for first time users. I've since made a recommendation on the language.

As for slowness, it's still slow with JMRI 4.12 and Digitrax DCS240 selected. If the internet was ever this slow it never would have taken off. I mean, reading/writing millions of bits in a matter of seconds over thousands of miles of cable is where we are at today. The JMRI/Digitrax set up takes almost 10 seconds to read and display a page with only 8 settings with two total feet of conductor wire.

Digitrax was always slow to respond when programming directly with the controller, meaning no JMRI involvement at all. So I guess this may be just a Digitrax thing. These command stations could use Atom processors or something if computer-operated setups are going to thrive and grow.

Happy holidays everyone.
--
Bob Jacobsen
rgj1927@...


 

Thank you for replying.? I do direct byte programming wherever I go, thank you for that confirmation.?

It just perplexes me that the speed of communication between the controller and locomotive in a non-programming environment (say, setting speed step from 0 to 80, or turning a forward light on or off) is relatively instant, whereas reading a small packet of data in the programming environment is remarkably slow. ? ?? Even if there are 120 CV settings on one sheet, why can't the software create ONE string and send that data packet instead of individual packets for each string??? I don't expect there to be a simple answer, nor do I expect there to be ANY answer... just things I think about as I watch the reading/writing color bars do their thing on the screen during a read or write.

In the end, the computer interface for programming decoders is a great and necessary achievement over throttle programming.? Keep up the good work!


 

Reading CVs is not a simple case of asking for the value in a CV and reading the answer.? To read a CV the command station sends a packet to that CV with a value - usually starting a x'00' - and waiting to see if the decoder responds by pulsing the motor (the only way a decoder can respond) to indicate that is the value in the CV.? If it does not respond then the command station sends the next larger value - x'01' if it started at zero - and waits for a response.? If the CV has a high? number in it, say x'249' then it takes a long time to cycle through all the values to get a response.? As you can see, if you are reading a 1000 or so CV it will take a long time.? Some command stations like the Digitrax DCS100 will start at the last value acknowledged instead of always at 0 to try to reduce the time required.?

Dale Gloer


Jon Miller
 

开云体育

On 12/23/2018 7:50 AM, Dale Gloer wrote:
Some command stations like the Digitrax DCS100 will start at the last value acknowledged instead of always at 0 to try to reduce the time required.?

??? Stupid question but does the DCS240 also do this or did they change the software?

-- 
Jon Miller
For me time stopped in 1941
Digitrax  Chief/Zephyr systems, 
SPROG, JMRI User
NMRA Life member #2623
Member SFRH&MS


 

开云体育

Operations Mode
The NMRA DCC Standards S9.1, S9.2 & S9.2.1 define the technique for encoding bits and sending data packets to a decoder via the DCC track bus. This bipolar bit stream is also rectified to provide the loco power and is basically one-way, with no provision for decoder reply. S9.3.2 (RailCom) later provided for limited return communication by switching track power off briefly to allow a decoder to talk back using onboard stored power, however it is not widely used by either Decoder or command station/booster manufacturers.

Service Mode
The NMRA DCC Standard S9.2.3 defines Service Mode (program track). This is a separate isolated piece to track with current flow both limited and monitored. The command station can ask questions using DCC packets but then has to wait a limited amount of time for a response from the decoder. This response from the decoder consists of a single pulse of increased current draw (at least 60mA for 6ms), usually achieved by the decoder pulsing the motor on.

This means the only two possible responds are ACK (yes) or silence (time-out) taken to be a NACK (no).

For Paged Mode Reads, the only question that can be asked is:
- Is 'xxx' the value of 'CVnnnn'?
As others have pointed out, the worst case is that the command station has to wait 254 timeout intervals before it determines the correct answer (or 255 timeout intervals before it determines a no-reply).

For Direct Mode Reads, the two questions that can be asked are:
- Is bit 'x' of 'CVnnnn' set (1/on)?
- Is 'xxx' the value of 'CVnnnn'?
The worst case is that the command station has to wait 8 timeout intervals before it determines the correct answer (or 9 timeout intervals before it determines a no-reply).

These protocols and timings are defined in the NMRA DCC Standards and no amount of processing power in the command station or connected computer can overcome them.

--?
Dave in Australia

On 24 Dec 2018, at 2:28 AM, tooooons@... wrote:

It just perplexes me that the speed of communication between the controller and locomotive in a non-programming environment (say, setting speed step from 0 to 80, or turning a forward light on or off) is relatively instant, whereas reading a small packet of data in the programming environment is remarkably slow. ? ?? Even if there are 120 CV settings on one sheet, why can't the software create ONE string and send that data packet instead of individual packets for each string??? I don't expect there to be a simple answer, nor do I expect there to be ANY answer... just things I think about as I watch the reading/writing color bars do their thing on the screen during a read or write.


 

Thanks for the answer, Dave.? I appreciate your time.