Cannot read

I see the first page and then I get pop ups. Something in new with reading your articles.

Rich

Tell us about yourself

System

Linux Mint Cinnamon, 64 bit. Firefox 43.0.

Mint works with everything else at your site. I have read Bruce's articles before but not for at least a month.

Bruce will probably post this somewhere else. Thanks anyway.

I will try downloading the monthly magazine. Maybe that will make a difference.

Rich

We didn't change a thing

Wondering about Myth 5 about MTH locos

Hi Bruce- I have a couple of MTH locos with Proto-Sound 3.0.  I operate them with my NCE Power Cab DCC system.  I also have successfully programmed CV's in these locos with the NCE, using both programming on the main and a program track.

So, I am wondering why you say "MTH Proto-Sound locos may be able to be programmed on a DCC system, or they may not"--- are you saying that there is a particular DCC system that cannot program the CVs in these locos?  And if so, is it known that the problem is with MTH and not with that DCC control system?

It seems like you are splitting hairs with words.  You quote the MTH website as saying "runs on DCC."  Fine.  Then why are you offering the myth debunking that MTH "uses DCC."   I did not find such a statement on the MTH web site.

As far as I know, the objective, fair and accurate statement would be something like: "MTH Proto-Sound 3.0 decoders are based on their proprietary DCS system.  However, the hardware and software in these decoders allows them to correctly respond to NMRA standard DCC protocol.  Certain features that the decoders offer are only supported with the DCS system and cannot be accessed in a DCC system."

I am not sure why bash MTH in this article.  You could have thrown in some Bachman bashing-- "Bachman Sound Value decoders are made by Soundtraxx, but they are not full Tsunami decoders."  But, Bachman doesn't claim that they are.

Dennis

...

Dennis, MTH DOES NOT use DCC.  It runs on DCS with minor compatibility enabled with DCC by the manufacturer.  It is not, however, DCC.  And this designation is extremely important if you are trying to troubleshoot an MTH locomotive having operation issues.

The soundtrax decoder and the economi decoder and Bachmann's sound trax decoders are ALL native DCC decoders.

MTH decoders are Not DCC native.  They are DCS.  Because of this issue, there are settings in the MTH decoder that are not programmable by ANY DCC system.  it is not the DCC systems, this is the design of the MTH DCS system BY MTH.  MTH wants you to buy a DCS command station; if everything in their decoders was available on DCC, then you would have no reason to buy their system.

Bruce didn't split the hair, MTH did.

His statements here are as objective, fair and accurate as one can get.

@Benny- This is confusing

HI Benny-

"MTH DOES NOT use DCC.  It runs on DCS with minor compatibility enabled with DCC by the manufacturer.  It is not, however, DCC.  And this designation is extremely important if you are trying to troubleshoot an MTH locomotive having operation issues."

NMRA Standard 9.-2.2 lists CV values and categorizes them as Mandatory, Recommended, Optional and Reserved.

The list of CVs supported by my MTH Proto-Sound 3.0 locomotives, as documented in their user manual, shows that these decoders support all Mandatory CVs, and do not intrude on any of the Reserved CVs.  The NMRA standard indicates that CV 2,3,4 and 11 are recommended.  MTH supports 2, 3, and 4, but does not support the recommended CV 11, which is "packet time out value."  MTH supports many of the Optional CVs.

Why do you call this "minor compatibility?"  It appears to be total compatibility with the official standard.

What are you alluding to regarding troubleshooting an MTH loco having operation issues?  Can you offer a specific detail so that I can understand this comment better?  What I know is that I can control my MTH loco with DCC, and I can manipulate the CV values, and the CV values cause the behavior that they are supposed to cause.

"MTH decoders are Not DCC native.  They are DCS.  Because of this issue, there are settings in the MTH decoder that are not programmable by ANY DCC system."

Yes, there are settings in the MTH decoder that are not programmable by any DCC system and that can be programmed only by the proprietary DCS system.  But, so what?  Those hidden-to-DCC settings do not impair or compromise operation under DCC.

Why is being "DCC native" a concern?  What does being "native" really mean?  If the software in a decoder was originally written to be a word processing program, and then was modified by adding features that allow that decoder to operate in a way that is compatible and compliant with DCC, so be it.  I guess such a decoder would not be "native", but it would work.  I would say that what is important is not so much the "cultural origin" of the decoder, but whether or not it complies with the standards and whether it is a quality implementation.

I mean no disrespect to either you or Bruce.  Goodness knows I have learned a lot from his contributions.  But, I don't understand what is going on here, and if I am missing something, I am eager to learn.

regards,

Dennis

MTH

As Benny said, MTH built their own castle across the moat from the NMRA standard DCC. It is DIFFERENT.

They can make their locos run on DCC.

I had a roommate in college who changed the oil on his VW bug. After removing the old oil, he put diesel fuel in the crankcase and ran the engine for a few minutes to "clean it out" before installing new oil. It would run with diesel fuel in the crankcase, but that was not how it was DESIGNED to run.

