What decoder do they use?

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Have you tried JRMI's "Read type from Decoder" option? It's on the same screen as the decoder selection for programming.
Puckdropper
--
On Usenet, no one can hear you laugh. That's a good thing, though, as
some writers are incorrigible.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jeff Dippel wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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 know I will go to hell, because I pardoned Richard Nixon."

- Former President Gerald Ford to his golf partners, as related by
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
David Nebenzahl wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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).
--
"I know I will go to hell, because I pardoned Richard Nixon."

- Former President Gerald Ford to his golf partners, as related by
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Robert Heller wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Robert Heller wrote:

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).
--
Venlig hilsen/Best regards
Erik Olsen
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?
--
"I know I will go to hell, because I pardoned Richard Nixon."

- Former President Gerald Ford to his golf partners, as related by
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
writes:

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.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?
--
"I know I will go to hell, because I pardoned Richard Nixon."

- Former President Gerald Ford to his golf partners, as related by
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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:
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
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

It can be a little flaky (or even wildly innacurate), but you can use the "identify" function in decoderpro to find out. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

They are MRC often called "pull" decoders. If you wonder about the word "pull" think in terms of skeet!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.