This is all true, but we're talking about a transport bus here (mainly) and even if we talk about CAN, we're talking about established technologies. I don't expect Model Railroad companies to Innovate in this arena. They aren't properly equipped to do so. Let the Telecom companies do that. What should happen is a coms standard should be chosen such that there is enough bandwidth and ability to support a wide variety of features currently not thought of. On the other end, a good API should be developed as a standard so that companies have a common interface to innovate too. Such an API could hide these competing CV uses to the user. It also allows more innovation by allowing Software programmers a standard interface and a large bandwidth so they can write universal software.
I actually disagree with this...sort of. first of all Talking about a collision domain is absolutely not relevant. You can't buy an ethernet hub today at any price. They are all switches and that means no competing collision domains. You're also misusing the concepts of VLANs and Subnets in this discussion. Neither of those is used to isolate collision domains. At the consumer/Prosumer level, You can purchase unmanaged switches up to the 48+2 variety for under $100. These would be 10/100 ports Probably over subscribed, but given the amount of bandwidth we're talking about for todays products, more than enough. The average home gateway already support 10/100/1000 interfaces routing and NAT. It would be absolutely simple to Isolate networks using basic of the shelf consumer components. A large club might be able to justify a more robust set of equipment from Cisco, Or one of the L3 SOHO managed switches, but only the largest layouts could even begin to justify such an expense. Yes, you would need to buy equipment much larger than you would typically as few people buy 48 port switches for home use, but they are available in stores nationwide at consumer prices. You mention Subnets. I can't even imagine why a home layout would need to worry about it. Simply assign the well known private Class B 192.168.0.0/16 And let me know when you have more than 65000 devices and need to start expanding. The one problem you would have is that current consumer WiFi access points have a relatively limited number of allowed devices on their network. This is somewhat of an artificial limit and probably could be overcome simply, but current device manufacturers don't have the incentive. This would be an excellent example of a place 3rd parties or hobbiests could add innovation. Devices like Linksys's gateways with the embedded linux have been development platforms for some time.
I think you are wrong on three levels: 1. We run over an effective 19.2k serial bus today (Digitrax LocoNet). 10Mbps ethernet is so much faster, and the reality is 100M and Gigabit are within reach of the home consumer, and 10GE is within reach of the large club. If one broadcast and collision domain are not a problem at 19.2k, they won't be a problem much, much faster. 2. We know how to solve the problem with ethernet. The 4x8 guy can use a 16 port Netgear 10/100 thing for $40 at the local best buy. The club that needs 10,000 decoders (again, thinking what the future may hold) can buy Cisco 6513's and load them up. Ethernet networks today are already several of orders of magnitude more devices than the current busses, I've seen ethernet networks with 4096 devices on them operate happily in a single subnet. That's more than the current standard can even address period; and I know we can go larger. 3. We can design around the problem, right now. For instance, rather than using broadcast, we can use multicast, one well known group for transponders, one for boosters, one for throttles, and greatly reduce the traffic. Heck, we could even move it all to a pure unicast model and let the central server handle it, a few thousand connections is nothing for low end hardware today, much less in the future. The devices that serve up the web page your reading this on move terabits or even petabits every day, the tech is there to scale orders of magnitude more than what your railroad needs. Similar properties apply to the wireless issues. 802.11b/g too congested in your neighborhood, buy 802.11n gear running in 5Ghz. Use IP over Bluetooth if you want. The point is, if we move to IP, and an Ethernet handoff there are off the shelf parts to do the conversion. I don't have to wait for Digitrax to release a new proprietary radio every 10 years, I can buy the next wireless standard in 3. I can even buy WiFi gear that operates in Licensed spectrum if I want, and get a license! Today if I get interference with my Digitrax throttle (not to pick on them, everyone has this problem) I have no choice. In an ethernet model I can go buy a new iPod touch and a new 802.11n access point and move to 5Ghz. I have a choice. I will get more in the future as well, as folks have other reasons to extend ethernet besides model railroading.
Well, I don't think a club is going to be affording 6513s any time soon. I'm not aware of any club of any size that has $100,000 to drop on netowrking up a layout. I could see a bigger club dropping the money for a Cat4500 with SupeIVs though. 10/100 or 10/100/1000 ports. Could all be Cisco Certified remanufactured/used. But really, I can't imagine any scenario where that kind of backplane would be needed for a model railroad. More likely we'd see large club layouts broken out into "Districts" or zones and 48-96 port unmanged switches would control those areas with a single uplink to the Central "Dispatch" unit. You are correct though, and I've said it. IP and Ethernet are the way to go. With multiple options for the phy. Multicast would be nice, but it's kind of a one way concept which I'm not sure would be helpful in all situations. I mean, this is the way the rest of the world works. Unless its a completely self contained system that is non-expandable such as the network in a Car, people use IP and Ethernet. Heck, even the Government and military are looking at moving to Packetized IP networks.
Point 1 - it is not the transfer speed that is the issue, but more the amount of messages being passed. While the speed is one part of it, line speed is not always line speed. That is negotiated between the source and the destination. The actual transfer rate is still controlled by other mechanisms. Point 2 - Show me where you can buy a 4096 port device that is dirt cheap....... My point with in tegration with the home network is that if there is heavy duty traffic caused by the computer streaming vidoe online and such, that without isolation this would affect the overall speed of the train side of the network. One thing in general you miss is not the speed of the connection but the QOS capabilities of the device and what the backplane bandwidth is.
Again, Isolation is as simple as adding a second Linksys or DLink home gateway effectively isolating your model railroad network from your home network while maintaining interconnectivity. If model railroad networks get to the point where we need 4096 ports 10/100 non-blocking... Well, I'll tell you this, no CAN network is going to handle that I don't care how efficient your MAC and Network and Transport layers are.. I could also see combo devices. Block detection/signal/switch mechanisms that would wire up an entire siding with signalling for mains and siding.
Actually, you have that choice right now. Using JMRI you can run your trains on a Digitrax(or NCE or several others) using an iPod.
Which requires additional complexity since you now have to interface with JMRI. Whereas if the whole thing were Ethernet from the get go, you would not have that issue.
I guess I'm missing something here.... Why exactly do we need NMRANet? If you use Digitrax loconet, using a DCS100 which allows for 120 locomotives, 120 throttles and 999 switch address and you were actually running every locomotive possible, using every throttle possible and stationary decoders to throw 999 turnouts, you'd only be using about 30% of the capacity of loconet. In Louisville, there was something like 106 locomotives runnning on that layout at the same time. There was NO lag or even issues with loconet (once the LNRPs were properly powered). So why the push for NMRANet? I know of no manufacturer's on board with it. I've asked and noone can tell me one that is. Don't get me wrong, I'm for progress in the hobby and in DCC. The NMRA had the DCC working group for years and everything I've read and have heard is that they were ineffective in getting anything done. That group has been dissolved and this new group started to push NMRANet. As an N Scaler, I find the NMRA useless. Some of there standards and RPs for still from the 60's. I think the Rapido is still the standard for couplers per the NMRA. It was the manufacturer's that started producing knuckle couplers. Unless the manufacturer's get on board this isn't going to happen. Rich
999 switches? what about block detection? Signalling? Defect Detectors? Surround and Ambient sound? On the fly Audio changes. Video feeds? Realsitic ABS/CTC and Dispatching? Standardized network interface so the home user can go out and buy a little project system with Ethernet on board and make his own widget to put on the system? How about interopability of the network. What if I think Digitrax sucks, but I want the capabilities of a Loconet? Or I like Loconet, but think Digitrax throttles suck and want NCE? What about a standard API so Software programs can work on any system and be advanced. Like complex dispatching and automated train control?
Loconet can handle all of what you're saying. Loconet is available for for licensing so someone can make their own widget. Team Digital and Logic Rail and examples. With that said, someone making their own widget is pie in the sky stuff. It just doesn't happen. You can use the Digitrax BDL-168 and SE8C for signalling with NCE, EasyDCC and Lenz. Its simply a matter of making the BDL-168 a master device and it will generate its own messages back to a computer running Winlok, R.R.& Co., or JMRI This is something I'd like to see. Have you looked at any of the third party software? Its already here. I would guess that very few people ever get around to actually installing signalling. Not because of the DCC system because the signals are so expensive. Like I said, unless the manufacturer's get on board (I highly doubt) we all can keep dreaming. You can waste bandwidth until your blue in the face but its not going to change anything. With or without NMRANet. I'm just being practical here. Bottom line is that the NMRA has been ineffective in the past and will continue to be the same way in the future. Rich
In addition to whatRich said, consider the majority of hobbiests who are not IP net savvy (i.e., virtually all of therm). I'm an EE, and have been in telecom systems for 40 years, but I got out of school in the era when computers and communications were totally separate disciplines. I can follow bit and byte level stuff and command parsing as described in LocoNet PE (and actually like to muck around in it a bit), but when you start getting into IP nets and subnets and the like (all stuff that the folks at work live and breathe), I get brain-fogged by the abstraction of it all. Considering that this is to run trains (and even steam engines (!) at that), maybe what is "possible" is overkill and overly complex for the audience. Heck most folks don't use 10% of the capabilities of their cell phones, and the 3GPP folks are working on LTE/4th gen standards! I don't think model railroaders are the early adopters the mobile users are. Heck, I used to be able to tune my own car up and balance the carbs. Now they don't even HAVE carbs, and it takes a computer readout to troubleshoot anything! The idea of a standardized throttle bus is intellectually appealing, but I don't see a real need for it at this point. Step back and take a breath.
The reason I think IP networking is a better choice is, because I think that yes, any of these concepts are hard for those not technically savvy. DCC, in particular, is hard to the point of irritation. See BarstowRick's thread of a few weeks ago. DCC is unacceptably complex. IP networking may be complex, but every single person that has a computer with a high speed network uses it and anyone who wants more than 1 computer on that network is forced to learn the rudimentary functionality of it. That means that the group of people who must become at least familar on the most basic level with IP networking is a much larger set than the people who are model railroaders and the people therefore that would be compelled to understand DCC. I'm an Electical Engineer. I work in System engineering and System Test. Whenever I'm forced to think about the DCC standard I want to throttle somebody. Hey, lets take a bunch of people who Understand basic DC and Artistry of model building and force them to now also learn all the ins and outs of industrial electronics. And then we'll call it easier. The very notion of esoteric concepts like CVs being the only way for a consumer Hobbiest to set up what is a consumer product is just really poor design. No engineer from a consumer products background would think that's ok. Also, LTE would be 5g or maybe 4.5g since WiMAx/4g already exists. And in fact you are wrong, the 3g network is being taxed. Streaming Video and audio. The 3g network is just already at it's limit. If iPhones and Droid phones continue to become the norm, 3g will go from just low bandwidth to complete saturation really fast. Also, if you don't think that tapping into the high availability of cheap, network aware projject devices won't spur more hobbiest innovation then.... If IP networking was the transport layer and the protocol was a standard, then you wouldn't need to buy soom extra part from Digitrax or any other company. You would just buy your little project board with it's network port, pick up the protocol stack as software and design away. The point is to not have to buy little specialty transition boards and PC interface cards..All of that type of stuff is just BS to gouge people for money. That is why a proprietary network standard sucks.
YoHo, Well I too am an EE who designs sattelite and secure airborne communications equipment and am similarly frustrated with many of the aspects of DCC. One of the reasons I started this thread. But I will point out that BartowRicks problem was not DCC itself, but the lack of quality documentation and the low quality system he was using. He was looking fo a flowchart that doesn't really exist, but an illustration of the CVs by number and function, and settings from an actual programmed decoder cleared up all of his confusion. So in his case, and possibly others, DCC is not the problem, it is the lack of quality documentation or quality components that make it difficult. Your drive to make DCC WiFi and IP based is laudable, but it is also overkill. The use of simple phone cords with RJ11 jacks or RJ45 jacks and cable is more than adequate as the physical connection without out having to be Ethernet, if the protocol is more of a state command system instead of a constant refresh system. I support a unified interface standard so I can use a Digitrax throttle in a non-Digitrax layout. But more to the point, I am less woried about the physical connections than I am about the system architecture. And for the record, the 19.2K DCC rate is not a limitation of the physical bandwidth the cable, it is the just how the adopters of DCC implemented it. It is a bizzar frequency at that too given the possible bandwidth of inexpensive cable. But if a simple packet exchange protocol was in use instead of the constant refresh, you would not need any more bandwidth than is currently being used. In any event, it is clear that there were no true communications engineers were involed when the NMRA did their thing. My issues are that DCC is not an open or scalable architecture. There shouold be no limits to the number of locomotives or the number of stationary or accesory decoders, and why is ther no intellegence built into boosters such that they can act as a distributed command station, that ould in effect, make them slave command stations , but instead of just supplying power for a power district and re-broacasting the DCC traffic, they could actually control every aspect of DCC withing that power district essentially turning into a Controller District. This way, as a user needed more control for larger or more complicated layouts, having the localized control processor in the boosters allows limits to the overall traffic on the whole layout, and if a segmentation architecture is included, then there is no more limit on turnouts counts or locomotive slots to worry about. And then there is the point of having a consistent user interface, and that is easily done by embedding something like JMRI DecoderPro into the DCC controllers.
For a number of reasons, but they are all in the future. We were at 106/120 locomotives at a show, which is effectively full. There will be larger shows in the future. Also note this is with the huge inconvenience of everyone having to reprogram the locomotives they bring to the show (to their badge number), and making all of their locomotives the same number totally rendering some of DCC's best features (like independent control) useless. If we had a large enough number space (say, 64 bits) you could have each participant register with the NMRA and get a 32 bit "modeler" identifier, and then have 32 bits for locomotive. There would be no conflicts and no reprogramming, and you could support many more locomotives. Also with transponding, it opens up things like "show me all locomotives belonging to modeler 12345". Consider that when DCC came out, the idea of Z scale locomotives with decoders in them was a bit of a pipe dream. Perhaps it could have been done, but not mass market, and not affordably. As time passed, Z scale decoders are now no big deal. Now, apply a similar view towards the future. I can see in 20 years time N scale locomotives coming factory equipped with a small video camera inside the cab. DCC controlled pan/tilt/zoom, and 1080P video being streamed back out of it wirelessly. LocoNet, and even CANBus can't do that. An Ethernet/IP model will have no trouble doing that in 20 years, at cheap consumer prices; most importantly using gear that hasn't been invented yet. 100Gbps 802.11z will be standard in every home by then! My position is not that anything is broken today, indeed for the average home hobbiest DCC is fine as it is, today. My issue is that the largest applications (e.g. Louisville) have pushed it to its limit. It's time for a new spec. Realistically it will take 2-3 years to get a spec defined in the NMRA, and another 2-3 years after that to see the first real products. So we're taking about something you might be able to buy 5 years from now, and a spec that then might live on for another 20-30 years (or longer) after that. Let me leave you with this thought. My understanding is DCC as we know and love it now was standardized by the NMRA around 1993-1994 and had been "in the works" for several years before that. So let's say the idea behind this was hatched around 1990. Here's 1990's tech: http://www.youtube.com/watch?v=694TX2lQ7Uo That standard has survived into today, an era when a cell phone looks like this: Apple - iPhone 4 - Video calls, multitasking, HD video, and more I can only imagine if someone had told the designer of that 1990's cell phone that in 20 short years his cell phone would move data at the speed the backbone networks of the day were using (T1's at 1.5Mbps built the backbones in 1990, DS-3 was new to data), and you would have 2-way video chat and battery life that could reach week on standby all in a device that fit in your shirt pocket and worked worldwide he would have likely laughed at you. But yet, that is what new standards and protocols are all about, not what we need today, but what they will look like when deployed in 10 years, and when ubiquitous in 20 years, and ready for replacement in 30.
I wouldn't say it's bizarre at all; 19.2k is a standard comms frequency (it's 2x 9600) and we used it a lot with our PLC (low end industrial controllers) at about the time DCC was being developed . Actually, 19200 was sometimes glitchy on RS232 or 485 and more than once we got better performance by dropping the speed to 9600 ... which I think is not far off what the DCC track bus runs at ... fancy that Going back to the IP/ethernet/collisions business, I can well understand that ethernet switches will handle collisions on a wired network of many devices, since each cable is effectively its own little world. But once you go wifi (or bluetooth) all your packets have to travel in the same 'virtual cable', and often along with the neighbours streaming video too. It's going to be tough to sort that out. Just to throw another log in the fire ... how about the industrial wireless stuff that runs under (on top of?) the various fieldbus protocols. It's been a few years since I was 'there' but those systems are designed to control and monitor things like refineries (and maybe certain drilling rigs :embarassed: ) so should be better oriented to running trains than TCP/IP/ethernet. Just a thought.
You know I forgot all about those old modems. And it is sad too because they already had 10BaseT Ethernet at that time too. So the NMRA chose a Modem technology over a netwrok technology. I guess they never realized that hooking up all these devices constituted a network.:thumbs_down: Again, the lack of communications expertise was the biggest mistake then, and it looks like they are going to repeat that mistake now.:mnerd: The NMRA need to step out of DCC, but I am not sure where the responsibility goes. But it is for sure folks worried about wheel profiles and track gauges are ill prepared to oversee DCC.
This is essentially a MAC address now. Unique to each device (well, unique enough). If it were me, and it was an ethernet network implemented, I would utilize the well known existing SNMP net work management protocol to set Locomotive name, Loco owner, and all other relevant info like CVs. It would be easy to write a gui to that interface. Perhaps a generic API would be better, but SNMP has the concepts of taking a MAC address and applying meta data to it. One of my club mates has a wireless NTSC camera mounted on a flat car. The camera was originally for a model airplane. It wirelessly transmits to a base unit plugged into a TV. It is by far the coolest thing ever and on open house days, it is the number 1 draw. There is another modeler in the greater Portland area who has a similar camera mounted in the nose of a dummy PA. He has it set up so you control the consist and run the train from in front of the TV so you literally are the engineer. How cool is that? Now imagine a network capable of supporting multiple instances of that. Yes Oh no doubt, and It may be that it still has it's place. Your collisions in the WiFi space have more to do with signal interference though than network congestion and it's an issue that is a problem for the entire networking world...which is good, that means it will be addressed without the NMRA having to think about it. And it is addressed to an extent by N and it will continue to be refined. It may be that the largest clubs will need to more robust WiFi implementations. Or it may be that wired DCC will remain for big installations. Ideally a DCC decoder would have options for both. And way more expensive. In the consumer world you trade robustness for cost and ease of use. Something DCC's spec doesn't understand. Yes to this and your comment about. No telecom engineer, even back in the early 90s was involved with this.
The people who developed the DCC specs do fully understand this, and that was one of the driving forces behind many of their decisions. Adding wifi and ethernet will increase costs and complexities.
No, the NMRA chose neither and left it up to the manufacturers. Loconet, which seems to be the one discussed the most and was developed by Digitrax, does run at modem speeds(it actually runs at 16.66 kilobaud, not 19.2) but it is still a network technology.
