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

Reply to
Jeff Dippel
Loading thread data ...

"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

Reply to
Puckdropper

Yes, I used the decoder reader first and got more than a dozen possible responses... which is why I'm asking the group.

Carter

Reply to
Jeff Dippel

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

Reply to
Stevert

It can be a little flaky (or even wildly innacurate), but you can use the "identify" function in decoderpro to find out. *

Reply to
PV

Reply to
Jon Miller

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).

Reply to
David Nebenzahl

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

Reply to
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.

Reply to
Robert Heller

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).

Reply to
David Nebenzahl

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

Reply to
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).

Reply to
Erik Olsen

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. *

Reply to
PV

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. *

Reply to
PV

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?

Reply to
David Nebenzahl

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

Reply to
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. *

Reply to
PV

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?

Reply to
David Nebenzahl

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? *

Reply to
PV

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:

formatting link

Reply to
David Nebenzahl

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.