# Wireless DCC? Check this out.



## TonyWalsham (Jan 2, 2008)

IS IT REAL RADIO DCC?

Or is it just another Airwire/NCE partial DCC?

Enquiring minds want to know.


----------



## krs (Feb 29, 2008)

Tony, 

This is not even close to anything "DCC" 

From the Q&A: 

I looked quickly at the Quantum Revolution manual. The good news: It uses only functions F0 to F12 for control, which S-CAB supports. The bad news, we still have to “reverse engineer” the decoder to find out how to connect DCC signals from the radio receiver to the decoder’s microprocessor. If successfully converted, the decoder would be used for motor control as well as sound. If we get enough interest we’ll add this to the list. 
Reverse engineer the DCC decoder? 

Switch on the CAB, assign the model a 1 or 2-digit identifier (loco address; standard DCC stuff,) 
One or two addresses in DCC? 

Q: Will the S-CAB only work with the radio receiver supplied with my order and installed in the loco? 
A: That is correct. 

A separate Cab for each loco? How is that DCC? 

...and the list goes on - max. system voltage is 18 volts, DCC is 22.... 

Knut


----------



## TonyWalsham (Jan 2, 2008)

Knut, 
I am not saying it is DCC. They are. 

If it irks you so much, perhaps you should take it to them for clarification.


----------



## Greg Elmassian (Jan 3, 2008)

Sure looks very similar to Airwire, which sends MOSTLY DCC commands over the air, and presents them to a decoder. 

There is no standard for "radio DCC"... DCC is defined as over the rails power. 

So it's as "radio DCC" as Airwire is, and by reading the information, it also has deviations from the DCC protocol / command standard... 

Greg


----------



## TonyWalsham (Jan 2, 2008)

...........In which case why are they allowed to say it is DCC?


----------



## krs (Feb 29, 2008)

Posted By TonyWalsham on 21 Jul 2011 06:21 AM 
Knut, 
I am not saying it is DCC. They are. 

If it irks you so much, perhaps you should take it to them for clarification. 
Oh Boy Tony,

Let's not start that again.

You asked: 
IS IT REAL RADIO DCC?

I answered your question, that's all.


I didn't say or suggest or imply that you're saying this is DCC.




And what makes you think their statements irk me?

Not in the slightest - just shows how important they think DCC is to consumers if they feel they need to pretend that their system is "DCC"


Knut


----------



## East Broad Top (Dec 29, 2007)

Okay, I'm more than a little confused on the semantics here. Greg writes, "DCC is defined as over the rails power." Here's how the NMRA defines "DCC:" "Method of controlling multiple trains and accessories using digital communications packets to send commands. The NMRA DCC Standards S-9.1 and S-9.2 for digital command communication for model trains." (_source: http://www.nmra.org/standards/DCC/standards_rps/rp912.html_) 

I've read the referenced standards, and can find no language within those standards which defines DCC as dealing exclusively with "over the rails" power. They do reference rails, but only in the familiar context of how power is delivered to the locomotives (likely for lack of any other practical means at the time the standards were authored). Language in other RPs reference "wires or rails" as a means of sending DCC signals. So, wouldn't any control system that uses DCC components, protocols, and encoding to control trains by the NMRA's definition be a "DCC" system? Can anyone point to a reference that clearly defines "DCC" as pertaining solely to "over the rails" transmission? 

Now, to the product at hand... 

Whatever you want to call it, a few things jump out at me as being a bit odd. First, when you read the description, it says that it's available for all scales, including large scale. It goes on to say it's up to the user to make sure the decoder is capable of handling the load of the locomotive. All well and good. But then it says it's currently only available for two decoders, neither of which are particularly suited to typical large scale operation. (Both available decoders are rated at just about 1 amp, that's it.) Other decoders will have to be "engineered" to be compatible with the receiver. Hardly strikes me as being universal or easily adapted to QSI, Lenz, Zimo, or whoever's large scale decoder you want to use. That right there seems to be a deal breaker. I'm still waiting for a transmitter/receiver set that simply encodes the DCC control signals over a battery voltage, a la an on-board DCC base station. Then you could attach any DCC decoder to it via two simple wires to the power inputs. 

Later, 

K


----------



## Greg Elmassian (Jan 3, 2008)

You just need to read a bit more Kevin, the standards are not always easy to follow. You can consult Stan Ames, he is the "goto guy" on questions like this. 

We actually went over this ad nauseaum on the last thread on this subject, which interestingly had some of the same participants, and some of the same agendas apparently. 

The proprietary nature of the "receiver" / "decoder" completely flies in the face of DCC, so further consideration is pointless if the question is really as presented in the first post. 

I'm not interested in duplicating the last thread. 


Regards, Greg


----------



## East Broad Top (Dec 29, 2007)

You see, Greg, that's just the thing. I _have_ read--a lot--largely based on your previous recommendations that I take it upon myself to learn about DCC. And in all that, I have yet to find any reference to DCC being "by definition" track power as you assert. I've found plenty that leads to the conclusion that track power is certainly the "native" environment for DCC, but nothing dictating that it's exclusive to that environment. So, I post here asking for a reference to support your definition and you merely tell me to keep reading. Thanks. 

Later, 

K


----------



## Greg Elmassian (Jan 3, 2008)

