I want to program my Genesis G1014 Southern Pacific F-7A Phase 1 using the
JMRI program but I don't know what kind of decoder Athearn builds into the
unit. Can anyone tell me what it is please?
Thank you
Carter
"Jeff Dippel" wrote in
news:tr7dl.9232$ snipped-for-privacy@flpi149.ffdc.sbc.com:
Have you tried JRMI's "Read type from Decoder" option? It's on the same
screen as the decoder selection for programming.
Puckdropper
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
On 1/19/2009 7:33 PM Stevert spake thus:
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'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.
On 1/20/2009 5:51 PM Robert Heller spake thus:
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).
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
formatting link
for which CVs are Mandatory (M), Recommended (R) or Optional (O).
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. *
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. *
On 1/21/2009 2:15 PM PV spake thus:
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?
David Nebenzahl wrote in
news:4977cc5b$0$25697$ snipped-for-privacy@news.adtechcomputers.com:
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
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. *
On 1/22/2009 9:43 AM PV spake thus:
Got it. Thanks for that.
I don't know what came over me trying to compare a fast, bidirectional
synchronous, *reliable* data bus (SCSI) to DCC.
I don't know anything about "ops mode"; have to look that up. Is it
available when trains are running or only when using a programming track?
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? *
On 1/23/2009 11:48 AM PV spake thus:
Not sure, but I *think* I may actually have found it in the forest of
NMRA RPs and stuff on their DCC pages:
formatting link
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:
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.