Yet another "what were they thinking" from someone who wants to be a DCC alternative

[betamax]

They are probably targeting those who believe that DCC systems cost a fortune and that they'll have to convert every locomotive they have immediately.

So they can sell something that is like DCC but isn't DCC. They just omit that their product is lightyears behind what a current DCC decoder is capable of, and incompatible with the wiring of the lighting in a typical locomotive today. 

Being proprietary, it is all good until the maker loses interest in supporting the product or the software.

[wvg_ca]

the power to the LEDs is backwards ??

so they aren't NMRA  compatible ...

seems kinda useless??

[ATLANTIC CENTRAL]

betamax

They are probably targeting those who believe that DCC systems cost a fortune and that they'll have to convert every locomotive they have immediately.

So they can sell something that is like DCC but isn't DCC. They just omit that their product is lightyears behind what a current DCC decoder is capable of, and incompatible with the wiring of the lighting in a typical locomotive today. 

Being proprietary, it is all good until the maker loses interest in supporting the product or the software.

 

Well first off, I'm not interested in anything that uses a smart phone as a throttle, so that leaves me out.

And plug/polarity thing is stupid beyond stupid.

But DCC is expensive and you do have to convert all your locomotives if you plan to actually run them. I don't have any shelf queens, I don't have 20 locos and a shelf layout......

I have 140 powered units, I'm about ready to start a new layout that will fill 1500 sq ft, support the operation of 8 trains at the same time, and stage 30 trains.

It takes most of those 140 locos to "protect the schedule".

I still run DC, I have no interest in sound, and no use for ditch lights, consisting, etc.

I have wireless radio throttles with pulse width modulated motor control. I have CTC, detection and signaling fully intergrated with my turnout controls and I use an Advanced Cab Control system that makes the operator experiance much the same as DCC, especially with a dispatcher on duty.

Why I am on this little rant?

Because your opening line, and to some degree, your whole post is condescending  to those who have decided not to use DCC.

You are saying this product is aimed at the "stupid" people who have not gone DCC.

How much are 10 DCC wireless throttles and 140 decoders? My system did not cost that much.

And I have CTC, signals, one button turnout route control from multiple locations, and, drum roll, something you don't have in DCC, Automatic Train Control - run a red signal, your train stops.

Those of us who think DCC is expensive are not gullible targets for products like this, we just have different goals in the hobby.

Personally, I think a GOOD direct radio system would be better than DCC, reducing the under layout infrastructure. But I don't know that I would invest in that either. Even if it was an open access platform like DCC.

I'll go back to sleep now.

Sheldon 

[tstage]

ATLANTIC CENTRAL

Why I am on this little rant?

Because your opening line, and to some degree, your whole post is condescending to those who have decided not to use DCC.

You are saying this product is aimed at the "stupid" people who have not gone DCC.

Sheldon,

Sometimes I think you go looking for threads with the intent of finding "something" to be offended at - real or imagined.  You are reading an entirely different book than I am in betamax's response.   Yes, get some sleep.

Tom

[Paul3]

Sheldon,
You know he didn't say "stupid" yet you put it in quotes as if he said it.  That's not right, man.

And he's correct in that there are some people think that DCC costs a fortune, yet a good starter system costs the same as one Athearn Genesis SDP40F without DCC or sound.

We've debated many times the cost of your DC system, and IIRC you got your relays and other electronics at incredibly low prices, correct?  Hardly a fair comparison.  And BTW, DCC can have Automatic Train Stop, so you're incorrect about that one.  It's not easy nor widespread, but then neither are detection and working signals that are needed to make it work in the first place.

Is DCC right for everyone?  No.  Is it right for you?  Absolutely not.  Is DCC the best solution for the majority of model railroaders?  Well, I think the market has spoken on that with a resounding, "Yes!" 

FWIW, on my old 25' x 50' layout, the full retail value of my DCC system was just under $1200, plus the cost of my DCC decoders at $20 each for 30 engines.  Of course, I did not pay that; it was at least 20% off that price.  So I was probably out of pocket just under $1500 for a Zephyr, a radio receiver, 3 radio throttles, 5 panel plugs and 30 decoders.  Better still, my club friends would bring their own throttles that worked with my system, so I could easily have 7 more engineers and it didn't cost me a dime.  Yes, $1500 sounds like a lot, but not when you consider that I also bought $1500 worth of turnouts and $1000 of flextrack.

Best part is that my entire layout worked with just two 14AWG wires under the 200' long double track mainline (with 22AWG feeders every 9 feet) and a 6-conductor flat telephone cable behind the fascia.  And that's it.

[ATLANTIC CENTRAL]

Paul, I know that you can do ATC with DCC, for me it is a free feature built into the design of the cab control and would work without the detection or signaling, it requires no extra cost or effort.

While I bought some of the relays on the secondary market, many were purchased new, bulk, directly from a manufacturer/importer, as well as my lighted push buttons. I also had relay boards custom manufactured.

Where DCC gets expensive is decoders for larger fleets of locomotives, you had 30, I have 130. Even at $20, that is big additional expense - and that is one of the main things I am offended by when this comes up - the idea that I should/could do with less locos so that I can have DCC. $2000 buys a lot of wire and widgets.

Because I don't/have not bought locos with sound and DCC, and only bought a few with DCC only, the cost of my sizeable loco fleet is pretty low - dollar cost average about $100 each. And it is all nice stuff, Proto, Genesis, BLI, Spectrum, Intermountain, etc.

Do you know how many times someone has said to me "you don't have to convert all you locos at once" - if I had a dollar..........

My investment in track is similar to yours.

You had three throttles, I have, and would want/need 8-10 throttles. I get the buddy thing with the extra throttles. Not something I would rely on. I can display run six trains at once. I like display running as much as "operation". Guess I need my 10 throttles so I can have a few people working the yards while trains display run on the main.

Like so many people consider sound and/or DCC essential, I consider detection and signaling essential.

I completely agree DCC is the best choice for most people, and most people have no interest or ambition for signaling or CTC. Many people have no interest in display or casual running, I do. Different goals, different needs.

Most of my "wiring" is done on the work bench. My double track mainline on the new layout will be over 400' with thru staging for 30 trains. I don't need feeders every 9 feet. The trains run fine with one feeder per block, typically 30 to 60 feet.

If I may ask, why did you take you layout down?

Sheldon

[SeeYou190]

ATLANTIC CENTRAL

Well first off, I'm not interested in anything that uses a smart phone as a throttle, so that leaves me out.

I used to feel the same until I saw/heard Kato's sound system for their DC throttle set-up. The Smart Phone throttle worked good, and it solves my desire for a wireless throttle and a good sound system I can run through a 100 watt amp with a sub-woofer.

Sound that sounds real, can shake the room, a wireless throttle... and no locomotive modifications.

They have a sound card that goes with my Kato NW-2, so that is convenient.

Of course, my train room is small enough that a stationary powerful sound system makes better sense for me than on-board sound.

I am sold.

-Kevin

[ATLANTIC CENTRAL]

Kevin,

Good sound, one train, intimate viewing of that one train, I might be all in for sound.

But that does not satisfy my other modeling goals. 

6-8 trains moving at once, no matter how low the volume, or how big the space, just turns into a din to my ears, especially when you throw in some humans trying to talk over it all.

If I wanted the one train intimate experiance, I would model 1/4" two rail.

Sheldon

[dknelson]

There was a sort of cottage industry in DCC alternatives back when DCC was pretty firmly entrenched but the decoders still had to be separately installed and few if any locomotives came DCC equipped.  I think as long as there are garage tinkerers there will be ideas and systems floated that have their positive points and maybe even genuine improvements and some curious customers will buy in,  but it is tough to dislodge a proven and accepted method which has become entrenched.  

One that interested me at the time was an outfit called Signal Research which was DC and block control but a system which supposedly "learned" your layout and assigned power to blocks (and turned it off to other blocks) more or less automatically.  So if I understood it correctly the array of toggle switches would not be needed - a "black box" took care of everything, all the blocks.

There were several threads about it at the time on these Forums, one of which is this one

http://cs.trains.com/mrr/f/88/t/3657.aspx

I read everything I could get on the subject of the Signal Research Trainmaster (it was reviewed in Model Railroader but the review was sketchy and it was not clear from reading it that the reviewer had actually installed it on a layout) and contacted the company via email but I could never get a straight clear answer to some pretty basic quetions, one of which was, OK if this is a DCC alternative just how do multiple operators run multiple trains?  

I have been around long enough to recognize that DCC is highly unlikely to be the "last" power/control system in model railroading, any more than the compact disc proved to be the last word in recorded sound (despite claims at the time that it would be).  A buddy of mine has gone whole hog into RailPro and extols its superiority to DCC at every opportunity (before that he was into RailLynx and Dynatrol).  I hope for his sake that RailPro exists as long as he needs it to exist for support and new locomotives etc.  But at this point in my model railroading life I am confident that DC and DCC are going to remain available options for as long as I am a potentialy customer, and thus they are the two realistic choices, with the rest being for others to explore. 

Dave Nelson

[Paul3]

Sheldon,
I had to take down my layout because it was in the basement of my parent's bookstore.  After 25 years of ownership, my folks decided to retire and close the business in 2014.  The bookstore basement was a former commericial space, too, so was well lit, had HVAC, and about 90% finished with a tile floor, drywalled, etc. (the back corner didn't have a ceiling).  I always knew I'd lose the space someday, but I knew that for years I would have a great layout space and it seemed foolish to waste it.

I still have every wood piece of my layout; all the wood is stacked inside my shed at home, and all my track is stored in the basement.  But I don't want to build a layout in my basement due to the dirt floor cellar and fieldstone foundation, and while I do have an nice upstairs attic that can turned into a layout room, it's full of 80 years worth of family stuff.

Besides, I'm still a member of one of the largest model railroad clubs in the USA, the South Shore Model Railway Club in Hingham, Mass. with our 10,000 sq. ft. building.  If I didn't have the club, I would totally feel the pressure to build a layout again.

[Overmod]

EDIT: for future readers going through this thread, the initial premise was that LocoFi was using 'the same' 8-pin connector as NMRA standard DCC.  They subsequently comment in this thread (about 6 pages in) that their connector is NOT NMRA plug-compatible ... by that, I assume they mean it will not mechanically fit; that the connector tracking is different, and the two will not mate.  This should be confirmed by the reader before they get further into the trash and treasure that the rest of this discussion holds...

Lastspikemike

It isn't necessary now to run power as an AC mimic and the control signal as DC piggybacked on the same wires. 

Can you explain what this sentence means as written?

Meanwhile, in my opinion, a proper 'replacement' for DCC, whether dead-rail-based or not, needs to follow the Vail model of evolution in the Bell system as it evolved.  Relatively simple overlays, glue logic, and emulation can provide compatibility with the great mass of older equipment and know how, and it will run even if no more than thunked in a corner of what a modern ultra-low-power processor and radio setup provides.  That in turn allows different paradigms of operation to work -- as preferences -- on a newer system.

Some of us want the locomotive to accelerate as soon as throttled up, others (including ESU) only when the prototype has 'developed power' to move the train.  This shouldn't be a global setting, but it should likewise provide a locomotive owner no surprises when he plunks his programmed engine on any layout as a guest.  To make a complex system 'just work' like a competent walled garden takes much more than careful programming... but we've learned quite a bit since Win95 was deprecated.

One thing that will be interesting is DC compatibility; another will be to see if the not-too-difficult 'fix' for using both kinds of 5e four-pair Ethernet cables interchangeably in the same modem or switch gets applied to 'inconsistent pinout' ...

[Paul3]

Lastspikemike,
Yes, DCC is old tech.  In fact, it's older then you think.  It started back in 1989 with Bernard Lenz and Marklin, was investigated by Stan Ames in 1992, and was proposed as an NMRA Standard in 1993.  Which means it's more equivalent to an IBM 486 running Windows 3.1.

I use computer keyboard function keys all the time when I'm using programs that use them.

You don't need to know bit programming for DCC.  That's why they have charts.  In 20 years of using DCC, I have never added up bits to figure out, say, CV29 values beause I use the chart.

You said, "It isn't necessary now to run power as an AC mimic and the control signal as DC piggybacked on the same wires."

Um, no.  That's not how DCC works.  It's a square wave AC signal, with the length of the wave determining if it's a 0 bit or a 1 bit.  With DCC, the power is the signal.  DC is not piggybacked on anything. 

Each locomotive only needs a variable DC voltage throttle and wireless link. The rest of the DCC control software isn't necessary at all.

What about lights, sounds, and functions like brakes?

Personally, I don't like touch screen controls for a throttle.  If I have to look at the throttle to control my train, it isn't worth it for me.  I use a switcher way too often, and I want to watch my train couple up to another car or spot a car to be constantly looking at my touchscreen throttle.

[tstage]

Lastspikemike

Changing over to bluetooth or Wifi LAN software now would be very expensive but ideal.

Not to me, it wouldn't.  I'm with Paul.  I can operate the speed steps of my "outdated" Power Cab throttle without even looking at the buttons...AND one-handed.  I couldn't do that with a touchscreen throttle.

Advancements in technology don't always make for improved MRRing experience.

Tom

[ATLANTIC CENTRAL]

Same here, DC, DCC or whatever, no touch screens for me. It needs to be one handed without looking at it.

I can hold my Aristo Train Engineer wireless throttle in one hand and speed up, slow down, change direction, and apply the emergency stop without ever looking at the throttle.

A touch screen device would be a step backward in terms of ease of use.

If you are guest operator on my layout, and we have a dispatcher on duty, your user experience is easier than DCC. I hand you a throttle and say there is your train.

