Yoho, Are you directly involved with NMRANet? Are any of the manufacturer's on board with NMRANet? What time is the meeting next Wednesday in Room 103 (I assume at the convention center)? Rich
Sorry, not involved, just a rabble rouser. At this point I have enough MR commitments that the most I could provide is the same thing I'm doing here. Opinion.
This reminds of a problem a friend had with his wifi network. He had it up and running fine and suddenly one day it just quit working. Changing channel settings on his router didn't help, but he could take his router and laptop to another location and they would work fine. He did finally get his problem solved(if I remember correctly it was traced to a defective wireless phone), but if he had a model railroad that relied on wifi to work, he would not have been able to run trains until the problem had been solved. I have had a similar situation at my office at work. We have had some Bluetooth transceivers that would not cause a problem when connected to another transceiver, but if one transceiver was shut down the other one would knock out the wifi in my office.
I think that with a bus speed of 125kb and maximum distance of 500 meters CAN would be well suited to model railroad accessories(the bus length can be extended at lower data rates and the bus speed can be increased with a shorter bus length).
125kbps. As Bill Gates Famously said, Who needs more than 640K of ram. 125kbps. How would that support surround sound features, or Video features?
Bluetooth class I devices have a range of 330ft(most people are only familiar with Class 2 devices, with a range of 30ft), plenty for most model railroads; however, there are other reasons that Bluetooth would not be an ideal choice. Bluetooth is designed as a one-to-one connection or one-to-few connection, not one-to-many or many-to-many. Most Bluetooth devices can only connect to one other device at a time, and the Bluetooth equivalent of an access point(such as a USB Bluetooth adapters that plug into a PC) can only connect to seven devices at a time.
I just don't see any reason why you would want to put video or sound on the control bus. Why have the added cost and complexities of a higher data rate bus when it is likely only a small percentage of users would ever use it to support video or sound and even the ones who did would only need it for a small percentage of devices. If you are going to support video and sound, do it with a seperate bus. Besides, most streaming "realtime" video I have seen has a slight delay to it, so if I was running a train and viewing video from it, I would rather it not be sent by TCP/IP. Ethernet is designed to move large amonuts of data between computers, not as a control bus. That doesn't mean it won't work as a control bus, but it is not ideal for it. As an example, TCP has a minimum header size of 20 bytes, which means a decoder would have to process more than 20 bytes just to receive a 2 byte speed and direction command. From a user stand point that wouldn't matter, but from a code development standpoint it certainly would. It would also be interesting to know what kind of latency you would have on an ethernet network with a few dozen throttles, a few dozen trains, and turnouts and signaling for a large home or club layout. If you select a file to transfer or a video to watch over a network, if you were to have a half second delay before that transfer begins it wouldn't even be noticed, but try smoothly coupling to a cut of cars with a half second delay from your throttle.
The ethernet network shouldn't introduce more than a handful of miliseconds delay. Also, You don't see audio and video being a big deal? surround sound combined with DCC audio has been something people have been talking about a lot on this very board. As for video, I've seen video from a moving train a couple times now. It is absolutely the most amazing thing. If that tech could be integrated into a single bus. So that the DCC/Sound controller could give location feedback to trigger sounds in speakers around the layout. That would be awesome. Sounds that would be on the fly based on the specific locomotives involved, the speed, perhaps number of axles. Imagine it triggering defect detectors with accurate axle counts. As for TCP, I use it, combined with IP as a catch all term that non-telcom people might understand. TCP would be a horrible protocol to use in this application. I would see something more like the VOIP protocols making more sense Small packets, fast, in order delivery. No need for the handshaking of TCP or the extended header sizes. And yeah, 2 byte packets, sure, but that is again, with the current crop of technologies and concepts, not any future concepts. Any time you start a technology comment with "I just don't see us ever needing that much...whatever" you should stop, remember that that sentiment is almost always proved wrong and then go on.
I have no opposition to additional standards that improve the system and are practical to implement. However, standards have a way of restricting innovation. Consider all the non-standard CV settings in a decoder. Sure it would be nice if you could read one manufacturers manual and know how to configure every manufacturers decoder, but that would prevent anybody from coming up with something new. The other issue is the practicality of the proposed standard. If it's not commercially viable to build hardware to the proposed standard right now, the standard may become obsolete before it's ever implemented. Consider the suggestion that decoders have a WiFi connection. While there may be WiFi circuits available on the market, there aren't any with the logic to interface motor control circuitry small enough to fit in any of my locomotives. I believe this is possible with the resources of a company like Intel or AMD. I don't think any of the existing DCC manufacturers have the capability of producing an integrated circuit containing both the decoder logic and a WiFi interface on a single piece of silicon at a price I can afford and if all the logic isn't on one IC the decoder size is going to grow and won't fit. By the time a manufacturer can produce a decoder with on-board WiFi will the WiFI standard still be the same? Remember there are at least four WiFI standards in common use today.
There are certainly Wifi devices that could interface with anything down to HO. N would be a challenge, but then, N is a challenge with Sound too, that doesn't stop sound from being a very relevent part of the DCC market. I realize I might make some enemies here, but I think if there is support for sizes down to HO, then that's enough to start looking at a viable market. N will come just as it came with DCC and now sound. This is the curse of N scale. Miniaturization is hard. It's always going to be easier to do this stuff with more space. And yes, 802.11 does have a/b/g/n But n is backwards compatible to g is backwards compatible to a&b. So that isn't even an issue. Most of the size of a current DCC decoder is nothing but circuit board in order to make room for solder pads. And as for standards stifling innovation...Bad standards stifle innovations. Standards that don't include the vendors and the consumers, stifle innovations. Certainly though well made standards that are designed to be easy for vendors to implement and users to deploy will work best. That's another reason I support ethernet. It is dead simple. Wifi can pose issues just interms of reception, but as I've said, I see wifi as a part of the system, not the focus. Ethernet in general though is simple to set up. Over the past decade it's become a part and parcel of many homes and it's the same concepts that will be a part of entertainment devices going forward. Taking a proven working system with broad support and adapting it to the application is the basis for some of the most popular specifications out there. See DOCSIS Cable modems, and then WiMAX 4g Wireless. These specs flow from the ethernet spec and the MPEG spec and then WiMax builds on DOCSIS, because DOCSIS is a world class spec.
You're kidding right? DCC has advanced into the 90's tech at a snail's pace lest you forget that "industry" was a joke before LocoNet. The fact that it is hard to program non-standard CV settings is because the command station is built to be stupid! Even better is the idea that a decoder is too stupid to be upgraded? Again the decoder wasn't designed with wifi or any other current protocol, it is not inherently harder or more expensive to design a cell phone pcb than a decoder. The standard is what allows the company to know what is needed on the board. Let's assume that someone somewhere will come out with a new design for decoder, even Z or T scale is not a problem with any new design, or do you think that the companies are all using the same design team for all decoders and will only make improvements if it fits on the original circuit board? With software it takes less than two hours to design the pcb traces, 90 sec to etch and 20 sec to solder components onto the board. The only issue is contracting parts and assembly at a scale that is viable. You want a cheap decoder for your current working system, push new protocols and that Digitrax123 will now sell for $1.50. AUTO CONFIGURATION is easy enough with feedback and a command program, how any commercial device can be plugged into a PC and it knows what it is and where to get the proper drivers (as with Windows there will always be issues when there is a changing of the guard). Get the software out of the decoder and back into the command system and voila you have a simple device that only has five to ten jobs, only needs to know how fast, what direction, which lights. There is no way to overload a WiFi hot spot (unless your train learns to watch youtube movies of itself) as the commands are sent confirmed and nothing else until there is a new command, unlike the current protocol that repeats the command even if the train is pulled off the layout. Believe me the current NMRAnet proposals are already obsolete but it is hard enough to get some modelers to even consider DCC over DC, a system first commercialized in 1890 and hasn't changed much since 1930 and there are still more dc layouts than dcc. Respectfully, thad
Last skunk touches on something that really is an advantage of Ethernet that I've kinda glossed over. With DNS and UPNP, programming as you now know it would be a thing of the past. Imagine a world where you pull a new loco out of the box. Put it on the track and within seconds it has a unique address on the network without your intervention. Suddenly, on the small screen of your throttle, or even better on your pc, you get a pop-up saying. There's a new loco on the layout, would you like to configure it? If it's factory equipped, the loco would provide all the relevent defaults. populate speed tables based on manufacturers defaults. Let you choose a unique name that would stay with it across layouts. etc. Adjusting the speed tables would be interactive. No isoteric CVs to program. If its a unit that has had the decoder added, there are a few more pieces of information you supply. Though still in an interactive manner. Loco make, model, features (ditchlights, sound) if it has sound, maybe you choose a sound library for it. If you have your tran net connected to the web some of this could even be downloaded right at the time of configuration. All of it would be interactive with plain english instructions and concepts. A common API and standard bus make this possible. Heck, if you wanted to get really crazy on the PC side, imagine playing yardmaster. building up a representation of the consist by dragging and dropping the locos into it including orientation. Add the car count (or axle count) and name the entire train. (ATSF 991 for example)
A modern solution... I have long advocated that DCC should move to using Ethernet as the transport. Chips to do ethernet are dirt cheap, and folks understand it. Yes, you would have to buy ethernet hubs/switches, but they are also dirt cheap these days. The advantage, of course, is everything could run over IP. Computer interface is just a matter of software, no hardware dongles needed. Command station hardware could be replaced with command station software, allowing for much more rapid innovation and in the long term cheaper costs. Wireless is already done, WiFi works and is understood. Integration with smart devices (e.g. iPod touch as a wireless throttle) is a simple software problem again, no hardware required. All accessories would speak ethernet for two way, reliable communication. The only custom component would be the booster to provide the rail interface. I can envision something that looks more like a set top box, with a power cable and a set of power pole connectors and an ethernet port in the back. That isn't to say I see anything wrong, per se, with the current system, but if you're going to design a new standard you have to think about what things will look like 20-30 years down the road. CAN bus is not it. This effort is being lead by a bunch of folks who are in old-school industrial design. There's a place for that, but I don't think it's where the hobby is going, just look at JMRI.
I'm not talking public - the problem is multiple home networks as there are effectively only three channels available that don't clash. Even in our neighbourhood, where we have medium/low density houses (for the UK) and an empty field on one side of us, we can 'see' 4 or 5 other networks. They can cause problems simply by transmitting on the same frequency. In this respect the long range of wifi (and the bluetooth Robert mentions) are actually a disadvantage. It would be better for a model railway to use a system that only has a range to cover the layout and in a frequency band where only short range devices are permitted to avoid clashes with others. Or else we'll all be cladding our rooms with tinfoil (Off topic I think long range bluetooth is mad. I have a normal bluetooth handsfree adapter in my van, but only use it on long journeys because it actually reaches about 50 foot. So when I get out and go somewhere nearby and the phone rings I can't answer it cos the mic/speaker are still in the van . Yes, I know I could disconnect it when I get out and reconnect when getting back, but that gets tiresome really fast. Anyone got a neat solution? )
This is exactly it, It's being driven by the old school. It's like a bunch of Old Steam Maintenance staff from 60 years ago Time Travelling to now and trying to design a modern diesel servicing facility. And yes, you totally are seeing the advantages I'm seeing. With the current crop of miniaturized PC foot prints, such as Intel Atom or VIA C7 and newer, creating a command station that is in effect a server becomes cheap and easy. And it would be very easy in such a scenario to be backwards compatible. The actual circuitry in the command station to send out signal on the wire is cheap. Instead of designing the smarts in hardware, Software driven by a self contained server operating on free linux with a web interface and Ethernet as the bus. This is your backwards compatibility.
But this is really going to be a problem with any wireless system. I can see over 10 wireless networks from my apartment. I'm sure some of them cause interference, but the signal strength is relatively low. If it becomes an issue, then yes, you will need to become more technically involved,but that would be true if you just had a home computer network as well. RF co-channel interference is a resolvable issue. Further, because this is a problem with WiFi in general and getting worse, Wifi companies are working on it. I would expect that year over year we will see new products that will mitigate this at consume prices. And I'd expect them to be backward compatible. And even if they weren't, decoders like mobile phones could include the SD interface so that the wireless component is upgradeable. This is also why I would like to see the accessory bus remain wired. It's also a good reason to keep the existing DCC signaling on the rails even though I hate it as an option. Or go to a more advanced signalling similar to Powerline ethernet. Again, off the shelf standards and technology that's already supporting a much higher data rate.
Long range Bluetooth doesn't make sense in most situations, but it is ideal for what we used it for at work. One of our products is data collection systems for race cars. By using Bluetooth to download the data to the PC(which is usually located in the team's trailer), they can start the download before the car even gets all the way back to the trailer. By the time they get the car parked and the driver gets out the download is usually done and they can start analyzing the data. In case anyone is wondering, yes, we looked at using wifi for the download but the programming overhead and more importantly the end user configuration was much easier using Bluetooth.
In a situation like that I would think Bluetooth made more sense as well. Now if you were getting data from multiple cars at the same time, or there were gigs worth of data. I'd say something different. Actually, if there gigs worth of data, it would probably be better to wait till the car was at the computer and use a wired connection. USB/Firewire/eSATA.
No I'm not kidding. Standards limit innovation. This is not necessarily a bad thing because what standards do is allow the market to stabilize and new technology to be adopted before the next innovation makes it obsolete. Innovation occurs when somebody figures out how to improve upon existing standards. With most technology an innovation occurs then a standard is established, then the innovations becomes widely available. The standard rarely precedes the innovation. VHS and Beta were innovations, Beta dropping out was the market choosing a standard not an innovation being made. And you totally mi-understood the point I was trying to make about non-standard CVs. They're not hard to program because of any fault of the command station design. In fact I don't find them hard to program at all. The problem I have with the non-standard CVs is remembering which one does what. It would be nice if the volume control on my Tsunamis was in the same CV as on the LokSounds. It would be nice if the motor control CVs (the BEMF CVs) were all configured the same. That would make them standard. But if making them standard meant losing the excellent motor control in the LokSounds, well no thanks I'll go with the innovation, it's not that hard to look the CVs up in the manual. As to decoders not being upgradable, current Lenz and ESU decoders already are. Again the innovation precedes the standard.
My desire to start this thread was to engauge discussion, and it has seen some good and some nopt so good. Leo, you bring up some very good points, but the Ethernet side of it is not as easy as you may think. Your dirt cheap hubs and switches may work for 4x8 layout, but as you integrate the home computers etc into the same mix, you have established a rather large broadcast and collision domain that the "Dirt Cheap" products will not be able to ovecome and the communications will be very slow and unreliable. For more complicated systems, higher end network equipment would be needed to isolate layout traffic and home network activity using subnets or VLANs. These features are not availble on the dirt cheap equipment. Where the problems beging is still up in the air, but if you have enough devices on the network talking, without the ability to isolate traffic patterens you will see delays in command execution. As an example, I have 6 BDL168's and 12 DS54/DS64 devices along with 33 Team Digital SIC24 devices for a 32 foot NTrack module set. So 51 devices chattering at the same time in a cheap hub/switch will not cut it. Where we do agree, is thinking outside the box about the long term future of DCC and the possibilities that are yet untapped. And it is here that I wanted to bring these ideas out because the same crew that was shortsighted in developing DCC, are only interested in putting on bandaids instead of admitting the weakness of the original specifications and taking the high road and fixing them. They should have never released a half-complete spec. This is why instead of Lenz and Digitrax using a common network, they have 2 seperate and incompatible networks. And yes NCE and other have thier own as well. This is part of the cluster#$%^ of DCC for the consumer, where we are almost forced to be tied to a single manufacturer. From the beginning, a physical network specication was needed for both wiring and bi-directional capabilites. An interface specification should have been specified for accessory devices so that you could easily plug a Lenz device into a NCE layout and have everything work seamlessly, without losing device capabilities. And on the mobile decoder front, why was there no provision for them to sqwak thier address so the occupancy detection could also identify the locomotive in the detected section? There should have been a specification for a standard message tree so that all stationary decoders talked the same language and similarly, for signal controllers and occupancy detectors. It is time the NMRA handed off this responsibility to another organization that is less concened with wires, wheel profiles and track gauges, and more concerned with implementing a scalable technology that can grow with time instead of being hamstrung by poor decisions and 40 year old design standards.
