Proto Throttle

[KPack]

I don't think Ring's architecture would be set up for Protothrottle, nor do I think they will give up Railpro's operating code to do so.  It just doesn't seem likely to me.

Regarding Mac support, Railpro works fine with Bootcamp.  Hearing from another Railpro user, my understanding is that Max OS comes with Bootcamp and doesn't cost anything.  Lots of programs don't have Mac support.  Back in grad school half the class had Mac's and they all had to use Bootcamp in order to run some of the programs the school used.  Just part of the game.

RPA isn't the greatest interface in the world, sure.  But the last time I used JMRI it was....bad.  Talk about clunky.  Yikes.

Didn't the internet thing get resolved with RPA?  I thought I remember there being some sort of resolution with that.

-Kevin

[G8B4Life]

I don't think Ring's architecture would be set up for Protothrottle, nor do I think they will give up Railpro's operating code to do so.  It just doesn't seem likely to me.

You've hit the money of the head with the second part I'm sure. The first part I'm not sure how they would be able to get it to work anyway; the ProtoThrottle in it's normal sense talks to a command station using a wireless adapter specific to that brand. As we know RP has no separate command station for it to talk to so it would have to directly communicate with LM's as the HC does. The trouble then becomes how do you set up an LM and the ProtoThrottle so when you pull the horn lever on the PT for example the LM knows to play the horn sound.

RPA isn't the greatest interface in the world, sure.  But the last time I used JMRI it was....bad.  Talk about clunky.  Yikes.

But at least someone could design a cool interface for JMRI if they really really wanted to, with RPA that's not possible for the masses, only Ring himself, and it appears he thinks it's fine.

Didn't the internet thing get resolved with RPA?  I thought I remember there being some sort of resolution with that.

Yep, it did get fixed. I think Jacobs visits here are so infrequent now compared to many of us that he could be missing stuff.

- Tim

[William Brillinger]

and zero fix to whatever issue the Hugh's net guys are having.

The satellite issue was fixed earlier this year.

As far as RailPro working with ProtoThrottle, it could easily be done on the software side but I don't think Ring is willing to adopt the Open license that is required to sell the interface.

[TwinStar]

I don't think Ring's architecture would be set up for Protothrottle, nor do I think they will give up Railpro's operating code to do so.  It just doesn't seem likely to me.

Regarding Mac support, Railpro works fine with Bootcamp.  Hearing from another Railpro user, my understanding is that Max OS comes with Bootcamp and doesn't cost anything.  Lots of programs don't have Mac support.  Back in grad school half the class had Mac's and they all had to use Bootcamp in order to run some of the programs the school used.  Just part of the game.

RPA isn't the greatest interface in the world, sure.  But the last time I used JMRI it was....bad.  Talk about clunky.  Yikes.

Didn't the internet thing get resolved with RPA?  I thought I remember there being some sort of resolution with that.

-Kevin

I've run both Bootcamp and Parallels. Pros and cons to both for sure but right now I'm not running either. To be fair, Mac support in the MRR community is zero so Ring isn't alone there.

RPA is the worst. While RailPro is the best, by leaps and bounds, RPA is a D- afterthought. It's an embarrassment to sell someone on RailPro and then have to bring up the RPA caveat. As dysfunctional as DCC and JMRI are (and you're absolutely right about JRMI Kevin) Rings RPA is equally as bad. In my opinion, RPA offsets almost all the benefits about the ease of use in RailPro.

Glad to hear the Hughs thing got fixed. I think I remember seeing something about that now but age and memory. I got into a disagreement (friendly one) with my neighbor yesterday about what day it was. He was correct, I was off a day.

[TwinStar]

[/quote]

Yep, it did get fixed. I think Jacobs visits here are so infrequent now compared to many of us that he could be missing stuff.

- Tim
[/quote]

Sorry about that. I've been focused on building my passenger car fleet and my modules. I haven't opened a loco or dealt with RP in quite some time. I did buy the speakers that KPac recommended awhile back but once they arrived they went into the drawer. It is good to see some new faces around.

[Alan]

We need to keep everything in perspective.

DCC suppliers, RailPro, and every other variant are small enterprises doing well what they know and doing poorly at what they do not know so well. Each has obviously mastered the technical side (electronics/software) in one form or another. Where they all equally fail to some degree is psychology (UX). Makes sense, engineering and psychology are not common academic bedfellows. Being such small companies they are constrained in their expertise and resources. The technical side is price of admission. Seems most companies meet this minimum and fail to go much further. So, in a sense we are dealing with engineering firms, not marketing firms. Temper your expectations accordingly.

Since the advent of DCC, RailPro with touch screen and Protothrottle with tactile realism are the only two clear cut examples I can think of where some element of disruptive marketing-thinking is evident in the train control business. We should be happy we can have at least one of these. Until recently (relatively) you couldn't have either.

[nodcc4me]

