Yes, I used the decoder reader first and got more than a dozen possible
responses... which is why I'm asking the group.
Carter
"Puckdropper" <puckdropper(at)yahoo(dot)com> wrote in message
The reason for that is because MRC uses the same firmware revision
(32) for several of it's decoders. That's a common situations, it
happens with other manufacturers as well. All JMRI can do is read the
CV08 (the manufacturer) and CV07 (firmware version) and present any and
all decoders that match those two values.
Anyway, I don't have any MRC decoders (I refuse to buy them), but
looking at JMRI it would appear that one of the selections it's offering
you should be "Athearn Genesis F Unit" That's the one I'd use.
HTH,
Stevert
Too bad DCC doesn't have something like the SCSI "inquiry" command.
Thing o' beauty: if you have an unknown SCSI device on a working bus,
you can always hit it with the INQUIRY command and the device will
respond and tell you who and what it is. In addition to the model,
manufacturer, firmware rev., etc., it will tell you what type of device
(fixed storage, removeable storage, scanner, etc.) it is, and even if
you don't know how to address the specific device, you can treat it as a
"generic" device of whatever type it is and actually use the damn thing.
Wonder how hard that would be to implement over DCC; all you need is a
relatively small amount of data (< 1K).
--
"I know I will go to hell, because I pardoned Richard Nixon."
- Former President Gerald Ford to his golf partners, as related by
I've never owned any SCSI devices and wasn't aware of those
abilities. Pretty neat!
As for decoders, since they already have a manufacturer ID and
firmware version, all you'd really need is a specific model designation.
I agree, it wouldn't be hard at all to implement.
I believe that the DCC standards (or RP's?) have some "user areas"
set aside for manufacturer use. Maybe one or more of them will get the
hint and use it thusly? We can only hope...
Stevert
Question:
How much does it really matter that you know the make / model
of a DCC decoder for basic operation? Aren't the basic functions
standard? Eg. the speed and direction registers and so on? Yes, I
would imagine the 'extra' functions would be specific to this decoder
or that (i.e. some decoders can only handle just the headlights, others
can handle headlights and ditch lights, and also a horn, and others
have elaborate sound features, etc.
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
I guess the answer is "it doesn't really matter, so long as I know the
capabilities of the decoder". So maybe it would be good to have a
standard way of discovering the decoder's capabilities, perhaps some
bit-mapped fields indicating support for various kinds of lights, etc.
Again, something done long ago in SCSI (and other protocols as well).
--
"I know I will go to hell, because I pardoned Richard Nixon."
- Former President Gerald Ford to his golf partners, as related by
You're confusing "functions" (horn, bell, lights, etc) with CV
(configuration variable) settings.
Different decoders have different abilities that can be tailored to
behave differently, and that tailoring is done by changing the values
stored in CV's. Also, the NMRA has given the decoder manufacturers
quite a bit of leeway with *how* the CV's can be used to tailor that
behavior. So CV settings that work well for one decoder may not work at
all for another.
And that's the whole point here, to be able to use JMRI to accurately
identify, describe, and set the CV's for a particular decoder, and then
save a copy of those settings.
Sure, you can select the default address with your DCC system, run
the loco with all the default settings and never be concerned with
changing the value of a CV. But considering that the OP even asked the
question in the first place I don't think that's his intention.
Stevert
An example:
Setting the locomotive speed may be done in two different ways. Not all
decoders use the Vstart (CV2), Vmid (CV6) and Vhigh (CV5) speed settings
but require a speed table.
See
http://www.nmra.org/standards/DCC/standards_rps/RP-9.2.2%202007%20July.pdf
for which CVs are Mandatory (M), Recommended (R) or Optional (O).
It's the extra functions that you want to know about, but even some basic
things, like the number of supported speed steps, aren't something you can
ask the decoder to tell you and get a reasonable answer. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.
Given the horrifying way readback works, 1K worth of data would be no fun
at all on a programming track. It would be practical over loconet in ops
mode though.
The feature set wouldn't be a problem if manufacturers actually maintained
good numbers for the product ID CVs, but they get reused, left unset,
or set WRONG, in many cases. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.
So what's your guess as to the maximum amount of data that would be
manageable under actual model railroad operating conditions? 256 bytes?
more? less?
--
"I know I will go to hell, because I pardoned Richard Nixon."
- Former President Gerald Ford to his golf partners, as related by
Less. Given how long I've waited to read back a few locomotive addresses
(like 9900), and that's only 3 bytes (CVs 29, 17, 18 I think), readback
of anything more would take a long time.
As I understand it, readback works like this:
CS: Decoder
Does CV 29=0 No pulse
Does CV 29=1 No pulse
Does CV 29=2 No pulse
Does CV 29=3 No pulse
Does CV 29=4 Motor pulses
There's much faster ways to do readback, if you simply look at the values
as the bits that make them up.
Puckdropper
--
On Usenet, no one can hear you laugh. That's a good thing, though, as
some writers are incorrigible.
There's no maximum, but because of how readback functions, it would be
crazy to send even that much on a programming track. Readback of just one
byte of CV goes like this:
Booster: Hey decoder, is your CV#1 set to 0?
Decoder: (no answer)
Booster: Hey decoder, is your CV#1 set to 1?
Decoder: (no answer)
...
Booster: Hey decoder, is your CV#1 set to 253?
Decoder: Huh, what? Did you say something?
Booster: Aha! Got it!
Lather, rinse, repeat for each byte, averaging 128 tries per byte. I'd say
this is no way to run a railroad, but, er, well.
If you wanted to have a feature like this, the much superior ops mode
interactions, which are relayed via loconet, would work a lot better. I
think it's still sent sorta-kinda like this, but it seems to be much
faster. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.
Ops mode is addressed programming sent to decoders on the rails while the
layout is in normal operation. You can read or write CVs (it's great for
fiddling with speed tables or starting voltages) directly, and instead of
it taking several seconds, you can generally get a good chunk of them in an
eyeblink. These days, unless I'm dealing with an ancient decoder that
doesn't support it, the only thing I ever do on the programming track is
set the address. After that I move it to the layout and do any other fancy
stuff there.
I've never looked into why ops mode is so much faster than normal readback.
Can someone here tell us? *
--
* PV something like badgers--something like lizards--and something
like corkscrews.
Not sure, but I *think* I may actually have found it in the forest of
NMRA RPs and stuff on their DCC pages:
http://www.nmra.org/standards/DCC/standards_rps/RP-921%202006%20Aug%2021.pdf
Apparently "ops mode" is the widely-used jargon for what they
technically refer to as "configuration variable access
instructions--long form". From what I can gather, these instructions:
o Can write (modify), verify, or write or verify bits in a configuration
variable (1 byte at a time)
o Require 2 consecutive "hits" before the instruction actually "takes"
(apparently a safety feature to avoid bogus settings due to noise)
Actually, it's very frustrating, as this document refers numerous times
to "operations-mode acknowledgement", but never defines the term (at
least so far as I could find).
After further reading, it seems that this term *is* defined in RP-9.3.1
and RP-9.3.2, but since I haven't downloaded those PDFs yet I can't say
anything about them. (You can check the "Standards & Recommended
Practices Index" if you're interested:
http://www.nmra.org/standards/DCC/standards_rps/DCCStds.html )
--
"I know I will go to hell, because I pardoned Richard Nixon."
- Former President Gerald Ford to his golf partners, as related by
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.