Will Jmri Read Cv Values Higher Than 255
I have the latest JMRI installed on a Windows ten 64bit system, brand new USB cable, new Digitrax DCS240, and less than ii 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 i.5Mb connection. Pocket-size amount of data being retrieved, just it takes way as well long. Am I doing something wrong, or is this just how fast the Digitrax processor tin work?
While attention is here, how come information technology is so confusing to set JMRI preferences with the DCS 240? The latest digitrax system JMRI offers in the choice 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, just it would be a lot easier merely 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 information technology is to sometime to accept the DCS240. My guild 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.
toggle quoted messageShow quoted text
From: jmriusers@groups.io on behalf of tooooons@...
Sent: Saturday, December 8, 2018 17:53
To: jmriusers@groups.io
Subject field: [jmriusers] JMRI / DCS240 gear up up question and why and so slow?
I take the latest JMRI installed on a Windows 10 64bit organisation, make new USB cable, new Digitrax DCS240, and less than two anxiety 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 ane.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 and then disruptive to set JMRI preferences with the DCS 240? The latest digitrax system JMRI offers in the selection listing is DCS200. DCS240 has been around for a few years. Why not include it? I sympathise the DCS240 has an integrated PR3 or PR4, simply information technology would be a lot easier just to select the organisation I take when selecting the system I take. Kind of frustrating.
Thank you for your thoughts!! I am non 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 exist given xx different options of decoders when I do "detect". This system actually tin can't tell the deviation betwixt a LokSound and LokPilot? I'd think by at present the decoder manufacturers would have ID codes embedded that positively identify exactly what decoder information technology is and that JMRI could read such data. I would prefer non to crevice open my models to meet 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 observe shows information technology's a TCS decoder and gives me 12 options to pick from. A1, A1X, DP2X, Function, MX series, 150 serial, Tx series, V51+, Ten series, Z2, X w/BEMF, Mx serial. How does this aid? It shouldn't exist this hard.
Kinda grumpy, simply not always. But venting, I guess.
The detect is dependent on the manufacturer identification and as you institute not all use different values so JMRI only tin can do then much with limited data.
toggle quoted messageEvidence quoted text
From: jmriusers@groups.io on behalf of tooooons@...
Sent: Sat, Dec viii, 2018 nineteen:23
To: jmriusers@groups.io
Subject area: Re: [jmriusers] JMRI / DCS240 ready question and why and then wearisome?
Cheers for replay David. This is a brand new install, all the latest. JMRI iv.12, DCS240 latest firmware.
I also wish that I wouldn't be given xx different options of decoders when I do "observe". This system actually can't tell the difference between a LokSound and LokPilot? I'd think by now the decoder manufacturers would accept ID codes embedded that positively place exactly what decoder it is and that JMRI could read such information. I would prefer not to crack open my models to see exactly what's in at that place. I literally am given 25 decoder options ranging from LokPilot 2 to LokPilot four and the various LokSound versions.
On some other model, automobile find shows it'south a TCS decoder and gives me 12 options to selection from. A1, A1X, DP2X, Function, MX series, 150 series, Tx series, V51+, X series, Z2, X due west/BEMF, Mx serial. How does this help? It shouldn't be this hard.
Kinda grumpy, but not always. Only venting, I estimate.
I accept discovered that hit 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 final time ESU was discussed
Sent from my T-Mobile 4G LTE Device
toggle quoted bulletinBear witness quoted text
-------- Original message --------
From: David Klemm <davidklemm7511@...>
Date: 12/8/eighteen four:14 PM (GMT-08:00)
To: jmriusers@groups.io
Subject field: Re: [jmriusers] JMRI / DCS240 set up question and why so ho-hum?
Tooooons,
What version of JMRI are you on? My guess it is to old to take the DCS240. My lodge uses a 240 and it is in the selection.
And Loksound taking a long time is normal in my opinion given its complication. Though after versions practise better.
From: jmriusers@groups.io on behalf of tooooons@...
Sent: Saturday, Dec viii, 2018 17:53
To: jmriusers@groups.io
Subject: [jmriusers] JMRI / DCS240 set up question and why and so slow?
I have the latest JMRI installed on a Windows 10 64bit system, brand new USB cablevision, new Digitrax DCS240, and less than two anxiety of wire to the programming rail.
It takes like 25-xxx 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 attending is here, how come it is so confusing to set JMRI preferences with the DCS 240? The latest digitrax system JMRI offers in the option listing is DCS200. DCS240 has been effectually for a few years. Why not include it? I understand the DCS240 has an integrated PR3 or PR4, simply information technology would be a lot easier just to select the system I have when selecting the organisation I have. Kind of frustrating.
Thanks for your thoughts!! I am not ordinarily grumpy.
If you are reading a LokSound V4 or Select decoder in Paged Mode, it will take 25-30 minutes. Information technology should exist about half that in Direct Manner.
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 control station. Nosotros're not talking about anything like a ane.5Mbps connectedness, something more similar several CVs per 2d.
Read All Sheets with some decoders (ESU included) can crusade random read errors, due to a known simply as yet unfixed issue in JMRI. Read Full Sail on the CVs pane is a lot amend every bit it avoids this trouble. When washed, sort by Status descending and keep striking Read Changes on Sheet until no red entries remain.
--
Dave in Australia
toggle quoted bulletinProve quoted text
On nine Dec 2018, at eight:09 AM, tooooons@gmail.com wrote:Information technology takes like 25-xxx minutes to "read all sheets" from a LokSound Select decoder-equipped locomotive. We're non talking a 50GB download at ane.5Mb connectedness. Small amount of information being retrieved, merely it takes way as well long. Am I doing something incorrect, or is this only how fast the Digitrax processor tin can work?
I don't know who told y'all that, but information technology's very untrue. Well-nigh DCC systems are fine with ESU decoders. Run across my other posting.
Your solution is a sure recipe for disaster with ESU decoders!
--
Dave in Australia
toggle quoted bulletinShow quoted text
On 9 Dec 2018, at 12:04 PM, Alfredo Escalante via Groups.Io <alfredo_escalante2001=yahoo.com@groups.io> wrote:I have discovered that striking read all sheets is basically fatal on ESU , all you tin can exercise is hit the write the folio and leave it at that .this was the solution given concluding time ESU was discussed
I forgot to mention that at that place were some serious speed bug with reading ESU CVs on the DCS240 when it get-go came out.
My memory is that it was finally resolved and may have involved a DCS firmware update.
Someone else may be able to call up the details...
--
Dave in Australia
toggle quoted messageShow quoted text
On 9 Dec 2018, at 1:09 PM, Dave Heap <dgheap@gmail.com> wrote:If y'all 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 accept around one,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 one.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 equally even so unfixed issue in JMRI. Read Total Sail on the CVs pane is a lot improve as information technology avoids this trouble. When done, sort by Status descending and keep hitting Read Changes on Canvass until no reddish entries remain.
When you say "detect" returns numerous options for loksound, I am not sure what you are doing. You lot should use New Loco so Automobile Detect Decoder. And let it finish - dont jump the gun thinking it is finished when it may not be.... For Loksound, it volition render the exact decoder you have. I take never had information technology give me a whole listing of options. (What I dont know is if your command starion will exist influencing that or non) That said, at that place are many - most - manufacturers peculiarly older decoders that practice non take identifying information in them. Sometimes you get a family unit of decoders to choose from. This is getting better with newer stuff.
Also, when y'all say yous have "all the latest" - 4.12 is older. The latest is iv.13.5 and very soon to be 4.xiii.half-dozen... yes four.12 is considered the official production release. Only enhancements and problems fixes and new decoders and new equipment definitions are constantly being added.
Loksound v4.0 and Select do take a long fourth dimension to read and write. They have 1000 plus cvs. Its the nature of the beast.
Tom Wilson
Colorado Springs, CO
toggle quoted messageShow quoted text
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 exist given 20 unlike options of decoders when I do "detect". This organisation really can't tell the difference betwixt a LokSound and LokPilot? I'd retrieve past now the decoder manufacturers would have ID codes embedded that positively identify exactly what decoder information technology is and that JMRI could read such data. I would prefer not to fissure open my models to see exactly what's in at that place. 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 information technology's a TCS decoder and gives me 12 options to pick from. A1, A1X, DP2X, Function, MX series, 150 series, Tx series, V51+, 10 serial, Z2, 10 w/BEMF, Mx series. How does this help? It shouldn't be this difficult.
Kinda grumpy, but not e'er. Simply venting, I guess.
Y'all certainly have some setup-specific issues.
JMRI will uniquely identify any modern ESU decoder, except the Essential Audio Unit (considering I tin can't complete the definition for information technology until ESU gets the fourth dimension to address problems/queries I have reported). So all the V4/Select range will uniquely place if yous take the latest JMRI test version (I call up I've added a few newly-released ProductIDs since V4.12).
It tin can't uniquely identify older decoders (V3.5 and earlier) considering there'southward no way to exercise that using decoder CV reads.
--
Dave in Commonwealth of australia
toggle quoted messageShow quoted text
On ix December 2018, at 12:23 PM, tooooons@gmail.com wrote:I as well wish that I wouldn't be given 20 different options of decoders when I do "detect". This system really can't tell the deviation between a LokSound and LokPilot? I'd think past now the decoder manufacturers would have ID codes embedded that positively place exactly what decoder it is and that JMRI could read such data. I would prefer not to fissure 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.
Thank you for the replies. It turns out I had installed an older version, ii.14 unknowingly. The user experience of the download page has some serious defoliation for outset time users. I've since fabricated a recommendation on the linguistic communication.
As for slowness, it's still ho-hum with JMRI 4.12 and Digitrax DCS240 selected. If the net was ever this irksome information technology never would have taken off. I hateful, reading/writing millions of $.25 in a affair of seconds over thousands of miles of cable is where we are at today. The JMRI/Digitrax set up takes virtually ten seconds to read and brandish a page with only eight settings with two full feet of usher wire.
Digitrax was e'er dull to reply when programming directly with the controller, significant no JMRI involvement at all. So I judge this may exist just a Digitrax thing. These command stations could use Cantlet processors or something if calculator-operated setups are going to thrive and grow.
Happy holidays everyone.
Bob Jacobsen
I retrieve I now empathise ameliorate why you lot accept trouble with the logic of the download page instructions. Thanks once more for the suggestions.
As to speed: Yes, in that location are hardware limits to how fast CVs can read. Since DecoderPro is software that uses that same hardware, information technology's not whatever faster. You shouldn't expect it to be.
Instead of trying to apply DecoderPro in ways that it tin't improve, please remember most how to use it in ways that piece of work well: keep runway of those values so you don't take to read them from the decoder. Many people only ever exercise 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, y'all might exist able to apply other programming modes that are faster. (You've supposition that the time is due to processor speed is wrong; it'southward due to the time it takes to communicate over a tiresome DCC signal, so different forms of DCC packets tin speed that upwards) For example, if the decoder can handle it (well-nigh practice), Direct Style is almost always faster than Paged Manner.
Bob
On Dec 21, 2018, at 11:28 AM, tooooons@gmail.com wrote:Thanks for the replies. It turns out I had installed an older version, 2.14 unknowingly. The user feel of the download page has some serious confusion for start time users. I've since fabricated a recommendation on the language.
As for slowness, it's still tiresome with JMRI four.12 and Digitrax DCS240 selected. If the cyberspace was always this slow it never would take taken off. I mean, reading/writing millions of $.25 in a matter of seconds over thousands of miles of cablevision is where we are at today. The JMRI/Digitrax fix takes about 10 seconds to read and display a folio with only 8 settings with two total feet of conductor wire.
Digitrax was always wearisome to answer when programming directly with the controller, significant no JMRI involvement at all. So I gauge this may be simply a Digitrax thing. These command stations could use Atom processors or something if computer-operated setups are going to thrive and grow.
Happy holidays anybody.
--
Bob Jacobsen
rgj1927@gmail.com
Thanks for replying. I do direct byte programming wherever I go, thank you for that confirmation.
It only 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 low-cal on or off) is relatively instant, whereas reading a small package of data in the programming environment is remarkably tedious. Fifty-fifty if there are 120 CV settings on one sheet, why can't the software create One string and ship that information packet instead of individual packets for each string? I don't expect at that place to be a simple answer, nor practise I wait there to be Whatever answer... just things I think about every bit I picket 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 slap-up and necessary achievement over throttle programming. Keep upwardly the good work!
Dale Gloer
Reading CVs is not a uncomplicated case of asking for the value in a CV and reading the respond. To read a CV the command station sends a packet to that CV with a value - ordinarily starting a x'00' - and waiting to run into if the decoder responds by pulsing the motor (the only way a decoder tin respond) to indicate that is the value in the CV. If it does non answer and so the command station sends the side by side larger value - x'01' if it started at null - and waits for a response. If the CV has a high number in it, say 10'249' and so it takes a long time to wheel through all the values to get a response. As yous tin can see, if you are reading a 1000 or so CV information technology volition take a long time. Some command stations like the Digitrax DCS100 will starting time at the last value best-selling instead of always at 0 to effort to reduce the time required.
Dale Gloer
On 12/23/2018 seven:50 AM, Dale Gloer wrote:
Some command stations like the Digitrax DCS100 will start at the concluding value best-selling instead of ever at 0 to try to reduce the time required.
Stupid question just does the DCS240 as well exercise this or did they alter the software?
-- Jon Miller For me fourth dimension stopped in 1941 Digitrax Chief/Zephyr systems, SPROG, JMRI User NMRA Life member #2623 Member SFRH&MS
Operations Manner
The NMRA DCC Standards S9.one, S9.2 & S9.ii.i define the technique for encoding $.25 and sending data packets to a decoder via the DCC runway bus. This bipolar flake stream is also rectified to provide the loco ability and is basically 1-way, with no provision for decoder reply. S9.3.2 (RailCom) after provided for limited return communication past switching runway power off briefly to allow a decoder to talk back using onboard stored power, all the same it is not widely used by either Decoder or control station/booster manufacturers.
Service Mode
The NMRA DCC Standard S9.2.3 defines Service Mode (programme track). This is a split up isolated piece to rail with current flow both express and monitored. The command station can inquire questions using DCC packets but and then has to await 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), ordinarily achieved by the decoder pulsing the motor on.
This means the only two possible responds are ACK (aye) or silence (time-out) taken to be a NACK (no).
For Paged Mode Reads, the only question that tin be asked is:
- Is 'thirty' 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 right answer (or 255 timeout intervals earlier information technology determines a no-reply).
For Directly Mode Reads, the 2 questions that can be asked are:
- Is flake 'x' of 'CVnnnn' set (1/on)?
- Is 'xxx' the value of 'CVnnnn'?
The worst example is that the command station has to look eight timeout intervals earlier information technology determines the right reply (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.
toggle quoted messageShow quoted text
On 24 Dec 2018, at two:28 AM, tooooons@... wrote:
Information technology only perplexes me that the speed of communication betwixt the controller and locomotive in a non-programming environment (say, setting speed stride 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 at that place are 120 CV settings on i sheet, why tin can't the software create ONE string and send that data parcel instead of private packets for each string? I don't expect at that place to be a unproblematic respond, nor do I look at that place to be ANY answer... simply things I remember about as I sentry the reading/writing colour bars do their affair on the screen during a read or write.
Thanks for the respond, Dave. I appreciate your time.
Source: https://groups.io/g/jmriusers/topic/jmri_dcs240_set_up_question/28679938?p=
0 Response to "Will Jmri Read Cv Values Higher Than 255"
Enregistrer un commentaire