DCC-Ex Wifi Shield

jngeddes Mar 11, 2023

  1. jngeddes

    jngeddes TrainBoard Member

    13
    6
    2
    Hi Big Jake,

    Thanks for your comments. Interesting.

    Again I agree 100% re the challenge of keeping up with 3rd party hardware --- and I acknowledge that it likely is/will be the source of the majority of problems for conductors/tinkerers. This is a strong argument against a "free-for-all" in terms of component supply. So far the DCC-Ex team seem to have done a very reasonable job of testing/recommending a suite of options.

    I am not conversant with the technical details of implementation but I would throw out the following general questions (I don't pretend to know the answers)

    - Is our hobby's attraction to a 5a supply somewhat historical? That is, does it come from the era in which our locos drew much more current than they do today? (I am thinking of the HO world)

    - We all know the benefits of running multiple power districts -- would it make sense to have a CS architecture that supports multiple 1.5-2a motor drivers rather than a custom build 5a driver? i.e. for larger layouts simply have more power districts? (I realize that for mega-club layouts this may not be practical but might it be a good approach for the need of the everyday modeller?) (IOTT has built a 5a DCC-Ex compatible driver so this question may be mute).

    - Or does a 5a motor driver cost no more than a 1.5a, so better to have the larger supply?

    - Again from an architecture perspective is it better to fully load a single DCC-Ex processor with all functions or develop an architecture that assumes separate independent processors for some functions, e.g. a Loconet interface (as has IOTT has done), LCC, etc. I don't know enough about Railcom to know how best to implement it but if I understand correctly that it is integrated in a degree in the basic DCC waveform then obviously it likely needs to built-in to the core. But as you point out an independent RailCom reader may be possible.

    - I know that the DCC-Ex team is looking at new processor options (more powerful, more memory). It will be interesting to see where they go with this. And as you point out, at some point new functions may be more important than supporting better processors --- but I am confident that they must be considering these trade-offs.

    The very interesting aspect of the DCC-Ex initiative for me is that it opens up the possibility of asking these type of questions and addressing them in new ways. I look forward to what the DCC-Ex may bring us next.

    Cheers
    John
     
  2. Sumner

    Sumner TrainBoard Member

    2,798
    5,840
    63
    I'm running DCC-EX and have 4 boosters and 8 circuit breakers for 8 power districts. I have a 12v 5 amp power supply on each booster. Do I need 5 amps for the trains? Not with me being a single user but the circuit breakers I'm running if I understand Tam Valley's instructions need the 5 amps so that they trip. You can set the circuit breaker for either a 2 amp or 4 amp current limit. I have mine set at 2 amps but believe, don't know for sure, that at the 2 amp setting they still need a 5 amp power supply. The 5 amp power supplies are about $15 each so not a major expense compared to the rest of the layout. The DCC-EX Command Station trips at a little under 2 amps I believe. My command station is only supplying the DCC signal to the boosters so hopefully it should never trip.

    As far as the component staying available. I thought they were so cheap, especially if you buy direct from China that I've got 3 command stations setup. 2 on Megas and an older on a Uno. I have extra of Arduino's and motor shields as I use them for other projects. It isn't like one has hundreds of dollars in these command stations. Under $50 for the main components. If things change a few years from now I'll either keep running what I have as it does the job for me or I'll buy new stuff. People do the same all the time with commercial command stations that cost a lot more.

    I wonder what percentage of home modelers use or will use RailCom and some of the other products that were mentioned. I don't see the need for my layout at this time and if I want to move to more automation DCC-EX has a lot of options and they are is growing. They have a number nice features now if you want to do more than run trains. Turntable control, EX-Rail automation and are working on being able to run DCC and DC with a phone throttle for both on the same layout. How many commercial products can do that? A number of modelers here have moved from one manufacture to another over time some will move to DCC-EX and some will move away. I think it is getting more people into the hobby or helping to move more from DC to DCC and that is going to be good for the hobby and the manufactures in the hobby.

    When I got back into the hobby a few years ago I was going to buy a commercial DCC command station and a wireless throttle. It was going to cost about $500 or more to have the flexibility I wanted. I found DCC++ and built a command station for under $50 using it and then the guys started working on DCC-EX and I moved to it and have everything I envisioned with it. But who knows what I might be using 5 years from now if I'm still around.

    Sumner
     
  3. BigJake

    BigJake TrainBoard Member

    3,259
    6,173
    70
    John,

    Excellent points and questions!

    As far as amperage goes, 5A (or more) is more important for larger scales than it is for N scale and smaller. Let's not forget that while N scale may be slowly growing, it is still ~half the market size of HO scale. So, if you are a commercial entity, ignoring 2/3 of the market is not a good business strategy, when current capacity is the only difference. This is why many commercial systems are capable of 5A (and increments thereof, in the form of multiple boosters.)

    Note that a RailCom compatible booster needs some intelligence and additional circuitry too, to at least shut off at the appropriate time for a responding loco's RailCom transmitter. The booster must also be able to relay the RailCom decoder's response back to the controller. This additional expense is a little more affordable with fewer, larger boosters, rather than more, smaller boosters.

    While 10A DCC systems are available, they really need multiple, lower amperage circuit breakers feeding smaller track power districts, to safely manage track shorts at smaller scales (even including HO). It's not just the track and adjacent scenery that could be damaged, but the smaller loco would quickly melt (if not ignite) if its wheel shorted 10 amps while running against a switch.

    5A driver components may be a little more expensive than 3A ones, and they may also need more/better thermal augmentation (heatsinks, fans, etc.)

    As for command stations, generally speaking, it is easier and more reliable/resilient to delegate separate, loosely-coupled, time-critical functions to separate processors/cores, than to execute them together on one processor/core.

    But a lot depends on how much the processor itself has to do to manage the track DCC waveform (the most time-critical function.) Bit-banging it from software is possible, but is also very demanding of the CPU, and intolerant of interruptions to handle other tasks. If IO hardware can be programmed to manage the waveform autonomously, using timed DMA, etc., then that frees up the processor to handle other tasks (reading throttle interfaces, decoder programming or RailCom current feedback, etc.) Not incidentally, LCC can be controlled by a USB peripheral LCC node that is responsible for relaying message traffic between command station and the LCC bus nodes, rather than managing it directly via CAN bus transceivers from a processor already responsible for juggling many other tasks.

    The LCC bus nodes themselves are designed to autonomously handle their IO, and use the LCC bus to communicate/coordinate with other nodes. Thus, LCC sensor nodes can inform LCC signal nodes, switch-control nodes, etc. to manage train traffic, without the aid of a master, all-knowing central processor. At the same time, LCC-WiFi throttle nodes can inform processors in command stations controlling the DCC waveform, to alter the speed of the loco, sound the horn, flash the lights, etc.

    So the short answer is, dedicated processor/cores for unique tasks are a more functionally effective solution, but perhaps more expensive in recurring costs (hardware). That latter constraint can be the impetus for deploying more expense towards the effort to integrate multiple tasks on fewer processors.
     
  4. BigJake

    BigJake TrainBoard Member

    3,259
    6,173
    70
    Sumner,

    You asked "I wonder what percentage of home modelers use or will use RailCom ..."

    I have to wonder how many model railroaders have asked the same question, but regarding DCC itself? "DC does all I need!"

    I'm not privy to the market data from ESU, Zimo, and now TCS DCC systems, but it's almost certainly more users than for DCC-EX... as if that were a reliable indication of the relative merits of any of the systems. But it does indicate relatively how many users use RailCom.

    RailCom is not supported by NCE or Digitrax, the dominant US DCC system suppliers for decades. Therefore, many established US DCC users cannot and have not used RailCom. SPROG does not support it either. Therefore, in the US, Railcom is very likely not used as much as in Europe or the rest of the world.

    RailCom allows knowing not just IF a block is occupied, but by which locomotive(s) or decoder-equipped railcar(s). It also allows safely programming decoders, with readback confirmation, on the mainline, while other trains are present and even running. Reading back a decoder's programming is MUCH faster with Railcom than on the programming track, and the locomotive does not have to move (nor does it have to be still.)

    LCC is a relatively new NMRA standard that is similar in purpose to Loconet. It is based on CAN bus over CAT-5 modular cables, with intelligent nodes for performing functions and relaying commands and/or status to other nodes. CAN bus brings superior reliability to the implementation. Nodes can send and react to messages to/from other nodes to accomplish complex tasks, without having to involve the command station if desired. An occupancy detector node can send a message to other nodes to operate signals, throw switches, etc. Some available nodes can perform both occupancy detection and signal control. RR-Circuits (who has offered Loconet-based occupancy detection, signal and switch controlling systems for years) offers LCC-USB bridges, bus terminators, as well as occupancy detection, signal excitation, and switch-throwing LCC nodes, etc.

    The LCC protocol also operates over Ethernet/WiFi, as used for connecting throttles to LCC-equipped command stations, stations to boosters, etc.
     
    Sumner likes this.
  5. Sumner

    Sumner TrainBoard Member

    2,798
    5,840
    63
    I've pretty much switched to ESU for my decoders and they all have RailCom so I have it now in 'some' locos but don't see myself using it. One, I can't since I don't have a RailCom capable command station and don't see myself buying one. Two, all my locos that have been switched to DCC don't have RailCom decoders in them and won't have. The majority of my locos are older pre-drop-in decoder ones so I'm using hard wired decoders in them, mostly ESU until I use up my hard-wired Digitrax decoders. The locos that will take a drop-in have been getting mostly Digitrax and TCS decoders when available. Not sure if there are ESU drop-ins available or not for these locos so will probably continue to use Digitrax and TCS.

    I can understand some users being drawn to RailCom but would think that is probably a pretty small user base. Still a number of things that start with a small user base grow to a much larger user base as it becomes more widely available. I saw that with computers. I started a computer store in '84 and by the time I sold it in '90 computer sales had exploded, prices had come down and hardware/software had become much more capable and user friendly (although far from what we have now).

    Since I'll have a mix of RailCom and non-RailCom decoders if I want block occupancy detection down the road I'll stick with something not as glamours but more practical for my layout since if have a mix of decoders. In Regards to DCC-EX it has those capabilities now. I hope they don't feel the need to put much in the way of resources or needing more significant processors/hardware to pursue RailCom. I think Arduino's are going to be here for quite a while yet and hope they make whatever they do backwards compatible to running on an Arduino Mega. One might have to give up some advanced feature if they wanted to run an Arduino but it would run in some basic way.

    There was a good discussion on here a ways back about DCC-EX and the possibility of it becoming RailCom friendly (most of it over my head)...

    https://www.trainboard.com/highball/index.php?threads/dcc-update-project-2020.130071/page-19

    Sumner
     
  6. jngeddes

    jngeddes TrainBoard Member

    13
    6
    2
    Re Railcom - Because of the limitations noted by Sumner, I have never paid a lot of attention to Railcom. Like Sumner the majority of my decoders are ESU but not all. As noted by FlightRisk some time ago, two way communication over the rails seems like an approach that would be limited for a whole variety of reasons. Blunami has shown us the power of wireless communication to locos.

    Re LCC - again a development that I have never fully understood. I see the advantage of a standard network replacement to Loconet. But the concept of super-intelligent nodes seems like over kill. Isn't it better to keep intelligence in software and on a standard computing platform like the Arduino than in specialized custom hardware. After all, what we are doing is not rocket science -- controlling a few turnouts, signals, maybe some animations, etc. It seems to me that a high-speed, robust network (ideally wireless) connected with a centralized intelligence (controller or CS or whatever) with super cheap (at least as low-cost as possible) remote distributed actuators and detectors is what we need. I know my comments will trigger the LCC folks but even after all these years since its introduction, I still don't understand the benefits. Bottom line I don't see the advantage of intelligent nodes on a model layout - just cost and complication. I remain open to be enlightened.

    John
    Vancouver
     
    Sumner likes this.
  7. Sumner

    Sumner TrainBoard Member

    2,798
    5,840
    63
    We do have to remember that for tons of people in the industry like or don't like what they are doing but are driven by making a profit/living off what they design and produce. I put up lots of 3D print designs that I share but don't need to make a living off of. Most, maybe all, of the folks working on DCC-EX are in the same boat. Lots of modelers contribute one way or another but also aren't driven by the 'need to make a profit'.

    Thank goodness there are others that do make a living off of model railroading and do design and produce products. I've used a lot of them and we need these people to stay in business. Developing proprietary software/hardware helps them to corner some segment of the market that they can make a living off of and keep supplying product to those of us that don't want to design and build items. Apple figured this out a long time ago. They don't need everyone, just a large group of people that will buy their product and are loyal to it. I built and sold Microsoft based computers and you had a choice and still do of buying from a number of different manufactures that run the same software. They all have to compete with each other for market share. To some extent Apple doesn't. You want an Apple you buy one, you don't have the option of an Apple clone.

    Just rattling on here so no real point. Time to get back to the layout and lay track...........

    Sumner
     
    NotchHill likes this.
  8. BigJake

    BigJake TrainBoard Member

    3,259
    6,173
    70
    ESU command stations use Railcom to pre-load the throttles with locomotives that are actually on the track. Put a new loco on, it pops up as a choice on your throttle. Take a loco off, it disappears from your throttle. While ESU does not have the variety of drop-in decoders that others collectively have, they are adding more as we speak. And both ESU and Zimo have tiny decoders that can fit most anywhere, for more custom installations. I'm really surprised more locos are not sold with light boards featuring shorting plugs that can be replaced by standard format, miniature plug-in decoders, sound or not. Of course installing a speaker is almost* always a custom venture, often requiring frame modification in N scale.

    I agree that track rails are not the best electrical media by which to communicate with and control locomotives or accessories on the track. But they remain the primary, widely supported medium by a huge margin. At what point do we accept it as good enough?

    Blunami, using Bluetooth, is very new, but also somewhat promising. It does NOT yet support N scale. Note that Bluetooth cannot transfer enough power to run a locomotive at any scale, so the rails must still be used to distribute power to the locomotives. So, if you have reversing loops, etc. you still need hardware to manage them. HO and larger scale locos could incorporate batteries, but smaller scales like N and Z are much farther off. Until that happens, exactly what is the advantage of Blunami?

    Like any new train control technology, a lot depends on how well Blunami can penetrate the markets for HO and N (the two largest markets by far) with agreements from locomotive makers, as well as figuring out how to integrate with other existing railside solutions. Can Blunami integrate with whatever is controlling a switch? It will take time to overcome market inertia with existing technologies. And by the time that happens, will even better technology have overcome Blunami? Are they willing to license the wireless technology to better decoder manufacturers? Standards help everyone get on the same page, but are slower to adopt new technologies.

    (*) I just purchased an Atlas loco that is "sound ready" for a decoder, and even includes the speaker.
     

Share This Page