The throttle has five buttons, easy to identify by feel - FASTER, SLOWER, EAST, WEST, EMERG STOP.

You just make your train go and obey the signals.

The dispatcher sets your route and clears your signals.

All done with "old school" tech.....

Sheldon

[Bayfield Transfer Railway]

You know, I KNOW how Progressive Cab Control with relays works.  Not only did I read all the MR articles on it from back in the 50s and 60s, I was a member of MIT's Tech Model Railroad Club for seven years, and they implemented PCC on their layout.

It is neither simple nor easy.  If Sheldon has the knowledge to implement it, good for him.  But to push it as something any modeler can do is just errant nonsense.  It's like saying to play the flute you blow in one end and move your fingers up and down.

 

[ATLANTIC CENTRAL]

Bayfield Transfer Railway

You know, I KNOW how Progressive Cab Control with relays works.  Not only did I read all the MR articles on it from back in the 50s and 60s, I was a member of MIT's Tech Model Railroad Club for seven years, and they implemented PCC on their layout.

It is neither simple nor easy.  If Sheldon has the knowledge to implement it, good for him.  But to push it as something any modeler can do is just errant nonsense.  It's like saying to play the flute you blow in one end and move your fingers up and down.

 

 

First of all, I know what Progressive Cab Control is too, and that is not what I use.

I use a CTC/TOWER CONTROL version of MZL Control developed by Ed Ravenscroft, and partly based on Bruce Chubb's original relay based signals and CTC, adapted by me for use with Aristo wireless throttles (or any similar base station radio throttle).

The system uses a number of different ideas suggested by Ravenscroft, Malory and others to provide a simple user interface for DC.

There are no block toggles, turnout control is "one button" route control, which automatically routes track power correctly thru interlockings, reducing the number of block command inputs by half.

It allows full walk around operation by operators with no more buttons or switches than DCC with track side turnout controls.

OR, it provides a complete CTC experiance with a dispatcher on duty.

Cabs are correctly and automatically connected to the proper route with the push of one button to clear the next signal to green.

If an operator runs a red signal, his train simply stops, he will not enter trackage controlled by another throttle.

The Aristo Train Engineer wireless throttle provide smooth speed control using the same pulse width modulation technology as is that used by a DCC decoder.

Turnout and cab selection/CTC assignment buttons are redundant on local tower panels and the main CTC panel.

Detection shows train locations on the CTC panel and overhead panels around the layout for operator reference.

Maybe a lot to build, but easy to use.

I never suggested it was for everybody, in fact I said DCC was likely the best choice for most people.

Sheldon

[wvg_ca]

i looked at both when i was making my layout, 15ft by 16ft ..

DCC was less work AND less money, sold!

[SeeYou190]

ATLANTIC CENTRAL

Good sound, one train, intimate viewing of that one train, I might be all in for sound.

My layout is planned for several different operating schemes to maximize play value.

One of these schemes is simply a single switch locomotive, like the NW-2, working the car float. That is when I would use the Kato sound system.

At other times, it would not be appropriate.

I have a 4 pole 3 throw break-before-make rotary switch to select which throttle set-up controls the local. It can be Kato wirless, panel control, or tethered walk-around.

For different operating schemes different controls would be appropriate.

-Kevin

[ATLANTIC CENTRAL]

Lastspikemike

 

All the new DCC locomotives come with dual sound decoders that run just fine in DC mode with useful sound effects. 

Obviously your idea of "just fine" is different from mine.

Needing extra voltage, or turning the throttle up half way before the train moves is not "just fine".

But most dual mode decoders will not run at all on my DC throttles.

I use DC throttles with full voltage pulse width modulation speed control and most dual mode decoders, sound or otherwise, simply do not work, the loco sits there and vibrates.

dual mode decoders are joke when it comes to DC operation.

Sheldon

[SeeYou190]

ATLANTIC CENTRAL

dual mode decoders are joke when it comes to DC operation.

I completely agree.

The dual mode decoders need to be removed if you are going to stay with DC operation.

On my beloved Bachmann 2-8-8-4 I accidentally glued the tender shell on, and I cannot get to the decoder to remove it. 

-Kevin

[ATLANTIC CENTRAL]

wvg_ca

i looked at both when i was making my layout, 15ft by 16ft ..

DCC was less work AND less money, sold!

 

Every person and every layout is different. Without signals, without CTC, with only a few locos, DCC is way less expensive and way more flexible than any kind of advanced DC.

But that is apples and oranges.

DCC for large layouts with large loco rosters is expensive, and all signaling solutions layered over top of DCC are just as complex and expensive as any DC signal solutions.

DCC offers no particular advantage for detection, signaling, CTC or advanced route control of turnouts.

With my particular set of operational goals, DCC would only provide a few additional features beyond my current system. And in fact I would loose a few features. And it would require purchasing and installing 130 decoders.

I'm not anti DCC, I logged lots of hours on the DCC layouts of my friends, I get it. 

But those few features are not worth the work or expense for my personal goals.

I am anti sound, at least when it comes to onboard sound in HO on a large layout with lots of trains running at the same time.

Just another reason why I don't need DCC or any other command control system.

Sheldon

[ATLANTIC CENTRAL]

Lastspikemike

I cannot help but notice a deep historical interest displayed by many contributors to this forum.

Dual mode decoders are very, very good. Older decoders do not work well in DC only mode. 

Of course a sound decoder needs 7+ volts to start which leaves only 5-7 volts range to vary the speed. Duh.

 

Have you ever used a dual mode decoder with a pulse width modulated DC throttle like the Aristo Train Engineer?

Trust me, they don't work.

Full voltage pulse width modulated DC sets DCC decoders nuts.

Sheldon

[ATLANTIC CENTRAL]

Lastspikemike

I cannot help but notice a deep historical interest displayed by many contributors to this forum.

Dual mode decoders are very, very good. Older decoders do not work well in DC only mode. 

Of course a sound decoder needs 7+ volts to start which leaves only 5-7 volts range to vary the speed. Duh.

 

One more thought Mike, as someone who has been in this hobby a long time, and who knows lots of others who have been in this hobby a long time.

Yes, things do change, manufacturers work on problems, sometimes successfully, sometimes not. But I'm not trading in 54 years worth of models, or even the last 20 years worth, to have the "latest thing".

This hobby was orginally build on interchangeablity of products.

DCC would have been a better product if they had done like all the other command control systems, and said you are either all in or all out.

DCC has been around a long time now, and still has not become "universal". That fact alone makes a statement.

Sheldon

[doctorwayne]

Like Sheldon, I'm not a fan of on-board sound, even though I run only one train at-a-time and am a solo operator.  It just doesn't sound real to me, at least for steam.  I've operated DCC on friends' layouts, and don't have any quarrel with it, but it has nothing to offer me that plain ol' DC can't do. 
In fact, if someone were to offer me complete installation of a DCC system, including decoders (sound or not) in all of my three dozen locomotives, for free, I wouldn't take it...simply because DC does everything I want or need.

This isn't a "Which is best contest."...I'd say more like which is most suitable for each individual.

The only complicated (to me, anyway) wiring on my layout was when I was using a variety of throttles from different manufacturers, but since I settled on one, that wiring is no longer used.

Wayne

[wvg_ca]

ATLANTIC CENTRAL

 Every person and every layout is different. Without signals, without CTC, with only a few locos, DCC is way less expensive and way more flexible than any kind of advanced DC.

But that is apples and oranges.

Sheldon

 

 