OK, here we go (I'll go step by step)


Lets get rid of the wireless part, since there's probably nothing invalidating presenting a DCC signal to a decoder that came from an extension cord.


DCC welcome page, several references to voltage on rails, no mention of DCC transmission over radio, gravitational, x-rays, etc.: 


*http://nmra.org/standards/DCC/index.html* 




Standard S9.1 which you say you read: *http://nmra.org/standards/DCC/standards_rps/S-91-2004-07.pdf* 

Section A, lines 12-13 read:

"The NMRA baseline digital command control signal consists of a stream of transitions between two equal voltage levels that have opposite polarity1." 


Do you need more? This says that it is an electrical voltage.

Do you now agree that it's not wireless? 


We'll stop here for now.

(by the way, you need to PROVE wireless is IN the standard as an accepted form of transmission of the DCC protocol, not say it's in the standard because it is not specifically excluded) 


Greg 


reminds me of the joke: (by the way, I'm Armenian)


News story:

Trying to show that their culture was advanced in early communications, Swedish archeologists recently unearthed bits of what appeared to be copper wire between ancient buildings, thus the claim was made that they had telephones many centuries ago.


Not to be outdone, the French dug down much further, thus going farther back in time, and discovered bits of glass fibers around some ancient buildings, and made the claim that they were even more advanced, since obviously they had fiber optic communications.

The Armenians could not take this lying down. They excavated twice as deep, and in dwellings near the dawn of man, they discovered..... NOTHING..... and thus made the claim that they were even earlier in advanced communications, because, the absence of copper or glass fiber could only mean they had wireless!

(hope someone got a giggle out of this... apologies to the French and Swedes)..


----------



## Treeman (Jan 6, 2008)

Anthony, "Bubba" Was a pioneer along this line as far as I know when he installed an LGB Central Station in a battery powered locomotive.

He wanted to use all of the factory sounds in a LGB MTS loco.

This idea lead to Massoth announcing their raido receiver, to operate a DCC decoder. 


This may still be in the works?


----------



## Greg Elmassian (Jan 3, 2008)

The thread was about a simple question Tony asked. 

Then it went into can they call themselves DCC? 

Then Kevin forgets all the verbiage in the standards about the electrical interface (hint kevin, you cannot have a conforming DCC device unless it works from track power, and thus it is NOT DCC, because DCC is a registered trademark, owned by the NMRA) 

So now it's shot to ****... 

I'll wait for the 3rd installment of "wireless DCC".... is it a standard or a floor wax? (remember Saturday Night Live?) 

I won't be back to this thread... waste of time. 

Greg


----------



## East Broad Top (Dec 29, 2007)

"The NMRA baseline digital command control signal consists of a stream of transitions between two equal voltage levels that have opposite polarity1." 

Where does that mandate DCC signals have to travel _through the rails?_ It can just as easily travel from a receiver (base station) through wires directly to the decoder--no rails involved. That's all I'm talking about. "Wireless" doesn't enter the discussion. I'm specifically talking about what happens between the receiver and the decoder, which is wired. 

Think of your wireless NCE system. You've got a transmitter and receiver combination. How those two components communicate doesn't matter, in fact the NMRA doesn't even address that. It's not important. What's important is what the reveiver does with the instructions it receives from your wireless controller. It translates those instructions and encodes them, outputting them to the track for the decoder to interpret. Now, take that receiver/base station, and shrink it down to fit inside a locomotive. Replace your power supply with a battery pack. Nothing's changed. The components are still the same, but the rails are removed from the equation. You're feeding the decoder directly via two wires inside the locomotive. It's still the same DCC system you've always used, but in a smaller, much more portable package. That's what I'm talking about when I say DCC isn't definitively "track power." You can have a DCC system without running electrons through the rails. You can easily make it portable/battery power, and take the track out of the equation. It doesn't cease to be DCC just because you're not running track power. The encoding/decoding protocol doesn't change because the voltage it uses comes from a battery instead of a regulated power supply. It's that encoding/decoding protocol that's standardized by the NMRA's DCC standards; the voltages necessary, and the formation of the specific data packets used by the decoder. 



What's missing from the marketplace is a _universal_ wireless transmitter/receiver pair whose receiver puts out a true DCC signal--one that can be wired directly to the power inputs of any generic DCC decoder. These systems are not that. They require the output of the receiver to be tailor-made for the decoder you're looking to attach to it. It _is_ "wireless DCC" in that you have wireless control of a specific decoder that uses the DCC protocol to control the locomotive. But it lacks that full interchangeability that's the hallmark of an open protocol such as DCC. 


Later,

K


----------



## Mike Reilley (Jan 2, 2008)

Posted By East Broad Top on 21 Jul 2011 02:12 PM 
.....

I've read the referenced standards, and can find no language within those standards which defines DCC as dealing exclusively with "over the rails" power. ....

Later, 

K


Nope...you're reading the standards improperly...DCC is a standard that ONLY applies to track powered trains...with control signals passing through the rails. Open system standards are NOT only defined by the language of the standard...but by the "conformance test standards" that go along with the "definition" of a standard. Frankly...the conformance tests are what PROVE that a device/item/machine/interface/whatever either comply or do NOT comply with the standard. Period. 


In the case of "over the air DCC devices " (my term) there is NO WAY TO PROVE they are DCC compliant. The whole reason for open systems standards...pick one...USB, Firewire, HDMI, 802.11a, 802.11b, 802.11g, 802.11n...whatever, is to ENSURE that devices meeting a standard made by manufacturer A could seemlessly interoperate with devices made by any manufacturer B. Well...you can't do that for "over the air DCC"...because there is NO compliance test that every manufacturer can run to PROVE conformance. That means that a vendor (like NEC or Airwire) cannot PROVE DCC compliance...because there's no conformance test for them to demonstrate compliance with the DCC standard. It's that simple...no test...no proof of conformance.


The DCC conformance tests are for track powered engines ONLY.....the control signals MUST pass through the track to the decoder to prove compliance. There is NO test that allows the control signals to go any other way...period. Therefore, NO "over the air DCC device" can be DCC compliant....unless you can send the signals/power through rails to the device and it passes the DCC compliance tests. Period.


Now....manufacturers always try to cheat...especially by adding additional "features" outside the standard to their device. In the open system standards world, if the basic functionality passes the conformance tests, it's compliant, even though it has "other features"....and it's those "other features" that over time often get added to the standard through a regulated process owned by the standard owner. So, "over the air DCC" could become an extension IN THE FUTURE to the DCC standard if the NMRA wished...but it's CLEARLY not part of the standard now, nor the conformance test program for DCC...ergo, "over the air DCC" ain't DCC. Period. 


I think we would be well served if NMRA were to establish an "over the air DCC" standard with a conformance test. There's nothing magic about using the rails...especially since were seeing this "over the air DCC" concept being applied to the smaller scales.


----------



## Mike Reilley (Jan 2, 2008)

Posted By TonyWalsham on 21 Jul 2011 08:14 AM 
...........In which case why are they allowed to say it is DCC? 
Simple...because the standards authority, NMRA, does NOT send them a letter telling them to cease and desist. DCC is afterall an NMRA trademarked term.


----------



## TonyWalsham (Jan 2, 2008)

Hello Mike, 
Like my original question, that was also a rhetorical one. 

The NMRA seems not to care that more than one commercial organisation is claiming their products to be something they are not.


----------



## krs (Feb 29, 2008)

Posted By East Broad Top on 21 Jul 2011 11:11 PM 

It _is_ "wireless DCC" in that you have wireless control of a specific decoder that uses the DCC protocol to control the locomotive.

This system is most certainly NOT "wireless DCC".

You need to go a bit deeper than just look at the transmission of the DCC packets.

DCC also requires that the DCC devices conform to certain *mandatory* CV's and can operate over specified voltage ranges.

I mentioned some of those in my earlier post.

The NWSL system doesn't meet either of these NMRA DCC requirements.


But separate from these shortcomings, "Wireless DCC" in itself would mean that the standardized NMRA DCC signal is transmitted by wireless means rather than by wired means the way it is done today (let's keep the transmit via rails or not out of this for now).

Doing that even conceptually is pretty much impossible, certainly impractical - nobody is going to develop a 'wireless DCC' signal that transmits the DCC protocol along with 10 amps of current wirelessly to run the trains.


The system that you envisage with the equivalent of a DCC central station on a chip inside the engine connecting to a DCC decoder of your choice is the product that Massoth announced a few years ago.

I have no clue if that is ever going to see the light of day - but if it does, then we can again "argue" if that can truly be considered to be a "DCC system".


Knut


----------



## krs (Feb 29, 2008)

Posted By TonyWalsham on 22 Jul 2011 02:16 AM 
Hello Mike, 
Like my original question, that was also a rhetorical one. 

The NMRA seems not to care that more than one commercial organisation is claiming their products to be something they are not. 

Yes Tony,

NMRA seems to have really taken a back seat when it comes to DCC.

Case in point is bi-directional communication (or Railcom as Lenz calls it).

Most of the European DCC manufacturers got together on this and formed a working group to move that 'standard' forward - it's covered to some degree in the NMRA RP's but NMRA takes no interest in it.
That European working group has now had their own severe differences - after all, they are all manufacturers and have a commercial interest which outweighs the technical interest it seems.
So some are pulling in one direction, others in the opposite direction and others are or have left the group already.

Some leadership by NMRA (or possibly MOROP) is required byt neither one is anywhere to ne seen.

Knut


----------



## East Broad Top (Dec 29, 2007)

Mike, I have to disagree. The conformance tests surround mandatory CVs, voltages, data packets, etc.; all things that can be checked on a workbench with alligator clips between the base station and decoder. The rails don't enter the equation beyond being a common means of conveying electrons from one point to another. Per my example to Greg, I can dissect my base station, stuff it in a locomotive, power it with a battery, and wire it directly to a DCC decoder; it's still every bit the DCC system it was in its original packaging. 

Having said that, the products we're discussing here are not so clear cut. I think as Knut points out, there seem to be some limitations which fall short of the NMRA's standards, though that's hardly stopped others from calling their products "DCC." The real question is where does the NMRA draw the line in terms of what it looks for? They have no standards for transmitting/receiving signals between transmitter and receiver. They just look at the specific DCC signal that's superimposed over the supply voltage by the receiver/encoder that goes to the decoder. So long as what the receiver/encoder outputs is compliant with that, can they say anything? In the case of this stuff where the receiver/encoder/decoder is married as one complete product, is there much they can say about it at all? I don't have the foggiest. 

But the real question is, how much control do we have over the term "wireless DCC?" Certainly it's clear the NMRA hasn't given it much thought, seemingly leaving it to the marketplace to define it. I think we can sit here and argue semantics until we're blue in the face, but like "G-scale" shedding its scale-specific identity, we have little control over what catches on in the lexicon of large scale despite what's "technically" correct. 

Later, 

K


----------



## East Broad Top (Dec 29, 2007)

Knut, I'm afraid you're near spot on relative to the NMRA and DCC. I wonder if they're inclined to just let things evolve as they will, so long as things stay reasonably compliant to at the core level. I wonder if the technology is advancing faster than they can keep up with it, so they've stopped trying to. In many ways, I think that's a good thing as it allows companies to keep pushing the envelope, but it also invites the potential for incompatibility. But that may be the price we pay for improved innovation. 

Later, 

K


----------



## TonyWalsham (Jan 2, 2008)

..........which is precisely what we can expect. 

Anyway, isn't RF broadcast the actual transmission of minute amounts of electricity that can be measured? 
If so, then quite possibly that would actually comply with the NMRA standard that was brought up earlier in this thread by Greg. 
*"The NMRA baseline digital command control signal consists of a stream of transitions between two equal voltage levels that have opposite polarity1."* 

....and before anyone jumps on me for lack of technical expertise. I freely admit I know zip about DCC. I am just raising possibilities and airing "claims" by others that they are making *DCC* equipment.


----------



## krs (Feb 29, 2008)

Posted By East Broad Top on 22 Jul 2011 02:59 AM 
Knut, I'm afraid you're near spot on relative to the NMRA and DCC. I wonder if they're inclined to just let things evolve as they will, so long as things stay reasonably compliant to at the core level. I wonder if the technology is advancing faster than they can keep up with it, so they've stopped trying to. In many ways, I think that's a good thing as it allows companies to keep pushing the envelope, but it also invites the potential for incompatibility. But that may be the price we pay for improved innovation. 

Later, 

K 
Kevin,

The key element of "DCC" is the compatibility and interworking of products from various manufacturers at the interface level between the "control product" and the "controlled product", ie typically the Command Station and the various types of decoders.

But the control product could also be a PC or other box that generates DCC compliant packets *and* enough power to operate the controlled product - from a system point of view these devices would just be called "black boxes" with a set of defined parameters.

The actual technology employed is simply a means to an end.

People who buy "DCC" components regardless what they are expect a certail level of compatibility and interworking between them and any DCC product they already have or will purchase in the future - this product by NSWL doesn't interwork with any other DCC equipment, it's a fee-standing proprietary system. I can't use that throttle to control switch decoders for instance, or even connect a DCC auxiliary decoder in the loco (or a DCC sound decoder) since I believe I cannot get to the actual DCC packets between the R/C receiver and the DCC decoder they use.

The way it's described, the NSWL system doesn't actually generate DCC packets anywhere within the system - it reads as if the output of the R/C receiver is tied directly into the microprocessor of the DCC decoder being used.

There is no reason why the requirement for compatibility needs to stifle innovation - the trouble is you need someone who has no commercial interest to drive it.

Knut


----------



## krs (Feb 29, 2008)

Posted By TonyWalsham on 22 Jul 2011 03:43 AM 
..........which is precisely what we can expect. 

Anyway, isn't RF broadcast the actual transmission of minute amounts of electricity that can be measured? 
If so, then quite possibly that would actually comply with the NMRA standard that was brought up earlier in this thread by Greg. 
*"The NMRA baseline digital command control signal consists of a stream of transitions between two equal voltage levels that have opposite polarity1."* 

....and before anyone jumps on me for lack of technical expertise. I freely admit I know zip about DCC. I am just raising possibilities and airing "claims" by others that they are making *DCC* equipment.

Tony,

As far as I am concerned, and I'm certainly not Mr. NMRA DCC (not sure who is), one key element of a DCC compliant system is that it also provides the power (voltage and current) embedded in the DCC signal to directly operate the locomotive for instance.

I don't think a system that applied say 20 VDC to the rails and somehow superimposed 1 volt DCC Packets to control some decoder could be called "DCC"
It's transmitting the power wirelessly I think is a problem 'definition-wise'.

Technically, to send DCC packets wirelessly, you need to modulate them onto some carrier frequency and then extract the DCC signal at the receiving end - power would have to come either from the local on-board battery or the track - it can't be transmitted wirelessly.
If that type of system configuration qualifies as an "NMRA compliant Wireless DCC system" is up to NMRA to decide - it certainly does not with the current NMRA definition but that doesn't mean NMRA could not define a wireless DCC system to be just that.
But I think it would require at least a 'standardized' modulation scheme of the DCC packets.


Knut


----------



## Mike Reilley (Jan 2, 2008)

Posted By East Broad Top on 22 Jul 2011 02:53 AM 
Mike, I have to disagree. The conformance tests surround mandatory CVs, voltages, data packets, etc.; all things that can be checked on a workbench with alligator clips between the base station and decoder. The rails don't enter the equation beyond being a common means of conveying electrons from one point to another. Per my example to Greg, I can dissect my base station, stuff it in a locomotive, power it with a battery, and wire it directly to a DCC decoder; it's still every bit the DCC system it was in its original packaging. 

Having said that, the products we're discussing here are not so clear cut. I think as Knut points out, there seem to be some limitations which fall short of the NMRA's standards, though that's hardly stopped others from calling their products "DCC." The real question is where does the NMRA draw the line in terms of what it looks for? They have no standards for transmitting/receiving signals between transmitter and receiver. They just look at the specific DCC signal that's superimposed over the supply voltage by the receiver/encoder that goes to the decoder. So long as what the receiver/encoder outputs is compliant with that, can they say anything? In the case of this stuff where the receiver/encoder/decoder is married as one complete product, is there much they can say about it at all? I don't have the foggiest. 

But the real question is, how much control do we have over the term "wireless DCC?" Certainly it's clear the NMRA hasn't given it much thought, seemingly leaving it to the marketplace to define it. I think we can sit here and argue semantics until we're blue in the face, but like "G-scale" shedding its scale-specific identity, we have little control over what catches on in the lexicon of large scale despite what's "technically" correct. 

Later, 

K 
There's more to the conformance tests than you indicate. For instance, there is a mandatory test configuration. That test configuration requires a decoder to have two pins called "track:...and two pins called "motor". It requires a specifically engineered test board that is placed in a computer which is loaded with specific conformance test programs. The test requires that the decoder under test accept bi-polar electrical signals at the "track pins". It TESTS to see that the decoder properly responds to signals sent in via the "track" pins....properly being defined by the standards. Tolerances are measured; variations are measured; absolutes are measured...and if they all fall within the standards, THEN the decoder can be presented for a Conformance Warrant. I can find NO OTHER method approved by the NMRA to validate conformance of a decoder to the NMRA standards.

Of note, the decoder change that made "wireless DCC" available was to separate the "track" input into "signal input" and "power input". Prior to that change, the signal came from a bi-polar change in the power feed that was generated by the Command Station. Well...in "wireless DCC", there's no bi-polar signal going through the air...there's a proprietary signal being sent to the "super decoder" (RX plus decoder) that get reconstructed inside the "super decoder" to control identification, movement, sound, and light. The purpose of DCC was to standardize the interfaces between devices so that any manufacturer gear would be interoperable. THAT is the basis for most open system standards...and it IS the singular basis that the NMRA touts for why DCC was invented...INTEROPERABILITY. (See Why DCC was invented.) Remember that DCC was the out growth of Command Control...which started with ASTRAC and went through to the CTC stuff...and that stuff worked...but the desire was for all the stuff to work together...and DCC was born out of that desire.


So...given that the test configuration can't be used to validate a "wireless DCC" decoder's conformance...and given that the DCC standard LACKS standards for the actual waveform that is transmitted from the TX/throttle to the RX/decoder...no "wireless DCC" device can be in conformance...because there is nothing to prove conformance against. You might consider this semantics...but this is the ESSENCE of conformance testing for all open system standards.


Your points are correct in that "functionally" provided by these devices for the RC/battery crowd are moving us in a new direction...and that the functionality we're seeing COULD be compliant with the DCC functionality standards...except there's no way to prove it. As you note, the NMRA hasn't chosen to get into "wireless" standards. Further, they've chosen to NOT enforce their warrants. Heck, lots of manufacturers of the old, track oriented decoders don't bother to even submit a request for a DCC Warrant from the NMRA...they look at it as a waste of money...and they just go ahead and print DCC on the boxes. So, given that there's no way to prove conformance, there's no way that a consumer will KNOW that any throttle he buys will work with any decoder he buys..."wirelessly". 


The roots of DCC are in interoperabilty...that meaning anyone's decoder will work with anyone's throttle electrically...and that they properly implement the DCC signaling standard defined in the DCC standards. DCC standards are about functionality AND interoperability. While the "wireless DCC" devices may comply with the functionality requirements, they can't comply with the interoperabilty requirements...and therefore can't be truly DCC compliant or conformal.


I would be comfortable if vendors used the term "DCC Functionally Compliant"...meaning it does what DCC does on all counts from a functional point of view...but ISN'T in full conformance with the interoperability aspects...but to do that right, the NMRA would need to specify what functional compliance needs to be.


----------



## TonyWalsham (Jan 2, 2008)

.....and enforce the issuance (or non issuance) of said functional compliance. 

In the meantime, all that can really be done is for observant and technically capable readers to point out that a such and such "DCC" system is not really DCC if it isn't. 

Once again Caveat Emptor.


----------



## East Broad Top (Dec 29, 2007)

Mike, I think we're on the same page. In my example (a product that doesn't--yet--exist), the decoder isn't part of the equation. What I'm suggesting is a compact DCC command station that can be powered by a battery and fit inside a locomotive. Its output would be the same DCC output that its larger brethren would label "track" outputs. You'd just wire that directly to the "track" inputs of whatever flavor of decoder you wanted to use. That would be a "wireless DCC" product which would be very easy to test for DCC compliance using the existing standards. 

But that ain't what we're dealing with here, and you're correct--it's difficult to test these for "full" compliance since they're essentially integrated products. The closest would be Airwire's receiver/command station, since it's the only one with a straight DCC output in addition to all its other outputs. You could feasibly plug any DCC decoder into that output if you wanted to, so long as you don't exceed its 3-amp rating. 

Later, 

K


----------



## Road Foreman (Jan 2, 2008)

Number 1, you can have a decoder that works on DCC but does not meet the standards.. There is nothing that makes you comply with the standards unless you want to.. Example Bachmann's Shay with sound.. 

Number 2, look @ how the AirWire system works.. The transmitter is sending a DCC signal over the air to a receiver that sends it to a decoder.. Example is the QSI decoder with a GWire receiver.. 

Number 3, there a issues when you hook-up a receiver to a decoder & use a AirWire or NCE throttle, I will not go there, you can if you wish.. 

The system that Tony is talking about looks very close to the AirWire throttle with a QSI receiver & decoder.. 
Is it Wireless DCC, I would have to say yes.. 

BulletBob


----------



## krs (Feb 29, 2008)

To number 1 - The only decoders that should meet the standard are those that have passed NMRA DCC compliance testing and have received the NMRA DCC conformance seal. I'm not aware of any manufacturer displaying the NMRA DCC conformance seal (the "football") without authorization by NMRA. 
Not sure what the point of "Number 1" is. 

To Number 2 - There is no way one can transmit the DCC signal over the air as I explained earlier. For one, you cannot transmit the power by wireless means required to run the loco (which is part of the DCC signal); you can also not transmit the DCC bi-polar signal directly using wireless means. 
Until NMRA defines "wireless DCC" and adresses those two issues there cannot be any "wireless DCC" system no matter what manufacturers claim. Simply technically impossible. 

To Number 3 - ???? 

The closest thing to "wireless DCC" will be the Massoth DRC-300 if it ever sees the light of day. 

Knut


----------



## toddalin (Jan 4, 2008)

Posted By krs on 27 Jul 2011 01:03 AM 

To Number 2 - For one, you cannot transmit the power by wireless means required to run the loco (which is part of the DCC signal); 

Knut 


I think Tesla would take issue with this.


----------



## Road Foreman (Jan 2, 2008)

I beleive that the AirWire throttle puts out a RF signal modulated with DCC packets.. This is received by the AirWire receiver or a GWire receiver.. From the GWire receiver it goes to the QSI decoder.. Power for the decoder is by battery or DC track power.. Is this wireless DCC, I say it is because the DCC signal is sent over the air.. 

As for standards I hve 2 DS52 decoders & 3 DH163IP decoders and they do not have the "football seal" so they must not be comoliant.. Therefore I say the DCC standards don't mean squat.. By the way I used Digitrax decoders because I had them laying around but there a plenty of others that are the same..


----------



## TonyWalsham (Jan 2, 2008)

Posted By toddalin on 27 Jul 2011 11:14 AM 


Posted By krs on 27 Jul 2011 01:03 AM 

To Number 2 - For one, you cannot transmit the power by wireless means required to run the loco (which is part of the DCC signal); 

Knut 


I think Tesla would take issue with this. 

Just another "Inconvenient Truth" that seems to be ignored??


----------



## krs (Feb 29, 2008)

Posted By toddalin on 27 Jul 2011 11:14 AM 


Posted By krs on 27 Jul 2011 01:03 AM 

To Number 2 - For one, you cannot transmit the power by wireless means required to run the loco (which is part of the DCC signal); 

Knut 


I think Tesla would take issue with this. 
I just knew someone was going to make that type of comment, but guys, let's not get ridiculous.

We are talking about DCC and Large Scale and a technology that is practical and affordable for us.


Knut


----------



## DaveE (Jun 9, 2011)

This is really funny. As a DCC user and worker in the electronics field, it is well understood that DCC is archaic. 
The DCC standard is clearly rail, Kevin's self-anointing not withstanding. I wonder why Toddalin is on the DCC 
forum at all; as Greg has pointed out, his overall attitude wouldn't meet some of the MLS guidelines. 

Greg & Knut are right. Knut: don't give an inch. Do you really care what an R/C guy with that picture thinks? 


Thread hijacking and rant: 
Look at the OpenLCB stuff from some the same guys who did JMRI. It has the beginning components in an open architecture to take 
out DCC from the bottom up. The manufacturers that push the proprietary stuff will bring on an open architecture sooner or later. 
Tony is right in his approach that high volume cheap stuff from other industries will cross-over, but it seems 
that his approach hasn't gone big time. Maybe for the next gen. A Sprog with a down-stream booster is the kind of price 
point that will help our hobby survive. $1,000 blue boat anchors with 1960s menus will not.


----------



## krs (Feb 29, 2008)

Posted By Road Foreman on 27 Jul 2011 01:19 PM 

I beleive that the AirWire throttle puts out a RF signal modulated with DCC packets.. This is received by the AirWire receiver or a GWire receiver.. From the GWire receiver it goes to the QSI decoder.. Power for the decoder is by battery or DC track power.. Is this wireless DCC, I say it is because the DCC signal is sent over the air..


Well, in that case we have to agree to disagree.

To me, DCC means both interoperability with other DCC components and the integration of power and control signal - Airwire or any of the systems like that do not meet either of those criteria.


The biggest issue (IMHO) of calling these systems "wireless DCC" is that people will buy them expecting them to interwork with their existing DCC components - and of course they won't.

Knut


----------



## Totalwrecker (Feb 26, 2009)

Can somebody 'splain me how DCC sends power?? 

DCC as I understand it, is piggybacked on the power supply and the decorder determines how much to use. No??? 
Seems to me that after the signal is decoded from power, it is similar to packets sent in a perfect spiral through the air*. In their respective recorders they go about their chores and assign power from their available sources, be it 'lectricty sent by rail or sucked from a battery. 

I have no dog in this fight, heck I don't even have a dog! 

Perhaps 'Limited DCC' could be applied to these products that try to use or mimic DCC features, yet aren't totally compatible. 

Afterall imitation is a pure form of flattery! 

John 
*the lockouts over!


----------



## TonyWalsham (Jan 2, 2008)

John. 
I would venture to say that *NONE* of the DCC systems are totally "compatible" with each other. 
The "compatibility" is limited to some specific features such as the the way the signal is transmitted from a command station along a power supply to a decoder. 

As I understand it, there is not even a standard for the type of power going out to the motor(s). 

Can anyone tell us which TX hand pieces for example with work with other brands of command stations? ........and for that matter which ones will not?


----------



## Road Foreman (Jan 2, 2008)

Here is a system that a friend has.. AirWire throttle, AirWire decoder & Booster 10.. The input of the Booster 10 is hooked up to the DCC output of the AirWire decoder.. If the throttle is on you can select a loco & run it like as if there was a command station running the booster.. If you turn the throttle off, you have no idea what the loco will do.. It may stop, run wide open forward or wide open backward.. This is because the DCC signal stops, throttle is turned off.. You can program the decoder in the loco to stop on DC voltage.. This will make the loco stop every time the throttle is turned off.. This means you get to run down the battery in the throttle because you can not turn it off while the loco is running.. You can run one loco only.. I do not know what will happen if you turn the throttle off on a QSI system.. 

BulletBob


----------



## Road Foreman (Jan 2, 2008)

Tony, 

They left the motor control up to the manufacturers because some use BEF for speed control & some do not.. What throttles will work with what systems requires a lot of study of the verious systems.. 

BulletBob


----------



## TonyWalsham (Jan 2, 2008)

Posted By Road Foreman on 27 Jul 2011 08:11 PM 

Tony, 

SNIP


They left the motor control up to the manufacturers because some use BEF for speed control & some do not.. 

BulletBob 

That I did know


Posted By Road Foreman on 27 Jul 2011 08:11 PM 

Tony, 

What throttles will work with what systems requires a lot of study of the verious systems. SNIP 

BulletBob 


Which does illustrate the point DCC detractors often bring up, that if a whole lot of study is required to determine even a relatively simple proposition such as that, DCC systems are not really totally compatible.


----------



## krs (Feb 29, 2008)

Posted By TonyWalsham on 27 Jul 2011 07:03 PM 
John. 
I would venture to say that *NONE* of the DCC systems are totally "compatible" with each other. 
The "compatibility" is limited to some specific features such as the the way the signal is transmitted from a command station along a power supply to a decoder. 

As I understand it, there is not even a standard for the type of power going out to the motor(s). 

Can anyone tell us which TX hand pieces for example with work with other brands of command stations? ........and for that matter which ones will not? 


Tony - 

Maybe you better read up on DCC - there is certainly lots of literature available.

Re your comment: "I would venture to say that *NONE* of the DCC systems are totally "compatible" with each other." 
DCC systems were never meant to be compatible with each other - why should they be?
If I have an NCE DCC system say - why would I care if it is compatible with the Digitrax system? or Massoth or Zimo or any other DCC system?
What I'm interested in is compatibility between my DCC system and any DCC decoders that I want to control - mobile decoders, stationary decoders, function decoders...what have you.


That's waht DCC is all about - on the DCC system side manufacturers develop product to address certain market segments, or you can build your own or even wrtite software for your computer to allow it to perform the DCC Cental Station function - on th decoder pretty much the same - buy one from any manufacturer or even build one yourself.
Same reason why there is no standard for the power going to the motor - a standard there wouldn't make any sense especially since different types of motors are used in model railroading where one type of power drive is not suitable for all.

As to the TX hand pieces, those are part and parcel of the system - there was never intended to be a DCC standard in that area.

But there is some limited compatibility that some manufacturers have developed based on market demand.
The "link" between throttle and command station is called a cab bus (or some similar terminology) - and there are some where the original manufacturer has made the spec vailable so that others can develop compatible devices, but that has nothing to do with the DCC standard.

Common buses are for instance Loconet (originally developed by Digitrax), X-Bus and ExpressNet (devloped by Lenz), CAN-Bus (used by Zimo)...actually googling for a few seconds brought this table of DCC systems up which lists which cab bus each one uses:

http://raicho.home.xs4all.nl/model/control/overview.htm

ESU and Massoth make receivers for their wireless throttles for a number of these cab buses so you can use their throttles with different DCC systems; the iphone and WiFi based throttles also depend on a receiver of some sort that ties into a DCC Central Station through one of these buses.

Bottom line - eventually one needs to generate the power to drive the motor in the loco and the control signal to tell the DCC decoder what to do - tht's where the NMRA DCC standard comes in.

Knut


----------



## TonyWalsham (Jan 2, 2008)

Posted By krs on 27 Jul 2011 10:17 PM 
Posted By TonyWalsham on 27 Jul 2011 07:03 PM 
BIG SNIP.

Bottom line - eventually one needs to generate the power to drive the motor in the loco and the control signal to tell the DCC decoder what to do - tht's where the NMRA DCC standard comes in. 
Knut 





Which brings us right back to the proposition put by others above.

If all that is required, as you put it above, is to superimpose a signal over the power source, such as batteries, to drive the motor, then, if the DCC signal was duplex back to the hand piece, how would that not be DCC and possibly compliant?


----------



## East Broad Top (Dec 29, 2007)

http://tsd.digitrax.com//index.php?a=22 

Interesting article by Digitrax that talks about standards, conformance, and why manufacturers may or may not fully comply with them. It sets up the manufacturers' use of the term "DCC" without necessarily being in full compliance with the NMRA. This was written 5 years ago, and I think we've seen even more innovation that goes well beyond the scope of the NMRA's standards since then. 

Read into that what you will about the role of the NMRA in future development and impact on DCC, but I think we can expect the famaliar contexts to be further challenged as the technology moves forward. 

Later, 

K


----------



## Axel Tillmann (Jan 10, 2008)

Tony - get it into your head.

DCC is a standard - and calling a pig a cow doesn't make the pig a cow.

The correct marketing for wireless control of engines equipped with DCC control boards is:

"RF technology that sends uni-directional signals to individual engine receivers that convert the signals into DCC commands, enabling the users to utilize certain DCC components".

What are the parameters of this "work". Now lets take a look.

Are you using Battery Power feeding the RF receiver and the RF receiver will generate on two wires xx Volt DCC track power, or do you rely on the Battery to be connected to the +/- voltage of the DCC board as well and you are only generating low power DCC that is connected to track inputs of the DCC boards, or are you even utilizing the SUSI interface in which case you are not even generating DCC commands.

In either of the 3 cases it is not (as Knut well established) DCC - it is some proprietary RF method that reconverts the signals to some form understandable by DCC controllers. If there would be such a thing as wireless DCC the the Air would be the "track" and anybodies handheld and anybodies RF receiver could be used - if you use the analogy of DCC.

We don't even want to go into the details of track segmentation, automated train control, Programming of engines via the RF handheld, you name - all features and capabilities inside DCC.

But what we want to mention is, why in the heck do you want to pay on top of the DCC decoder, which is a perfect receiver of DCC, for a battery and an RF receiver adding easily another $100 to you engine conversion. Wait a minute - I forgot track power is the Darth Vader of our hobby, I totally forgot.

It is only too bad that those problems haven't shown up at my layout yet, and neither by thousands of others.


----------



## TonyWalsham (Jan 2, 2008)

Axel. 
With respect. 
There is no point in lecturing me personally. I have no iron in this fire. 
The *ONLY* thing that concerns me is the fact that there are now many manufacturers of R/C - DCC equipment that are calling their products DCC. Products that both you, Knut and others vehemently say are not DCC compliant, and "mis-statements" that you seem not very interested in doing anything about. 
If you are so passionate about this "misnaming" of "DCC" products why don't you do something about it, contact the NMRA and take action to have these claims corrected, instead of picking on me? 

As to why battery instead of track power. 
If battery power was such a waste of time, effort and money, why is that there are now at least half a dozen DCC manufacturers that consider it worthwhile pursuing such a method of loco powering and controlling with what they say is DCC?


----------



## Chip (Feb 11, 2008)

Regarding compatibility: I run a Massoth central station with Massoth, Zimo, Digitrax, and other decoders. Why? Each one
has strengths for me. For example, the Zimo 82E has more ports for servos and the Digitrax 1 amp motor decoder is a $17 solution.


I don't understand Knut's declaration of "DCC systems were never meant to be compatible with each other - why should they be?"
That is not what I have heard personally from the DCC manufacturers. But hey, I am no match for Knit.


----------



## krs (Feb 29, 2008)

Posted By Chip on 29 Jul 2011 06:06 PM 


I don't understand Knut's declaration of "DCC systems were never meant to be compatible with each other - why should they be?"
That is not what I have heard personally from the DCC manufacturers. But hey, I am no match for Knit.




This was a comment I made in response to Tony's statement/question re compatibility of throttles.

What is standardized in DCC is the interface between the Central Station (or booster) and the DCC decoders, so that allows you to use any DCC compliant decoder with your choice of DCC system, Massoth in your case. That was the sole intent of the DCC compatibility.
There was never any intent for compatibility *between* DCC systems - for example, you cannot use a Zimo throttle with your Massoth system or Digitrax transponding with your Massoth system.


Now, there are some devices that manufacturers try to make compatible on the system side of DCC - the Massoth throttle for instance can be used with a Digitrax system or with a Lenz system, but that is because Massoth decioded to offer a receiver module for their throttle that is compatible with Loconet (for Digitrax) and XpressNet (for Lenz), but that has nothing to do with the NMRA DCC standard.

ESU also offers various receiver modules to make their throttle compatible with other systems.

When DCC mnufacturers talk about "compatibility", they mean betweem system and decoders, not between different systems.

Hope that is clear.

Knut


----------



## krs (Feb 29, 2008)

Posted By TonyWalsham on 29 Jul 2011 05:55 PM 
Products that both you, Knut and others vehemently say are not DCC compliant, and "mis-statements" that you seem not very interested in doing anything about. 
If you are so passionate about this "misnaming" of "DCC" products why don't you do something about it, contact the NMRA and take action to have these claims corrected, instead of picking on me?


Tony,

I actually sent an email to Stan Ames more than a week ago but don't have a reply yet.
Maybe it went to an unmonitored email address.

I also looked on the NMRA website - but couldn't find an appropriate email address there - only snail mail addresses.

In any case, I cannot prevent manufacturers from misrepresenting their products - happens all the time and Large Scale and DCC products are no exceptions.

In the end the manufacturer will be the one who is "suffering".


Knut


----------



## TonyWalsham (Jan 2, 2008)

OK Knut. 

Perhaps if enough stirring is done by those of us qualified to comment and would like to see products represented truthfully, the NMRA will be "stirred" into action. 
That is if the NMRA considers action actually needs to be taken and not simply ignored. 

Granted in the long run manufacturers may suffer from misrepresenting their products.. But that will only happen if all of us stop bringing such misrepresentations to the attention of the buying public.
It happens when we allow Grey areas of marketting to prosper when those areas should be black or white.
I believe it is the responsibility of relevant authorities, in this case the NMRA, to be vigilant in this regard and protect the interests of the buying public.

That is why I keep raising this subject. Not to bash DCC per se. 

I look forward to seeing follow up success in "correcting" the misrepresentations.


----------



## Mike Reilley (Jan 2, 2008)

Well...I guess I'm the one that got us started on the "standards" issue....and said (sorta) "if it's wireless, it can't be DCC". I also explained that I worked professionally with the Institute for Electronics and Electrical Engineers on setting IEEE standards for electronics. So...I have a strong bias as to what a "standard" is...and is NOT.

NMRA, like the IEEE and many other standards organizations, owns "rights" to their standard. It's important to enforce "rights" IMHO...as it is US, the consumer, that loses BIG TIME if vendors all allowed to say they are compliant with standards when they are not.

For example, everyone here uses a computer. It's FULL of standard interfaces...many are inside and you don't care about them. But there are many "outside" and YOU DO CARE. Take the USB interface....how would you like it if the folks that made you printer or your mouse or your keyboard or your scanner or...pick one...decided to say they had a USB compliant interface...and didn't. You would be pissed beyond recognition after having spent your money on something that didn't "work". How pissed would you be if your new supposedly "USB compliant mouse" burned out the USB interfaces in your computer?


I can make the same analogy for your TV...or your stereo...or you car's tires...or half of the consumer appliances in your home. You may not know it...but MOST of the complicated stuff you buy is built to "standards". Heck...even the simple stuff is built to standards....ever look at an electrical plug? Would you like it if it wasn't safe to hold with your hand to plug in?


So...what happens if we let every Tom, Dick, and Harry say their latest train control gizmo is DCC compliant? What if they just use DCC in the name of the gizmo? What if they claim it' a "wireless" variant of DCC? 


Well the answer is the value of the DCC "standard" to us GOES DOWN THE TUBE!!!!! It means when we buy a decoder, we can't be SURE it will work properly. It means we run the risk of the new gizmo DAMAGING a gizmo we already own. And, I could go on.


We should NOT let vendors claim stuff is DCC compliant...or even use the term DCC in the name of the gizmo unless they take particular care to clarify just how compliant their gizmo is to the real DCC standards...and frankly, where it isn't compliant. If we let this happen, we're shooting ourself in the foot.


(Footnote....I know many REAL DCC manufacturers do NOT actually take their new gizmo through the NMRA DCC compliance tests. They're not cheap to run. IMHO, they're running the risk of ruining their reputation...but it IS a cost benefit situation. IMHO, if they're a reputable manufacturer, they've probably done their due diligence and the device is probably safe. But, from my view, it's a heck of a risk.)


----------



## Homo Habilis (Jul 29, 2011)

I've been a lurker at this site for about a year and have finally joined since it was probably about time as I am getting ready to start an indoor Fn3 layout and will need to ask many questions. It will be DCC, battery and R/C.

Anyway, I'm not certain if the following adds anything to this topic but perhaps it will provide some clarity to the Stanton product. I was at the Sacramento show and saw a one page product overview at the NWSL booth. I asked if they had anything more informative and they didn't. I then did a bit of googling and found the following -

http://www.freerails.com/view_topic...orum_id=45

http://www.freerails.com/view_topic...orum_id=45

Mark 

p.s. hope this formats ok since it's my first post on this particular forum. Is the default font really this small?


----------



## krs (Feb 29, 2008)

Thanks for the link HH. 

To me this is yet another proprietary R/C system of which there are dozens. 
A different approach in that they use a standard DCC decoder which eliminates the need to develop motor drive and function output drive along with the short circuit and over temperature protection. 
What I think will be confusing (besides the DCC nomenclature) is which of the DCC decoder features can actually be accessed using this approach. 

And the default font renders fine for me, but that is probably my browser setting.


----------



## krs (Feb 29, 2008)

Posted By Mike Reilley on 29 Jul 2011 07:25 PM 

So...what happens if we let every Tom, Dick, and Harry say their latest train control gizmo is DCC compliant? What if they just use DCC in the name of the gizmo? What if they claim it' a "wireless" variant of DCC? 



Well the answer is the value of the DCC "standard" to us GOES DOWN THE TUBE!!!!! It means when we buy a decoder, we can't be SURE it will work properly. It means we run the risk of the new gizmo DAMAGING a gizmo we already own. And, I could go on. 




Mike,

I agree with everything you posted.............

One thing I noticed - none of the manufacturers who claim their system is "wireless DCC" actually use the DCC logo in their advertising











Maybe from the "True DCC" manufacturers point of view that makes the difference - just guessing.


Knut


----------



## TonyWalsham (Jan 2, 2008)

Thanks Mike. 
Very succinctly out. 

We need to be vigilant and voice our opinions where and when necessary. 

Thanks to You, Knut, Greg, and others we know that those items claiming to be DCC wireless are not actually wireless. 
Now it is incumbent on the NMRA to clear up the situation and state exactly what is and isn't DCC and prevent those items that are not DCC being associated with the DCC "brand".


----------



## East Broad Top (Dec 29, 2007)

What I think will be confusing (besides the DCC nomenclature) is which of the DCC decoder features can actually be accessed using this approach. 
If they do it "right," all of them. Look at how the NCE G-wire throttle controls the QSI board. There's absolutely no difference in functionality (or programming or even operation) between running the QSI board via NCE's "traditional" DCC rig and via their G-wire transmitter/receiver combo. Airwire's controllers do a good job of controlling any DCC decoder you plug into the DCC output of their receivers, too (in addition to programming the motor-control CVs on that side of the board.) From the links Mark supplied (Welcome, Mark!), the NWSL unit appears to be fairly full-functioned except for the addressing (two digits instead of four). We'll not be able to answer that for our purposes until they release a version that's beefy enough for large scale. 

As for standards, I agree with Mike and Knut about the need to make sure the interface between command station and decoder remain true to the established standards. The beauty there is that "wireless" doesn't enter the equation at that point since the "wireless" part is well upstream of that interface. In the Transmitter>Receiver>Command Station>Decoder model, _only_ the interface between transmitter and receiver is wireless, and _only_ the interface between the command station and decoder is covered by the DCC standards. The Transmitter>Receiver>Command Station aspect is largely proprietary on most fronts. That's where the various manufacturers compete. They take great strides to ensure their products work with any DCC decoder (with or without NMRA "testing") but each manufacturer includes various bells, whistles, etc. to make their particular throttle/command station bundle the most competitive. 

So, how is "wireless DCC" truly defined? Can it _be_ defined to any degree of specificity? Do you define "wireless DCC" in terms of the means or in terms of the end? Most manufacturers offer some kind of wireless control for their DCC command stations, as model railroaders generally don't like getting tangled in wires. Thus you have a wireless throttle that ultimately controls a DCC decoder. Is that "wireless DCC?" At the basic level, you've got the same thing with the NWSL system or the NCE/G-wire system; wireless control of a DCC decoder. The means are different, but the ends are identical. Personally, I tend to think that the term "DCC" has advanced well beyond its roots. It's no longer a concept that can be so narrowly defined as to mean any one single means of delivering command signals. At the same time, I think you can easily maintain the purity of the standards (i.e, the data packets, CVs, etc. that define how specific things are controlled) without infringing on the manufacturers' abilities to push the envelope of control. Personally, I see the day when the central command station becomes obsolete--when all commands are sent wirelessly to an on-board receiver that feeds the decoder. The rails will be there purely to supply power (if that). I suggest we not get so caught up in the semantics that we ultimately stifle technological advances. 

Let's face it, "DCC" carries with it something of a reputation of being hard to learn (whether deserved or not). If these advances in technology excite the masses to learn how to take advantage of what DCC has to offer, and can get them going with simple-to-install complete packages, how is that a bad thing? 

Later, 

K


----------



## krs (Feb 29, 2008)

Posted By East Broad Top on 30 Jul 2011 01:04 AM 
What I think will be confusing (besides the DCC nomenclature) is which of the DCC decoder features can actually be accessed using this approach. 
If they do it "right," all of them.
I don't think that is true generally.

For very simple DCC decoders this is probably true although I was rather surprised that this system does not handle 4-digit addressing (which I always thought was pretty basic with today's systems), but features in DCC to a large degree need to be implemented in both the DCC decoder AND the command station (or throttle in this case) to be accessible and it isn't clear to me at all which capability the throttle in this system provides.

There is no description of the capabilities that I have been able to find, the iterature so far just glosses over that aspect with comments like 


The throttle is a slider. Change directions by flipping the Direction switch. Press HALT in an emergency. *There is lengthy technical detail behind all this, but why bother.* Just have some fun running trains with the benefits of DCC, but without its complexity, at an affordable price.

This system seems to be aimed at the hobbyist who is looking for a very basic R/C type control of his trains with an absolute minimum of extra capabilty, but one at the lowest cost possible.


Knut


----------



## East Broad Top (Dec 29, 2007)

I don't think that is true generally. 
In terms of the NWSL control, it does appear to have some limitations (2-digit addressing only for one, and time--and experience--will reveal other potential ones) but in general terms of the overall approach to this kind of control, Both the NCE and Airwire controls allow you fairly thorough control of the boards (though there are some distinct limitations when using the NCE throttle to program the Airwire boards). There's no technical reason why these remote systems can't be as full-featured as their "big brothers," it's a matter of how small can you make the microprocessor to control it? It's purely up to the specific manufacturer as to how full-featured and complex they wish to make things. Also, if/when we ever get a "true" on-board command station--one that outputs a generic DCC signal to any manufacturers' decoder--I think the manufacturers are going to have to ensure their systems are very full-featured in order to attract the customers. 

This system seems to be aimed at the hobbyist who is looking for a very basic R/C type control of his trains with an absolute minimum of extra capabilty, but one at the lowest cost possible. 
I think that nails it on the head, though I don't know that I'd call the NCE decoder "absolute minimum." It's arguably fairly full-featured in its own right when compared to the non-DCC R/C control systems on the market against which I think this system is designed primarily to compete. (Aristo's HO "Revolution" and others.) But yes, I think this is aimed squarely at the "anti-diddle" crowd--the folks who don't need to customize every last aspect of a locomotive's performance. (Which--arguably--is a very large segment of the model railroading hobby.) And low cost is always a good thing.  

Later, 

K


----------



## Mike Reilley (Jan 2, 2008)

Posted By East Broad Top on 30 Jul 2011 01:04 AM 

So, how is "wireless DCC" truly defined? IT ISN'T. YOU'RE SUPPORTING A MOVE TO DO THAT THOUGH. I WOULD TOO...AND THEN THE TERM "WIRELESS" WITH "DCC" SHOULD BE USED. NOT BEFORE THEN.

Can it _be_ defined to any degree of specificity? YOU BET...JUST LIKE ALL STANDARDS ARE DEFINED...BUT IT TAKES A GOOD DEAL OF MONEY WHICH I DON'T SEE OUT THERE IN THIS INDUSTRY.

Do you define "wireless DCC" in terms of the means or in terms of the end? THERE ARE FUNCTIONAL STANDARDS (E.G. ADDRESS, COMMANDS, ETC) AND ELECTRICAL STANDARDS. BOTH ARE NEEDED IN THIS INSTANCE AS YOU WANT TO ENSURE IMPLEMENTATION OF A CONSISTENT FUNCTIONALITY AND YOU WANT TO ENSURE THAT ELECTRICAL INTERFACES ARE CAPABLE OF THE CURRENT, VOLTAGE, AND FREQUENCY REQUIREMENTS OF THE PROPOSED STANDARD.

Most manufacturers offer some kind of wireless control for their DCC command stations, as model railroaders generally don't like getting tangled in wires. Thus you have a wireless throttle that ultimately controls a DCC decoder. Is that "wireless DCC?" NO...IN FACT, ALL WIRELESS THROTTLES CURRENTLY IN USE HAVE COMPLETELY PROPRIETARY INTERFACES BETWEEN THE THROTTLE AND THE COMMAND STATION. YOU CANNOT USE THE THROTTLE FROM ONE MANUFACTURER TO CONTROL ANOTHER MANUFACTURERS COMMAND COMMAND STATION.

At the basic level, you've got the same thing with the NWSL system or the NCE/G-wire system; wireless control of a DCC decoder. The means are different, but the ends are identical. NO YOU DON'T. YOU MIGHT HAVE A FUNCTIONAL SIMILARITY BUT THAT'S WHERE IT ENDS FROM A STANDARDS POINT OF VIEW. YOU CANNOT INTERFACE THE NCE/G-WIRE SYSTEM WITH ANY DCC DECODER...ONLY CERTAIN ONES. THE AIRWIRE "DECODER" IS ACTUALLY A COMBINED RECEIVER/MOTOR CONTROLLER WITH A SUPPOSEDLY DCC COMPLIANT INTERFACE TO HOOK TO APPLIANCE DECODERS. GIVEN THAT CVP MAKES REAL DCC DECODERS, IT'S LIKELY THEIR DCC OUTPUT IS CLOSE TO COMPLIANT TO THE STANDARDS.

Personally, I tend to think that the term "DCC" has advanced well beyond its roots. It's no longer a concept that can be so narrowly defined as to mean any one single means of delivering command signals. WELL, THAT'S EXACTLY HOW YOU TRASH A STANDARD. YOU JUST IGNORE IT BECAUSE THERE IS A "BETTER" REPLACEMENT. CAN YOU IMAGINE HOW COMPUTER FOLKS WOULD HAVE LOVED TO HAVE THE COMPUTER CHIP MAKERS DUMP THE USB 1.0 STANDARD IMPLEMENTATION WHEN USB 2.0 CAME OUT?. I DON'T THINK IT WOULD BE SO GREAT TO HAVE TO REPLACE YOUR USB 1.0 COMPLIANT STUFF (YOUR OLD DECODERS) WITH NEW ONES JUST BECAUSE YOUR NEW COMPUTER RUNS USB 2.0 (THE NEXT GENERATION DECODER).

At the same time, I think you can easily maintain the purity of the standards (i.e, the data packets, CVs, etc. that define how specific things are controlled) without infringing on the manufacturers' abilities to push the envelope of control. AGAIN, YOU'RE SPEAKING ON JUST THE FUNCTIONAL INTEROPERABILITY PARTS OF THE STANDARD...AND NOT THE ELECTRICAL PARTS.

Personally, I see the day when the central command station becomes obsolete--when all commands are sent wirelessly to an on-board receiver that feeds the decoder. The rails will be there purely to supply power (if that). I HOPE SO TOO. I HOPE WE CAN USE THE NEW 2.4G OR 5.8G STANDARDS FOR COMM...NOTE, I SAID STANDARDS. LEAST THE NMRA WOULDN'T HAVE TO GET INTO THE IEEE BUSINESS OF DEFINING THE BASIC COMMUNICATIONS PROTOCOLS.

I suggest we not get so caught up in the semantics that we ultimately stifle technological advances. IT'S ONLY SEMANTICS TO YOU. THE BEAUTY OF DCC WAS THE ABILITY TO BUY ANY DECODER, ESPECIALLY THE NEXT NEW DECODER, AND KNOW THAT IT WOULD WORK WITH YOUR OLD GEAR. WITHOUT STANDARDS, THAT'S NOT POSSIBLE WITH THE WAY THE MANUFACTURERS ARE GOING IN THE NEW BS "WIRELESS DCC" WORLD. IT'S JUST NOT DCC...AND CERTAINLY DOESN'T FULFILL THE INTENT OF DCC...THAT BEING INTEROPERABILITY AT THE FUNCTIONAL AND ELECTRONICS LEVEL.

 Let's face it, "DCC" carries with it something of a reputation of being hard to learn (whether deserved or not). If these advances in technology excite the masses to learn how to take advantage of what DCC has to offer, and can get them going with simple-to-install complete packages, how is that a bad thing? WELL...IT'S NOT DCC THEN...BECAUSE THE WHOLE POINT OF MOVING FROM ORIGINAL "COMMAND CONTROL" OF TRAINS TO "DIGITAL COMMAND CONTROL" WAS SO YOU DIDN'T NEED BUY A "COMPLETE PACKAGE".

Later, 

K


----------



## SteveC (Jan 2, 2008)

Mike

While I totally agree as to the intent of standards, however, their existence in and of themselves does not assure a plug-n-play compatibility.

Admittedly it is older technology, but over the years I've worked on many pieces of computer equipment that utilized an RS-232C standard for communication between various pieces of equipment manufactured by different companies. And even if you didn't have to bother with two different cable end connection plugs (i.e. DB-9 & DB-25) and its associated wiring requirements. When connected, they wouldn't actually communicate. Yet, when looked at from either products' point of view they fully met the respective RS-232C standard.


----------



## DKRickman (Mar 25, 2008)

You know what I think? 

I think folks enjoy arguing! 

It's an interesting debate, no doubt, but it seems to be getting a bit heated at times, and I can't see that it's worth getting mad at each other over. 

Mike, I agree with your comments about standards, but... there is a certain well known company (dark cabal?) in Redmond WA that is very well known for perverting standards - Java comes to mind, but I'm sure we can all think of one or two. I don't find that it damages the standard, but it makes me think pretty poorly of that company that does the perversion. Maybe something similar will happen with DCC - there will be one or two companies with poor reputations, and folks will tend to shy away from them while still supporting DCC in general.


----------



## Road Foreman (Jan 2, 2008)

Mike, 

Posted By East Broad Top on 30 Jul 2011 01:04 AM 

So, how is "wireless DCC" truly defined? IT ISN'T. YOU'RE SUPPORTING A MOVE TO DO THAT THOUGH. I WOULD TOO...AND THEN THE TERM "WIRELESS" WITH "DCC" SHOULD BE USED. NOT BEFORE THEN. The manufacturers have already started to define the term.. 

Can it be defined to any degree of specificity? YOU BET...JUST LIKE ALL STANDARDS ARE DEFINED...BUT IT TAKES A GOOD DEAL OF MONEY WHICH I DON'T SEE OUT THERE IN THIS INDUSTRY. Not so, to many things changing to fast.. 

Do you define "wireless DCC" in terms of the means or in terms of the end? THERE ARE FUNCTIONAL STANDARDS (E.G. ADDRESS, COMMANDS, ETC) AND ELECTRICAL STANDARDS. BOTH ARE NEEDED IN THIS INSTANCE AS YOU WANT TO ENSURE IMPLEMENTATION OF A CONSISTENT FUNCTIONALITY AND YOU WANT TO ENSURE THAT ELECTRICAL INTERFACES ARE CAPABLE OF THE CURRENT, VOLTAGE, AND FREQUENCY REQUIREMENTS OF THE PROPOSED STANDARD. Maybe.. 

Most manufacturers offer some kind of wireless control for their DCC command stations, as model railroaders generally don't like getting tangled in wires. Thus you have a wireless throttle that ultimately controls a DCC decoder. Is that "wireless DCC?" NO...IN FACT, ALL WIRELESS THROTTLES CURRENTLY IN USE HAVE COMPLETELY PROPRIETARY INTERFACES BETWEEN THE THROTTLE AND THE COMMAND STATION. YOU CANNOT USE THE THROTTLE FROM ONE MANUFACTURER TO CONTROL ANOTHER MANUFACTURERS COMMAND COMMAND STATION. You need to check out ESU, there system will work with 4 or 5 throttles.. And there are maybe more.. 

At the basic level, you've got the same thing with the NWSL system or the NCE/G-wire system; wireless control of a DCC decoder. The means are different, but the ends are identical. NO YOU DON'T. YOU MIGHT HAVE A FUNCTIONAL SIMILARITY BUT THAT'S WHERE IT ENDS FROM A STANDARDS POINT OF VIEW. YOU CANNOT INTERFACE THE NCE/G-WIRE SYSTEM WITH ANY DCC DECODER...ONLY CERTAIN ONES. THE AIRWIRE "DECODER" IS ACTUALLY A COMBINED RECEIVER/MOTOR CONTROLLER WITH A SUPPOSEDLY DCC COMPLIANT INTERFACE TO HOOK TO APPLIANCE DECODERS. GIVEN THAT CVP MAKES REAL DCC DECODERS, IT'S LIKELY THEIR DCC OUTPUT IS CLOSE TO COMPLIANT TO THE STANDARDS. The Gwire receiver will work with both the AirWire throttle or the NCE/Gwire throttle.. Also the Gwire receiver will work with most decoders.. 

Personally, I tend to think that the term "DCC" has advanced well beyond its roots. It's no longer a concept that can be so narrowly defined as to mean any one single means of delivering command signals. WELL, THAT'S EXACTLY HOW YOU TRASH A STANDARD. YOU JUST IGNORE IT BECAUSE THERE IS A "BETTER" REPLACEMENT. CAN YOU IMAGINE HOW COMPUTER FOLKS WOULD HAVE LOVED TO HAVE THE COMPUTER CHIP MAKERS DUMP THE USB 1.0 STANDARD IMPLEMENTATION WHEN USB 2.0 CAME OUT?. I DON'T THINK IT WOULD BE SO GREAT TO HAVE TO REPLACE YOUR USB 1.0 COMPLIANT STUFF (YOUR OLD DECODERS) WITH NEW ONES JUST BECAUSE YOUR NEW COMPUTER RUNS USB 2.0 (THE NEXT GENERATION DECODER). 

At the same time, I think you can easily maintain the purity of the standards (i.e, the data packets, CVs, etc. that define how specific things are controlled) without infringing on the manufacturers' abilities to push the envelope of control. AGAIN, YOU'RE SPEAKING ON JUST THE FUNCTIONAL INTEROPERABILITY PARTS OF THE STANDARD...AND NOT THE ELECTRICAL PARTS. The Gwire receiver has already changed the voltage specifications of the standard.. 

Personally, I see the day when the central command station becomes obsolete--when all commands are sent wirelessly to an on-board receiver that feeds the decoder. The rails will be there purely to supply power (if that). I HOPE SO TOO. I HOPE WE CAN USE THE NEW 2.4G OR 5.8G STANDARDS FOR COMM...NOTE, I SAID STANDARDS. LEAST THE NMRA WOULDN'T HAVE TO GET INTO THE IEEE BUSINESS OF DEFINING THE BASIC COMMUNICATIONS PROTOCOLS. Again the Gwire receiver has already done that, but it only runs in the 900 Mhz range.. 

I suggest we not get so caught up in the semantics that we ultimately stifle technological advances. IT'S ONLY SEMANTICS TO YOU. THE BEAUTY OF DCC WAS THE ABILITY TO BUY ANY DECODER, ESPECIALLY THE NEXT NEW DECODER, AND KNOW THAT IT WOULD WORK WITH YOUR OLD GEAR. WITHOUT STANDARDS, THAT'S NOT POSSIBLE WITH THE WAY THE MANUFACTURERS ARE GOING IN THE NEW BS "WIRELESS DCC" WORLD. IT'S JUST NOT DCC...AND CERTAINLY DOESN'T FULFILL THE INTENT OF DCC...THAT BEING INTEROPERABILITY AT THE FUNCTIONAL AND ELECTRONICS LEVEL. 

Let's face it, "DCC" carries with it something of a reputation of being hard to learn (whether deserved or not). If these advances in technology excite the masses to learn how to take advantage of what DCC has to offer, and can get them going with simple-to-install complete packages, how is that a bad thing? WELL...IT'S NOT DCC THEN...BECAUSE THE WHOLE POINT OF MOVING FROM ORIGINAL "COMMAND CONTROL" OF TRAINS TO "DIGITAL COMMAND CONTROL" WAS SO YOU DIDN'T NEED BUY A "COMPLETE PACKAGE". 

Later, 
K 

BulletBob


----------



## TonyWalsham (Jan 2, 2008)

Hey Bob. 
Apart from quoting the contribution from Mike, were there any extra comments added by you?


----------



## East Broad Top (Dec 29, 2007)

Mike, nothing I'm suggesting would in any way negate or infringe upon the current standards. The NMRA standards concern the interface between the command station and the decoder (the thing that in the "traditional" model is separated by rails). That doesn't change. What I'm suggesting is essentially a repackaging of what we currently have. 

Example... 

If you run traditional track-powered DCC, you choose your brand of command station based on the features it has and how it relates to your personal preferences and needs. This command station and how it works with its wireless handheld controllers is proprietary. As you already agree, you can't take your NCE wireless handheld device and expect it to work with your neighbor's Zimo command station. But each and every one of those different command stations puts out to the rails the exact same thing, because that's determined by the standards. Any DCC decoder will be able to work with any command station thanks to that standardization. 

Now, get rid of the big black box command station, and replace it with a small microprocessor on a small PC board that can fit inside a locomotive. Nothing changes except the size of the boxes. So long as the output of that PC board is compatible with any DCC decoder on the market, all is right with the world. Just as DCC users currently choose their proprietary big black box command stations based on their personal needs, they'd choose their proprietary little green PC board command stations instead. How the little box in your hand communicates to the little green PC board doesn't matter, so long as any manufacturer's DCC decoder works properly when you push the buttons. 

I think I see where you're going--you'd like to see a standard interface between transmitter and receiver, so that you can use any manufacturer's transmitter with any other manufacturer's receiver. While I think that may be cool, I don't think it practical for a variety of reasons. Most important of them being the frequencies involved and how they vary from country to country. You can't standardize on a frequency if half your market can't legally purchase it. And if you were to choose a frequency that's legal when the standards are written, what happens 5 years later when the government of XYZ country changes their spectrum allocations? If you do nothing, then you've just cut that country out of being able to use your standards. If you rewrite the standards to a new frequency, you've just obsoleted everything up to that point. Essentially, the "wireless" aspect really has to for practical reasons remain proprietary. But that's not really different than what we have now. With a traditional DCC system, you're "stuck" with your brand of command station for wireless gear, additional throttles, etc. The only "universal" aspect is that you can use anyone's DCC decoder in the locomotive. I think with the years we've had DCC standards so far, no one seems to be complaining too loudly about a lack of interoperability at the command station level. So long as they can take their DCC-equipped locomotive over to their neighbor's track, enter the address on whatever system they use and run the loco, I think most are pretty happy. 

But the reality is that the term "Wireless DCC" is already being used by some in the industry to describe their wireless systems that control their trackside command stations. And as more and more wireless systems using DCC components come on the market, I think we're going to see that phrase garner more commercial acceptance despite not being "technically correct." What alternative is there? "Wireless control using DCC components" isn't exactly catchy. I'm afraid the die may have been cast already. I think the proper course of action is to smile, nod, and keep pressure on the manufacturers to make sure they stick to the standards regardless of what they want to call it. 

Later, 

K


----------



## TonyWalsham (Jan 2, 2008)

Using the example described by Kevin as I read it. 
I would assume that the interface pcb that holds the "micro" command station fed the DCC signal the said "micro" command station generates onto the battery power supply, which then fed the power and DCC signal into what were the track pick ups of any suitable DCC decoder. 
The "micro" command station could probably be programmed to accept any sort of control signal such as multi channel Digital Proportional (DP) R/C as well as regular "DCC" RF transmitters. 
It would be the "micro" command station that did the conversion. 
Sure, DP radios would have a more limited range of functions, but, as mentioned in previous posts, not everyone wants all the "Bells and Whistles". Especially as DP radios would be very cost competitive to the more elaborate hand pieces.


----------



## Road Foreman (Jan 2, 2008)

Tony, 

My comments are after Mike's quotes in capitol letters.. 

Let me add this for the mix.. If you use the GWire receiver with the AirWire throttle you can control 1 locomotive per frequency channel, for a total of 8 locomotives.. If you use the NCE throttle you can control 8 locomotives per frequency channel, for a total of 64 locomotives.. Therefore it looks like the NCE throttle has a small command station built into the throttle.. If I got this wrong I hope somebody from CVP or NCE will jump in & set us straight.. This also looks like the wave of the future to me..

BulletBob


----------



## East Broad Top (Dec 29, 2007)

Tony, I hadn't thought about using DP (digital proportional) radios, but yes, you're interpreting my example correctly and they'd work. As you surmise, they'd be very limited in terms of which DCC functions they can control (speed, direction, and probably 4, maybe 6 sound/light functions? Probably the same as what they can control on non-DCC systems now) but you'd be able to use your favorite DCC motor/sound decoder instead. DCC "power users" would probably cringe, but the DCC users who barely so much as change the decoder address would find it very simple. Programming the CVs would probably be the big stumbling block. I'm not sure how you'd do that with a DP radio. 

Bob, a clarification on the G-wire receiver; it's compatible with many DCC decoders, but you've got to figure out where to tap into them. It's not quite as simple as taking the output of the receiver and simply attaching it to the "track" inputs of the decoder. You can do that with the Airwire receiver and its DCC out terminals, but you're limited to 3 amps capacity. With the G-wire receiver, the QSI board is already getting its power from the battery via the "track in" pins. The receiver takes a 5-volt tap off of that board to power the receiver, and returns the instructions from the transmitter which the QSI board interprets. QSI's web site has some wiring diagrams which show how to attach the G-wire to various boards, but it's definitely not just a 2-wire connection. 

Later, 

K


----------



## Road Foreman (Jan 2, 2008)

Kevin, 

Don't get hung-up on 2 wires for this new wireless DCC.. Somebody posted on this site where he used a GWire receiver running on 5 volts to run a function decoder with LED lights.. How long will it be before the large scale decoder manufacturers start adding the GWire socket to there decoders.. Looks like they are going to have to play catch-up to CVP.. If I was going to go battery power I would use CVP's plug-&-play decoders with a NCE throttle.. Lets try to think out side the box.. What if somebody built a 2.4 Ghz receiver to woik with the 2.4 Ghz throttles & QSI's decoder..

BulletBob


----------



## krs (Feb 29, 2008)

Posted By East Broad Top on 31 Jul 2011 03:01 AM 
If you run traditional track-powered DCC, you choose your brand of command station based on the features it has and how it relates to your personal preferences and needs. This command station and how it works with its wireless handheld controllers is proprietary. As you already agree, you can't take your NCE wireless handheld device and expect it to work with your neighbor's Zimo command station. But each and every one of those different command stations puts out to the rails the exact same thing, because that's determined by the standards. Any DCC decoder will be able to work with any command station thanks to that standardization. 

Now, get rid of the big black box command station, and replace it with a small microprocessor on a small PC board that can fit inside a locomotive. Nothing changes except the size of the boxes.
Nothing changes ???

Well, there is one HUGE change that needs to be considered - with that approach you now need one "Micro Command station" for each and every locomotive rather than one per system.
That gets expensive real fast

And what you are describing is the Massoth DRC-300
http://1stclass.mylargescale.com/krs/DRC_300_Basics.pdf

Obviously not something the market is clamouring for - this item has been on the Massoth drawing board for several years, it sure as heck is not getting any priority to bring it to market.

All the feedback I have had so far on this concept - yeah, it's great, but....I might buy one for a very specialized application.
It's the same problem that Greg has pointed out a few times when comparing battery R/C to DCC, once you have more than a few locos (the number varies a bit depending on thich systems you buy and how much capability you need) te cost of equipping each one with a R/C receiver and battery gets expensive compared to DCC decoders.


Knut


----------



## krs (Feb 29, 2008)

Posted By TonyWalsham on 31 Jul 2011 06:39 AM 
The "micro" command station could probably be programmed to accept any sort of control signal such as multi channel Digital Proportional (DP) R/C as well as regular "DCC" RF transmitters. 


Just a word of clarification -

There is no such thing as a *regular* "DCC" RF transmitter. at least not today or in the forseeable future.

The way ESU and Massoth make their transmitters compatible with other Command Stations is by developing a receiver that takes their proprietary wireless receiver and modifies it to generate one of the standard cab buses, Loconet or XpressNet in Massoths case (plus their own)<
I already mentioned that earlier.
Lenz has taken that a step further by developing and marketing a wireless receiver that accepts the signal from a standard cordless phone as the input.

That has to be the most inexpensive way one can go wireless - the approach sounds a bit awkward from a user point of view, but I have a few friends who tried it and for basic operation this actually works pretty well - probably at least as well as a multichannel DP R/C


Knut


----------



## Greg Elmassian (Jan 3, 2008)

The difference between DCC "systems" and a one to one set of a transmitter to a loco is that there is NO system... In AirWire, and the Revolution and other systems like this, there is no "common knowledge" of what locos are in operation on the system, and how to stop them, for one small example. 

So that's why "all stop" on a DCC system will halt all locos immediately, as opposed to something like the Revolution is FORCED to do, blindly put out a stop command for every "possible" loco, whether it knows about them or not. 

Also, all this falderal about being DCC, the NCE throttle does NOT command every function of the Gwire receivers, and in fact it controls the older ones to a different degree than the newer ones. 

Why? because there IS NO standard for wireless DCC... if there WERE, then you could "mix and match" "wireless DCC transmitters" with "wireless DCC receivers"... 

Right now you have systems that use bits and pieces of DCC ideas and put them over the air. 

If you don't care, that's fine... I use DCC because I can use virtually any decoder with virtually any DCC system. 

If you move from DCC compatible to DCC certified, then that phrase "virtually any" turns into "any"... 

There's a value to standards. Maybe not everyone needs them, but all this malarkey about the definition of DCC changing because of this similar products is just that malarkey. 

If you don't care about standards, fine. But calling something DCC wrongly, whether it is an individual or a company, does not make it right. 

If a person specifically use phrases like "exact same thing", which besides being poor English, is just wrong, similar, and very similar is fine, it is NOT EXACTLY the SAME, and I'm particularly sensitive to people making untrue statements. 

If you are going to use absolutes, then you must be EXACTLY CORRECT. Many "absolute" statements above are NOT EXACTLY CORRECT. 

Greg 

p.s. if the "hidden agenda" on starting this thread is to promote one's product, then out with it, be honest. If it's just to damage the DCC community, or some other part of the hobby, shame on you.


----------



## Axel Tillmann (Jan 10, 2008)

First of all:

If we want to introduce an analogous "wireless DCC", one of the requirements should be that the RF transmission becomes a standard, then the air will be the new "track". Anybodies receiver can be build into a loco and DCC RF handhelds are becoming the new integrated central station.

Of course nobody convienced me yet why - except for Tony who proclaimed the equivalent to "Eat crap - million flies can't be wrong"







("There must be something of in it if 10 manufacturers are offering "RF Pseudo DCC").

There are things that cannot be easily accomplished with the RF simulation and all we are ending up is a subset of DCC. Why sell anybody short on capabilities that have already proven to be well worth to many people.

Ah - I know "marketing gimmicks"


----------



## Mike Reilley (Jan 2, 2008)

LMAOROTF!!!!!!!!!!!!!!! The perfect ending to this topic....I hope.


----------



## Road Foreman (Jan 2, 2008)

Well I don't think it is the perfect ending.. There appears to be a dispute going on between Lenz & another manufacturer over how the standards should be changed.. Course I think Lenz has more pull than any other manufacturers because they gave the NMRA the rights to use there code.. There is also talk that maybe a new standard is needed, maybe one for the small scales & one for the large scales.. So you DCC boys better keep your eyes open & hopefully it will be backwards compatible.. 

BulletBob


----------



## TonyWalsham (Jan 2, 2008)

Greg. 
With respect, what part of "I have no agenda" do you not understand? 
1. I do not make any RF components that could possibly used to control DCC decoders. Period. 
2. Nowhere in this thread have I attempted to promote my own track/battery powered ESC's. 

I have no iron in this argument. Period. So why would you consider I am trying to discredit DCC? 
I started this thread as a result of reading of yet another battery powered DCC system. A system that seems to be just like all the other systems and is not really DCC. 
In fact it is these erroneous "battery DCC" claims that are actually doing a good job of discrediting DCC by highlighting the lack of regulation by the NMRA of the term DCC. 
Go after the NMRA if you don't like the message and stop attacking the messenger. 

As to the "What If" possibilities raised by Kevin, myself and others. Some of us like to think a bit outside the box and offer up other ways of doing things.


----------



## wigginsn (Jan 9, 2008)

I for one have learned a lot from this thread. I was under the impression that an NCE/GWire/QSI combo would provide me a 'battery DCC' solution and had been discussing it with others using those terms. Clearly not so and I now understand the reasons why. 

OTOH, from the user perspective my requirements for a new control system haven't changed. The what-ifs under discussion had me putting my hand up straight away, and I don't really mind what you call it as long as it has the functionality I'm after (excepting any mislabelled marketing - if it can't meet the DCC Standard then it 'aint DCC so don't use the term!). 

Thanks all for your expert input. 

Cheers 
Neil


----------



## Road Foreman (Jan 2, 2008)

Neil, 

Welcome.. 
Remember that just because a manufacturer says it is compatible that does not mean it will work in all cases.. 
Example: Decoder for large scale says it will work up to 20 volts when the standard said it should work @ 24 volts.. 

BulletBob


----------



## East Broad Top (Dec 29, 2007)

What if somebody built a 2.4 Ghz receiver to woik with the 2.4 Ghz throttles & QSI's decoder.. 
According to QSI's web site on the Titan, they're slated to introduce just such a receiver that will work with Aristo's Revolution throttle. That'll be interesting to see if/how they pull that one off, and to what degree of functionality. The possibilities are endless (as, apparently, is this debate.) 

Later, 

K


----------



## Axel Tillmann (Jan 10, 2008)

Kevin:

A QSI receiver that receives Revolution signals is by definition a proprietary Revolution compatible solution. Clearly the Revolution is not DCC and never intended to be DCC. If QSI decides to then take Revolution commands and "translate" them to DCC comands is by their own choosing and adds just another proprietary solution to the mix.

Also it will be interesting to see if they choose to take the battery power in regenerate a 1/2/3/4/5/... Amp. DCC Signal or if they are doing a backdoor DCC where it is required that the DCC board takes its power from the Batter on the post DCC side (+/-) and all they are doing is feeding the comands into the DCC IN (track conncetion).


----------



## Road Foreman (Jan 2, 2008)

Axel, 

The QSI decoder has a GWire plug so the DCC/Revolution signal would go there & the battery power to the track pins.. 

BulletBob


----------



## East Broad Top (Dec 29, 2007)

Axel, no doubt the Revolution/RevG-wire*/Titan interface would be as proprietary as the NCE/G-wire/Titan interface. (*My term, not theirs.) And until it hits the market, we can only guess as to how much "DCC" functionality it actually has. My bet would be that the "RevG-wire" board would essentially translate the Revolution commands so that the Titan would understand them, but the board's functionality would be limited to that which the Revoluion is capable. (i.e, only 6 function triggers, limited speed curve, on/off directional headlights only, etc.) Another option might be to use the receiver as a pseudo-Quantum Engineer, that then runs the Titan under analog DC mode, but that to me sounds VERY limiting, and not worth the R&D costs. I'm looking forward to seeing how they do that. If they can use the Revolution transmitter to get full control of all the DCC minutia the Titan looks to offer, then anything _is_ possible. I don't think we're there...yet. 

Later, 

K


----------



## Road Foreman (Jan 2, 2008)

Kevin, 

My bet is they will change the GWire receiver to 2.4 Ghz & work on the QSI microprocessor, look @ what MTH does with there system, DCS & DCC together in 1 chip.. Still looks like a winner any way you cut it.. Bring it on the more the merrier.. 

BulletBob


----------



## East Broad Top (Dec 29, 2007)

Now, get rid of the big black box command station, and replace it with a small microprocessor on a small PC board that can fit inside a locomotive. Nothing changes except the size of the boxes. 
Well, there is one HUGE change that needs to be considered - with that approach you now need one "Micro Command station" for each and every locomotive rather than one per system. 
That gets expensive real fast 
Er, Knut, that's precisely what we battery R/C folks do already. We spend $120 for the G-wire receiver to plug into our $160 QSI. We spend $140 for the Airwire, then add $180 for the Phoenix sound. It's part and parcel of running battery power R/C. (It's an expense somewhat offset by not buying a $600 command station, power supply, boosters, hundreds of rail clamps, stainless steel rail and a bunch of extra feeder wires.) So spending $120 or so for an on-board DCC command station to which we can attach _any_ DCC decoder that's on the market has a great amount of appeal. Think about it--We could use Loksound, Zimo, QSI, Massoth, whoever we want to and not be pigeonholed into brand X or brand Y because that's the only decoders the "systems" are bundled with. I don't know what's holding the production of the Massoth unit up, but from the popularity of Airwire and the G-wire/QSI combination, and the size of the battery R/C market in large scale, I'd really hesitate to call it lack of demand. 

In terms of folks who run track power, there's no need for them to buy an on-board decoder because they simply don't need to. That's why they spent $600 on their command station, so all the brains sit in one black box. Now, advance the technology a few years into the future, and--as I mentioned earlier--I can foresee the technology becoming inexpensive enough to where you can chip a loco with an on-board command station and decoder for the cost of just the decoder today. On the other hand, there's the cool train location features Greg mentions which can only be handled by a single central command station, so perhaps the future has two parallel paths; one where the "traditional" model continues to evolve with newer and greater features, and another for folks who want perhaps a bit more simplicity and the freedom from _needing_ power through the rails. 

Later, 

K


----------



## Greg Elmassian (Jan 3, 2008)

You are also forgetting the "system" part, instead of having multiple transmitter/receiver pairs that have no awareness of any other transmitters or receivers, DCC "SYSTEMS" understand and coordinate the commands going to all the locos. That's why a "single" channel, whether wired or not handles commands, rather than requiring separate channels so these uncoordinated transmitter/receiver pairs don't interfere. 

Again, one excellent example is a DCC command station being aware of all consists that exist, so that any consist can be used by any throttle. The other excellent example is the "all stop" command that all locos can respond to. 

Even though this conversation seems to keep degenerating to some very simplistic requirements (and that's why you guys don't need or want DCC), you cannot keep comparing DCC systems to things like Airwire that will NEVER have the functionality of a true DCC system. 

It's fine to argue about just the things you want, but it's not a fair or realistic comparison if you only consider the subset of DCC features you want for yourself. 

So, putting the "command station" inside every throttle is NOT the same as a DCC system, your logic is flawed by making a comparison leaving out important differences. 

Greg


----------



## krs (Feb 29, 2008)

Seems to me that we have beaten this subject to death


----------



## East Broad Top (Dec 29, 2007)

It's fine to argue about just the things you want, but it's not a fair or realistic comparison if you only consider the subset of DCC features you want for yourself. 
Sure it is, for the same reason DCC manufacturers offer different "tiers" of command stations and decoders. Not everyone needs all the bells and whistles. MRC's "Prodigy Express" is just as much a DCC system as NCE's Power Pro 10R despite largely different capabilities. Determine your needs, and pick the system that's right for you and your budget. It's all "DCC." An on-board-based system would simply be one of many options for users to choose from, offering advantages in some areas, and being less advantageous in others. 

I personally find it very elitist for you to suggest that battery R/C folks don't "need or want DCC." Hogwash! I love the functionality and control DCC systems offer, but I hate cleaning track. So I accept the "limitations" that the current DCC-based battery R/C offerings have in exchange for the freedom to run wherever, whenever I choose. As technology advances, I think those limitations will get less stringent, allowing me to get closer and closer to the "full DCC experience" if I so desired. Who knows what technology will bring in the future. I find it quite exciting, and applaud manufacturers who continue to push the envelope and try new technologies and bring new ideas to the table. Scream and holler all you want about definitions and what "is" or "isn't" really DCC, or embrace the possibilities and have fun running your trains, leaving it to the manufacturers to define concepts as they evolve. I know which road I'll travel. 

Later, 

K


----------



## Greg Elmassian (Jan 3, 2008)

Umm... Kevin, you just changed it into something personal... calling me elitist.... stop it. You are a moderator. Follow the rules. 

As to objective data, would you like me to present all the posts where 99% of the battery guys say they only want bell and whistle and forwards and backwards? You have stated this for yourself many times. 

I'm pulling objective, factual data from right here. 

You have resorted to name calling. For shame. 

Greg


----------



## Road Foreman (Jan 2, 2008)

Lets us look @ how things have changed.. 
Look @ Digitrax, had a wireless throttles, 900 Mhz one way talking to a receiver.. 
Now they have a transeiver talking to another transeiver, for 2 way talking.. 
Why not have the throttles talk to each other & the onboard transeivers.. 
Now the command stations are in the throttles.. 
You can always have a master throttle with slave throttles if you think that is necessary.. 

BulletBob


----------



## Mike Reilley (Jan 2, 2008)




----------



## Greg Elmassian (Jan 3, 2008)

Bob, you could indeed have a mesh network with all the throttles talking to each other. 

More software, more CPU needed, MUCH more communication between them keeping synced. 

Possible, but on 900 MHz, too much data traffic... remember that the more sophisticated DCC systems communicate to the hand held throttles in duplex, verifying and acknowledging the commands (a big advantage over a one way system that has no idea if the command was received or not) 

Possible, but now you are taking bandwidth away having the throttles talk to each other. 

DCC systems normally have the ability to have MANY trains running with MANY operators. By using more bandwidth by having a command station in each throttle and the command stations all having to sync with each others "database", you would seriously limit the number of simultaneous users. 

Nothing is free, you use more bandwidth between the throttles, you take away system capacity. 

Again, for the people who will only run one or 2 locos, they don't need this capability. 

By making each throttle a command station, you increase the overall cost per user without any benefit in performance, bottom line. 

There are logical and economic reasons for the architecture. The fact that most major DCC companies follow that architecture means something. 


Regards, Greg


----------



## Gary Armitstead (Jan 2, 2008)

This whole thread almost seems like an "inside baseball" or "inside the beltway" discussion. Washington politics so to speak AND nothing really gets accomplished, IMHO. Folks are already committed to the systems they prefer for whatever reason. I don't think that this thread is going to change anyone's mind to another system. I would probably wager that most folks are totally clueless to these electronics sermons (I am! That's why I picked a system and let someone who really knows what their doing, install the system for me). These threads ALWAYS seem to degenerate into name calling. SAD!


----------



## East Broad Top (Dec 29, 2007)

...calling me elitist.... 
Forgive me, 'twas not my intention to suggest that you _personally_ were elitist, only that your statement came across as such. Accept my apologies for poor word choice. 

And maybe you're correct--that many battery R/C guys are merely concerned with being able to go forwards and backwards, and blow the whistle and ring the bell. But gosh darnit, we want to do it _well_ and the DCC-based systems on the market offer a level of sound and motor control that's hard to match with the other systems. Why shouldn't we want the best? That's why we choose Phoenix and QSI. An on-board receiver/command station system would allow us to use Zimo and all the other sound/motor-integrated controls you're always touting as superior to any separate sound and motor systems. I'd love to have the option to run them as well, but until someone makes a receiver that allows me to use it in my sandbox, I'm stuck with the others. It ain't bad company to be stuck with by any means, but it'd still be nice to have the greater options available. 

The reality is that many track-powered DCC users only want to go forward and backwards and blow the whistle and ring the bell, too. I recently did a story on an HO scale club that converted to DCC because they got tired of the hassles of block wiring. That was their _only_ motivation for the change. I asked them about how much customization they did, they said "well, we change the loco address." Some of the guys there don't even use sound. They went with their particular system because they had a specific need and DCC met it. 

Battery R/C folks are no different. We have specific individual needs, and choose our systems to best meet those needs. For me, it's as simple as wanting really kick-butt sound. I love the customization and control that QSI and Phoenix offer me, so I choose the DCC-based control systems as they're the systems that give me the best/most control over the sounds. I'll never consist or use track telemetry to tell me where my train is located. I run one loco at a time and I'm nearly almost always right next to it. So, yes. "All" I want to do is run my train back and forth, ring the bell, and blow the whistle (and play with other sounds as available). But I want to do so in the most realistic way possible, and _only_ DCC allows me to do so. So yes, I do "need" DCC. It's uniquely positioned to meet my paramount goal for a control system. Nothing else is capable of what I want for my top-drawer installations. 

Later, 

K


----------



## Axel Tillmann (Jan 10, 2008)

*Applicability Scale*
About a year ago I developed an applicability scale. That scale is designed to determine which technology matches best with the customer's current and future desires. I can actually now add a spreadsheet which even helps calculating the cross over points, based on number of trains and accessories, years you want to be involved in the hobby..... And it will become apparent to every user which way to go.

One thing this RC/Battery discussion leaves out of the mix is other operational elements. Our community needs to expand on the "play value" and I have seen many examples of loading/unloading hopper cars, loading and unloading tank cars, operating cranes, elaborate shunting operations with remote controlled decoupling, constant switching of train routes with many switches involved, semi or full automation of certain trains, station sounds triggered by running trains or by the handheld, other sounds in the layout, moving figures..... the possibilities are endless.

Or what about desires such as programming on the main, automatic feedback after power down of the last position of all switches, visual feedback of switch and function key (engines) settings, multi consist setting and programming, reduced speed values via single button command for shunting operation, 28 Function keys (why because modern engines have already 6-10 physical function needs and the additional functions are needed for sound implementations), train operations with multiple operators and hand over of one train to another operator... we can go deep.

Obviously once you go down the list, you will quickly understand the huge divide between RC/battery and true DCC. If I then throw into the mix the ongoing costs of battery power (dying batteries every 1-2 years) you shrink down the RC/battery applicability to a narrow opportunity.

And the entire opposition is based on the track power conductivity issue. I have my layout for years out there and had as nearly 0 problems other than track that came apart based on 5 winters of contractions and summer expansion. And while that happens to any track, even if you run battery, rail-clamps are mostly advisable for any layout work.

*Cleaning?* 
- that needs to be rephrased into oxidation cleaning. Because cleaning needs to be done no matter what, constant shifting of crusher fines caused by the elements, falling leaves and yes unfortunately also pine needles (I just can't take down some of the beautiful trees in my yard, and may are in my shoes). So what about oxidation cleaning, you will need this on brass, but those of you who recently received the LGB video saw the spring opening of a huge layout and the guy stated that he accomplishes for the most part with a drywall pad on a stick in the beginning of the season (after a long winter) while he has to do other maintenance work anyhow. For the rest of the operating season track cleaning cars as part of his trains do the maintenance work and for tunnels he uses a track cleaning loco.

You don't like cleaning at all, no problem. There are two choices that avoid this, Brass Track with pure Nickel surface (nor to be mixed up with Nickel-Silver) or Stainless Steel. Having used both, I prefer Brass with Nickel Surface over Stainless Steel because I have less conductivity loss, which one can compensate however with re-feeding the power from a power bus that goes alongside the track (I just opted to live with a single power feed). This all comes at a cost (Nickel 20% more than Brass, and Stainless Steel about 60% more than Brass). Even for battery power my preferred choice still would be Brass, of course you can go down to Aluminum or even Plastic, that all comes at a price of sturdiness. If Brass is the common denominator for all layouts then the differential for not cleaning is about 20% (or 60% with Stainless Steel).

*As far as the enhancements and controversies of DCC?*
Oh well, there is always politics involved, who controls what and why and it will be all settled in the future. ZIMO has published a new bi-directional DCC standard and its English version can be ordered from me. It has clear advantage of the proprietary Lenz/ESU proposal - technically and business wise. Business? Yes it is for free, no controlling organization, everybody can participate, no contracts, no fees, no licenses.

*Can someone come up with something better than DCC?*
Of course - technology improved, so did modulation capabilities. Of course we can run IP or iven TCP/IP on the track, train announcement via DHCP, train identiciation via a MAC address and so on. Possibilities are endless, question is only is the DCC comunity ready to trash all the current investment and start from scratch? Talking about $$$$.


----------



## TonyWalsham (Jan 2, 2008)

........and when (proper) battery operated R/C DCC appears on the market, or what is available now gains formal imprimatur from the NMRA, what are you going to use as an argument against it? 

Nowhere has anyone said they want to REPLACE regular track powered DCC with battery powered DCC.
What is being proposed is a complimentary system to track powered DCC. Yes of course your arguments are valid. Are they realistic for those requiring something less comprehensive? I don't think so.

If a "Command Station" can be fitted into a TX hand piece such as AirWire for example it is not going to cost anywhere near what it would cost to equip a RR for track power for one loco. Yes there will be a changeover point re the number of locos where it becomes uneconomic and I will leave for others to work out what that point is.
Or is that track powered Command Stations are overpriced anyway?


----------



## East Broad Top (Dec 29, 2007)

Axel, this debate isn't about track vs. battery. Tony hit it correctly; it's about a product line within the scope of the broad spectrum of DCC products available which appeals to a particular subset of the market for DCC products--one that isn't nearly being tapped as well as it could be. It's about making some of the best features of DCC products (particularly high-quality sound and motor control) available to more users who would like to use it outside of the "traditional" DCC environment. 

... "Something better than DCC...is the DCC comunity ready to trash all the current investment and start from scratch? Talking about $$$$. 
Depends on the new system and what it offers. We're constantly seeing new technology come out and replace old technology. If the improvements are worth the investment, sure folks will switch over. Computers, TVs, Entertainment... Where _isn't_ it happening? We see it within the hobby with the Airwire or G-wire systems and the Revolution systems replacing the older, outdated RCS "elite" and older Aristo Train Engineer systems. There's significant money invested in those systems as well, but for those who have abandoned the old technology, the re-investment is clearly worth it for the improved functionality. I don't see DCC as being any different. The bar may be higher, especially in the smaller scales where some folks have literally hundreds of locos that would need to be refit, but for those with smaller collections, the change would be easier on the finances to make. And there will always be those who see no advantage to the "improvements," and will gladly keep investing in the older technology. 

Later, 

K


----------

