 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups General ModelsRailroadsRocketsRadio Controlled Air ModelsHelicoptersLand ModelsWater ModelsModelGeeks.com Contact UsLink To UsSearch & Site Map |
Model Forum / General / Railroads / January 2009What 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 > 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 [quoted text clipped - 3 lines] > > Carter Have you tried JRMI's "Read type from Decoder" option? It's on the same screen as the decoder selection for programming. Puckdropper  SignatureOn Usenet, no one can hear you laugh. That's a good thing, though, as some writers are incorrigible. To email me directly, send a message to puckdropper (at) fastmail.fm Yes, I used the decoder reader first and got more than a dozen possible responses... which is why I'm asking the group. Carter >> 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 [quoted text clipped - 8 lines] > > 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 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: >> Yes, I used the decoder reader first and got more than a dozen possible >> responses... which is why I'm asking the group. [quoted text clipped - 4 lines] > CV08 (the manufacturer) and CV07 (firmware version) and present any and > all decoders that match those two values. 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). Signature"I know I will go to hell, because I pardoned Richard Nixon." - Former President Gerald Ford to his golf partners, as related by the late Hunter S. Thompson > On 1/19/2009 7:33 PM Stevert spake thus: > [quoted text clipped - 18 lines] > 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 > > On 1/19/2009 7:33 PM Stevert spake thus: > > [quoted text clipped - 29 lines] > set aside for manufacturer use. Maybe one or more of them will get the > hint and use it thusly? We can only hope... 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. > Stevert > SignatureRobert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/ On 1/20/2009 5:51 PM Robert Heller spake thus: >> > On 1/19/2009 7:33 PM Stevert spake thus: >> > [quoted text clipped - 39 lines] > can handle headlights and ditch lights, and also a horn, and others > have elaborate sound features, etc. 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). Signature"I know I will go to hell, because I pardoned Richard Nixon." - Former President Gerald Ford to his golf partners, as related by the late Hunter S. Thompson > Question: > [quoted text clipped - 5 lines] > can handle headlights and ditch lights, and also a horn, and others > have elaborate sound features, etc. 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 > 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? 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). SignatureVenlig hilsen/Best regards Erik Olsen http://www.modelbaneteknik.dk/ > How much does it really matter that you know the make / model >of a DCC decoder for basic operation? Aren't the basic functions [quoted text clipped - 3 lines] >can handle headlights and ditch lights, and also a horn, and others >have elaborate sound features, etc. 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. * Signature* PV something like badgers--something like lizards--and something like corkscrews. >Wonder how hard that would be to implement over DCC; all you need is a >relatively small amount of data (< 1K). 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. * Signature* PV something like badgers--something like lizards--and something like corkscrews. On 1/21/2009 2:15 PM PV spake thus: >>Wonder how hard that would be to implement over DCC; all you need is a >>relatively small amount of data (< 1K). > > 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. 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? Signature"I know I will go to hell, because I pardoned Richard Nixon." - Former President Gerald Ford to his golf partners, as related by the late Hunter S. Thompson > On 1/21/2009 2:15 PM PV spake thus: > [quoted text clipped - 8 lines] > manageable under actual model railroad operating conditions? 256 > bytes? more? less? 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 SignatureOn Usenet, no one can hear you laugh. That's a good thing, though, as some writers are incorrigible. To email me directly, send a message to puckdropper (at) fastmail.fm >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? 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. * Signature* PV something like badgers--something like lizards--and something like corkscrews. On 1/22/2009 9:43 AM 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? [quoted text clipped - 15 lines] > 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. 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. > 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. * 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? Signature"I know I will go to hell, because I pardoned Richard Nixon." - Former President Gerald Ford to his golf partners, as related by the late Hunter S. Thompson >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? * Signature* PV something like badgers--something like lizards--and something like corkscrews. On 1/23/2009 11:48 AM PV spake thus: >>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? [quoted text clipped - 10 lines] > I've never looked into why ops mode is so much faster than normal readback. > Can someone here tell us? * 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) Signature"I know I will go to hell, because I pardoned Richard Nixon." - Former President Gerald Ford to his golf partners, as related by the late Hunter S. Thompson >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? It can be a little flaky (or even wildly innacurate), but you can use the "identify" function in decoderpro to find out. * Signature* PV something like badgers--something like lizards--and something like corkscrews. >but I don't know what kind of decoder Athearn builds into the >unit. Can anyone tell me what it is please?< They are MRC often called "pull" decoders. If you wonder about the word "pull" think in terms of skeet! |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2012 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.