MTH is DESIGNED to run on DCS. They are striving with each new iteration to be more DCC compatible. But they do USE DCC.

Read it on their web site ( http://mthtrains.com/product-line-pages), where you will find this:

Bashing . . .

is NOT my intent. My intent is to educate folks as to the nuances of DCC.

In the USA, If I were to sell you a DVD player and you were to take it home and find that it only played PAL DVDs (as sold in Europe) and was incompatible with the (NTSC) DVDs in your collection, would that be right? It is a DVD player, but you cannot use it. It complies with some standard, just ont one that you can use. So, no, it would not be right.

I'm not saying the MTH issue is this drastic, but it is similar. Early on, the marketing was blurring the DCS / DCC line and the locos were less functional on DCC. As I said in a prior post, MTH locos are getting more DCC compatible. But that is still compatible, not compliant.

There seems to be a specter of what a MTH loco will or will not do on DCC. For example, this morning one fella asked on the NCE DCC Yahoo group if his MTH loco would do an advanced consist on a NCE system. This depends upon how the MTH decoder handles CV 19. Since they don't march to the NMRA DCC specification, there is no guarantee. Since it won't hurt either the loco or the DCC system, I counseled the poster to try a consist with two DCC locos and the MTH loco. If all three locos moved, the MTH supported advanced consisting. If the two DCC locos moved and the MTH didn't, then the MTH decoder didn't support advanced consisting.

If someone can point us to documentation by MTH as to what they support in the DCC realm (and which series of decoders do so), it would be a real boon to us all.

DCC

Bruce, I have enjoyed your columns in MRH. They are informative and have assisted me greatly with my conversion to DCC. Obtaining a PTB 100 for my DCS 100 on your advice has enabled me to add and program sound decoders to my layout and to help my friends set theirs up. Thank you.  Ron Kearsley.

That and the price premium

That and the price premium over similar locos is why I do not buy MTH locos. I am not knocking them they chose a different path and I chose not to go down that path. The NMRA came up with some standards for DCC or adopted them however you wish to describe it nearly everyone is building things that are using this system. Rail pro went with something different and it is a major difference I did not adopt their system either but I sure did look at it! I will say it was a near thing.

Please do not consider this as me thinking less of anyone who did buy them or of their products they are just not the fit I want.

Bruce I almost forgot to add thanks for another great article I believe your articles go into a special note book (large 3 ring binder) in our club that deals with DCC. Another 5 star performance!

MTH properly supports DCC advanced consisting

Hmm-- It feels a little like we are sitting in different universes.  My comments apply to MTH Proto-Sound 3.0 decoders.  I do not have any experience with Proto-Sound 2.0, and I am not making any claims about how MTH may have marketed in the past.

I have successfully formed advanced consists with MTH Proto Sound 3.0 locos using my NCE Power Cab using the Power Cab's advanced consist menu.  In addition to allowing the Power Cab to do the details of setting this up, CV 19, 21, and 22 can be directly programmed as needed, per NMRA DCC specifications, to set up the consist. In particular, CV 19 is implemented in a way that does match the NMRA specification.

See page 31 and beyond of the MTH Users Manual for their Proto Sound 3.0 PA diesels, available here on their web site: http://mthtrains.com/sites/default/files/download/instruction/80dl19283i.pdf

Elsewhere in that document, you will see that MTH very specifically contrasts DCS and DCC and does not claim that they are at all the same.   What I see is a manual that describes a "triple mode" decoder-- it can be used in DC, DCC or DCS.  It is not only "operable" in DCC, it is compliant with the DCC standard.  What part of the DCC standard does it not comply with?

Why do you say that MTH does not match the DCC specification?  I want to believe you, but I just don't see it.  I compare their documentation to the NMRA DCC specification and conclude that they do match, that they are COMPLIANT.

Again, I repeat: I am eager to learn if I am missing something.  I appreciate nuances.

regards,

Dennis

MTH decoders and JMRI

I have an MTH loco, and really like it.  It's a great running unit.  However, it came DCC ready and I added my own decoder.  Have never had to deal with the MTH system.  

My question is, can JMRI read and/or program MTH decoders?  I'm guessing no.

John C

MTH decoders and JMRI

Can we separate the past from the present on this MTH DCC issue?

Ok.  I have no issue with the statement that older MTH locos have shown problems regarding their implementation and compliance with DCC.  I have no direct experience with those products, but I certainly believe what has been said.

But, to be fair, can we be accurate about current MTH products- MTH Proto Sound 3.0?  Items that people would buy new today?  It seems that many people seek guidance on this forum regarding "what to buy?"  Unless there is a factual reason, why cast a shadow on whether a new MTH loco is DCC compliant?  Either it is or it isn't.   My experience with Proto Sound 3, which is backed up by the MTH printed documentation (I don't believe they are lying in their manuals) convinces me that their current product is DCC compliant and will work with standard DCC systems (and also can be programmed/configured by those systems).  If someone can identify specific reasons why they are not compliant, I would like to see that.  Otherwise, it seems unfair to make non-specific allusions to things that might be problems (but might not be).

