First layout - struggling with control system choice

I have an MRC 500N, an MRC Loco-Motion 1500, and an MRC Loco-Motion 2500.

Whaddya think of that?



Doug

 

Doug wins. Now who is in charge of the victory cookies?

 

I'll take an original version (the one with the long motor) Con-Cor PA, instead of a cookie, just because I never bought one (I have the second iteration) and I'd like to mess with one to see how they run (good reviews in MR in 1967), etc.



Doug

 

Examples of Some “Truth”? (or “Miss-information”?)

That would depend on what you consider “adequate”. I am getting more than 60 feet and there are videos showing the commercial-Bluetooth-system operating at ~150 feet. And these are just the first-generation systems. When correctly designed Bluetooth-stationary-decoders become available the range will be sufficient for even the largest layouts, because they will relay the Bluetooth-control-signals. I already have the inexpensive commercial Bluetooth-sub-boards that have this relay capability.

The NMRA DCC systems continually send the current mobile-control-commands to the track. That is why the Lenz appears to be correctly decoding data while it is “over paper on the track”. Correctly designed Bluetooth gets a response back, so there is no need for this bandwidth eating repetition.
If sending signals through the track was not problematic, there would not be all the knowledgeable information about how to correctly do DCC-track-wiring, and separate programming-tracks would not be needed or used.

This is all so “bad” that I can reload and verify all the control-variables with Bluetooth before DCC can change and verify one control-variable.

There are "79 channels (each 1 MHz wide) and changes channels, generally 1600 times per second" (as in ~79 simultaneous video streams), so for low-bandwidth requirement like train-control, there is effectively an unlimited number.
Except for an extremely-dumb-implementation-or-use, it is impossible for a user to notice the “latencies” you attribute to Bluetooth.

Don’t panic, DCC will be around for a long time yet (as is DC today), the hobbyists move to new technology very slowly.
Bob

 

As stated earlier, DCC does not need the larger bandwidth provided by Wi-Fi and bluetooth.

However it DOES need the low latency and guaranteed delivery of commands NOT provided by Wi-Fi and Bluetooth. Wireless signals have to cooperate with other wireless systems within range, this is WHY there are multiple channels and more importantly, why the wireless protocols have to have sophisticated command collision avoidance systems.

Also wireless is inherently more lossy, so typically about half of the data packet sent is error correction (again our bandwidth requirements are so low it does not affect performance)

