|
I really like Decoder Pro. But, the ESU Programmer is significantly faster at reading/writing ESU decoders. Is there a command station or other computer to DCC interface that I can use with JMRI Decoder Pro that would give me similar read/write as the ESU Programmer?
?
It is my understanding that the weak link of decoder pro is the computer to track interface.
--
|
Heath,
?
The NMRA method of ‘reading’ CV values is the JMRI read time ‘weak link.’
?
The LokProgrammer uses a proprietary method for quickly reading and writing CV values.? ?However, LokProgrammer isn’t compatible with JMRI.
?
FWIW – you can read the CV values with LokProgrammer, then export them to a file that can be imported into JMRI.? ?
?
Ross
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Human[c]ity Junction
Sent: Wednesday, March 19, 2025 8:18 PM
To: [email protected]
Subject: [jmriusers] Best Command Station to use with Decoder Pro
?
I really like Decoder Pro. But, the ESU Programmer is significantly faster at reading/writing ESU decoders. Is there a command station or other computer to DCC interface that I can use with JMRI Decoder Pro that would give me similar read/write
as the ESU Programmer?
It is my understanding that the weak link of decoder pro is the computer to track interface.
|
Standard DCC is a one-way protocol: [NMRA] standard DCC command stations can only send messages to DCC decoders and DCC decoders cannot send messages to [NMRA] standard DCC command stations (yes, there is RailCom, but that is something different). Normally, DCC decoder CVs cannot be directly "read". Reading CVs is done via a trick. The DCC command station asks if a bit is a one or zero and the decoder does (or does not) run the motor a little if the bit is a one and the command station detects the slight current draw. To read a CV byte, the DCC command station asks 8 times, once for each bit in the byte. This process takes time. All [NMRA] standard DCC command stations do this the same way, so all take the same amount of time. At Wed, 19 Mar 2025 17:17:52 -0700 "Human[c]ity Junction" <heath@...> wrote:
I really like Decoder Pro. But, the ESU Programmer is significantly faster at reading/writing ESU decoders. Is there a command station or other computer to DCC interface that I can use with JMRI Decoder Pro that would give me similar read/write as the ESU Programmer?
It is my understanding that the weak link of decoder pro is the computer to track interface.
--
Heath @ Human[c]ity
( )
( )
( )
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
Heath,
?
?Not a command station, but my PR4 will reliably read all the CV's on a LokSound in about 20-25 minutes. That's not as fast as the LokProgrammer, because as Ross pointed out, the LokProgrammer uses a proprietary method. But it is quicker than at least some command stations.
?
What I did before the PR4, and still do to a lesser extent, is open the CV's tab and tell it to read the page. Then I find something else to busy myself with until it finishes.
?
HTH,
Steve
"Breezlys"
?
?
?
?
|
Thank You all for the very informative answers.
--
|
All,
?
I've used a SPROG 3 for several years now as my programming track interface to DecoderPro. Has been very reliable.
?
Regards
|
But, how often do you need to read all cvs anyway??
I typically do it ONCE per decoder, so the wait isn’t that onerous - even with a Ras Pi.
toggle quoted message
Show quoted text
On 20 Mar 2025, at 01:34, Breezlys via groups.io <livinthelife@...> wrote:
?
Heath,
?
?Not a command station, but my PR4 will reliably read all the CV's on a LokSound in about 20-25 minutes. That's not as fast as the LokProgrammer, because as Ross pointed out, the LokProgrammer uses a proprietary method. But it is quicker than at least
some command stations.
?
What I did before the PR4, and still do to a lesser extent, is open the CV's tab and tell it to read the page. Then I find something else to busy myself with until it finishes.
?
HTH,
Steve
"Breezlys"
?
?
?
?
|
As others have said, the ESU Programmer uses a proprietary closed method to communicate.?
The fastest route for decoders that support RailCom (includes ESU) via JMRI is a Command Station which supports Programming on the main Read by using RailCom.? ?That is massively quicker than any service mode (programming track) reading of a decoder.?
? There are several Command Stations which do this which are supported by JMRI.??
- Nigel
toggle quoted message
Show quoted text
------ Original Message ------
Date 20/03/2025 00:17:52
Subject [jmriusers] Best Command Station to use with Decoder Pro
I really like Decoder Pro. But, the ESU Programmer is significantly faster at reading/writing ESU decoders. Is there a command station or other computer to DCC interface that I can use with JMRI Decoder Pro that would give me similar read/write as the
ESU Programmer?
?
It is my understanding that the weak link of decoder pro is the computer to track interface.
--
|
Guys,
I have also used a SPROG 3 for many years - never
let me down.
Gerry
On 20/03/2025 4:37 pm, Don Shroyer via
groups.io wrote:
All,
?
I've used a SPROG 3 for several years now as my programming
track interface to DecoderPro. Has been very reliable.
?
Regards
--
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder
|
Heath, ? I’ve been very happy with my TCS LT-50 using RailCom and LCC to interface with it. I can read LokSound decoders in under 5 minutes that way. ? -Ken Cameron, Member JMRI Dev Team
? ?
|
Crew:
Not reading the entire thread...
If sound loading or modification is a needed function the the Lok programmer is a must and independent of your DCC system...
Gotca is that Lok software is Windows only that might be the bigger issue. Anyone on Linux ever get it running under WINE?
Jim
|
Heath, As others have indicated, the LokProgrammer is faster because it only works with ESU decoders. Kinda like that question you asked about function labels and BLI. Single manufacturer means special methods can be used. DecoderPro uses the NMRA method because it has to work with a wide range of manufacturer decoders. I have read that there is faster reads IF (1) you have a Railcom enabled command station AND (2) the decoder is Railcom capable and enabled. It also allows reads using POM.
Mark Granville
|
On 3/20/2025 9:29 AM, Mark Granville wrote: Heath, As others have indicated, the LokProgrammer is faster because it only works with ESU decoders. Kinda like that question you asked about function labels and BLI. Single manufacturer means special methods can be used. DecoderPro uses the NMRA method because it has to work with a wide range of manufacturer decoders. I have read that there is faster reads IF (1) you have a Railcom enabled command station AND (2) the decoder is Railcom capable and enabled. It also allows reads using POM. _Or_ if you have: - a LocoNet system, and - Digitrax "Transponding" equipment, and - a mobile decoder that supports Digitrax "Transponding", and - the decoder has its "Transponding" feature enabled, and - that decoder is in a "transponding-enabled" track section, method. In this particular situation, mobile decoder CV reads are MUCH quicker than with "Service-mode" CV reads.
|
Mark,
The difference with RailCom is that it is part of the
NMRA specifications, not proprietary, and it may be supported by
any manufacturer. As far as I know TCS and MRC (NEXXT) are the
only US manufacturers either supporting, or planning for RailCom
support. That is a manufacturer's marketing choice, and the
European companies have chosen to support it for some time. It is
probably supported by more systems than not. (at least recently)
Note that ESU decoders support RailCom, not just their own closed
ecosystem. The chances are pretty good that if you have a loco
with a modern European decoder, it already includes RailCom.
By ignoring RailCom the big US companies have effectively kept it
hidden from the US market place. Then they excuse themselves by
claiming that their users don't ask for it. Duh!
Dick :)
On 3/20/2025 9:29 AM, Mark Granville
wrote:
toggle quoted message
Show quoted text
Heath, As others have
indicated, the LokProgrammer is faster because it only works
with ESU decoders. Kinda like that question you asked about
function labels and BLI. Single manufacturer means special
methods can be used. DecoderPro uses the NMRA method because
it has to work with a wide range of manufacturer decoders. I
have read that there is faster reads IF (1) you have a
Railcom enabled command station AND (2) the decoder is
Railcom capable and enabled. It also allows reads using POM.
Mark Granville
|
Billybob, Yes, transponding also. But is that another single manufacturer thing? Who else but Digitrax makes decoders with Digitrax transponding?
Mark
|
Dick, Good point about Railcom and NMRA. As I understand it, Railcom became an RP in 1997 and didn’t become a standard until 2012. Even then, the standard underwent extensive revision in 2021.
Why haven’t manufacturers like Digitrax and NCE upgraded to include this in their command stations? Who knows. I guess Digitrax doesn’t want to compete with its transponding. I have used an NCE PowerHouse since 1998 when I wouldn’t have expected Railcom. I can’t tell from their web site if the new PowerPro system has Railcom capability, but with a price of $1K, the TCS system isn’t looking too bad.
Mark
|
On Thu, Mar 20, 2025 at 07:34 AM, dick bronson wrote:
The difference with RailCom is that it is part of the NMRA specifications, not proprietary, and it may be supported by any manufacturer. As far as I know TCS and MRC (NEXXT) are the only US manufacturers either supporting, or planning for RailCom support. That is a manufacturer's marketing choice, and the European companies have chosen to support it for some time. It is probably supported by more systems than not. (at least recently) Note that ESU decoders support RailCom, not just their own closed ecosystem. The chances are pretty good that if you have a loco with a modern European decoder, it already includes RailCom.
My understanding is that the ESU decoders support RailCom+, which I understand is a proprietary extension of RailCom specific to ESU.? Does this mean that in fact ESU decoders support RailCom as well?? I have recently purchased an ESU Cab Control command station and am waiting for it to be delivered.? Will this command station be able to read ESU decoders faster than my current Digitrax DCS52 system?
--
Tom
|
On Wed, Mar 19, 2025 at 06:32 PM, Robert Heller wrote:
DCC decoder CVs cannot be directly "read".
Reading CVs is done via a trick. The DCC command station asks if a bit is a
one or zero and the decoder does (or does not) run the motor a little if the
bit is a one and the command station detects the slight current draw. To read
a CV byte, the DCC command station asks 8 times, once for each bit in the
byte.
This is very informative.? I always wondered why the locomotive motor has to turn when reading CVs and why it takes so long.??
--
Tom
|
Yes,? ESU decoders support "ordinary RailCom".? The "+" part is additional capabilities.? ? ??
RailCom+ (mostly automatic decoder registration with command station) is part of the RailCommunity standards for DCC.? ?RailCommunity are the standards body for European manufacturers, setting out what DCC does and doesn't do: most of
the documentation is in German.? ?Give it a few years and the NMRA will copy a translation of RailCommunity standard, and call it a NMRA standard....
Nigel.?
toggle quoted message
Show quoted text
------ Original Message ------
From "Tom Myrick via groups.io" < jmri@...> Date 20/03/2025 17:45:09
Subject Re: [jmriusers] Best Command Station to use with Decoder Pro
On Thu, Mar 20, 2025 at 07:34 AM, dick bronson wrote:
The difference with RailCom is that it is part of the NMRA specifications, not proprietary, and it may be supported by any manufacturer. As far as I know TCS and MRC (NEXXT) are the only US manufacturers either supporting, or planning
for RailCom support. That is a manufacturer's marketing choice, and the European companies have chosen to support it for some time. It is probably supported by more systems than not. (at least recently) Note that ESU decoders support RailCom, not just their
own closed ecosystem. The chances are pretty good that if you have a loco with a modern European decoder, it already includes RailCom.
My understanding is that the ESU decoders support RailCom+, which I understand is a proprietary extension of RailCom specific to ESU.? Does this mean that in fact ESU decoders support RailCom as well?? I have recently purchased an ESU Cab Control command
station and am waiting for it to be delivered.? Will this command station be able to read ESU decoders faster than my current Digitrax DCS52 system?
--
Tom
|
Mark,
You probably will not read this in MR, so do I dare to publicly
post this info about what folks are missing out on here in the US
of A? <G>?
Hopefully it is not too far off topic from the original poster's
question.
Decoder Manufacturers Supporting RailCom:
- Lenz Elektronik – The creators of
RailCom; their Gold and Silver series decoders fully support it.
- ESU (Electronic Solutions Ulm) – Many
LokPilot and LokSound decoders
support RailCom.
- ZIMO – Almost all of their decoders
are RailCom-compatible.
- TAMS Elektronik – Offers
RailCom-compatible decoders.
- Doehler & Haass – Many of their
decoders support RailCom.
- Train-O-Matic – Their decoders support
RailCom functionality.
- Train Control Systems – Some TCS
decoders support RailCom.
- Kuehn – Some decoders support RailCom.
- Uhlenbrock – Some decoders support
RailCom.
RailCom Compatible Command Stations:
-
Lenz – LZV200 (successor to LZV100)
- Developed by the creators
of RailCom. Full support for RailCom feedback and
addressing.
-
ZIMO – MX10
- High-end DCC system with
full RailCom support, including feedback and decoder
programming.
-
ESU – ECoS 2 (50210, 50200)
- Supports RailCom and
RailCom Plus for automatic train detection and feedback.
-
TAMS Elektronik – RedBox
- A lesser-known command
station that fully supports RailCom.
-
TCS CS-105
- This command station from
Train Control Systems also supports RailCom.?
- This system also offers
global RailCom transmissions over LCC for supporting
boosters, enhancing bi-directional communication
capabilities to include booster districts as well.
-
MRC – NEXXT
- I am including MRC in this
list, because their (announced) NEXXT command system
includes plans for support of both RailCom and LCC, even
though it is not yet available.
Apparently some other European command
stations, e.g. Roco Z21, may be upgraded to RailCom with the
appropriate add-ons.?
The openDCC project supports RailCom
via the Open DCC GBM command station.
Do not confuse RailCom and RailCom
Plus, which as far as I know, is not an NMRA standard, so I
suppose that it should be classed along with other proprietary
options.
I'm sure that this info is probably
wrong at some points, so others feel free to update/correct it.
Dick :)
On 3/20/2025 12:48 PM, Mark Granville
wrote:
toggle quoted message
Show quoted text
Dick, Good point about
Railcom and NMRA. As I understand it, Railcom became an RP
in 1997 and didn’t become a standard until 2012. Even then,
the standard underwent extensive revision in 2021.
Why haven’t manufacturers like Digitrax and NCE upgraded to
include this in their command stations? Who knows. I guess
Digitrax doesn’t want to compete with its transponding. I
have used an NCE PowerHouse since 1998 when I wouldn’t have
expected Railcom. I can’t tell from their web site if the
new PowerPro system has Railcom capability, but with a price
of $1K, the TCS system isn’t looking too bad.
Mark
|
Heath @ Human[c]ity Junction
Ken Cameron
Tom Myrick