i don't run block contol, [don't have to] or signalling [don't want to], , or ctc [whatever that is],  .. and only maybe 4 or 5 locos at the same time ... only a couple with sound ...

It's just so much easier with far less to go wrong..Bonus!

[ATLANTIC CENTRAL]

wvg_ca

 

 

ATLANTIC CENTRAL

 Every person and every layout is different. Without signals, without CTC, with only a few locos, DCC is way less expensive and way more flexible than any kind of advanced DC.

But that is apples and oranges.

Sheldon

 

 

 

 

 

i don't run block contol, [don't have to] or signalling [don't want to], , or ctc [whatever that is],  .. and only maybe 4 or 5 locos at the same time ... only a couple with sound ...

It's just so much easier with far less to go wrong..Bonus!

 

I understand. And if my layout goals were different, I might pick DCC.

Sheldon

[rrinker]

 There really aren't that many DC controllers using PWM - if you use a more common DC power pack or power supply for DC, then the motor only decoders work perfectly fine on DC, as intended. Sound is another story, but that has everything do do with basic physics and the compromise needed to get sounds on DC before the loco is baralling down the tracks. Non-sound decoders don't have this limitation.

 You can;t please 100% of the people 100% of the time. It's unfortunate the a full voltage DC PWM signal looks enough like the DCC signal to confuse many decoders, but the sheer number of DC modelers affected is very small. But when it's you - it seems like a huge 'mistake' on the part of manufacturers. Not all DCC decoders are confused by this - but even the ones that aren't, I suspect if you put a decoder-equipped loco on the rails with the throttle at a very specific non-zero speed setting, it could still confuse them.(if the pulse width were just so)

                                    --Randy

[wvg_ca]

ATLANTIC CENTRAL

I understand. And if my layout goals were different, I might pick DCC.

Sheldon

 

 

agreed, to each their own ...

[doctorwayne]

rrinker

There really aren't that many DC controllers using PWM - if you use a more common DC power pack or power supply for DC, then the motor only decoders work perfectly fine on DC, as intended. Sound is another story....

The only DCC loco I've run on my layout was a BLI Mikado that I detailed and painted for a friend.  While it ran not too badly, the sound feature would cut-in and out, as if it were re-setting itself.  Perhaps that had some influence on my disinterest in sound, but after almost 40 years in a steel mill, sound isn't an attractive feature.
The throttle upon which I finally settled, (mentioned in my previous post) is a DC throttle with an adjustable PWM output.  I power it from the AC terminals of a MRC Controlmaster 20.  I haven't bothered adjusting the throttle because the trains already run the way I want them to run, as-is.  The manufacturer is located about 20 minutes away, and stands behind his product, so if service is required, easily done.
The throttle offers very precise control, and easily handles multiple locomotives pulling heavy trains on rather steep grades.  Fits my requirements completely.

Wayne

[betamax]

Lastspikemike

In computing terms DCC is already seriously outdated. The NMRA standard has proved to be a double edged thing, as these standards often turn out to be.

Using Function keys isn't even convenient for actual computer work. DCC still requires some understanding of the concept of programming at the level of the bit.

It isn't necessary now to run power as an AC mimic and the control signal as DC piggybacked on the same wires. 

Each locomotive only needs a variable DC voltage throttle and wireless link. The rest of the DCC control software isn't necessary at all. 

The iPhone throttle is just the thin edge of this technology wedge. The problem is the heavy financial investment made when NMRA governed DCC got started in the 90's which, unfortunately, could not look far enough down the road at that time.  Changing over to bluetooth or Wifi LAN software now would be very expensive but ideal. Recall that the Windows 95 era is contemporaneous with the currently valid NMRA DCC....

 

The myths somehow thrive...

 

We should just scrap the internet, after all, its technology started 50+ years ago and runs on Unix, developed in the 1970s.  You can't use Unix unless you type in all those arcane commands, so it is not "user friendly".

 

Function keys are usless? Faster than taking your hand off the keyboard.

 

DCC programming difficult?  A basic decoder had to be easy to setup 20 years ago. Today we have software to do that, because an ESU decoder could have up to 10,000 CVs. Simple things like setting a Primary or Extended address are often handled by the command station, which sets the appropriate bits without any user intervention.

 

Where does this myth of an AC signal riding on a DC voltage come from, and why does it continue?  DCC uses a Digital pulse train to supply both power and data. This myth belongs in the era of analog command control. Why won't it stay there?

 

The mulitfunction decoder in a locomotive needs more than "a variable DC voltage throttle and wireless link". The software on board provides precise control of the motor using PWM. Beyond what any analog throttle could do. Not by a variable voltage. For the wireless link to work you need more than a throttle, as a minimum amount of power is required to operate the "wireless link".

 

What does Bluetooth and WiFi have to do with DCC being obsolete?  They can carry DCC data just as easily as they carry TCP/IP data.

 

Just look at what the European DCC suppliers are doing. GUIs, automation and other features beyond what was considered when the DCC Standard was proposed.

 

 

 

 

 

[rrebell]

Well from someone on the fence still about DCC, I can tell you this. Pro's about DCC, sound (love that feature), two or more trains on same track and no turning off a side track just so the main engine can be used. Con's, much more fussy and prone to damage from operator error. Also DCC can be way more expencive than DC but has powered frog options that are much better and better automatic y controls for those that have that type of trackwork, These things have to be done manually in DC but can be done.

[rrinker]

 Whereever did you get the idea that DCC uses an AC power source with a DC control signal superimposed? That's actually opposite what most pre-DCC command control systems used - steady DC power with an AC pulse superimposed. 

 The DCC power IS the signal - full amplitude, there is no little tiny signal to pick out from the noise of brushed DC motors operating. 

Wayne - as I said, sound on DC is just a non-starter,. I think it was a silly idea to even bother - and I'm sure I'll get plenty of responses that "I do it allt he time, it works fine". The only people I can imagine are actually satisfied witht he way sound locos work on DC are those who don't know any better. It's pretty simple - the electronics need around 5 volts to operate. The only way to get 5V or more to the loco on DC is to turn up the throttle. Unless a loco is relatively poor quality, by 5-7 volts, it should eb moving. However, if a sound loco behaved like that, it would be moving, with no sound since the voltage is high enough to turn the motor but not run the sound electronics. So they are set up not to move until a relatively high track voltage, leaving enopugh for the electronics plus some dead band because not all (more like most common) DC throttles aren;t particualrly precise, so a dead band is necessary to allow you to actually stop the thing but keep the sound going. Only once the voltage gets above that point does it start moving - but at 7-8 volts, you're already 2/3 of the way to full throttle. So you have a limited range of control for the sound loco to go from stopped but making noise to running full speed. And any other locos, without sound, at 2/3 throttle are probably already going faster than is realistic. If you want sound, go DCC, period. There are workarounds, like the MRC Tech 6, but when running that sound loco, it's using DCC, and when running a DC loco, you're now using the MRC pack and not that nice PWM DC throttle. 

                                             --Randy

[York1]

Lastspikemike

I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". 

I'm not clear on what you mean.

I know absolutely nothing about coding or computer languages.

Yet referring to a one page sheet containing commands (since I don't remember them), with two or three buttons pushed on my handheld control, I can change virtually hundreds of different commands to my locomotives.

What am I missing by using this primitive software?  What am I missing by using a handheld control rather than a laptop or phone?  Why should I worry how easy or difficult it is to access?

[betamax]

Lastspikemike

I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". 

I have a two BLI, a paragon 2 mikado and a paragon 3 pacific. I note that the pacific is very sensitive to the slightest voltage drop out while the Mike is not.

My understanding of DCC, limited as it is, is that the main power is not a true AC but it does differ from the control signal and that both sets of power are transmitted down the rails concurrently. The decoder picks out the control signal and also converts the pseudo AC into DC (I guess "rectifies" is the term) with the variations in voltage required to control motor rpm. The power is phased and the alternating aspect  is alternating the voltage in tiny amounts but not the polarity.

So, the technical problem solved economically by DCC in the 1990's was standardizing the technology required to deliver power and the control signal down the same two conductors,  which effectively froze development of the supporting software.

 

You must stop thinking in terms of Analog DC.

The DCC signal is not AC.  Never was.  It looks like this: DCC Power.  The waveform is the data and the power are combined.

The decoder picks off the pulses from one rail, at full voltage, so there is no mistake which logical state the rail is in at that point in time.  It takes the pulses and routes them through a rectifier to provide power for the microcontroller and the motor.

The motor is driven using full voltage PWM. There is no phasing or polarity needed, the motor's drivers determine speed and direction by their switching sequence.

How did the standardisation of the control/power signal on the track lead to stagnation in the software?

Decoders and throttles have advanced enormously since the mid 90s as the microcontrollers became more powerful and the components got cheaper.

Television wasn't frozen in the 1950s.  If it was, we would still have monochrome sets with a small CRT. Many engineers of the day would consider today's 4k televisions witchcraft. They considered the bandwidth needed for video to be excessive.

 

 

[gregc]

Lastspikemike

I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". 

curious what type of modern software system you might be suggesting?   (is your background in software)

DCC users don't need to know how to code, they need to understand configuration options described in CVs.

and DCC only describes the electrical signals on the track, not the user interface which you may be referring to

[wjstix]

doctorwayne

The only DCC loco I've run on my layout was a BLI Mikado that I detailed and painted for a friend. While it ran not too badly, the sound feature would cut-in and out, as if it were re-setting itself. Perhaps that had some influence on my disinterest in sound, but after almost 40 years in a steel mill, sound isn't an attractive feature.

If you were running it on DC, most likely you were running it right on the edge of where it was just getting enough power for the sound to be on and the engine would move. If you ran it on DCC, the sound would be constant - unless you have really dirty track.

 

[wjstix]

rrebell

Con's, much more fussy and prone to damage from operator error.

Only problem I've had came with trying to solder connections to a 'lightboard replacement' decoder, too much heat can hurt the decoder. Other than that, there's not much you can do to damage a decoder unless say the engine derails and you allow the resulting short circuit to continue long enough to burn something out. If you mess up the decoder programming, you can always do a re-set to the factory defaults and start over. BTW, since decoders come with pre-set defaults built in, the only thing you really need to 'program' is to change the ID number to the engine number. The engine then will run basically the same as it had on DC - unless the decoder has a "keep alive" function built in it; then the engine will go over dead frogs and dirty track that would stop it on DC.

[rrinker]

 All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs. Open collector common positive current sinks in general tend to be more efficient.

 At least Sheldon and some others understand DCC, and have their own reasons for not using it.

                                 --Randy

 

[Overmod]

rrinker

rrinker wrote the following post 3 hours ago:  All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs.

Well, not precisely, the original issue was that LocoFi wired that, in a standard plug mind you, backward from the way DCC does it.

I'm delighted to see reasons why DCC's convention is more efficient, but the original point of why LocoFi reversed it remains a WTF moment... now, in fact, even more of one.

[rrinker]

Overmod

 

 

rrinker

rrinker wrote the following post 3 hours ago:  All this from mentioning that the suggested replacement system of direct wireless to the loco uses ironically the more primitive common negative connection for the function outputs.

 

 

Well, not precisely, the original issue was that LocoFi wired that, in a standard plug mind you, backward from the way DCC does it.

 

I'm delighted to see reasons why DCC's convention is more efficient, but the original point of why LocoFi reversed it remains a WTF moment... now, in fact, even more of one.

 

 I think that's what I said - the LocoFi makes the blue common the negative, the individual function wires are positive, which is backwards from DCC, yet they designed their controller to plug in to a standard DCC format socket. At least one responder mentioned that this sort of direct wifi is how things ought to be done, a lot less "primitive" than DCC, yet the irony here is the "advanced" device is using a more "primitive" circuit design. 

 I did start this thread, after all. 

                          --Randy

 

[gregc]

Lastspikemike

I point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't.

plug and play certainy by itself won't make it less primitive.   can you be more specific about it's shortcoming?  provide some examples?

[Overmod]

rrinker

 I think that's what I said -

That was, in fact, just what you said; what you did not say then was 'why' one way was better -- which, as I said, is what you just added.  (Anyone remember the 'Who's on First?' patter?)

Both your comments stand, despite any discussions with different 'interpretations'.

[rrinker]

Lastspikemike

 

 

gregc

 

 

Lastspikemike

I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". 

 

 

curious what type of modern software system you might be suggesting?   (is your background in software)

DCC users don't need to know how to code, they need to understand configuration options described in CVs.

and DCC only describes the electrical signals on the track, not the user interface which you may be referring to

 

 

 

 

My background is definitely not in computing, that would be my brother with his PhD in artificial intelligence.

I am completely self taught, I know my way around a motherboard enough to have "upgrade" them. I can install software most times. I know a little bit about networks but much of that is from the days when you had to do all the network programming yourself. Now it's pretty much plug and play even for network stuff.

I repeat, I am not advocating abandoning DCC. I point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't.

The description of how it works is useful for me. It brings to mind my Spectrum DCC Santa Fe which wil only run in one direction when powered by the MRC Tech 6 used in DC mode.The reversing switch has no effect. It works correctly in DCC ("dual") mode and when run in DC only with MRC Tech 7 which is very interesting to me. 

 

 I'd possibly take that up with MRC, no idea why that should be, the decoder appears fine, working on DC if it works with the Tech 7. Possibly a difference in the way the two systems do their pulse output in DC. Not a DCC issue.

 I've found DCC to be pretty much plug and play - not sure what you see that makes it not. I bought my original system, then I added a walkaround throttle which also added support for more functions, and all I did was plug it in. No configuration, no setup. OK, I soldered my track feeders - but I did that for DC layouts before DCC was available too. I've run locos with decoders from all sorts of manufacturers, they all just work. 

 Installation of decoders can vary, but there are plenty of locos where it is as simple as plugging it in. Using a different control method such as direct radio to a board in the loco isn't going to change that installation issue for older locos. You have to do the same sort of work to install a DCC decoder as you do a WiFiTrax board as a Railpro board. Sometimes more - the direct radio boards are almost universally larger than a DCC decoder, simply because they need everythign the DCC decoder has PLUS a radio module. That may change and they will make the radios smaller, but the antenna trace on the PCB needs to be a specific length to work, so it's not going to get that much smaller. ANd the same improvements that make the radio boards smaller will also make DCC decoders smaller, so the direct radio system will always be at a disadvantage where space matters. There's already been major improvements over the years - the first sound decoders were more suitable for S scale than HO and N, and were ONLY sound - the motor control had to come from a second decoder. Now N scale has sound and motor combined decoders, and there are ones barely larger than a dime. 

 I'm not sure what you see that is so primitive about DCC. If DCC is primitive, then DC must be prehistoric. DCC is a very robust system that works from small switching layouts to things the size of small aircraft hangers. It's also quite reliable. Not once piece of my equipment has failed in nearly 20 years of use, nor have I EVER blown a decoder in the time since I got my first system.

 How else do you propose activating functions? Seems pretty user friendly to me that the button with the light bulb symbol turns the lights on and off, the one with the picture of the bell makes the bell ring, and the one with the whistle on is sounds the whistle. Turn the knob clockwise, the loco goes faster, turn it counter-clockwise, it slows down, just like most every DC throttle. Sliding my finger up and down a touch screen has zero appeal to me. But if you like that, it works with DCC. Yes, that primitive system can easily use a modern smartphone for a controller, if that floats your boat. 

                                   --Randy

 

[gregc]

Lastspikemike

The one example that came to mind was changing cv29.

what about it?    what's so primitive?   what are the shortcoming?

[Paul3]

Lastspikemike,
CV29 programming is a simple as can be.  They made a chart; it's in every manual.  Don't worry about what bit equals what value, just follow the chart.  And even then, you're only going to be using two values in the vast majority of locos.

CV29 controls 2 or 4 digit addresses, Normal Direction of Travel (NDOT), Speed Steps/Speed Table, and Analog/Digital mode.

99 times out of 100, you're going to use one value for CV29 and one value only.  For me, that value is 34.  That means a 4-digit address, NDOT = Forward, 128 Speed Steps, and Digital-only mode.  CV29=34 is such a basic number to know that at my club we have signs on the programming track telling people to use it.

The only real exceptions at my club are for locos set up to run long hood forward instead of the standard short hood.  In that case, add 1 to the CV29 value and make it 35.  Now the engine will run in the other direction compared to what it did from the factory.

Only a handfull of the 2000 engines at our club use a speedtable and only by our DCC experts who like to play around with it.  Two digit DCC addresses are reserved for club use only, so the two digit number values for CV29 are never used by members.  And it is highly recommended that all DCC decoders used at the club have analog mode turned off (DCC-only) because analog mode can lead to runaways with a short circuit.

Out of the 2000 engines on the roster, probably less than 20 of them use a CV29 value that isn't 34 or 35.  That's how rare it is to use any other value for CV29.

[rrinker]

 You don't even need a chart. All the popular DCC systems take care of it automatically, based on how you answer a question or two on the display. 

 There are other CVs used in a similar manner. From an engineering point of view - why would you use a full 8 bits to represent ONE item being turned on or off? One CV can control 8 individual on/off options. Otherwise, you would use 64 bytes to represnet what can be contained in 1 byte. That's just good design, not primitive. Unless by primitive you mean conserving system resources. Who cares, my computer has 32GB RAM, no need to make the program small and efficient. That seems the attitude of most modern programmers, and frankly, I hate it. I'm no fan of the super expert who rolls a whole routine into one line which is unreadable, either. Big and bloated just because it's there - just no.

 In addition to easily setting bitmapped CVs like CV29 right in the system, there's walways JMRI. Now you have a whole screen of check boxes with full explanations to set CV29 (and pretty much every other CV in a decoder). All settings clearly defined and explained, and the displays change based on the specific decoder you are working with, so you only see options for features supported in the specific decoder. Definitely not primitive.

                              --Randy

[gregc]

Lastspikemike

DCC is new to me and puzzling even though modern computing is no mystery.

do you realize that DCC is a communication protocol across the tracks.    not a human interface provided by the command station vender such as NCE or DigiTrax

[richhotrain]

Lastspikemike

I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding". 

Your terminology is flawed. Something doesn't become primitive until something more advanced comes along in the evolution of things. So, enlighten us. What is more advanced than DCC in your view to run locomotives on a model railroad layout?

[Bayfield Transfer Railway]

"You keep using that word.  I do not think it means what you think it means."

 

[tstage]

Lastspikemike

I repeat, I am not advocating abandoning DCC. I point out that it is VERY primitive and not at all plug and play user friendly. It should be but it isn't.

Lastspikemike

DCC is new to me and puzzling even though modern computing is no mystery. I've been tinkering with hardware and software for 30 years now and my introduction to DCC has not been transparent, shall we say.

Mike,

With that being the case, why not spend more time studying and learning about DCC and less time drawing and stating erroreous conclusions about a technology you admittedly have limited experience with.  We all have 2 ears and one mouth for a reason.  This might be a good opportunity to take advantage of that truism in order to learn so that you can make a wise and informed decision should you choose a DCC system down the road at some point.

And feel free to ask questions along the way.  Most folks here are more than happy to pass along their wealth of knowledge and experiences; as much as you have about your own.

Tom

[York1]

Lastspikemike

I predict DCC will develop into a more effective and user friendly TCS

OK, Mike, I'm going to ask this, and I'm not looking to argue or say you're wrong.  I'm genuinely interested in how you consider DCC to be less effective or not user friendly.

I just started a railroad two years ago when I retired.  I know nothing about computers, computer languages, or much of anything else, for that matter.

I bought an NCE DCC system.  I learned to run trains in 30 seconds.  I learned to adjust various commands to the locomotives in about five minutes.  It took me ten minutes to adjust the speeds of two different locomotives with two different decoders so the locomotives travel in a consist at the exact same speed.  It took me 30 seconds to set up the consist.

I guess that's why I'm wondering what you would do to improve the system.

As with everything else, one day I may look back at what I'm doing now and wonder how I ever used something so primitive.  I guess I just don't see it right now.  I'm not much of a visionary.

[betamax]

Lastspikemike

I predict DCC will develop into a more effective and user friendly TCS in the not too distant future unless the current generation of new entrants dries up.

You need to look at that the European DCC manufacturers are doing.

TCS is a private company that makes decoders and is working on their own command station. So you can't use a tradmarked name to describe your advanced train control system, it's already taken.

[gregc]

Lastspikemike

I predict DCC will develop into a more effective and user friendly TCS in the not too distant future unless the current generation of new entrants dries up.

as i said, Digital Command Control is a protocol across the rails that modulates power polarity.  it doesn't define the user interface.  venders like NCE, Digitrax provide a command station that provides power to the track and impose communication on the power to communicate with DCC compatible decoders

venders also provide control units users use, the "user interface", that communicates using a proprietary bus (e.g. NCE cabbus, Digitrax loconet) with the command station.    Jmri can also be used as an intermediary between a wifi controller such as on an android phone or i believe TCS and various command stations.

jmri decoder Pro can be used to configure a decoder (e.g. CVs), presumably more "user friendly"

you might prefer BlueRail which uses wireless tech to communicate with the loco and a graphical user interface on their controller.

consider that your phone, that you replace every few years, provides a "user interface" and uses 3g, 4g, 5g to communicate with nearby tower but communication with the endpoint is thru various older communication tech (sonet fiber, undersea cable, satellite, ...)

 

[richhotrain]

I hope that lastspikemike is just playing with us. Otherwise, I am worried.

Rich

[doctorwayne]

While I'm not a user of DCC on my own layout, I have run trains on friends' layouts using it, and have done a DCC installation for one of those friends.

Lastspikemike

...A brief look at the current state of dead rail (could you invent a worse name for exciting new technology?). Looks like the main limitation at the moment (or at least in 2019) is the circuit board size in order to get the wireless onboard, which frankly surprises me a lot....

I'm currently installing "dead rail" technology in a Bachmann tender for another friend (a die-hard user of DC, even moreso than myself) and it looks like everything will fit just fine, including stuff to allow re-charging the battery without disassembling anything.
He's simply interested in seeing how it works.  The controller is wireless and appears to be similar to the DCC stuff that other friends use.

Wayne

[Overmod]

York1

one day I may look back at what I'm doing now and wonder how I ever used something so primitive.  I guess I just don't see it right now.  I'm not much of a visionary.

Part of what he's saying is that the modulation and data rate from the early Nineties, and a reliance on a registry-style list of assigned bit values, is old-fashioned whether or not it's familiar or 'as easy to learn as programming the IBM System/36' or knowing how to dial long distance.

The modulation on track power is already something of an artifact, as is the idea that switching power rail-to-rail with a square wave is an easy technical solution for a combination of high data rate and low effective bit error rate.  Thing is, as with early SCADA there are advantages to that powerline approach that don't require enormous bandwidth, and if you're synthesizing the electricity to the different hard-wired functions, your power and power line modulation can well stay 'primitive'.

In any case that stuff is down in the physical layer; it's like the old Unix International joke that if your users ever saw a command-line prompt you'd failed utterly as a systems designer.

There is the hardware, and then there is the HMI, and running on top of that is the UI, and over time there is the IxD.  Note that not only is this radically different from the OSI telecommunication model, in many cases you can't translate from one to the other effectively.

Of course, the moment you use a knob to adjust locomotive speed, you're unprototypical wherever the PWM and waveform modulation to control a motor speed is performed.  As noted in recent posts, there are people who like it that way ... and they can 'get it from Walthers'.  Meanwhile a company like ESU tinkers with defaults so that engines run more like the prototype, and there are people who prefer that, too.  The interesting question that is only peripherally being asked is just how much UI and IxD design needs to be accommodated in the DCC modulation restriction... I would argue that it's 'good enough' to be retained, and that any future more sophisticated system -- we're sure to see them for 'dead rail' and wireless communication -- have at least a compatibility mode to work with DCC standards.

Now of course it also ought to work with the various proprietary end-runs and imperfectly realized alternatives that, ahem, certain manufacturers try.  A combination of ESR-style 'bazaar programming' and a Linux-style approach would easily get you to open-source interworkability where that is technically possible.  The problem lies slightly but significantly elsewhere.

Does anyone remember the word-processing program LeBlond Software published in the '80s that ran inside Lotus 1-2-3 v.2.01?  That was perhaps the greatest 'road not taken' of anything in my experience: it had a very long emulation menu of then-popular word-processing programs and would work just like the chosen program once that simple choice was made.  You won't be surprised that this has disappeared almost without a trace, but it's still a high-water mark of user convenience of an important kind -- a highly relevant kind in the current discussion here.  Many people want to keep what they know, and in some cases that does mean a great deal of technical sophistication goes into the equivalent of thrashing or nonoptimized emulation.  

The key, though, is to let even the hidebound get help, and if necessary consulted advice, without necessarily knowing all the timing conventions and pulse offsets in the legacy standard... for that you need special care not always as implicit in 'standards-making' as I thought it ought to be.

[York1]

I wish I knew what you are talking about.

I do know this:  I turn on the power, push a button, and my Kato BNSF locomotive moves.

[Overmod]

York1

I do know this:  I turn on the power, push a button, and my Kato BNSF locomotive moves.

And that's what you need, and what you have come to expect, and it's sufficient unto the day.  I'm among the last to say you need to re-learn the whole 'interface', like going from Word 98 to Word 2008, just because the latest and greatest can do lots more.

[richhotrain]

Lastspikemike

http://cs.trains.com/mrr/f/88/t/275672.aspx 

 

http://cs.trains.com/mrr/f/88/t/275672.aspx 

http://cs.trains.com/mrr/f/88/t/275672.aspx

 

[richhotrain]

York1

I wish I knew what you are talking about.

No you don't, and you don't want to. It is a whole lot more fun just "running trains", and not worrying about what makes them run. I just don't know why some guys just want to try to make model railroading tantamount to building a super computer.

Rich

[Bayfield Transfer Railway]

richhotrain

 York1

I wish I knew what you are talking about.

 

 

 

No you don't, and you don't want to. It is a whole lot more fun just "running trains", and not worrying about what makes them run. I just don't know why some guys just want to try to make model railroading tantamount to building a super computer.

 

Rich

 

 

I was on the Email list for the DCC standard before its adoption, with Stan Ames, Dick Lord, and others.

There were a large number of people who just seemed to want excess complication.

 

[Bayfield Transfer Railway]

A kitchen stove is extremely primitive technology if you spend under $500.

Yet nobody complains.

[rrinker]

Are you really that hung up on terms? No, you aren't "programming" the decoder in terms of writing a computer program. Neither is the DCC system, the decoder comes pre-programmed with firmware to respond to the DCC protocol, along with various user-controlled variables to adjust the behavior - hence why they are called Configuration Variables.

 As for your responses to the idea the DCC is just a protocol - I don;t undersstand what you are missing. DCC only specifies the packet format for the data transmission and the waveform used on the rail signal. When you get down to it, that's ALL it specifies. It does not specify how the user interface devices connect to the command station to tel lit what data to send, it does not specify anything about what the user interface devices look like. You've got everything from a handheld miniature lcomotive control stand (Proto Throttle) to touch screen smartphones to simple LCD display screen devices with knobs to very simple devices that just have a knob and some buttons, no screen whatsoever. Or even a full blown computer - running Windows, Mac OSX, or Linux. They connect via numerous wired formats, proprietary radio formats, and WiFi. 

 The NMRA controls and defines none of that. They only care about what comes out of the track connections, and how the decoder in the loco responds.  

 You still haven't explained 'primitive'. At the same time you praise truly primitive locos that didn't need instruction manuals (because they just basically had wires from the track pickups to the motor and no other features), you condem a modern loco as 'primitive' because it requires an instruction manual to exolain all those advanced features.

                              --Randy

 

[Bayfield Transfer Railway]

ULTRACREPIDARIANISM:  Expressing opinions outside of your knowledge.

 

[tstage]

[richhotrain]

tstage

 

An Internet troll is a member of an online social community who deliberately tries to disrupt, attack, offend or generally cause trouble within the community by posting certain comments, photos, videos, GIFs or some other form of online content.  

https://www.lifewire.com/types-of-internet-trolls-3485894#:~:text=An%20Internet%20troll%20is%20a%20member%20of%20an,all%20over%20the%20Internet%20%E2%80%94%20on%20message%20boards%2C

[Bayfield Transfer Railway]

"I don't understand what people are talking about, so I'm going to write a lot of words to cover up the fact."

[ATLANTIC CENTRAL]

Lastspikemike

Looks like there are a few innovators out there already. Railpro has the right idea. Backwards compatible. 

Once you separate the command signal from the track power DCC isn't very useful. Wifi or Bluetooth is the way to achieve that. Then the track power can go  back to just standard DC.

Make just a radio throttle control board to stick into DC only locomotives and a wifi or Bluetooth system can run anything on the same track.

Works for dead rail also.

As for recharging locomotive batteries in a dead rail system, that's protypical refuelling/servicing  time. For steam it would include re-watering time. Inductive charging is very feasible. You would not need to plug in any battery, just park the locomotive over a "refuelling" track.

Reading a bit more about DCC confirms my earlier posts to my satisfaction. I have no need to explain and certainly no need to justify my posts.

The original poster complained about having to reverse the polarity of led lighting. Most often you can do this simply by reversing the plug on the power feed to the bulb. I agree it is unfortunate that soldered wires would be inconvenient to change. But splicing in a reversible plug could be done at the same time and is s good feature to have anyway. Really this is a drawback to using led bulbs rather than a criticism of this new system.   

It would be interesting to know if this was just an error or required by some other factor.

Considering all this information I am glad I decided to build a double isolated multiple  block  DC only layout to begin with. I bought the MRC Tech 6 because for me it was an extra DC throttle with DCC capability added basically for free.  Once I added the hand held throttle it was no longer a free DCC but then I also acquired the ability to run up to 6 DCC locomotives at the same time. Since running three locomotives on my DC only layout taxes my current operating skills I see no need for more DCC capability as yet.

I don't see me investing in a more powerful DCC system making any sense for me, given my affection for all the used DC locomotives I have decided to acquire.

Change is in the wind and  Tech 6 ought to be enough for me for the foreseeable future.

 

 

I am a big believer that direct radio, like Railpro, would be a great system.

The problem with Railpro as it exists today, is the pictograph throttle.

I have over 130 locos, I'm not searching thru 130 pictures to assign a throttle to a loco.

It is easy to imagine the perfect throttle for your current needs in the hobby. it is yet another to imagine a throttle that will meet the needs of a large percentage of modelers who have different goals, different size loco fleets, different size layouts and desire different types of operation.

My Advanced Cab Control DC is tailored to my needs. It can be modified and adapted to a variety of needs. But it must be custom designed for each layout. And, it helps if the layout is designed with some of its basic parameters in mind.

Likewise, DCC is very suited to a wide range of different layout conditions and user goals.

Since you are so sure you know what would be better, let us know when you have this product ready for market........

Sheldon

[rrinker]

Lastspikemike

Reading a bit more about DCC confirms my earlier posts to my satisfaction. I have no need to explain and certainly no need to justify my posts.

 You certainly don't, but posting controversial statements with no explanation is classic internet troll behavior.

 Clearly you haven't read up that much on DCC, as your paragraphs after that explaining away my original post make perfectly clear. The product is a direct WiFi control system, not DCC, however they vendor made it with a standard NMRA 8 pin DCC decoder connector. Except they made the function wiring backwards. So while you can just plug it in, no soldering required - it won't work with LEDs. Drawback of LEDs? Well, if you want more primitive incandescent bulbs...  What's the point of having a plug and play install if you then have to solder and swap the wiring around? Might as well just make the receiver something that solders in.

 As for why - it has to be a mistake. Whether the output is active low or active high is a simple software issue for the microcontroller, and the drivers to get enough current, well, every DCC decoder uses one or another component that is commonly available. So there is no excuse. 

 As for fitting a reversible plug? Why woudl you make soemthing harder to use? In the case where there are a lot of lights in the shell, it's quite common when isntalling DCC to put a plug or plugs between the chassis and the lights, so you can remove the shell without leaving long excess length wires curled up inside the loco, just asking to get wrapped into the drive mechanism. You use polarized connectors, not reversible connectors, so you can plug things in and put the loco back together and be confident the lights will all work. Having a reversible connector just makes it more likely to make a mistake, and give zero benefit. DCC is always common positive. Ring RailPro receivers also use a common positive and come with an NMRA standard connector so they can just pluf in to a DCC ready loco. Only MTH and this WiFiTraxx module do it backwards, and MTH doesn't really matter because they don't sell their DCS decoders for separate installation. They are pre-wired into their locos, so it doesn't matter, unless you want to rip out their electronics and use standard DCC.

 As for the controllers, I'm with Sheldon, even though I use DCC and he doesn't. Scrolling through a list of pictures might seem 'cooler' to younger people, but it is far less practical than simply keying in the cab number of the loco you want to run usign numbers. It's technology for the sake of technology, so you can say "ok look, that 'primitive' DCC only has a 4x20 monochrome character LCD, outr system had a 4.7" full color high res display" Yes, and what exactly does it improve? It might be 'cool' and 'fun' some someone with a small layout and a small number of locos, but for anyone who has an actual fleet of locos and/or actually operates their layout, it just gets in the way. Is it really faster to scroll through 100 pictures of locos to get the one you want than to press a maximum of 6 buttons to select ANY loco directly? (the loco select button, up to 4 digits, and the enter key) Who does this make it easier for? Really little kids who can't read numbers yet, so they can scroll to a picture of Thomas and run it? We will occasiionally allow kids that small to run trains on the club layout, but they get handed a throttle that already has a train selected, and pretty much the only thing they do is blow the horn. Older kids may be instructed to watch the signals and may have to slow or stop the train, but those kids could also easily be taught how to select a different loco. 

 Change is always in the wind, DCC has not remained static for 25 years. Battery on board is still not really small enough for HO, except steam locos with tenders, and definitely not there for N scale. For HO diesles, it usually requires running a dummy permanently attached to hold the batteries. Not suitable for prototypical operation. At the opposite end of the spectrum, direct radio control and batteries has been used in G scale for many many years, it's nothing new. I'd almost think it foolish to build an outdoor layout and expect it to run on power conducted through the rails, DC or DCC. The biggest problem is that the systems that have electronics small enough to use in HO, even if they still draw power fromt he rails, is that there are multiple vendors entering this space, and none of the systems work with one another, they are all proprietary. This was the state of command control before DCC. You are at the mercy of one particular vendor. Without a standard, it's not going to take off in any sort of mass adoption. Command control was around 30 years before the NMRA DCC standards were established - some well-known layouts used one system or another, but it wasn't widely used. Companies came and went over those years, stranding people. 

 And one final thing. The whole idea of yours that combining the signal and drive power is 'primitive'. Combining them is what made DCC practical and successful, compared to all the others which superimposed a weak AC signal on a steady DC track powe, or something similar. Many of those older systems, the address of the loco was set by a hard wired jumper inside the loco. The receiver just counted pulses - if the jumpers were set to make one address 7, then it counted pulses and ignored the first 6 and responded to the 7th. After trying to pick those low amplitude pulses out from the noise and spikes placed on the rails by the brushed DC motors in the locos. DCC is fairly immune to that. 

                                    --Randy

 

[Bayfield Transfer Railway]

Lastspikemike

 

 

Bayfield Transfer Railway

A kitchen stove is extremely primitive technology if you spend under $500.

Yet nobody complains.

 

 

 

 

Not true. Even the simplest electric stove is not primitive. I mean you compare that to an open fire for cooking? Seriously? Can you even build a cooking fire ???

 

 

why yes, I can.  Eagle Scout and all.

 

and explain to me how a cheap electric stove is more sophisticated than DCC.

 

Please do.

[SeeYou190]

What is going on in here?

I don't use DCC, but I have operated layouts with DCC many times.

DCC seems wonderful for what it does. Simplified wiring, direct control of a locomotive, lights, sounds, and it was easy to learn.

It might be an old system now, but I don't hear too many people saying the system is not good enough. It seems to do everything that DCC users want it to do.

Promitive or not, that seems to say to me that it was designed right from the beginning.

My Samsung oven was about $500.00 when I bought it. I don't know if it is primitive or not, but it sure does a lot better than the 25 year old oven it replaced.

I can also build a fire good enough to cook hot dogs and s'mores. What else do you need?

I don't know what that has to do with anything.

-Kevin

[gregc]

Lastspikemike

I'm not advocating replacement of DCC. I point out that it is in fact a very primitive software system not readily accessible to current computer users with very little interest in "coding".

requests to clarify what a more modern improvement (not replacement) would be has been evasive

comparison of DCC to a TCS throttle compares the communication with the loco and the human interface

comparision of DCC to "dead rail" compares a wired approach to a wireless approach requires a "replacement" of the system.

it might be interesting to consider what the NMRA might propose today if DCC did not exist.

 

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

Lastspikemike

My understanding of DCC, limited as it is, is that the main power is not a true AC but it does differ from the control signal and that both sets of power are transmitted down the rails concurrently.

what does "both sets of power" mean?   there is no separate (e.g. high frequency) carrier for communication.

Lastspikemike

The decoder picks out the control signal and also converts the pseudo AC into DC (I guess "rectifies" is the term) with the variations in voltage required to control motor rpm.

"variations in voltage required to control motor rpm" suggests that the track voltage is varied to control the motor voltage.

Lastspikemike

The power is phased and the alternating aspect  is alternating the voltage in tiny amounts but not the polarity.

the polarity does change.   the polarity is modulated to communicate bits.    this approach is very clever because it requires a minimal of parts to modulate and demodulate.

 

i often find the best way to clarify my understanding is to state it and listen to the responses.    my goal is not to win the argument, such as a lawyer might in court, but to learn.   

 

 

[ATLANTIC CENTRAL]

Yawn..........

[gregc]

Lastspikemike

Direct wireless communication between the throttle unit and the decoder board is superior to DCC.

if that is what you suggest as less primitive, glad to hear it stated

Lastspikemike

I'm not able to understand the remark about the throttle (which actually generates the control signal) being the interface and somehow DCC being different.

glad to hear you say "not able to understand", suggesting a desire to understand

if by "throttle" you mean the device used by a user to control a loco, the DCC standard does not describe how it works or how it communciates.

multiple "throttles" ("cabs") communciate using a proprietary protocol to a single "command station"(which may control multiple boosters).  the command station controls the polarity of the track voltage and it is the timing between polarity changes (not frequency) that represents a bit (see below)

DCC is different from the control system.  NCE and Digitrax throttles are different but both support the same DCC protocol over the track

Lastspikemike

Dead rail locomotives can run on a DCC track

it certainly can since "dead rail" doesn't require track power

Lastspikemike

It seems direct wireless operation of a NMRA standard DCC decoder is already technically and economically feasible.

while you could transmitt DCC packets using other means of transmission, both wired and wireless, DCC specifically describes a wired transmission mechanism.   i don't doubt that some have built built wireless front-ends for DCC decoders albeit with additional hardware and demonstrated its feasibility.

i'll argue that wireless DCC is not DCC (e.g. DCC does not specify frequency or modulation method).

Lastspikemike

The control unit (throttle actually) adds a frequency modification transmitting the digital control instructions and, in some cases, communications back from the locomotive.

not frequency

one or more control units (throttles) communcate with a single "command station"  that sequentially generates DCC frames for each active loco decoder.   a booster receiving the frame data from the command station provides power to the track.

DCC communication represents bits by time between polarity changes.  each bit is represented by a pair of polarity changes completing a cycle where the polarity is both positive and negative for the same period of time.

 

most DCC systems do not support communciation from the decoder back the command station.  I do not know where the Bi-Directional Communciations Standards stands.

Lastspikemike

You clearly like to read into words meaning that isn't there and then construct an argument or discussion about something not said.

i am an EE and interpret words literally looking for a complete, correct and unambiguous statement and hope to do the same.

i am not looking to make a technical distinction to win an argument.  i do question an ambiguity when things are incomplete, incorrect or unclear.   i am trying to establish a clear understanding

Lastspikemike

The decoder varies the voltage and polarity of the power delivered down the rails in order to run and control that locomotive just like a standard DC controller does.

a "decoder" is in each and every locomotive.   it does not vary the power on the rails, it receives power from the rails and decodes DCC frames from it.    the decoder in the locomotive uses an h-bridge like circuit to provide power using pulse width modulation to the DC motor in the locomotive of either polarity.

Lastspikemike

All of this information is readily available over the internet,

yes indeed. i've provided references.

[rrinker]

 RailPro can't run a DCC loco, its receivers can use AC, DC, or DCC power in the tracks, it doesn't car which. That simply means their circuit has a rectifier on the track inputs.

 There actually is at least one dead rail system that uses the DCC protocol but over a wireless link. It's the one developed by Tam Valley and now sold by DRS. The transmitter side gets a standard DCC signal from an existing DCC system, and transmits it to a receiver in the loco with then drives a standard DCC decoder. Sound or not, you can use any decoder you like. The power source comes from an onboard battery pack. The obvious downside is that you need that much more hardware to fit inside the loco, and it's just not practical for many scales in common usage. Even with the best miniaturization available today, straight DCC is pretty tough in Z scale, let alone adding a radio receiver and batteries.

 DCC systems do have a common around which the track voltage does go positive and negative around. Relative to an external power supply, it may be generated as 2x the baseline, but there is a system common that references the center point, and most system include in their instructions the information that this common needs to be connected between all boosters. In fact, one way to measure track voltage recommended by Digitrax is to measure the DC voltage from Rail A to the common, and from Rail B and the common, and add them together. Still think the DCC signal is only a positive going waveform?

 One DCC booster can run your entire layout too, if the Tech 6 has enough power, so does one DCC booster. Not sure why you think otherwise. ANd common rail wiring stinks for DC too, I never used it even back when DC was the only way to control trains. I ALWAYS gapped both rails and ran TWO wires to power each block. But to say you can't use DCC with common rail is actually not true. It simply requires that each booster use optically isolated inputs so each booster is electrically isolated from every other one, yet still gets the same command signal.

 "Primitive software system not readily accessible to modern computer users not interested in programming"? If modern computer users are not interested in programming, then why would a system with an accessible programming API (hint, DCC has one, as do the major manufacturers' proprietary throttle interface systems. There are DIY DCC decoders, and even full systems. But the whole point is to NOT have to program anything - hence a wide variety of off the shelf devices for controlling, monitoring, and signalling) be any less primitive or more desireable?

 How is a simple electric stove not 'primitive'? It's a rheostat connected to a heating coil. That's a pretty primitive electrical circuit. The oven simply adds a thermostatic switch to the mix. My gas stove is even simpler, a gas valve and a burner. All the fancy electronics in the back, to give me a digital clock display - that's all for controlling the oven. All the electronics do is enable me to be lazy - I can walk away with something baking and the oven will shut off by itself at the proper time. 

 You've got more than one EE in this thread. Suffice to say I think we have a pretty good handle on just how a DCC booster and decoder actually work. If Greg's explanation doesn't clear up some of your misconceptions, I'm not sure what will.

 Instructions printed ont he back indicate complexity? MRC's claim to fame is that their system is so easy to use, the complete instructions are printed ont he back, instead of a multiple page user manual. It's a marketing white lie, as they leave out many things the system can do in those abbreviated instructions, but ANY system that allows control of multiple locos is by definiteion going to be more complex than a DC throttle with a speed knob and a direction switch. You aregue that DCC is primitive and then complex - which is it? - but then say a direct RF system is less primitive - but it will be just as if not more complex, because RF design is almost always more complex than a wired system. ANd you still have some of the same issues as with DCC, like addressing each loco so your handheld controls your loco and your buddy's handheld controls their loco. Therew will have to be a mechanism similar to DCC where you decide what address you are going to use, and the system sets that address in the receiver. ANd if the system instead uses an internal address it never exposes to the user, and instead uses pictures - we're back to that whole "what happens when I have dozens of locos" thing where it is completely impracticatl to scroll through pictures on a handheld LCD screen trying to find the one you want - compounded by having multiples of the same engien type. How do I tell which on my dozen RS3's I am selecting? By trying to read the road number (on a small handheld LCD screen, color and high resolution notwithstanding)? This is a horrible idea for a user interface.

                                   --Randy

 

[Track fiddler]

Wow!

You know, ... I don't find it hard at all to admit I don't understand some of the things in this thread.  Frankly that's why I shut up and listen.  I like to learn things whenever I can,  It keeps things interesting.  

My ex-wife was one of Those "No-It-All-People".  I tend to avoid Those like that anymore

I will say this though.  I do understand this has been one of the more entertaining and interesting threads I've read in the last 3 years

 

Thanks for posting

 

 

TF

[Overmod]

I think our self-characterized BS professional should look more carefully at why the DCC power is implemented as it is, and ought to be retained even if unmodulated.  It is NOT slightly higher voltage DC -- although it acts that way in the first step of 'decoder' operation -- and it is interesting to note that it provides a way to eliminate 'polarity' as an issue completely; no more fancy arrangements for reversing loops, frogs and the like.

 What is not as clear -- and this was a very significant concern in the 1990s, when things like V32.bis over POTS was important -- is that the structure of data communication explicitly zeroes out any direct-current charge transfer due to modulation concerns.  Some of the more complex constellations used for 'high speed' modems had to be very carefully laid out to avoid what was basically DC charge transfer over time in a way difficult to dissipate.  The inverted modulation scheme shows to me that key people were aware of the importance of this.  Brother Mornard, who was there during the standards process, may have some knowledge or recollection of this.

As a peripheral and not entirely pedantic point, sometimes solutions that did things that now appear 'primitive' in hindsight involved perhaps wildly more expensive and 'high-tech' approaches.  An example probably familiar to many is the evolution of high-speed dynamic random-access memory.  Some of the features in SAGE in the 1950s required enormous cost and complexity to do very simple things; the original patent for video-on-demand actually involved multiple cameras with little glass slides to render the 'on-screen prompts' as even ASCII character generation was not an evolved technology -- hard as that is to remember!

[rrinker]

 Indeed - on screen generated graphics even in the 80's in professional TV studios look so laughingly silly these days. Prettyy much any computer can do a far better job of superimposing text and other images on a video feed, but as late as the late 90's, the hardware to do this was not cheap. Now it's a device you can plug into a USB port. It was all the rage 15 or so years ago to make your own videos with the lightsaber effect from Star Wars - something that previously had required (originally) hand painting frame by frame and later a whole rank of computers to render (and not in real time), and now could be done in real time on any reasonably powerful home computer. Look at all the YouTube content creators using green screens these days - now in real time. With no fancy equipment, nothing at all like a full blown TV studio.

 Back to DCC - indeed, there are several reasons for making the DC average be 0 volts. Although in another (maybe not so brilliant, depending on your experience) option was to build in the concept of stretching one side of the 0 bit to introduce a deliberate DC offset to allow non-decoder locos to run. The usability varies depending on the type and quality of the motor involved, but it does work fairly well in at least some cases. Loosely built motors, like the old Athearn gold sided motors where even the magnets aren't glued in place buzz very badly which renders the utility of using zero stretching somewhat limited, but others can be fairly quiet with only a mild buzzing. Coreless motors of course are destroyed in short order due to no way to dissipate heat, but coreless motors were an issue with the earliest DCC decoders as well because they used low frequency PWM drives. With any 'modern' DCC decoder (which goes back quite a way - only the very earliest and then some super cheap brands used the low frequency drive), you can drive a coreless motor in perfect safety.

 I must confess to being around when the initial talks started to create a standard command control system, and as far as features go, it was CVP's Railcommand that did the most. The initial Lenz system was MUCH more limited than what became DCC - perhaps more proof that DCC is not 'primitive' - the original basic design allowed for much extension with little change, to get a wide variety of features, which has continued to be extended. I believe the original only had 2 functions, but by the time it was submitted for approval, there were 8. Then this was expanded to 12, and then 29. Originally there were only 14 speed steps, but this was expanded to 28 and 128. Railcomm has been added for 2 way communications - this was originally Lenz proproetary but is now been standardized by the NMRA. DCC is a growing standard that has evolved over the years, it is not the same today as it was in 1995.

                                          --Randy

[Bayfield Transfer Railway]

The NMRA DCC Standards are available online.

 

I recommend starting thete.

[Overmod]

Lastspikemike

Some say DCC is like AC and some say not. Some say polarity exists in DCC and even that polarity is significant while some say not. Some even suggest that the power and the control signal are "the same thing' and some say they are separate "things".

The good news is that a careful and conscious reading of the basis for the power and data modulation will definitively answer all these points for you without any more pedantry required.  It's common sense, and I think you have that sense.

There are a few thought-experiment 'finger exercises' you can do to make sure you have the peculiar genius of the idea captured -- will it work if the rail-to-rail swings are sinusoidal instead of square wave; will it work if there is no digital modulation of the applied voltage; will it work if the square-wave voltage swing is less than 'rail to rail'.

 While we're at it: calculate the required characteristics and state the likely characteristics of the keep-alive and device that detects a DC PWM signal from a power pack and generates a proportional DC output to a "DCC compatible" motor... just the thing that DCC doesn't like...  (There are likely multiple alternative ways; see which you think are best.)

[richhotrain]

Lastspikemike

I've certainly learned a lot about DCC I'd looked for before and could not find.

Certainly clear to me now why there's not even agreement in the online information that is available.

Some say DCC is like AC and some say not.

Some say polarity exists in DCC and even that polarity is significant while some say not.

Some even suggest that the power and the control signal are "the same thing' and some say they are separate "things".

What for me at least is new information about DCC is very useful to know even though I am still processing a lot of the detail.

I certainly understand semantics and pedantics if anyone was still wondering,

 

Why not just buy a DCC command station and scope it? Find out for yourself what goes on with the DCC signal.

 

[SeeYou190]

ATLANTIC CENTRAL

Yawn..........

Yeah... me too.

Track fiddler

one of Those "No-It-All-People".  I tend to avoid Those like that anymore

Me too. It is amazing how little the "Know-It-All-People" actually understand.

Steve-O already locked one thread today for pointless arguing, maybe this one will get locked too.

Going in circles....

richhotrain

Why not just buy a DCC command station and scope it? Find out for yourself what goes on with the DCC signal.

That would mean the "Know-It-All-People" actually have gained real knowledge and understanding of a subject, and not just read about it on the internet and acted like experts. Not going to happen.

In Florida we like to say that a child that has dragged an alligator home by the tail understands a lot more about it than his friend who just read the story.

It is easy to pick out the people in here that have actually built layouts and done things from those that just read about it and act like experts.

-Kevin

[Track fiddler]

  I hear you Kevin

yep yep yep

One could be one of the most knowledgeable persons in the world or just come across that way but without a trace of humbleness that intelligence is hard to be admired

Why take one piece of cake and share the rest with others when you can take the whole thing is a few people's logic I guess ...

 

 

TF

[Overmod]

Lastspikemike

It is sometimes called a "square wave" which is an oxymoron. I'm a sailor and DCC is most definitely  not a wave.

This reminds me of a guy who used to work at Lockheed - brilliant engineer, but he just didn't get eddy currents.  He actually filed for a patent on how to use the 'new discovery' and requested it receive secret access restriction...

Sine, sawtooth, square and other waves are called that because the mathematics to describe them is similar.  You can think of a practical square wave as though it had the attack and decay 'risetime' equal to that of a much higher frequency sine wave but good clamping on peaks.  So the effect is to switch quickly between two voltage levels.

In practice, not only can't you switch potential 'instantaneously' but you can't stop fast slew precisely at a clamped peak.  There are fascinating little artifacts that 'ring' a little at the "finish" corners.

The point of using a square wave in DCC is to get around problems of spike and inductance noise on the power wires.  The voltage transition is clean, and as large as the physical power supply is regulated to deliver, so it is easy to pick out (we call this high SNR, or more precisely CNR because DCC uses width modulation) and the transition stays 'latched' high at either extreme of swing for longer than the average of much random noise or transients.

Now this matter of bit coding needs a bit (I couldn't resist) more thinking: you don't want binary states 'on' and 'off' like computer explanations for kids, and you don't want them 'positive' and 'negative' pulses or peaks on a zero-crossing waveform either.  So you have two different clock-timed pulses, one twice as wide as the other, for the two states, which leaves many possibilities for recognizing things like guard intervals or signal multipath recovery.  
Remember the bakancing of charge?  This is why you send the 'inverse' of a control sequence: any tendency for electrons to drift where they are hard to cope with is inherently balanced in no more than a few cycles.

If you wanted to do this with a sine wave or modulated signal, you could do it by specifying a voltage transition well down from peak -- like clipping in an audio amplifier.  Some timing precision is compromised and of course the information in the clipped part of the wave is lost -- you will now recall that DCC uses the full rail-to-rail voltage difference to modulate its signal; it can in essence be no clearer.

An oscilloscope displays waves, or at least is intended for that purpose ( and yes I saw those tv shows also about scopes being used as computer displays and radar displays, etc etc, even read the books.)

And if your 'scope was not made by the company that built Chevy Chase's discount phones,  you will find a square-wave setting among its controls.  Note that logic probes do essentially the same signal and timing recognition but they resolve in ns. or other timing and not a continuous display of SHM.

As Locofi points out in their FAQ the DCC control signal is more like Morse Code but I say only if you consider that it also has variable length dots and dashes superimposed on the power flow.

This is a reasonable analogy if you know both how the power modulation and Morse code groups work. Technically a bug could be used to send bistate binary in 'dashes' and 'dots' with the same meaning the convention in DCC uses.  But the purpose of dashes and dots in practical Morse as used for all but special communication is to form recognizable tone patterns to the ear, not convey 'letters' sequentially over the wire to a printing device as in Morse' original... and not very workable... patent.

DCC isn't AC because it isn't analog.

But of course the power part of DCC is analog, and the production of the digital waveform is also analog.  Only the supervised information is digital.

Polarity is also meaningless because it's not analog.

It is never anything but analog, an indication of potential differences measured by physical equipment.  Ordinary DC works (in great oversimplification) by shoving electrons in one direction, and because of how attached devices use that electron flow whether it is pulse-modulated or not, we consider the polarity of DC flow significant.  In this connection the 'double voltage' rail-to-rail in the DCC supply can be thought of as two counter-polarity interrupted DC flows, alternating across the zero crossings; either of these could be 'half-wave rectified' and smoothed into a DC current if desired polarity -- in fact, both can be.  A good decoder in fact will 'know' which of these half-flows to use on any given locomotive facing in any direction... which is a big reason 'polarity' issues are so little a concern in evolved DCC.

Note that a simplistic understanding of sinusoidal AC charge can be considered just this way with some of the circuits the EEs have been describing; one reason RMS measurement is used is that it gives average for a smoothed rectified waveform and not the actual high-voltage peak in sine-wave AC.  

[SeeYou190]

Going around in circles.

We are so far from the original question that we might need to engage the hyper-drive to get back on course.

-Kevin

[gregc]

Lastspikemike

DCC isn't AC because it isn't analog.

it seems that the AC-nish of a DCC signal is confusing the issue of polarity and a proper understanding.   AC does not need to be sinusoidal.

Lastspikemike

The power is delivered by digital wave that alternates between zero and max voltage on each rail and each rail has to be out of phase with the other rail.

i think the confusion is how can a current alternate (go in opposite directions) if the voltage simply goes from zero to some value and back to zero.

a current flows between two points, one of higher potential than the other.   current doesn't flow in an incomplete circuit, an unconnected wire (exception antenna at RF).

current flows between the two rails of a track when they are at different potentials.   when rail A is positive and rail B is at ground, current flows from A to B.   when rail A is at ground and rail B is positive, current flows from B to A. 

in other words the current flows in one direction then the opposite direction, alternating, AC, and due to a polarity change.

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

Lastspikemike

The DCC control signal is not communicated by polarity changes.

the spec clearly says it is and I previously showed how the time between polarity changes encodes bits of information.   (see link)

 

Lastspikemike

Why use a picture when 10,000 words would do?

are you serious?  or a waste of time?

 

3318 101700

[tstage]

This song from the 70s might sum it up, as well:

[tstage]

Lastspikemike

??? I'm a litigation lawyer. Why use a picture when 10,000 words would do?

Well, you know what they call 500 lawyers at the bottom of the ocean?

A good start...

[richhotrain]

tstage

 

Lastspikemike

??? I'm a litigation lawyer. Why use a picture when 10,000 words would do? 

Well, you know what they call 500 lawyers at the bottom of the ocean?

Lastspikemike

For myself, I'm not so sure. I don't have a PhD nor a Masters. I have only a post graduate bachelors degree. I'm pretty smart

With a post graduate bachelor's degree no less.   

[rrinker]

Lastspikemike

In that spirit I finally did what the original responder to the OP might have done, check with LocoFi

https://www.wifimodelrailroad.com/faq

The last two FAQ answer the questions posed, express and implied.

The design is deliberate and intended to capture the DC only market as well as DCC "ready". 

 

 Which is the product I started this thread about - the 8 pin compatible with DCC ready locos plug is wired backwards with regards to functions. It has the white and tyellow wires +, and the blue -. DCC specifications for the 8 pin connector have the blue wire as + and the white and yellow are -.

 ANd the other huge goof so far - they do not have an app fo Apple IOS. Only Android phones.

                                        --Randy

 

[rrinker]

SeeYou190

Going around in circles.

We are so far from the original question that we might need to engage the hyper-drive to get back on course.

-Kevin

 

 Even better - the original wasn't a question, it was merely my observation that the vendor got the wiring backwards for a product that is supposed to plug right in to a standard 8 pin DCC socket.

                                      --Randy

 

[Overmod]

rrinker

the original wasn't a question, it was merely my observation that the vendor got the wiring backwards for a product that is supposed to plug right in to a standard 8 pin DCC socket.

CVP makes a similar product, in the Airwire900 series

http://cvpusa.com/doc_center/r2_M15_User_Guide_web.pdf

and they see no need to reverse standard NMRA wiring even though their decoders don't come hardwired.  They also provide a simple LED test that, in my opinion, shows up LocoFi's supposed "FAQscuse" as, at best, lame.

[rrinker]

 CVP has been at this a LONG time - starting with CTC-16 in the 70's. Railcommand was an expanded version that added headlight controls, right before DCC. They make DCC systems, and AirWire itself has been around a long time, one fo the first commercial direct radio control systems, very popular with garden railroads. The throttles are even compatible between their DCC system and AirWire.

                                     --Randy

 

[tstage]

DC...it's soooooo primative...<tongue firmly placed in cheek>

[Overmod]

Lastspikemike

Ahem, yes, like those electrons that orbit the nucleus in Bohr's "model" of the atom. And wander through the airwaves or the "ether" remember that stuff?

Yes, essentially point carriers of very well-defined charge, with very well defined virtual mass.  I'm sure you'll whine they are 'theoretical constructs' but they have been just as good as other subatomic particles as engineering working assumptions for many years, first in electricity and then in electric power.  I think it is safe to continue working with the assumption that "they" behave as described as there is so much interesting nuclear physics associated with them and their 'heavier' versions.

Incidentally the stuff that 'wanders through the airwaves' isn't electrons.  You really should look stuff like that up before shaming yourself further in postings.

You know current isn't electrons actually flowing or transistors couldn't work.

And you think current is... what, exactly?  ExB?  Magic displacement?  "Waves" in the "luminiferous aether"?  Hint: what is a coulomb, and why is it important to amperage?...

Again there is so much physics on conduction that relates to electronics that it is comical to hear a discourse 'debunking' it as if you knew something secret the rest of us don't.  You probably think nerve conduction is electronic, too.  What's next, that holes in semiconductors don't exist either, because you can't have charge less than zero?

And so on.

And it's certainly on and on: this is something like the sixth field I've seen you discourse on that you haven't really understood, but that doesn't stop you from browbeating those on here who I think actually might.

[richhotrain]

Overmod

 

Lastspikemike

And so on. 

And it's certainly on and on: this is something like the sixth field I've seen you discourse on that you haven't really understood, but that doesn't stop you from browbeating those on here who I think actually might. 

Here is something that every 19 year old law student (hmm) would be familiar with - - that old evidentiary adage, He knew that he did not know whether or not he knew.

Rich

[Overmod]

richhotrain

He knew that he did not know whether or not he knew.

I think the issue here is different.  He is quite sure he knows whether or not he knows.  It's whether he does know that is at issue.

Now to cut him some slack, there is that aspect of 'knowledge' my father would expound after the 5th bottle of Old Dutch Philosopher -- the part you can't know.  No one has ever 'seen' an electron and it does not behave like a true particle (other than statistically).  Likewise no one can make a 'perfect' square waveform in a number of respects.  And you can certainly have 'currents' with, for example, protons in fluids, or holes in some semiconductors.  Perhaps my favorite is phlogiston, the career-wrecking politicized ego-ridden global-warming-style consternation of the 18th Century.

The problem is that if you're going to disparage that sort of thing in practical use, you have to know the degree to which the theory applies or is a 'good predictor' -- certainly for technology, and in some cases for science.  As Copernicus pointed out (long before Fourier) there's no reason why epicycles sufficiently superposed won't generate any orbit ... just that treating the Earth's motion as if the orbit were heliocentric gives you easier calculations for accurate feast days.

[richhotrain]

Overmod

 

richhotrain

He knew that he did not know whether or not he knew. 

I think the issue here is different.  He is quite sure he knows whether or not he knows.  It's whether he does know that is at issue. 

Either way...

[Track fiddler]

 

 

TF

[rrinker]

 Yes, many of us EEs also had to take enough physics so we know the conventional way circuits are discussed is sort of backwards from how it really works in the physics world. But it works fine as a model to describe the behavior of all common electronic components.

 That's a pretty lame excuse, that WiFiTraxx isn;t making a decoder. No, they aren;t. But they ARE making a device to be used IN PLACE OF a DCC decoder and even outfit it with the standard connection plug that is provided in many locos so you don;t have to solder wires in - AND THEN WIRE IT BACKWARDS. The AirWire board is NOT a DCC decoder, either. It doesn;t respond to DCC signals on the track, it responds only to radio signals sent from the AirWire throttle. It connects between the power source and the motor, in place of a decoder. They just happened to not do their lighting circuits backwards, so if you are adding AirWire to a loco that already had an NMRA 8 pin DCC decoder socket, you can just plug it in, no changes, and everything works, unlike the WiFiTraxx board.

 AirWire at least also has features people have come to expect in a controller - a knob, which you can click to change direction, so no hunting for a button, toggle, or a part of the screen to tap on, and a screen to display info or walk you through configuration settings. Best of all, the same throttle works with their DCC system. so you could use their DCC system on your basement HO layout, then take the throttle outside and use it to run your dead rail, battery pack on boards, G scale garden layout. Same throttle, no need to learn two different control systems. 

                                  --Randy

 

[Overmod]

Lastspikemike

I appreciate the concerns expressed about my personality defects but it really is not necessary.

It is not the 'personality defects' at issue -- we all have them, me more than most.  It's the making of claims of superior expertise or experience that contain things that ain't so.  Those need to be corrected before the susceptible jury of modelers reading for technical advice are led into rendering an unjustified verdict...

We all love the sinners, but that won't stop us from hating sin...

[SeeYou190]

-Kevin

[gregc]

Lastspikemike

I deduce that one DCC throttle can control only up to 6 trains simutaneously operating and wonder if the up to 5 that are cut loose from the human operator at any one time are controlled by some sort of looping within the decoder or by simultaneous transmission of up to 6 streams of packets by the DCC control computer. I infer the latter as it is hard for me to see how a decoder could preserve the signal internally.

not looping within the decoder; the decoder is in the loco.

a single DCC command station communciates with all cabs (user interface) and generates the DCC signal to one or more boosters that provide power to the track.   the command station will sequentially generate a DCC frame for each active loco.  less than 8 msec/packet considering that the max bit is 200 usec and there are ~40 bits in a typcal frame (see S9.2 or all standards, S9)

i'm not sure what the max # of locos is for any one system but 100 would be conceivable.   i think NCE will poll up to 64 cabs.

 

Lastspikemike

smug superiority

errant information is confusing to other readers.   i think it better to state things as your understanding (e.g. "deduce") rather than facts

 

[stevetx]

I am confused about the subject of this thread.  I'm DC so most of this thread is over my 79 year old brain but I keep trying to learn.  I started out reading rrinker's starting post about LocoFi.

rrinker on 7/27/20 wrote:

". . . review the LocoFi system. . . . . . But they blew it - on their decoder, the function wires are positive and the common is negative - exactly opposite the DCC standard!" 

So, I went to the LocoFi web site and found in thier FAQ that the wiring was in fact not DCC compatible for 8 pin.  You do need to change the wiring in DCC ready locos to get LEDs to work.  Thus, rrinker is correct.

I thought this thread was all about LocoFi but then on page 5 rrinker brought up WifiTrax and said it was backwards.  

rrinker on 8/11/20 Wrote:

"That's a pretty lame excuse, that WiFiTraxx isn't making a decoder. No, they aren't. But they ARE making a device to be used IN PLACE OF a DCC decoder and even outfit it with the standard connection plug that is provided in many locos so you don;t have to solder wires in - AND THEN WIRE IT BACKWARDS." 

So, I went to the WifiTrax web site but I cannot find that a "used in place of a DCC decoder" product by WifiTrax.  They do make an 8 pin NMRA DCC standard compatible wireless interface to a DCC decoder that does process the incoming two track wires. I found this document for the inerface product "WDMI-35 Wi-Fi/DCC Loco Interface Module Getting Started" but it shows to be compatible to the 8 pin NMRA.  There is nothing that indicated that the common was backwards. 

What am I missing?  Yes, most of the commentary in this thread I do not understand but I am missing something in going to the LocoFi and WifiTrax web sites. 

[Overmod]

Lastspikemike

What number of trains can one operator reasonably expect to control on a home sized layout?  We have three DC controllers and running three trains simultaneously seems very challenging for one operator.

This will be an interesting question to ask the various modelers here.  I have generally thought that most of the 'multiple train' control involved the 'club night lite' operating sessions, where people get together to run on a private layout.  If I were going to run multiple trains at once it would be mostly to 'watch' (meaning only intermediate use of any controls, with some form of automatic otherwise) or to run just one at a time.  For DC this would immediately imply complex power management and ATS-enabled signaling; the operation would also benefit from 'interlocked' route selection.

We have two continuous loops and one yard so in theory operating three trains should be simple.

I would agree, and it would be comparatively simple to assign a 'cab' to each and have the trains merrily go when no one is tinkering with the corresponding settings.  We had a recent thread on who did and didn't like to do that sort of thing.

[/quote]I deduce that one DCC throttle can control only up to 6 trains simutaneously operating and wonder if the up to 5 that are cut loose from the human operator at any one time are controlled by some sort of looping within the decoder or by simultaneous transmission of up to 6 streams of packets by the DCC control computer.[/quote]This is a place you could reference 'primitive' technology.  There is a limit to the addressable bandwidth in DCC, but to my knowledge little control storage apart from CVs.  Adding the necessary information plus overhead plus any guard band between addressed instructions will give you the required bitrate... which must fit within the modulation rate of the signal.

 

I infer the latter as it is hard for me to see how a decoder could preserve the signal internally.

A more modern decoder could be treated as a small special-purpose computer, running what might be a sophisticated running program interrogating other devices on the layout for context.  The DCC modulation could easily bootload such a program, run a firmware update utility, etc.  Ask your brother about some of the possibilities of AI/ES in such a context.

More importantly this offers the capability you indicate: running what may be complicated operations with either interrupt-based or as hoc acceptance of external commands... cutting down dramatically on the actual real-time modulation needs for the DCC control signals.  (I would also mention that data fusion from other modulations, including several 'flavors' of wireless, then become easy to do, and relatively easy to secure...)

That would also explain why power interruptions cause signal dropouts even with locomotive keep alive circuitry. The DC power can be stored onboard but not the DCC signal stream.

That would be correct.  Some of the 'issue' is concern over failing safe; if the locomotive keeps running on unexpected LOS (as some of the old command systems did) you can have disasters with little warning involving hundreds of dollars' worth of sensitive equipment.  Another concern is the absence of even rudimentary reverse-channel signaling from the 'connected environment' which would allow the kind of short-term request and retransmit of dropped-packet or LOS information that would preclude most digital quality-of-signal concerns.  As you note, any information 'stepped on' by noise or interruption is gone (and the device has to wait for the next valid command to 'know more') -- the deep voltage slew of the DCC modulation helps with the former but of course can't put back what disconnection eliminated...

[rrinker]

 The only one that truly allows you to have live control of more than one train at a time is Digitrax, their full featured throttles have 2 knobs, so you cna have 2 trains actually under control (meaning not having to push any buttons or anything to switch between them). You can have many running at the same time, just good luck trying to switch back and forth between them. So I'm going to go with 2 as a practical maximum, because I can actually have them under control, just turn the respective speed knob, with my Digitrax throttle.

 The limit of 6 is very much system dependent. Right now I still have my original Digitrax Zephyr as a command station, it can handle up to 12 locos. The larger command stations can handle 100 or in the case of the DCS240, 400. Theroetically, you can start up all those locos from one throttle, the Digitrax system design does not limit the number of locos 'controlled' by a throttle to some limit based on the throttle's memory. In any case, only the loco who's address is shown on the display is actually under control of the throttle's knob and buttons.

 This is where you seem to misunderstnad something about DCC. The command station generates the DCC data. It is continually sending packets for every loco that is running. The throttle doesn't do that, althought he throttle does update the command station based on user inputs. Either by sending the updates in a peer to peer system like Digitrax, or by being polled like NCE. The decoder doesn't need to remember anything, it gets a steady stream of packets. There is usually a timeout setting in the decoder that tops it if it doesn't see packets for some period of time, likewise the command station may see a lack of updated information from the throttle as the loco no longer being controlled, and may also stop the loco. Packet timeout on the loco side is part of the NMRA standards, the throttle bus and command station communications are left up to the individual manufacturers to handle in their own way.

                                  --Randy

[rrinker]

stevetx

I am confused about the subject of this thread.  I'm DC so most of this thread is over my 79 year old brain but I keep trying to learn.  I started out reading rrinker's starting post about LocoFi.

rrinker on 7/27/20 wrote:

". . . review the LocoFi system. . . . . . But they blew it - on their decoder, the function wires are positive and the common is negative - exactly opposite the DCC standard!" 

So, I went to the LocoFi web site and found in thier FAQ that the wiring was in fact not DCC compatible for 8 pin.  You do need to change the wiring in DCC ready locos to get LEDs to work.  Thus, rrinker is correct.

I thought this thread was all about LocoFi but then on page 5 rrinker brought up WifiTrax and said it was backwards.  

rrinker on 8/11/20 Wrote:

"That's a pretty lame excuse, that WiFiTraxx isn't making a decoder. No, they aren't. But they ARE making a device to be used IN PLACE OF a DCC decoder and even outfit it with the standard connection plug that is provided in many locos so you don;t have to solder wires in - AND THEN WIRE IT BACKWARDS." 

So, I went to the WifiTrax web site but I cannot find that a "used in place of a DCC decoder" product by WifiTrax.  They do make an 8 pin NMRA DCC standard compatible wireless interface to a DCC decoder that does process the incoming two track wires. I found this document for the inerface product "WDMI-35 Wi-Fi/DCC Loco Interface Module Getting Started" but it shows to be compatible to the 8 pin NMRA.  There is nothing that indicated that the common was backwards. 

What am I missing?  Yes, most of the commentary in this thread I do not understand but I am missing something in going to the LocoFi and WifiTrax web sites. 

 

Simplest explanation? It's why a gas filler and diesel filler nozzle are different sizes, so you can't put diesel in yoiur gas car, the nozzle won't fit (you can do the reverse, and make a hash out of your diesel engine, but let's ignore that for now). If they were both the same, you'd have (believe me, people ARE this dumb) people ruining their gas cars left and right with diesel.

WiFiTraxx has chosen to use the same style plug as a standard DCC decoder on their product, in an attempt to make it easy to install. Except they wired it backwards. So it fits - but does not work, without further modification. That's ALL I was saying when I started this thread. It's a mistake, a bad design, because you can plug it in expecting it to work right out of the package, so you can use direct WiFi control instead of DCC - except that the plug is wired backwards and it WON'T work. All this add-on DCC stuff in the thread comes from LastSpikeMike.

                                      --Randy

 

[rrinker]

 Further on the DCC sisgnal - since the same packets are repeatedly sent by the command station, it's not actually an issue if a loco misses a packet or two addressed to it. Another will be along. That's why there is no need for a acknowledgement for packet reception. 

 The total available bandwidth allows for hundreds of locos to run at the same time. Most clubs don't come anywhere near this, but there is one well known layout, the owner has switched DCC systems more than once to get to the point where the wired and wireless throttles can reliably support the number of simultaneously running locos during his op sessions. If anyone stresses DCC's capabilities, it's him. Note the issues experienced over the years are entirely on the throttle/command station interface, NOT the DCC protocol. Even with so many trains moving at once (and this layout is big enough to handle them all, it's not a whole bunch of trains all chasing their tails), you press the horn button and the horn sounds. You slow down for a station stop, and the loco you are running slows down. 

 Not bad for a 'primitive' one-way communications protocol.

                                             --Randy

 

[stevetx]

Randy, Thanks for your quick reply. Your "Except they wired it backwards" still has me confused. All the wire instructions I see on the WifiTrax web site never gave me a hint of any 'backwards' situation like the LocoFi web site did.  The LocoFi product seems to be totally different product than the WifiTrax product but you say there the same.  my short coming.  I will go back and look again at WifiTrax to  find what I missed.

[Ringo58]

ATLANTIC CENTRAL

 

 

 

Why I am on this little rant?

Because your opening line, and to some degree, your whole post is condescending  to those who have decided not to use DCC.

You are saying this product is aimed at the "stupid" people who have not gone DCC.

How much are 10 DCC wireless throttles and 140 decoders? My system did not cost that much.

 

 

I think you took what he said out of context. He didn't call you out personally, he was referring to the people like me that don't want to spend the money on DCC. Never once did he attack DC or saying that it was behind in technology. All he said who the target audiance was and how the system is behind current DCC technology. Not how DCC is better than DC. 

[rrinker]

 SO much back and forth in this thread now even I am getting confused. Two different prodocts - the WiFiTrax ones with the 9 pin JST connector appear to be made to actually have the same pinout as the 9 pin DCC plug found on many locos. So they DO just plug in. It's the LocoFi one that is backwards.

 Names are too similar. The whole "WiFi" name for wireless networking is yet another one of the idiotic marketing things ever present int he computer industry. A stupid acronym that conveys exactly zero information on what the technology is. Wireless Fidelity? Only a marketing major who spent 4 years in college partying could come up with that junk. They claim it never stood for that, but the brand consulting firm that came up with it (yes, a company who's sole purpose is to advise people on brand names for their products - what a world) says it was a play on HiFi audio, and that has always stood for High Fidelity.

 Then the engineers go the opposite way, and just tack different letter suffixes after the base standard designation. Which one is better, a, b, n, ac, ax? So now the current top dog, 802.11ax, is being braded as WiFi 6. 802.11ac was retoractively named WiFi 5 for branding. So I guess that makes sense now, 6 comes after 5 and is an improvement on it, but on the cellular side we have 3G, 4G, and 5G. Nothing in sync. Leave off the outright lying from AT&T on which tech they actually are using for cell phones.

 What does this have to do with trains? Not much, but the confusion of all these "*Fi" names gets the products all mixed up. WiFiTrax makes a controller for direct WiFi control of trains that is plug and play with the standard type of connector found in many DCC Ready locos. LocoFi makes a board with a common plug on it, but which does not directly plug in even though it's the same plug. It doesn't help that the LocoFi web site is wifimodelrailroad.com, further comfusing them with wifitrax.

(another example - I've seen people want to build modular layouts and use standard 120VAC outlets and plugs as the power link for track power between modules - about the worst idea ever, because what's to stop someone from plugging one into a real AC outlet, energizing the tracks - two strips of bare metal - with 120VAC house current. That's why you don't repurpose a standard connector for something else) 

                             --Randy

 

[Overmod]

rrinker

Simplest explanation? It's why a gas filler and diesel filler nozzle are different sizes, so you can't put diesel in yoiur gas car, the nozzle won't fit ...

If I may, the fundamental issue can be illustrated in a slightly different part of the car.  Multiple DC circuits can be wired so either the 'source' or 'sink' of their voltage comes from one common point (to which a single common wire could be connected).  In a car this is conveniently the whole mass of what used to be metal chassis and other structure, so you only have to run one wire to a device to be powered (the other connection being where it screws to the 'common'.

Now' like it or not, the electrons in DC current flow from the 'negative' to the 'positive' (by early convention too pedantic to give here) and so with negative ground the whole chassis becomes the 'source' of current with only the voltage-dropped return having to negotiate individual wires.  Many British cars have positive ground, where the power goes out through the individual wires and only back to the battery through the common.

What Randy pointed out is that DCC assigned the 'utility' DC supply controlled by the decoder in a particular way, by standard -- and this facilitated the use of standard connection plugs that one could assume would reasonably follow the standard.  This is what LocoFi did not do that is the subject of this discussion.

In my opinion they could have avoided any concern by not using or touting a 'NMRA standard' plug if they wanted to wire that supply polarity backward.  Instead they crawfish and try to make it as feature not a bug'.  Randy pointed out early that the NMRA standard makes more objective sense electrically, so there was no performance reason they could assert.

[gregc]

Lastspikemike

By 6 I meant the maximum size of the recallable stack of locos that have recently been or are being run by one throttle

very precise

an NEC PowerCab can handle 6 locos.   bear in mind that a single knob is not a good way to control multiple locos because you may have the knob set high for one loco and may not want it set that high when selecting another.  the PowerCab uses buttons to control speed.

[rrinker]

 It is very specific to the system architecture - the stuff left up to the vendor, not controlled by the NMRA DCC specifications.

 NCE throttles are limited to no more than 6 loco addresses per throttle. That's in part because the cabs are really just dumb terminals, and all the information is held in the command station, and that's all the memory it allows for. Even though the PowerPro command station can handle a LOT more than 6 locos, you need more throttles to go over 6. Not that controlling 6 locos from one throttle is really possible for one person to do.

Digitrax's network works completely differently. There is no 'recall' because the information about which throttle is controlling which loco is stored in a completely different manner. If the command station is capable of 100 locos (DCS210 model) then I can theoretically use one throttle and start 100 different addresses running. 

(just because you CAN - doesn't mean you SHOULD< or that it's even practical)

Issue 2 is the type of knob. The NCE ProCab/PowerCab use buttions and an encoder wheel as speed control options. The Digitrax DT-series throttles also use encoder knobs (and there are buttons as well). With these, you can easily switch back and forth between multiple locos and none of the change speed unless you actually turn the knob. The NCE Cab-06p and the Digitrax UT4 use potentiometer knobs. So if you have one loco running at 1/4 throttle, switch to another one and accelerate it to 3/4 speed, then switch back to the first one, you have to guess and get the knob close to the right position, or else the loco will speed up from 1/4 to 3/4. And vice-versa. Just another reason I don't like potentiometer throttles. ESU solves this in the most typical German over-engineered way - their potentiometer knob is motorized, so when you switch to a different loco, the motor automatically dials the knob to whatever speed the loco is running.

 It's differentiation like this that makes a DCC market, where you can compare features between different brands, yet at the track level, they all work together, because they all output NMRA DCC packets. Same with decoders. 2, 4, 6, 8, 12 function wires. Sound/no sound. BEMF/no BEMF. Specific form factors for specific brands of locos, or generic wires, or one of several standardized plugs. Pick your desired options. Brand does not matter, they all respond to the same NMRA DCC packets coming in from the track pickups. 

                                         --Randy

 

[tstage]

That's why an encoder is preferred over a potentiometer when using recall stacks.  Moving the knob or encoder wheel increases or decreases the speed from where the throttle was last set for the recalled locomotive rather than from a fixed point on the potentiometer knob.

Tom

[rrinker]

 There's another way to handle switching between locos running at different speeds, but it would be the least desireable way possible to do it. I have no experience with MRC DCC so I have no idea how they do it, but they were rather late to the party as they had several DCC systems prior to their existing lineup that had little expansion capability - if you wanted/needed more, you tossed the old one and bought a new one. The other big players from the beginning designed their systems to allow you to start small and add on without having to discard your original investment.

 That would be to just take the current throttle knob position as the speed. So you are running a loco at 3/4 speed. The knob is 3/4 of the way turned up from the stop position. You then recall a loco that you left running at 1/4 speed. The knob now assumes the curent position (physical, 3/4 of a rotation) is that 1/4 speed. Meaning you turn the knob back to the halfway (phycical) point and the loco stops, or you turn it to the 100% point (physically) and the loco now either runs at half speed, or it compresses the speed range of 1/4 to full into just 1/4 of the physical range of the knob. I really hope NO system does that, that's absolutely horrible. None of the ones I am familiar with do.

 But somewhere you have to take that into account - the the knod is at 3/4 and you select a loco running at 1/4, at some point the two have to be matched (remember, we are talking about potentiometer knobs here, where there is a fixed range of motion, usually 270-320 degrees). If you touch nothing, it's fine, the loco can continue to move at the set speed. But at some point, either the command station has to poll the throttle, or the throttle has to send the current state to the command station. Or you touch the knob and turn it just a little. Having the loco adopt the throttle position is how most systems do it, ESU uses the motorized knob to physically turn the knob to match the speed.

 This is all a non-issue if the knob is instead a rotary encoder, as the physical position in a 360 degree circle has no bearing on the actual speed. The speed setting is simply a value in the throttle that is incremented when the knob is turned clockwise, or decremented when the knob is turned counterclockwise. When you move from a loco running at step 100 to one running at step 20, the number stored in the throttle changes to the new loco's value, and neither the physical interface (knob) nor the loco have to change to perfectly match the speed of the loco you just switched to.

 Remember we are now talking about the user interface side, which is NOT part of the NMRA DCC standard, so not all systems behave the same way. NMRA DCC was only designed to guarantee compatibility at the track level. So talk about how many recalls there are and what they do is strictly a specific manufacturer issue.

 An example - the DCC system comparison charts you can find all over typically list a Recall feature, and Digitrax is listed at 0. OMG, what a junk system, XYZ has 6 recalls. Not so fast. With Digitrax, there actual IS a recall function in the throttle, but it is merely a shortcut memory to the last few selected addresses. Sort of like hitting the Undo menu option in a spreadsheet to change the value back to the previous one. It has no bearing on the actual operation of locos. Whereas NCE, and it seems MRC, the locos in the recall stack of the throttle are the ones that are actually running, and the recall stack is used to select between the running locos.

 People talk about 'storing' locos in their DCC system. That''s not how it works, nor how you should use the system. It was very common a number of years ago when Digitrax came out with the original Zephyr, and then when NCE came out with the PowerCab. Zephyr was listed as having a capacity of 10 trains. PowerCab is 6. The common question heard was : I have more than 6 (or 10) locos, how can I fit them all in, I guess I need a bigger system. No. You do not store your entire loco roster in the system, you call them up as you use them. The number of trains limit is how many can be moving AT THE SAME TIME.

                                   --Randy

 

[York1]

I know next to nothing about the technical side of things, but ... 

My NEC powercab has both the thumb wheel and buttons to control speed.  If I have a locomotive running at 20, and switch to one running at 40, the thumbwheel automatically runs at that speed.  If you switch back, it's at 20 again.

I would think could somehow be accomplished with a knob.

If I understand, that's what Randy is talking about with a rotary encoder?

[tstage]

Yes, encoders do not have stops so you can spin or rotate them endlessly and they will only go to there pre-set max or min settings.

Tom

[gregc]

the thumbwheel is an encoder

[SeeYou190]

tstage

Moving the knob or encoder wheel increases or decreases the speed from where the throttle was last set for the recalled locomotive rather than from a fixed point on the potentiometer knob.

A common "real world" example of this is the volume knob in my car.

Whenever the car is started, the volume is always at 7 (this is programmable) no matter where the volume was when the car was turned off.

Since the volume knob is an encoder, and not a potentiometer, this is a simple matter of software coding.

I do not need to know how any of it works in order to adjust the volume of my radio. The whole system might even be very primitive, but none of that matters. It is a nice feature that works perfectly.

-Kevin

[LocoFi]

We would like to clarify some of the points made in some of the previous posts:

 

rrinker

... huge flaw - their lated decoder has an 8 pin socket matching the NMRA DCC 8 pin connector ...

 

LocoFi™ modules DO NOT plug into the 8-pin DCC socket found on DCC ready locos (even if the wire connections were reversed and blue wire was made common positive). This is not a flaw. LocoFi™ is not DCC, was never meant to be. It's a complete ground up approach to model railroading operations. However, we adhere to and provide NMRA color coded wires on our modules for easy identification. Because these wires don't plug into DCC ready 8-pin socket, we don't even provide the socket with our modules so that our users do not mistake it for plug'n'play into the DCC ready sockets and accidentally blow up the module. We clearly explain it in our install guides and videos to actually take out the DCC ready light board (from a DCC ready loco) and solder the wires as per NMRA color coding standard, wiring the blue to the negative side of LEDs and the white/yellow to the positive side of LEDs. It is probably worth an hour's effort of installation for many hours of enjoyment yet to come.

To plug'n'play into a DCC socket, the LocoFi™ module will need to be designed that way, limiting the operating voltages to that of DCC. This will defeat the whole purpose of LocoFi™ being able to operate on a range of flexible DC voltages from as low as 7V to as high as 24V making it deadrail compatible for a variety of batteries as well. Yet, LocoFi™ runs well on DCC track power as well.

Ideally, an 8-pin plug should have been just that, an 8-pin plug where you can plug in ANY decoder or module of your choice. But, then you can't make the loco work as a DC only board when the lights are LEDs. You need external circuitry to do that and that's what the light board provides. Now, to make that happen, the resistors had to be ON the light board and not part of the DCC decoder (that is why older DC only locos need external resistors when doing a DCC decoder install). Considering, DCC was the only available technology at the time, it was an easy choice for the loco manufacturers to provide a DCC ready light board.

 

Please see ["website" - Original URL removed by moderator] for more details.

 

To conclude, it would only be natural to make LocoFi™ plug'n'play with DCC ready sockets if we really wanted that. We certainly won't expect our customers to change the PCB traces of their DCC ready light boards to match OUR wiring scheme. :-)

One other thing. You can operate not one but multiple trains one handedly with LocoFi™ without looking at the screen. This was clearly mentioned in the the previous review of LocoFi™ in the March 2019 issue of MRR. Not only can you sense (sound and vibration) when you move the throttle but you can customize the pressure (upcoming feature) with which you may want to do certain operations.

 

LocoFi™ Team

[LocoFi]

LocoFi

... This was clearly mentioned in the the previous review of LocoFi™ in the March 2019 issue of MRR. ...

 

Here's the link for reference: Review of WiFi Model Railroad LocoFi locomotive decoder in the March 2019 issue of Model Railroader.

Also, please do not hesitate to e-mail us directly [address removed by moderator] for any other question or concern.

 

LocoFi™ Team

[richhotrain]

[tstage]

Time to mosey back to the layouts.  Have a good weekend everyone...