I get it that some people don't like MTH, or are angry that MTH developed and marketed a proprietary system.  But that should be separate from whether or not they are selling a DCC compliant product.  The compliance is not dependent on how their software started and evolved.  The compliance is dependent on what their software does.

Yes and no

Yes ... and no.

In searching the web, I'm finding reports over the last few months of programming problems still with MTH decoders on brand new locos. While things are better, MTH decoders can still be iffy if what modelers are reporting online in recent months is to be believed.

Reports are of programming difficulties that still exist with MTH decoders in brand new locos particularly.

So Bruce's point stands ... MTH is not 100% DCC compatible and that is still causing issues for some. For others, it's no problem and the problems are diminishing - but they're not gone.

Hello Bruce, in regards to

Hello Bruce, in regards to "myth" #7 from the latest issue, with all due respect please read up on the basics of acoustics / speakers / enclosures. Other than that, I love the column and giving it 5 stars. Cheers!

...

There's theory and then there's practice

Well, there's theory and then there's practice. Here's how I understand what Bruce is getting at here.

1. You don't necessarily need to use a sealed enclosure to get great sound from your locos - you just need to delay the sound from the backside of the speaker so it doesn't cancel out the front side sound - and it only takes a few inches to achieve this effect. Bruce demos this effect here in this video on the MRH Youtube channel:

2. If I read up on speaker enclosure theory, I find references to both sealed and ported/baffled enclosures. I also find a ported/baffled enclosure (not sealed) is recognized as a trick for increasing base response. This is in principle what Bruce is doing by using the loco shell as a baffle, which speaker theory says can increase base response. If there's anything our locos need, it's more base response!

3. By not needing to add a separate enclosure to a loco speaker, the speaker arrangement needs less room, and it's simpler to install. Both of these benefits are significant.

In short, Bruce has found that using the loco shell as a baffle, you can get better base response than from using a totally sealed enclosure, it's simpler to install, and it takes less room. All great benefits.

Sometimes you can get so wrapped around the axle with the theory that you miss the practical applications. In fact, per speaker enclosure theory, Bruce is advocating a "baffled" enclosure where the loco shell forms the baffle, which is a known technique for increasing base response.

Items that cannot be confiugred via DCC in MTH

Bennie may have missed the point I was making earlier in this thread.  MTH Proto-Sound 3.0 decoders have some parameters and features that can be configured or enabled via DCS that cannot be set by programming CVs in DCC.  The point is that these features and parameters are not part of the DCC standard, and are not required by the DCC standard, and do not affect the programming or operation of the unit under DCC.  They are just extra features above and beyond what is called out in the DCC specification that MTH chose to offer, and offer only via DCS.  Not supporting those extra features via DCC has nothing to do with DCC compliance.

In fact, there are DCC sound decoders from other manufacturers that are accepted as DCC compliant that also do not allow setting of some of the very same "extra" parameters.  In this regard, they are no different than MTH.  The fact that they do not support setting these parameters via DCC does not make those decoders non-compliant with the DCC specification.  If you had either an MTH Proto Sound 3.0 decoder or one of these on your DCC system, neither would let you experience these extra features.

The point I made is that although MTH decoders have items that cannot be configured via DCC, those items have nothing to do with DCC compliance- either operations or programming.  That is what my "so what" means.

Some of  these "extra" items might be desirable to be supported via DCC.  That same comment applies to other decoder manufacturers- it would also be desirable for them to add this "beyond the standard" feature to their DCC compliant products and support it via DCC.

regards, Peace, Love, and Understanding,

Dennis

...

So then the reality remains: they are not 100% supported on DCC systems.  Otherwise, if they were, then 100% of their features would be programmable on DCC systems, even though they have digital features not found on other DCC decoders.

Compatibility is ALL or NONE, and in this case, Compatibility means the DCC control systemcan program ALL features on the decoder, even if those features are not found on other decoders.

Sometimes, these parts of the decoder that can only be set in DSC can and will affect operation on DCC.  This is the heart of the compatibility issue.

THE MYTH STANDS BUSTED.

Compatibility is ALL or NONE

Compatibility, especially in electronics and devices, is not nor has it ever been, all or none. It just means it can work with. Many devices of all types have less or more features but its core functionality allow it to work. 

It's OK to be wrong. 

DC/DCC/DCS

MTH DCC ready

I recently purchased 2 brand new MTH engines due to their great rep as good running engines. I skipped all the DCS DCC stuff by buying DCC ready versions and installing RailPro receivers. Super quick consisting and very easy programing. I liked the fact that they were also ready for speakers.