Mike
I may have spoken too soon. The 82 ohm resistor cured my problem with
SoundTraxx decoders but I still can't read values from Digitrax decoders.
I've tried resistors from 68 to 150 ohms with no luck on DH121s and DN121s.
Any other ideas.
Thanks
Stony
toggle quoted message
Show quoted text
----- Original Message ----- From: "Mike Davison" <davison@...> To: <jmriusers@...>; "buchcty" <stony611@...> Sent: Sunday, August 04, 2002 12:05 PM Subject: Re: [jmriusers] Easy DCC
You may need to install a resistor between the CS and the programming
track. The comment from CVP was:
A reading of all 0's means there is excess amount of current consumed ' by the loco being programmed. The CS can't distinguish the motor
pulse from the idle current.
Before moving to the programming track, turn off all lamps and mute
the loco sound.
If still unable to "read" then insert a series resistance as shown
in the manual for MRC decoders. This may desensitize the programming
track circuit so the motor pulse can be seen above the idle current.
But this will be a trial and error determination of the value - try
75 ohms to start.
I think I have a 100 ohm resistor in place now. I did not find that turning off the lights/etc before programming made any difference.
Mike
On Saturday 03 August 2002 11:13 pm, buchcty wrote:
Hello
I'm new to the list and the JMRI Decoder Pro program. I've installed
Ver. 1 on a Win98 machine and I have inconsistant results with my
easyDCC. When trying to read values from a Digitrax DH121, DN121 or
Soundtrax LC100 it returns all 0s or times out reading each CV. A
Lenz LE103XF works like a champ, the neatest thing I've ever seen.
I would also like to install Decoder Pro on a Linux machine but I'm
not Linux smart enough to do it without an RPM.
Does any one have any ideas about the easyDCC interface?
Thanks
Stony
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: Varieties of Digitrax Decoders
Bob,
Let me first say that while the decoders under discussion belong to Digitrax there are other decoder manufacturers that are effected in the same way.
This is just a suggestion and works in concept on paper. Earlier this summer I started working on the idea of a DCC comparision web site. Depending on the type of DCC hardware under comparison I have grouped things differently.
In the area of Command stations I have two divisions:
a) entry level
b) full feature
In the area of decoders I have five divisions:
a) N/Z scale decoders
b) HO/O scale decoders
c) Large scale decoders
d) Function Only decoders
e) Stationary decoders
In my comment section of the decoder areas I have a statement that scale is not the only factor in choosing a decoder. I know many HO scale modelers that are using N/Z scale decoders. This usually happens when dealing with small locomotives. As an example several years ago I gave Don Crano a working HO scale Gandy Dancer. It is almost impossible to install a HO scale decoder in it but a Z scale might work just fine.
There is a problem in the standards when dealing with CV7. The Recommended Practices RP-9.2.2 only define CV7 as "This is reserved for the manufacturer to store information regarding the version of the decoder". It does not define how the manufacturer must use it. It RP allows the manufacturer use or not use this space as he sees fit. This allows the each manufacturer to make up their own rules for what is placed in CV7. It even allows for the manufacturer to change their mind. In my opinion at this time CV7 is worthless and should not be used in assisting to identify the decoder.
As I side note I have heard a rummor on several occasions that the NMRA DCC WG has discussed this problem but has not found a solution. I have heard that a solution discussed was the addtion of another recommended CV. In several of these rumors CV7 was to be the model of the decoder and the other CV would be related to the firmware issue and any subsequent changes to the hardware. Of course the manufacturers will have to change the rules they use to insure that the CV7 and this other CV are updated as a change in the decoder is implemented.
Just a few thoughts on my part.
Al
|
Locked
Re: Coping with the user-fiendish features of the DZ121
Bob Jacobsen wrote: At 3:15 PM -0700 7/31/02, Jon Miller described a nasty feature of the DZ121:
It basically says that anytime you reprogram CV01 (the 2digit address), the
DZ121 automatically resets several CVs. The key here is the reset doesn't
happen during programming, it happens the first time the DZ121 powers up on
the layout in normal mode. So if you use the PR1 to program your values and
change CV01, using the PR1 to read back the data shows everything as you
would expect. In other words, it confirms everything was programmed as you
requested. But when you carry the loco to the layout and place it on the
track, the DZ121 powers up, detects the CV01 change and resets the following
CVs ... The nasty thing about this is that there's no way for DecoderPro to
fix it while the decoder is on the programming track; the CVs are
changed when you _later_ power the decoder. At that point, it's too
late for the program to fix the values.
Can anybody think of a good way to cope with this? I guess the problem solution depends on the command station. With NCE, you can cycle power on the programming track allowing you to work around this. I cannot say absolutely about the others but it should be possible too since the service mode programming track is supposed to be unpowered when you put the locomotive on it and then enable the programing. Clearly this will not work with a system that do not support service mode tracks. This get things complicated since now we have a decoder pane response that depends on a command station. Maybe what you do is define a command that called reset that can be added to the XML files as part of the script in some way. When the command is called, a dialog box pops up and says resetting the programming track and goes away when it is done. But if the command cannot be implemented because the command station does not support it, it tells the user what to do manually instead. Best Regards, Mark Gurries Linear Technology Power Supply & Battery charger Applications Engineer/Manager --------------------------------------------------------- Model Railroad Club and NMRA DCC presentations are at: -------------------------------------------------------- Audio Enthusiast (Love SAE equipment) ----------------------------------------------------------
|
Locked
Re: Varieties of Digitrax decoders
Comments below Bob Jacobsen wrote: <snip> The "families" originally grew out of noticing that a manufacturer
would have the same CVs in a lot of different models. Sometimes the
models were just different in wiring harness, e.g. DH142AT vs DH142,
but other times you couldn't really tell from the number that they
were related. To save costs, manufacturers often put the exact
same processor chip & code in different decoder models which vary
only in the shape of the PC board, size and number of output drivers,
etc.
So the idea of the family was that if you knew you had a "FX"
decoder, you wouldn't have to worry so much _which_ decoder it was,
you could just select the family as a whole. This also helped with
the problem of automatic identification, which can't tell all those
models apart based on the CV values they contain (because the
processor is saying the same thing).
We went through several different approaches to manually selecting
decoders before getting to the tree method you see now. The original
single list made each one quite visible, but was _really_ long (there
are over 80 individual names on the list now, and it has a ways to
go).
But you raise an important point: The tree makes it hard to find a
DH142 unless you know it's a Digitrax FX decoder. And we don't want
to make that hard/confusing for people.
Can anybody suggest a solution that allows us to keep the tree?
Bob I would definitely keep the tree structure - it works great. What I would suggest is to separate the two approaches to finding an appropriate decoder into two branches: specifically-named decoders and family/generic decoders (and maybe a third for other devices). That way the tree would become something like (use fixed pitch font to keep readable): Digitrax |__ Decoders by Number |__ DHxxx |__ DH121 |__ etc. |__ DNxxx |__ DN121 |__ etc. |__ Other |__ DGxx |__ etc. |__ Decoders by Family (I just used these designations arbitrarily) |__ Basic |__ Basic-FX |__ etc. |__ Other Devices |__ DS54 |__ etc. I haven't delved into the details of the decoder configuration xml files, but I would assume this structure would call for a generic sheet for a family type and specific sheets for the individual decoders and may require some changes to the current xml files. I'm also assuming that the tree structure is created on-the-fly based on the decoder xml files that are present rather than being hard coded in the program. Dennis
|
Locked
Re: Coping with the user-fiendish features of the DZ121
The best idea way that I've thought of is to have the short address be a read-only variable on the programming screen.< The PR1DOS software has a special DZ121 program button. I would suspect the way that's done is to lock out programming CV01, basically what you are suggesting. I think it's the only way to do it with a DZ121. I weird thing about this is I understand it's a NMRA legal feature. It seems it's one that should be changed! Jon Miller AT&SF For me time has stopped in 1941 Digitrax DCC owner, Chief system NMRA Life member #2623 Member SFRH&MS
|
Locked
Coping with the user-fiendish features of the DZ121
At 3:15 PM -0700 7/31/02, Jon Miller described a nasty feature of the DZ121: It basically says that anytime you reprogram CV01 (the 2digit address), the
DZ121 automatically resets several CVs. The key here is the reset doesn't
happen during programming, it happens the first time the DZ121 powers up on
the layout in normal mode. So if you use the PR1 to program your values and
change CV01, using the PR1 to read back the data shows everything as you
would expect. In other words, it confirms everything was programmed as you
requested. But when you carry the loco to the layout and place it on the
track, the DZ121 powers up, detects the CV01 change and resets the following
CVs ... The nasty thing about this is that there's no way for DecoderPro to fix it while the decoder is on the programming track; the CVs are changed when you _later_ power the decoder. At that point, it's too late for the program to fix the values. Can anybody think of a good way to cope with this? The best idea way that I've thought of is to have the short address be a read-only variable on the programming screen. You then can't change the short address value, so you can't trip the "feature". I'd add a tooltip that says why this value is held read-only, and suggests that sequence that you need to set the short address. Yes, that's ugly. I'm hoping that somebody has a better idea. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) At CERN until August 10, replies may be slow.
|
Locked
Re: CVP's EasyDCC AD4 Accessory Decoder
At 7:39 PM +0000 8/4/02, original_black_bart wrote: I'd like to progran my CVP EasyDCC AD4 Accessory Decoder's via
DecoderPro but there no configuratrion file for them. Has anyone
produced an AD4 config file? If so, would you sharing it with the
group. I started to throw together a pane for this last night. In the process, I discovered that the address is split between two CVs, much like the long address in a locomotive decoder. It's inconvenient to have these show up as two fields, so I'm going to have to write a couple of lines of code to handle this. More to follow. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) At CERN until August 10, replies may be slow.
|
At 4:31 PM +0000 8/4/02, broman40de wrote: the problem is finished, i can now insert my own symbols
and assamble it now. The next step is to install the occupation
system and the combination with analog and DCC in bloc systems Great! I'm interested in working with you on this, esp. on signalling. Also, if you create a set of good icons, please consider sharing them. It would be great to have more than just the simple ones we've got so far. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) At CERN until August 10, replies may be slow.
|
Locked
Re: Varieties of Digitrax decoders
But you raise an important point: The tree makes it hard to find a
DH142 unless you know it's a Digitrax FX decoder. And we don't want
to make that hard/confusing for people.
Can anybody suggest a solution that allows us to keep the tree? Maybe the first/last top level item is called "All" and just list every specific decoder you know about/can detect alphabetically. That is of course if it doesn't do this already. Alex
|
Locked
Re: Varieties of Digitrax decoders
At 9:48 PM -0600 8/2/02, millerdl wrote: I'm not sure of the real intent of the family
names. If it is just to group the decoders to make them easier to find in
the listings, why not use the Digitrax designations as the groups. i.e. DHxxx
as a group DNxxx as another, etc. ... From a user's point of view, my intent is to find the decoder in the list as
quickly as possible - something that can be done easily when grouped by
designation, since I know the designation. When grouped by another
classification system it is actually _harder_ to find, since I now have to
find a way to figure out where my decoder fits in the classification system.
One possible reason I could see for trying to do families is if someone has a
decoder that isn't listed, so they could try a similar decoder (and similar
numbers don't mean similar decoders, witness the DN121 and DZ121). The "families" originally grew out of noticing that a manufacturer would have the same CVs in a lot of different models. Sometimes the models were just different in wiring harness, e.g. DH142AT vs DH142, but other times you couldn't really tell from the number that they were related. To save costs, manufacturers often put the exact same processor chip & code in different decoder models which vary only in the shape of the PC board, size and number of output drivers, etc. So the idea of the family was that if you knew you had a "FX" decoder, you wouldn't have to worry so much _which_ decoder it was, you could just select the family as a whole. This also helped with the problem of automatic identification, which can't tell all those models apart based on the CV values they contain (because the processor is saying the same thing). We went through several different approaches to manually selecting decoders before getting to the tree method you see now. The original single list made each one quite visible, but was _really_ long (there are over 80 individual names on the list now, and it has a ways to go). But you raise an important point: The tree makes it hard to find a DH142 unless you know it's a Digitrax FX decoder. And we don't want to make that hard/confusing for people. Can anybody suggest a solution that allows us to keep the tree? Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) At CERN until August 10, replies may be slow.
|
Mike
Thanks for the tip. An 82 ohm resistor and it works great.
Stony
toggle quoted message
Show quoted text
----- Original Message ----- From: "Mike Davison" <davison@...> To: <jmriusers@...>; "buchcty" <stony611@...>
You may need to install a resistor between the CS and the programming
track. The comment from CVP was:
A reading of all 0's means there is excess amount of current consumed ' by the loco being programmed. The CS can't distinguish the motor
pulse from the idle current.
I think I have a 100 ohm resistor in place now. I did not find that turning off the lights/etc before programming made any difference.
Mike
On Saturday 03 August 2002 11:13 pm, buchcty wrote:
Hello
I'm new to the list and the JMRI Decoder Pro program. I've installed
Ver. 1 on a Win98 machine and I have inconsistant results with my
easyDCC. When trying to read values from a Digitrax DH121, DN121 or
Soundtrax LC100 it returns all 0s or times out reading each CV. A
Lenz LE103XF works like a champ, the neatest thing I've ever seen.
Stony
|
Locked
Re: CVP's EasyDCC AD4 Accessory Decoder
Black Bart,
Here is a comment I made back in 5-24-02!
"Group,
Another plus for our beloved DecoderPro. I bought a group of CVP AD4
accessory decoders for switch motors. Not wanting to do these by throttle I
first used PR1DOS connected through the MS100. I already knew the PR1
'standalone' wouldn't work from another report. I could not get the PR1DOS
through the MS100 to work at all. Many tries.
I connected up DecoderPro through LocoBuffer and used the single CV
programming tool. Worked each and everytime. While I did have to put in
numbers for the CV's it's quite easy as they are explained in the AD4
instructions.
So another que for DecoderPro. I think a pane for the AD4 would
probably be easy but that's another one for the tomorrow file!"
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
|
Locked
CVP's EasyDCC AD4 Accessory Decoder
I'd like to progran my CVP EasyDCC AD4 Accessory Decoder's via
DecoderPro but there no configuratrion file for them. Has anyone
produced an AD4 config file? If so, would you sharing it with the
group.
Thanks
Bob
|
You may need to install a resistor between the CS and the programming track.
The comment from CVP was:
A reading of all 0's means there is excess amount of current consumed '
by the loco being programmed. The CS can't distinguish the motor
pulse from the idle current.
Before moving to the programming track, turn off all lamps and mute
the loco sound.
If still unable to "read" then insert a series resistance as shown
in the manual for MRC decoders. This may desensitize the programming
track circuit so the motor pulse can be seen above the idle current.
But this will be a trial and error determination of the value - try
75 ohms to start.
I think I have a 100 ohm resistor in place now. I did not find that turning
off the lights/etc before programming made any difference.
Mike
toggle quoted message
Show quoted text
On Saturday 03 August 2002 11:13 pm, buchcty wrote: Hello
I'm new to the list and the JMRI Decoder Pro program. I've installed
Ver. 1 on a Win98 machine and I have inconsistant results with my
easyDCC. When trying to read values from a Digitrax DH121, DN121 or
Soundtrax LC100 it returns all 0s or times out reading each CV. A
Lenz LE103XF works like a champ, the neatest thing I've ever seen.
I would also like to install Decoder Pro on a Linux machine but I'm
not Linux smart enough to do it without an RPM.
Does any one have any ideas about the easyDCC interface?
Thanks
Stony
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Bob,
the problem is finished, i can now insert my own symbols
and assamble it now. The next step is to install the occupation
system and the combination with analog and DCC in bloc systems
thanks for help
Dieter
|
I'm new to the list and the JMRI Decoder Pro program. I've installed
Ver. 1 on a Win98 machine and I have inconsistant results with my
easyDCC. When trying to read values from a Digitrax DH121, DN121 or
Soundtrax LC100 it returns all 0s or times out reading each CV. A
Lenz LE103XF works like a champ, the neatest thing I've ever seen. It's just a guess, but could you check the "mode" setting on the programmer? There's one on the screen where you select the decoder, and then another one at the bottom of the main programming screen. I usually use "paged mode" for Digitrax decoders. Since the Lenz decoder works fine, the various connections, speeds, etc are probably fine. So I suspect that there's something about the mode selected in the programming commands. I would also like to install Decoder Pro on a Linux machine but I'm
not Linux smart enough to do it without an RPM. I'd be happy to help anybody who wanted to create an RPM for Linux, but don't even know where to start. Hopefully somebody will volunteer to educate me... Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) At CERN until August 10, replies may be slow.
|
Hello
I'm new to the list and the JMRI Decoder Pro program. I've installed
Ver. 1 on a Win98 machine and I have inconsistant results with my
easyDCC. When trying to read values from a Digitrax DH121, DN121 or
Soundtrax LC100 it returns all 0s or times out reading each CV. A
Lenz LE103XF works like a champ, the neatest thing I've ever seen.
I would also like to install Decoder Pro on a Linux machine but I'm
not Linux smart enough to do it without an RPM.
Does any one have any ideas about the easyDCC interface?
Thanks
Stony
|
Locked
Re: Varieties of Digitrax decoders
First off, I want to thank everyone who has been working on developing this
program - it looks like it will be a fantastic help to me.
I'm new to this so maybe (probably) I'm missing something (or maybe it's
already been discussed), but I'm not sure of the real intent of the family
names. If it is just to group the decoders to make them easier to find in
the listings, why not use the Digitrax designations as the groups. i.e. DHxxx
as a group DNxxx as another, etc.
If further grouping is required, it could be done on the numeric portion of
the designation. I think this would be easiest because the designation is
what is known - any other classification requires interpretation. As an
example, when Digitrax lists the CVs used by decoders (p27 in the Mobile
Decoder Users Manual) they classify them as FX, LX and Gen4+, but when I look
at my decoder sheet for a DN142K2, it doesn't actually say what type it is in
these terms; I have to try and figure it out from the features. (in this
case, since it supports CV61 and CV05, it must be a Gen 4+ right?)
From a user's point of view, my intent is to find the decoder in the list as
quickly as possible - something that can be done easily when grouped by
designation, since I know the designation. When grouped by another
classification system it is actually _harder_ to find, since I now have to
find a way to figure out where my decoder fits in the classification system.
One possible reason I could see for trying to do families is if someone has a
decoder that isn't listed, so they could try a similar decoder (and similar
numbers don't mean similar decoders, witness the DN121 and DZ121). In this
case, rather than trying to determine an alternate classification system, I
would put the effort into getting as many of the decoders in the list as
possible.
Dennis
Bob Jacobsen wrote:
toggle quoted message
Show quoted text
I decided to take a systematic pass through the Digitrax decoder info
sheets and characterize their decoders, looking for the right
families. From their info I find:
DH121 2 leads, independent function
DH142 4 leads, FX, BEMF, transponding
DH150 5 outputs, FX
DH163 6 outputs, FX3, BEMF, transponding, silent
DH380 8 outputs, FX
DH580 8 outputs, FX
DN121 2 leads, directional lights
DN141 4 leads, FX, BEMF, transponding
DN142 4 leads, FX, BEMF, transponding
DN144 4 leads, FX
DN145 4 leads, FX
DN146 4 leads, FX
DN147 4 leads, FX
DN148 4 leads, FX
DN149 4 leads, FX, BEMF, transponding
DN163 6 leads, FX3, BEMF, transponding
DZ121 2 leads, CS, BEMF, transponding
DZ143 4 leads, FX3, BEMF, transponding
I didn't have Digitrax sheets for these following, so took the info
from Tony's Train Exchange table:
DN122 2 leads, directional lights (from TTX sheet)
DG380 8 outputs, FX
DG580 8 outputs, FX
DG583 8 outputs, FX3, BEMF, transponding, silent
DH083 ? outputs, FX
In the catalog they were handing out at the train show, Digitrax
referred to several types of decoders:
Basic (e.g. DN121, DH121)
Basic-FX (e.g. DN144, DN148): Basic plus FX lighting
Premium (e.g. DN141, DN149): Basic-FX plus BEMF and transponding
Series 3 (e.g. DH163): Premium plus silent, ops mode read, etc.
I think you'd have to add a category for the CS decoders, which I
think is just the DZ121. And you'd have to distinguish the "STD"
lighting basic decoders (DH121) from the "STD*" ones (DN121). That
would give a total of six families.
Does this sound right? What should we use for the family names?
Does anybody have CV7 values for any of these?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Re: Decoder Pro Digitrax programers
Michael,
I hope this makes sense.
When the FX3 decoders were announced I contacted Digitrax. My question was will there be a FX3 decoder available for a Nscale Atlas U25B locomotive soon. I wanted transponding for these engines.
I was told that during 2002 all decoders except the DN121 and the DH121 were going to be replaced with decoders that had the FX3 features. The order of replacement would most like be in order of popularity.
If this is the case we can look forward to many of the current decoders discontinued for newer FX3 models this year.
Just thought everybody would like to know that there are more new FX3 decoders are in the pipeline.
Al
toggle quoted message
Show quoted text
----- Original Message -----
From: Michael Mosher
To: jmriusers@...
Sent: Thursday, August 01, 2002 11:41 AM
Subject: Re: [jmriusers] Decoder Pro Digitrax programers
I agree, it's not clear cut. Some decoders do not support everything other decoders that are in the same class support. But the individual decoder XML files can take care of that.
As I see it (for decoders produced in 1998 and later):
Standard decoders:
DH-120
DH-121
DN-121
DN-121IP
DZ-120
DH140U is a multi format decoder with BEMF, but on DCC it's just a standard decoder with BEMF
Configurable Strobe (CS) with BEMF & transponding
DN-122K2
DZ-121
FX without BEMF nor transponding
DG-380
DG-580
DH-140
DH-150A & K
DH-83FX
DN-140
DN-144K
DN-145K
DN-146A
DN-147A
DN-148K
FX with BEMF & transponding
DH-142
DN-141E2
DN-141K2
DN-142
DN-149K2
FX3
DG-383AR
DG-583AR
DG-583S
DH-163A0
DH-163D
DH-163IP
DH-163K0
DH-163L0
DN-163A0
DN-163A1
DN-163K0a
DZ-143
Various cable options not shown, such as P, PS, AT... They're just different cabling connected to the same base decoder.
Michael Mosher
Webmaster
Daylight Division PCR/NMRA www.trainweb.org/daylight
Golden Empire Historical & Modeling Society www.trainweb.org/gehams
San Luis Obispo Model Railroad Club www.trainweb.org/slomrc
Personal
Member
Kern County Live Steamers www.trainweb.org/kernctyls
----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: July 31, 2002 08:28 PM
Subject: Re: [jmriusers] Decoder Pro Digitrax programers
At 7:35 PM -0700 7/30/02, Michael Mosher wrote:
>I really like Decoder Pro but there's a few mis classifications of Digitrax
>decoders. The DN140, DN144K, DN145K, DN146A, DN147A & DN148K are listed in
>the Digitrax STD decoders but they are really FX decoders without BEMF. I
>think a new directory called "Digitrax FX decoders" or "Digitrax FX decoders
>without BEMF" needs to be created and those decoders moved there. Also the
>DN146A (and I suspect the others as well) do not have the FX lighting CVs in
>the Function tab. Also there's a DN146 and DN146A entries, the DN146 is
>redundant, same decoder. The DH083 is listed in the Digitrax FX with BEMF
>dir, but this decoder does not have BEMF, thou it is an FX decoder, should
>be moved to the above dir. One more little thing, the DH150 is in a dir by
>itself, since there not likely to ever be any more 150's and since it's a FX
>without BEMF decoder maybe it should be moved and that dir removed for
>efficiency sake. Thanks.
Thanks for the detailed comments!
I put together the original Digitrax definitions, along with some
help from blameless others, and I'm happy to agree that I probably
didn't get all the details right.
I'm on a business trip, so my time is a little limited for the next
week and I can't get to my layout, but I'm happy to work on this type
of thing while sitting on airplanes.
The basic underlying idea was that decoder manufacturers would have
various software/firmware versions that they'd use to make multiple
decoders. That same firmware might be installed on various PC
formfactors, with various numbers of output transistors for
functions, but would have the same CVs in each case.
Those firmware sets are the basis for the "family" idea. A file,
which defines a family, also contains the list of decoders that
belong to that family.
So you can see how this would go wrong: I'd code something based on
the info I could get from the web. To the unpolished eye, perhaps
assisted by the "system" of decoder names, other models would look
like they had the same features, hence belonged to the same family,
so I'd add their names to that file. But it was easy to get this
wrong.
So, as a start, what should be the names of the various types of
Digitrax decoders? At one point I based the names on the Digitrax
function naming" FX, CS (configurable strobe), STD and STD*, plus
the new FX3. But that now doesn't seem to be the right approach,
because BEMF and perhaps other functions appear in different
combinations.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Yahoo! Groups Sponsor
Click here to find your contact lenses!
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Locked
Re: Decoder Pro Digitrax programers
I agree, it's not clear cut. Some decoders do not support everything other decoders that are in the same class support. But the individual decoder XML files can take care of that.
As I see it (for decoders produced in 1998 and later):
Standard decoders:
DH-120
DH-121
DN-121
DN-121IP
DZ-120
DH140U is a multi format decoder with BEMF, but on DCC it's just a standard decoder with BEMF
Configurable Strobe (CS) with BEMF & transponding
DN-122K2
DZ-121
FX without BEMF nor transponding
DG-380
DG-580
DH-140
DH-150A & K
DH-83FX
DN-140
DN-144K
DN-145K
DN-146A
DN-147A
DN-148K
FX with BEMF & transponding
DH-142
DN-141E2
DN-141K2
DN-142
DN-149K2
FX3
DG-383AR
DG-583AR
DG-583S
DH-163A0
DH-163D
DH-163IP
DH-163K0
DH-163L0
DN-163A0
DN-163A1
DN-163K0a
DZ-143
Various cable options not shown, such as P, PS, AT... They're just different cabling connected to the same base decoder.
Michael Mosher
Webmaster
Daylight Division PCR/NMRA www.trainweb.org/daylight
Golden Empire Historical & Modeling Society www.trainweb.org/gehams
San Luis Obispo Model Railroad Club www.trainweb.org/slomrc
Personal
Member
Kern County Live Steamers www.trainweb.org/kernctyls
toggle quoted message
Show quoted text
----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: July 31, 2002 08:28 PM
Subject: Re: [jmriusers] Decoder Pro Digitrax programers
At 7:35 PM -0700 7/30/02, Michael Mosher wrote:
>I really like Decoder Pro but there's a few mis classifications of Digitrax
>decoders. The DN140, DN144K, DN145K, DN146A, DN147A & DN148K are listed in
>the Digitrax STD decoders but they are really FX decoders without BEMF. I
>think a new directory called "Digitrax FX decoders" or "Digitrax FX decoders
>without BEMF" needs to be created and those decoders moved there. Also the
>DN146A (and I suspect the others as well) do not have the FX lighting CVs in
>the Function tab. Also there's a DN146 and DN146A entries, the DN146 is
>redundant, same decoder. The DH083 is listed in the Digitrax FX with BEMF
>dir, but this decoder does not have BEMF, thou it is an FX decoder, should
>be moved to the above dir. One more little thing, the DH150 is in a dir by
>itself, since there not likely to ever be any more 150's and since it's a FX
>without BEMF decoder maybe it should be moved and that dir removed for
>efficiency sake. Thanks.
Thanks for the detailed comments!
I put together the original Digitrax definitions, along with some
help from blameless others, and I'm happy to agree that I probably
didn't get all the details right.
I'm on a business trip, so my time is a little limited for the next
week and I can't get to my layout, but I'm happy to work on this type
of thing while sitting on airplanes.
The basic underlying idea was that decoder manufacturers would have
various software/firmware versions that they'd use to make multiple
decoders. That same firmware might be installed on various PC
formfactors, with various numbers of output transistors for
functions, but would have the same CVs in each case.
Those firmware sets are the basis for the "family" idea. A file,
which defines a family, also contains the list of decoders that
belong to that family.
So you can see how this would go wrong: I'd code something based on
the info I could get from the web. To the unpolished eye, perhaps
assisted by the "system" of decoder names, other models would look
like they had the same features, hence belonged to the same family,
so I'd add their names to that file. But it was easy to get this
wrong.
So, as a start, what should be the names of the various types of
Digitrax decoders? At one point I based the names on the Digitrax
function naming" FX, CS (configurable strobe), STD and STD*, plus
the new FX3. But that now doesn't seem to be the right approach,
because BEMF and perhaps other functions appear in different
combinations.
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Yahoo! Groups Sponsor
Click here to find your contact lenses!
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
Bob Jacobsen