DCC describes an interface for communicating with and controlling locomotives
The NMRA is proposing a similar standard, Layout Command Control (LCC), to control more than just locomotives. Like any communications protocol, this would allow devices from different venders to work with one another.
But neither of these addresses the interface to the human operator. Should there be a standard or adopt an existing (wireless/IP) communications protocol (the IP msg set) between the handheld device (e.g. smartphone, new NCE/Digitrax wireless controller) and DCC/LCC command stations?
the benefits would be to allow handhelds from different venders and non-modeler suppliers (e.g. smartphones) to operate with one another and have common capabilities.
It would allow a variety of human interfaces better suited for various operator preferences. Imagine using an NCE handheld (or one of several) with a Digitrax system because you prefer the NCE graphical user interface (GUI) but like the price/features of the Digitrax command station.
greg - Philadelphia & Reading / Reading
In theory at least, such a standard already exists. Anybody can write an application for a wifi device to control a JMRI throttle. Today applications exist for the iPhone and Android devices. There is nothing preventing anybody that thinks there is a market for it from producing a dedicated device with real buttons and knobs using this standard interface.
I have the right to remain silent. By posting here I have given up that right and accept that anything I say can and will be used as evidence to critique me.
I'm with Carl on this one. The open architecture of DCC allows for different wireless protocols to interface with it. That's a good thing because it doesn't stifle innovation.
At the same time, the JMRI wireless apps for iDevices and Android ones co-exist quite well. They're all but seamless. I set up WiThrottle on my JMRI install and there was no problem accommodating Android devices. It all just worked (at least that part, there's often something fiddly with JMRI that needs massaged the right way to properly implement it, but it applies equally to both devices if there is such a hiccup.)
Unless someone comes up with a third mobile device OS, that covers the vast majority of wirelss devices commonly encountered. Should this be a standard? Not sure, as there's the possibility of evolutionary change in those OS making WiThrottle obsolete. I'd imagine that the next OS would then inspire another interfacing program similar to WiThrottle to replace it.
But DCC would still work for that.
Mike Lehman
Urbana, IL
It would be nice, but it would be quite a lot of effort to add something like this. Besides, wireless capability already exists, and the various manufacturers are probably happier with their "captive" markets.
It would certain be a great benefit to clubs, though, whose members could bring their own throttles regardless of what system they had.
I've got a Lenz system. Lenz is one of the systems which is supported by the CVP wireless components. Lenz doesn't have wireless components of its own (correct me if I'm wrong,) so the CVP throttles are a terrific product for me.
It takes an iron man to play with a toy iron horse.
MisterBeasley Lenz is one of the systems which is supported by the CVP wireless components. Lenz doesn't have wireless components of its own (correct me if I'm wrong,) so the CVP throttles are a terrific product for me.
I believe that's correct. Whether or not Lenz develops its own, IIRC the problem was that Lenz is centered in Europe, which has it's own set of wirelss specturm for such wireless devices in general. The US has a different set of freqs/emission definitions permitted to use the wireless mode. It's easier to piggyback onto the mobile device bandwagon with either WiThrottle-like apps or already existing specific DCC wireless devices in these separate regulatory regimes than it is to get your devices certified apart from each other by both the FCC and whatever agency handles the European market regulations. Makes a lot of sense.
Mixing systems is at least theoretically possible today, but I don't know if anyone has attempted it so far. JMRI can communicate with multple systems at the same time. So it should be definitely possible to have a system where you can plug in NCE cabs, and a script running under JMRI translates the cab keypresses into the equivalemtn Digitrax Loconet commands and sends them out a second interface to a Digitrax command station. Or vice-versa.
I think any future development will be via WiFi. There are systems already which do this. Digitrax was developing a direct WiFi plug in unit, but the thing is, you have been able to do this with JMRI for many years now, and it's universal - works with any system that can connect to JMRI, which is pretty much all of them now that MRC is on board. Where I see a place for a product is a universal (BT most likely) add on device for a smartphone that gives you a knob for speed control. This would work with the existing Engine Driver and WiThrottle apps and JMTI, giving you a handheld wireless throttle for a fraction of the cost the DCC companies charge for their proprietary ones (even if you have to buy the phone - there are perfectly workable Androind phones for $20 or less out there). or maybe a full throttle device that uses WiFi and talks via the WiThrottle server in JMRI - this is something I want to experiment with using an Arduino and a WiFi shield, it's cheap enough. Add some buttons, an encoder, and a small display, and just have it talk using the WiThrottle protocol. This should be pretty inexpensive, and again will work with ANY DCC system supported by JMRI.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinkerMixing systems is at least theoretically possible today, but I don't know if anyone has attempted it so far.
aren't we able to use Tsunami decoders with Digitrax command stations because the DCC protocol is standard?
rrinkerI think any future development will be via WiFi.
Bear in mind the Wifi is simply wireless ethernet. There's no need for a command station to be wireless, it can have an ethernet connection.
Even a handheld could be ethernet (imagine ethernet panels on facial) but requires more sophisticated processors and longer power up times unless batter powered, which come for free with wireless smartphones.
rrinkerThere are systems already which do this. Digitrax was developing a direct WiFi plug in unit, but the thing is, you have been able to do this with JMRI for many years now, and it's universal - works with any system that can connect to JMRI, which is pretty much all of them now that MRC is on board.
While techies like combining different pieces (NCE, JMRI, smartphones) others seem to prefer a more user friendly less complicated approach.
rrinker... giving you a handheld wireless throttle for a fraction of the cost the DCC companies charge for their proprietary ones (even if you have to buy the phone - there are perfectly workable Androind phones for $20 or less out there).
having a standard operator protocol recognizes the availability and relative cost for smartphones.
techies can develop different types of smartphone GUIs ranging from the techie to simlpe.
However, I wonder where most venders make their profits: decoders, command stations or handheld controllers. Are the days of proprietary handheld controllers numbered and could venders survive?
Can something like a SPROG be enhanced with an ethernet interface and open interface allowing communication with a smartphone with a variaty of GUIs? Could an Arduino be the go between?
[/quote]
I thought we were talking about the throttles, not the track system - in which case, you can't today mix brands of throttles together, except theoretically via a go-between such as JMRI like I mentioned. There are a few exceptions - there are some homebrew Loconet throttles so you cna use non-Digitrax throttles on a Digitrax system, and CVP makes a wireless throttle for Lenz.
Given that you can have wireless or wired operation, for really the same price these days, not sure why anyone would actually pick wired. But sure, put an Ethernet jack on the thing if it makes you happy. ESU already does that.
There IS a defacto standard for wireless throttles - JMRI and WiThrottle. Apart from a few hardcore experimenters making their own, anyone who's gone the generic smartphone throttle direction is using JMRI. That's why anything I'd make for myself would use the same protocol, saves me the effort to make a Loconet protocol base, which would only be usable with Digitrax. If I make it talk to WiThrottle, my throttle design will work with any DCC system that JMRI supports, which means pretty much any that actually matter.
Sure, if you want to come up with a protocol, you could hook a box to SPROG that has an Ethernet port and use it as the basis for a full system. But that 'box' already exists - if you want it small, use a Rspberry Pi. That 'box' is again JMRI. You can today use WiThrottle and a phone to drive a train using the SPROG.
There currently is A throttle app for iPhones, and A throttle app for Android, but there is no licensing issue or proprietary nature of the system that is preventing someone else from making a compatible iPhone or Android app that offers different features than the existing ones. The original developer of WiThrottle write the iOS app - the Android app, Engine Driver, is the work of a completely different developer.
Will the system vendors survive? Sure, they just might not sell as many throttles. The current state of WiThrottle does not do programming, you still need either a JMRI console or your system's throttle to program. That could change, if someone wants to write it. JMRI gives full access to their APIs, so there's no technical reason why WiThrottle could not also support programming. And DCC throttle choices are subjective as anything - perhaps why no real effort has been made in the generic throttle area. The primary factor in chosing a DCC system for many people is the system's throttle design. Would they give that up for some generic device? There's plenty of people who won't give up a knob for a touchscreen, but if someone developes a generic throttle that has knobs and buttons, would people switch from their system's throttles to this generic device? Given that the only efforts to date in thei direction are DIYers not out to sell hundreds or thousands of devices, I'd venture that the answer right now is no. Or at least, not enough to turn a profit after R&D and manufacturering costs for said generic device.
I will also point out that the one closed DCC control bus, Digitrax Loconet, has MORE third party support than all the others combined, even though their interfaces are open and there is no licensing fee for a commercial product like there is with Digitrax. Yet the Loconet third party market, with both commercial AND DIY components, thrives.
I'm confused as to why JMRI seems to be the only control software ever mentioned on this forum. Rocrail has wireless throttles built in via both a web client and SRCP, and they work quite well. There is a simple HTTP protocol for making your own clients if you are so inclined.
Pretending JMRI is the only software that matters is rediculous.
Julian
Modeling Pre-WP merger UP (1974-81)
JMRI is free
Jack W.
fieryturboPretending JMRI is the only software that matters is rediculous.
No one is "pretending JMRI is the only software that matters."
People report on what they use and have experience with. JMRI is not only free, but is open source. If you want it to do something else, you're free to hack it to suit your pleasure or, even better, get involved in the sizable development community that supports it.
If you're so hot on another product, then tell us more. But if YOU aren't using it and can't elaborate on its advantages, then that says a lot right there about why you hear little about it.
Modeling BNSF and Milwaukee Road in SW Wisconsin
jrbernierIf I were converting to DCC today, I would just buy a command station and JMRI interface.
this makes sense for someone with your experience. But if you were just getting into the hobby or less of a techie, is this likely?
rrinker Given that you can have wireless or wired operation, for really the same price these days, not sure why anyone would actually pick wired.
Given that you can have wireless or wired operation, for really the same price these days, not sure why anyone would actually pick wired.
Same reason I prefer hooking my computers up to a router with a cable rather than WiFi. It is a better connection, it is faster, less chance of interferance. With a wired throttle I do not need to worry about my battery going dead.
Well, it would have to be PoE for that to work, so now you're getting up there in cost.
Speed is a non-issue with DCC, even ancient 10Mb ethernet is many times faster than railroad controls need to be.
Wifi to my home router is never an issue in my house - I don't see why a wifi based DCC throttle would be any different. It's other devices that use the same frequency spectrum that have issues. Plus with a wifi throttle, insteadof having wifi PLUS some other radio system operating at the same time, you'd just have the one. The main point being, get rid of cords all over the place where peopel trip over them.
fieryturbo I'm confused as to why JMRI seems to be the only control software ever mentioned on this forum. Rocrail has wireless throttles built in via both a web client and SRCP, and they work quite well. There is a simple HTTP protocol for making your own clients if you are so inclined. Pretending JMRI is the only software that matters is rediculous.
Because JMRI has been around the longest and is most well known. Yes, other software exists. In fact, RocRail may be just what I'm looking for, because frankly, I hate Java with a passion. But to reach the largest audience, I'd almost have to make my device use the WiThrottle procotol rather than RocRail's. It probabyl wouldn;t be too difficult to make two different builds, one that uses WiThrottle and one that used RocRail. If I used something other than an Arduino there may be cose space to have both options in the same device and the user could pick.
gregc jrbernier If I were converting to DCC today, I would just buy a command station and JMRI interface. this makes sense for someone with your experience. But if you were just getting into the hobby or less of a techie, is this likely?
jrbernier If I were converting to DCC today, I would just buy a command station and JMRI interface.
The alternative is each DCC vendor making a proprietary interface to convert their system to Ethernet/Wifi to support the standard generic throttles.
That I do not see happening - Digitrax has effectively abandoned development on the one they were working on.
It is possible these days to package up a turnkey system with a RasPi preloaded with the required software so all the user needs to do is plug in the wires and turn it on. That's about as simple as it gets. At some point, you have to learn SOMETHING - if you can't figure out how to wire a siding with a SPDT toggle to kill power so you can park a train, you're not going to be using wireless radio throttles.
mlehman fieryturbo Pretending JMRI is the only software that matters is rediculous. No one is "pretending JMRI is the only software that matters." People report on what they use and have experience with. JMRI is not only free, but is open source. If you want it to do something else, you're free to hack it to suit your pleasure or, even better, get involved in the sizable development community that supports it. If you're so hot on another product, then tell us more. But if YOU aren't using it and can't elaborate on its advantages, then that says a lot right there about why you hear little about it.
fieryturbo Pretending JMRI is the only software that matters is rediculous.
Rocrail is also free and open source.
No Java is required.
It can run in server mode where the rail layout and software are on one machine, and the client software is on another, so you can create and make changes to your layout from multiple PCs if you like.
It provides an SRCP server for throttle control. There is also an SRCP throttle app for iPhone(iThrottle), and one for Android(AndRoc).
It provides a mobile web client for throttle control.
It provides an HTTP service for throttle control, if you wish to write your own throttle software.
It does software consisting.
It has much better support for DIY throttles and command stations, and supports all the command stations that JMRI supports.
It has nightly and stable builds, and much more detailed walkthroughs and documentation than JMRI.
The developers are very quick to react to add features to the software or respond to a bug.
Scripting automation in your layout does not require Java programming knowledge.
It isn't broken down into 5 programs like JMRI (why did JMRI even do this?)
It can run as a command station with only a booster for a track connection (via DDX)
It has documentation for using sensors that is all but missing in JMRI. It supports many more feedback devices than JMRI.
I could keep going, but I won't.
fieryturboI could keep going, but I won't.
OK, that's much more useful than complaining that other people are holding back a discussion. At least half of that's way over my head, I rely on my lovely wife for tech support, so I can't make heads or tails of comparisons to JMRI. I do know there is some overlap of the features you describe, but you're probably in a better position to describe what benefits accrue one way or the other.
Except for the part about RocRail being one integrated program. I've yet to figure out the overlapping permutations of JMRI, so something based on one build, provided it's not overly unwieldy, could certainly be an advantage.
You didn't mention capatibility with things like the RPi, which would be of interest to many. Randy mentioned how those represent an opportunity to provided a RTR platform cheap enough to purchase whole based on the RPi. My own experience is that may not quite be so, because of the iffy little things involved in it going headless (unless those have been updated in recent weeks.) But with the RPi itself at ~$40, if someone loaded and sold those where all you needed to do was plug in and log in, then I'd bet you could sell 10,000 @ ~$100/each without too much trouble. No one's doing it yet, but I'd love to see a competition to deliver that to the hobby community.
jalajoie JMRI is free
JMRI runs on an off-the-shelf PC. Rocrail does not. At least, I can't find any indication that it does on it's less than user friendly web site.
There aren't really 5 programs with JMRI, there is one central program that accesses them all. It's different development teams. I really wish they had concentrated on the panels aspect of things before adding the Operations thing, which really is totally independent of anything using DCC.
I don't know about supporting more - if the device reports over one of the control systems supported by JMR, you can use it in JMRI. So if the feedback device is Loconet, Lenz, NCE, USB, CMRI, whatever, it will work with JMRI.
JMRI has a client/server mode over the network as well, so you can run a server that has your DCC interface and access it from mutliple client computers. Like RocRail, the server can run headless on a RasPi or similar small machine.
If you are adventerous enough to download nightly builds, JMRI has them as well. There is a completely separate discussion group for developers, developer talk is discouraged on the common JMRI Yahoo Group, that one is intended as user support.
JMRI scripting doesn;t use Java. Actually, it's worse - it uses Jython, a scripting langues where the designers decided that exact indenting of command lines matters! So it might LOOK ok in your editor, but if you used spaces on some lines and a tab on others - the code will error! Only an academic trying to teach a rote programming style could come up with something like that.
Milepost 266.2 jalajoie JMRI is free JMRI runs on an off-the-shelf PC. Rocrail does not. At least, I can't find any indication that it does on it's less than user friendly web site.
Just click on Software. There are downloads for Windows, Linux, and special builds for RasPi.
rrinker Milepost 266.2 jalajoie JMRI is free JMRI runs on an off-the-shelf PC. Rocrail does not. At least, I can't find any indication that it does on it's less than user friendly web site. Just click on Software. There are downloads for Windows, Linux, and special builds for RasPi. --Randy
Mac as well. (I run the client on both on my PC gaming desktop and Mac laptop, and my Rocrail server is Linux. However, you can run it as a single program on one machine)
Can we program decoders with Rocrail ?
jalajoie Can we program decoders with Rocrail ?
Yes.
As an aside, rrinker mentioned support. The Rocrail forum is much better organized, with a seperate section for general questions and those for specific command stations, so you can easily search for the help you need.
Some people like mailing lists (those of us that have been around to remember Bitnet and the original mail listservs), others prefer a forum. It gets mentione periodically on the various Yahoo groups about setting it up in forum format instead, and it always get shot down. I'm not sure why, the forum, approach IS better, especially with how Yahoo totally destroyed the usability of Groups with their 'Neo' update. With forums, common issues can be made sticky and permanently at the top where a newcomer can see common issues and their solutions without having to wade through thousands of posts or just ask the same question in a new post that's already been asked and answered 100 times.
Beats me, but a forum that works (keeps track of what thread you've read, etc) is to me far superior to an old style mail list, and I used to be a heavy participant in many newsgroups back in the day. In that other thread I talked about technology for technology's sake vs technology that actually offers me a benefit - well, forum type software is a good example of the latter. Easier to use and far better organized than any mail list ever was or could be.
jalajoieJMRI is free
the software is.
but my impression is that you typically use a dedicated laptop to run it. I realize you can get a 2nd hand laptop relatively cheap from ebay. But the point is instead of buying a ready to run system (e.g. NCE) you're buying ($) a more sophisticated system that has the support (i.e. OS, Java, serial interface, ethernet/wifi) required by the free SW.
and this assume you have a smartphone, which may be true for dad, but not necessarily a kid. Of course you can buy ($) a used smartphone from ebay.
As I pointed out in my original post, using a smartphone as the human interface for sophisticated products (e.g. Sony lens-style camera) may be a trend that both decrease cost and increases features.
I'm suggesting that an operator standard or adopted-standard (e.g. JMRI) recognizes this and can help newbies be able to build an inexpensive system from different venders (e.g. Tsunami decoder, Sprog command station, smartphone) without them needing to be a techie.
There's no reason the computer for JMRI needs to be dedicate to the train layout. Or even in the same room, depending on the layout interface. Nor does it need to be a laptop - you can get a refurb small desktop from vendors like Newegg for less than the price of one wireless throttle fromt he major DCC manufacturers
A universal throttle based on a smartphone will ALWAYS be cheaper than any dedicated device - I'm not sure what you're looking for here. Phone sell in incredible volumes, which keeps the cost down. Model railroad stuff never sells in anywhere near those levels. If you don;t already have a smartphone, there are sub $20 ones you can get that will run the Engine Driver software and be a throttle. How cheap do you want a throttle to be? Yes there's an infrastructure to interface that $20 phone - but consider, maybe $300 for an old computer plus the interface device for the DCC system, and after that $20 or less per throttle. Specific brand wireless throttles are around $200 each. So fof the price of 2 brand specific throttles you can have 5 smartphone throttles PLUS anyone that already has a smartphone, there are more throttles. That's one new sound loco.
Re: Throttles, there are a few things that are a bit of a problem.
Some folks in here have mentioned that they want a physical throttle to not have to look at it to operate. I'll take that as a valid point, but I have a hard time believing that anyone operates the lower 2 rows on a Digitrax throttle by feel in any reasonable amount of time compared to a smartphone.
Alright, let's assume they do. Even so, it would have to be completely by motor memory in the hands, as Digitrax uses the same buttons for the entire throttle. That takes some serious time training your hands, and you may or may not be able to do it.
What other wireless physical throttles are there that can be compared? The other ones I've seen are *huge* by comparison, not really practical for carrying around the layout.
From this perspective, I'm having a hard time seeing the benefit of the current wireless throttle offerings.
Some thoughts...
On mail lists vs forums...
I once was an active member of 40+ lists. Life got busy. I didn't unsubscribe from most, but remained a read-online-only member. My Inbox is somewhat under control, but I rarely login to any of them. While I understand the attraction of seeing list membership rise to developers, I'm just not getting on any more lists at this point in my life. I know how to use search, although it has it limitations. A forum format just suits me better.
On wireless throttles...
I went NCE for two reasons, the mostly uncryptic interaction sequences and the ergonomics. I'll leave the intelligibility question aside to avoid starting a major tangent here. But the NCE controlers, other than the "hammerhead" (which I don't find bothersome other than size, but I have big hands), fit well in the hand, have nice fat buttons (and knobs, etc, everything but a touchscreen, to suit your needs), and at least for me are easy and intuitive to use one-handed.
That said, the WiThrottle interface works equally well for me, despite being considerably different. YMMV, by which it should be added that if the point of the thread was to call for a single interface that "does it all" -- there is no such thing. And there won't be. Humans simply vary too much, and the ops style that people use also can be fundamentally different. The current systems, whether proprietary, JMRI, Rocrail, whatever, all offer choices. If you're unhappy with yours, keep looking. Something that works is already out -- you just need to do the homework to find what it is for you. An appeal for what can only be a mythical "single standard" in the user interface is a solution in search of a problem that won't be solved by that premise IMO.