One good point that was made is that DCC is not an acknowledged protocol, and that is a nice thing to have, it can improve efficiency (which we don't need because we have enough bandwidth) and reliability, and reliability is an important issue, and one that an acknowledged protocol can excel with. Please note that not all wireless systems are instantly using an acknowledged protocol. Oh, the acknowledgement takes time, no problem in the low latency DCC on rails, but it does impact performance on a wireless system. This also means your throttle needs to hear the loco very well too.

Nothing is "free" in physics and electronics, there are all tradeoffs.

Saying something is long in the tooth might also be an endorsement of a system that works well and needs no fundamental changing.

Greg

 

I've seen more than one reference to "latency". Both radio waves and electrical signals over wire travel close enough to the speed of light to not even be worth considering in this application. As for "command collision avoidance systems", they also both use pretty much the same approach - inspect the header of all packets, discarding those that are not relevant. Neither has the luxury of a private line between end points.

Honestly I'm not all that excited about the fact systems like RailPro are wireless. If DCC could implement the same feature set and just as effortlessly, we wouldn't even be having this conversation. Take for example the consisting and load sharing feature demonstrated in this video (skip forward to the 4:28 mark to see them demonstrate consisting and then load sharing):



I don't see how anyone could argue that the RailPro implementation of consisting isn't a noteworthy improvement. That kind of dynamic load sharing simply cannot be accomplished with DCC. What makes it possible is the two-way communication between locos. So, yeah, DCC works fine for what it does, but it could most certainly use some "fundamental change".

 

I don't know where you are in the hobby but I have found over the years what I thought I would be doing electronically, basic simple DCC has expanded to looking at signal systems, auto throw auto reversing systems so that reversing loop to loop can be continuous run, and adding form of animation. This has been said to ten of thousands of newbies, you don't want to be the only guy on the block with your system. No matter what you get, at some point you will have problems that are solvable but not by you. Its nice to have an understanding and experienced shoulder to cry on.

Electronic systems aren't going to evolve, and they haven't, as quickly as those electronic goodies outside the hobby. And guys don't really want them to evolve to quickly as they have a lot of money, labour and education tied up with the system they have. I moved kicking and screeming from XP to Windows 10. I could have just as happily remained an XP guy but I knew the times, they are a changing.

You may not have been around in the early days of DCC but I can tell you there were DCC/analog wars where the analog guys swore you couldn't pry their analog controllers from their hand. Guess what, everyone I personally know have moved on to DCC. But I can tell you from lots of experience, many a thread was locked over these territorial disputes. What I am gently saying is don't count on DCC going away any time soon.

 

It's not the sprog that has more features. It's JMRI and add ons that adds T features and the platform to roll your own. Heck all the major systems in the US at least Digitrax, MRC and NCE offer PC interface support which allows integration of jmri. JMRI based wireless actually uses wifi as the transmission medium. In fact until you mentioned them, I'd not heard of z21. Everyone I know or talk ti uses JMRI for nor advanced control and programming.

 

RC Junction, you need to understand latency, and it's not about the speed of light.

It's the time taken to guarantee the delivery of a packet of information.

With DCC on the rails, there is only one master transmitting, it transmits when it wants, and it transmits when it wants.

With the wireless protocols WiFi and Bluetooth you CANNOT transmit whenever you want, you normally need to listen first to see if it is OK to transmit, because the "rights" to transmit are SHARED among everyone.

This is the difference between CSMA systems and token based systems in computer networking.

You really need to read up on how this stuff works before you start quoting the speed of light.

Google latency on the internet and I'm sure if you have a open mind, you can learn and understand this.

Now, how much a factor this is (meaning wireless operation where you do have multiple transmitters sharing the bandwidth) in our operations has a lot to do with the number of devices on the network how often they transmit, and the response time required.

There's a whole list of things to be considered, but wireless systems are ALWAYS slower than wired systems in terms of latency, which we would see as response time, or loss of commands in a heavily loaded system.

There's plenty of ways to make things work, but coming on threads and saying that EVERYTHING about YOUR favorite technology is superior is just not true, and this holds for this situation, and pretty much the entire universe, there's pro's and con's to most everything that can be done multiple ways.

Greg

 

Greg,

It's definitely *NOT* my favorite technology, and I never even implied that "EVERYTHING about MY favorite technology is superior". I considered mentioning it in my previous reply, but you continue to use terms like "them/you" and "our/we". That creates a context of us vs. them or right vs. wrong, and it's not at all what this thread is about. I believe I mentioned some of my reservations with RailPro in the very first post in this thread.

My "favorite" technology would be a version of DCC (well established with a wide range of available parts and wealth of community support) that can offer the advanced features of some of the wireless systems coming out these days (robust two-way communication, no need for a command station, etc.). I may stand corrected on my understanding of latency, but even so I firmly believe the latency concern is all but inconsequential. Just taking RailPro as an example - only because that is the only wireless system I have researched to any degree - I have seen ZERO mention of latency issues. The fact is that every user I have encountered to a person has been thrilled with RailPro and had no regrets whatsoever. Take that for what it's worth. I do, as it's based on the subjective views of the owners, and people can sometimes be hesitant to second-guess their costly decisions in a public forum, feeling compelled to stay "all in" with their choice.

RC planes, cars, drones, heck even military/law enforcement recon robots all use wireless. That should be enough to convince anyone that any inherent latency in wireless communication is either inconsequential or a trivial matter with which to contend.

I can see how someone reading this thread might jump to the conclusion that I'm dead set on a wireless solution, but I'm not. Truth be told I'm leaning toward DCC at this point, chiefly because of the proprietary nature of current wireless systems and the breadth of equipment and resources available for DCC. What I *am* dead set on (at least for the moment) is leaving wireless on the table as an option and trying to not be influenced too much by activism. Whatever I choose will likely be my choice for a long time to come.

 

I read what you said, you basically disclaimed everything I stated.

BUT
You posted this: "I've seen more than one reference to "latency". Both radio waves and electrical signals over wire travel close enough to the speed of light to not even be worth considering in this application. As for "command collision avoidance systems", they also both use pretty much the same approach - inspect the header of all packets, discarding those that are not relevant. Neither has the luxury of a private line between end points.""

So, all I am reacting to is your post, quoted above. If you don't understand, then do not claim that all these systems, wired/wireless/unacknowledged/acknowledged are the same.

If you did understand you would not make such a claim.

So, where are we, do you accept there are differences, or do you want to stand by your comment above.

By the way if you don't want to believe me, Google is your friend, or talk to an RF Engineer that the familiar with wired and wireless protocols.

Bottom line opinions are fine, but when you state something as a fact, you better back it up. I'm reacting to somethings you states as facts which are, in my 35 years of experience as a real engineer, are FALSE.

Greg

 

Gotcha. So throttle + command station (Sprog) + USB interface (Sprog Nano + Booster) + PC, then? One thing I do like about the wireless systems is the fact that they communicate directly with the loco without need for a command station or PC interface. It's straightforward RC for trains. It sounds like JMRI (or something like it) would pretty much still be required for any advanced control and programming, regardless of the control system being used, though.

 

Sprog (Command station + Booster + USB interface) + Raspberry Pi 2 (Computer) + Wi-Fi USB dongle (Wireless) makes for a very low cost wireless DCC system that can run JMRI without the need for a router or another computer for less than £100 (not sure what that is in $ but knowing UK prices and taxes probably about the same!)

 

Sprog+laptop+booster if needed/wanted +droid/iphone/tablet+wi-throttle app (free download)= DCC System for $100

Sent from my SM-G920P using Tapatalk

 

Greg,
“guaranteed delivery of commands NOT provided by Wi-Fi and Bluetooth”? Not true, it depends on the implementation. Only very poorly implemented Bluetooth control-protocols do not provide an “acknowledge” in response to commands. It is actually DCC that does not provide for the “guaranteed delivery of commands”. That is way you can send (say) a DCC-front-light-on-command and the controller indicates no-error even though the locomotive does not respond. There is no “acknowledgement” for most DCC-commands. Also note that low-bandwidth-DCC-commands are much longer-in-time than high-bandwidth-Bluetooth-commands. (This DCC “latency”could even be greater than the typical Bluetooth RF “latency”). Also note that Bluetooth commands are inherently shorter. They do not need to send the locomotive-address with each command like DCC does.

“Also wireless is inherently more lossy,” than DCC? Maybe in near-perfect DCC implementations. Note all the talk about “stay-alive-capacitors” on the forums.
Bob

 

Stay alive capacitors are just there to provide power - they have nothing to do with the data stream getting through - that will still get through anyway on a decent decoder when there is very poor track to wheel contact (ref: driving a train over paper and it can still be controlled). Bluetooth and DCC will need auxilliary power to the same extent - both will stop when there is no power for the motor!

 

Perhaps you can provide a physical explanation of how a wire-delivered-signal travels through a piece of paper. Has it been somehow made conductive?

I suggest a stationary test for anyone skeptics, provide power through the connection for the “stay-alive-capacitors”, put this “paper-proof” locomotive on a DCC-track over no-conductive-paper, and provided it with a DCC commands switching the front light off/on. I am looking forward to seeing a video with test report of this.
Bob

 

I think we're getting a little off track here (no pun intended). The fact of the matter is that wireless control systems are available and entirely viable. Users of the RailPro (again, mentioned just because it's the only wireless system I've researched to any degree) have reported no more issues with latency or communications reliability than I've seen perusing the DCC forums, likely less. At least from where I'm standing, any issues seem to exist more within the various discussions of the technology than actual implementations. If anyone has actually tried any of the wireless systems and experienced any such problems, I would very much like to hear about it.

BlueRail is another product just getting off the ground and is used in Bachmann's new EZ-App control system. It's still very much in its infancy, though.

 

No test report, but there are videos on YouTube like this one:-



Paper is a sufficiently good conductor at DCC frequencies to get sufficient signal through for most modern European decoders, and the newer ones from TCS should perform quite well too. Try it for yourself - it is quite repeatable with the Lenz Gold and the auxiliary power module.