RPA is the worst. While RailPro is the best, by leaps and bounds, RPA is a D- afterthought. It's an embarrassment to sell someone on RailPro and then have to bring up the RPA caveat. As dysfunctional as DCC and JMRI are (and you're absolutely right about JRMI Kevin) Rings RPA is equally as bad. In my opinion, RPA offsets almost all the benefits about the ease of use in RailPro.

I don't see RPA as being bad at all. The download and transfer speed is extremely slow depending on the file, but the interface works perfectly. There are minor things that could use improvement, but for free software it does the job well.

The Proto Throttle may be an improvement over some of the DCC controllers I've seen, but the tactile feedback would never be enough for me to switch to DCC. In fact, with my limited club experience with DCC, nothing they could design would be a good reason to go there. Hence, my User name. LoL!

[Smoke]

I was afraid that it would be one of those things that will probably never happen. Having said that I am still very much interested in RailPro, the Proto Throttle would have been an added bonus. For me the advantage of the proto throttle is the brake lever (and throttle notches on some level) and the adjustment that this allows. Having worked around the prototype in low speed operations, that is something that I would like to mimic and the physical brake lever seems like the best option out there so far.

This may be better suited in another thread, but how does RailPro currently handle braking?I have read in the past that it wasn't available, but have seen mentions of it but not much detail on how it works.

With the right knowledge and a bit of time, the HC-2 could be turned into a throttle with a more hardware based throttle similar to the proto throttle. With the communication being proprietary, it really isn't an option unless Mr. Ring decides to do it himself.

[G8B4Life]

...Temper your expectations accordingly.

I don't fully subscribe to that. It really doesn't matter if they are engineering firms doing well in that area and not in psychology (UX) because they are engineers or not, it's the drive to improve the UX so people are attracted to your product for it's ease of use of it's features (and the UI is a big part of that) that is the biggest factor. I think that drive is sadly missing in the North American model train control ecosystem, either by resting on laurels, self induced fantasy that the UI is just peachy the way it is without getting feedback, or just fear of getting someone in who can do the job because of propriety secrets.

For work we use a firing system from the US. You can think of it as DCC on steroids in the way it works. The hardware is excellent, they are engineers. The UX is also very good, because the UI is also good. This company has only a couple of people and they sell way less than any DCC manufacturer would. It can be done!

I don't see RPA as being bad at all. The download and transfer speed is extremely slow depending on the file, but the interface works perfectly. There are minor things that could use improvement, but for free software it does the job well.

I see RPA as being built in a method that is not needed just to give it a look (and internal functionality) consistent with the handheld. That way is not needed for RPA. HC Sim, yes probably as it needs to mimic the way the handheld works but not RPA. If you get the chance look at the LokProgrammer software. You'll see what "free" software for a model train control system can be.

- Tim

[nodcc4me]

I think most model railroaders are over 60 years old. From my club experience, most of those, including me, don't want to be programmers. It would be nice to have the technical and electronic knowledge that some of the members here have, but I don't. If I wanted absolute control over every operational feature of my locomotives, I could switch to DCC and JMRI, which is, from what I've seen, a nightmare to use. I don't have enough knowhow nor the inclination to do programming. Rather, I just want to push a button and have something happen. For those who want to program, it's good that companies like ESU and software like JMRI make that possible. Guys like me want someone else to do the programming so we can just enjoy running our trains. RailPro and RPA fill that requirement nicely. Could it be better? Sure, but the support I've gotten from TR over the years has been outstanding, and that in itself would be enough to keep me happy. When I hand a controller to my 5 year-old grandson, he too can just push a button and have a good time with the trains. Perhaps he will have a continuing interest if he someday inherits my trains, and helps perpetuate a dying hobby.

[G8B4Life]

I'm not arguing against you Al, everything you said is part of the good part of the RailPro user experience, my reference to  the LokProgrammer software was not about how powerful (and potentially complicated for some) it is but was about the user interface, it is neat, logical and doesn't look like a early 1990's 16 colour .pcx file (there, that's showing my computer age, I used .pcx images!).

The user experience is made up of both the functionality and the user interface to that functionality. Going back to DCC here for a minute, historically DCC has had a very poor UI for the functionality (those old 100 button throttles, having to work out CV's etc). JMRI came along and improved part of that DCC UI and DCC's UX went up a huge amount. Leaving aside European developments here DCC continued with an partly improved UI to the functionality of DCC with JMRI in that programming got a whole lot improved (thought JMRI's UI itself could be better) but the UI to driving was still the same. Then came along ProtoThrottle. ProtoThrottle put a brilliant UI to the driving functionality and DCC's UX went through the roof for those that bought it.

Coming back to RP now, RP has some brilliant functionality, but the UX is being let down by the UI, both on the handheld and RPA. If your UX is good with the UI that we have then I'm happy for you, but I think it could be greatly improved, for the betterment of the RP UX.

- Tim

[nodcc4me]

I get it, Tim. It might be a good idea for you to make a short list of improvements you would like to see in RPA and send it to TR. The worst thing that could happen is that he says he can't make those changes, but I would think he would at least try to work out some of them. I know you had some issues with him in the past but hopefully, that's behind you both. Can't hurt to try.