TCS Universal Wi-Fi Throttles Are Shipping

[C855B]

Just received notice that my pre-ordered, pre-paid TCS Universal Throttle is en route. Will see it Saturday soonest, more likely on Monday.

Report to come, obviously. Did anybody here try one out at Amherst?

[delphiz302]

We got to try one in the ntrak layout in Mallory building.  I liked the physical form factor and especially the dial for throttle control.  One negative, it did not pick up any of our 5ghz wireless networks;  with dozens of 2.4ghz networks in a setting like Amherst, interference is high.  Not likely to be a big problem in a single home, plus 2.4ghz spectrum has better range and penetration of obstructions then 5Ghz, just lower bandwidth, which is not a factor for withrottle server.  I'm guessing all home routers still support 2.4ghz in addition to 5ghz.  I'm curious to hear how much use you get out a charged battery.

[pmpexpress]

Will see it Saturday soonest, more likely on Monday.

More likely Tuesday, as Monday is President's Day, a federal and post office holiday.

[C855B]

More likely Tuesday, as Monday is President's Day, a federal and post office holiday.

 

We're both retired. Holidays? 

[peteski]

Mike,
I briefly tested out that throttle.  It fells (and looks) like a smaller version of the NCE (old System One) ProCab throttle. Well, it has a more modern display, (better than the 16-character 2-line display) but still fairly low-res monochrome LCD.  The speed encoder knob works much smoother than NCE's.

It works ok, but we still have the old problem of 0-9 numeric keypad.  I wish some American manufacturer would come out with a throttle which has direct control (button) for functions above F9.  Especially with all those complex sound decoders which use many more than the 0-9 functions.  Another thing I think would be really easily implemented in any modern throttle (which likely has more processing power and memory than an early IBM PC) would be more customization.   It is all done in software nowadays, so why not make it more flexible?  For example, I would love to be able to have choice for each function to be either momentary or latching (again thinking of sound  decoder control).

Going back to the display, it is not something I would have expected in a product that just came out in the second decade of the 21st Century.  Even Digitrax seems to have embraced a color LCD display (in their Zephyr, and possibly in new handhelds) with higher resolution than when the TCS throttle uses.

All the above mentioned comments aside, the throttle was easy to use, and worked well (in the 5 minutes or so that I played with it). And it did have some cool features (I don't recall any specifics though).

[C855B]

OK, thanks. Lack of F-keys above F9 doesn't bother me (as you know, not a sound user), so we're good there. Aside from 99.99% reliable comm, my main criteria are speed control and ease of consist management. I guess we'll find that out Monday Tuesday.

[peteski]

OK, thanks. Lack of F-keys above F9 doesn't bother me (as you know, not a sound user), so we're good there. Aside from 99.99% reliable comm, my main criteria are speed control and ease of consist management. I guess we'll find that out Monday Tuesday.

I didn't play with consisting. But the speed control (even though I'm nto a big fan of thumbwheels) was fine in the short time I used it.

I also say that with such an arrangement (ever-spinning encoder thumbwheel) it would be really cool for shunting if the encoder wheel would control the direction too. So from zero speed, rotating the thumbwheel towards the display (forward) would make the loco drive forward, but rotating it back would make the loco go in reverse. So FORWARD <- ZERO-SPEED -> REVERSE.  Again, simple to implement in the throttle's firmware.  And it could be implemented as a custom option.

[Maletrain]

In the TCS clinic at Amherst, we seemed to find a potential issue with consisting.  When multiple TCS throttles are in use, and one "consists" 2 locos, it appeared that other throttles connected to the same command station (by WiFi) were still able to address/control individual locos in that consist.  There was only one loco used in the clinic, so it was not possible there to see what really happened when the consist throttle said speed up and some other throttle told the non-lead loco in that consist to slow down.  The show display did have 2 locos, and I thought the TCS guys were going to check that out on the show display.  But, from what they told me, they did not pursue the issue there, and "took it to the design team."

I would be interested in hearing  how that issue comes out.  One of the issues I have been seeing in both the NCE and Digitrax discusion groups (Groups.io) has involved more than one throttle being able to send commands to the same loco under some circumstances.

[C855B]

That is also a general JMRI issue. Were they using JMRI, or their own interface (does TCS have one?)? It may be something they have no say in fixing.

I have run into this before. JMRI (web and phone) throttles have no sense of "stealing" a previously captured number. You enter the number, you control it... unless somebody else has it, too, and then you get to duke it out.

The way it's manifested itself for me (as a solo operator) is in setup and debugging. F'rinstance, I'm working on a loco, and test at the control station (happens to be Digitrax with a DT). If I forget to dispatch the number and then use my phone to run it on the layout, the control station will periodically "ping" the loco with the last setting it knows - as it is supposed to do - to assure that the most recent command it sent is in effect. If I'm running the loco with the phone and the control station/DT speed is set to zero, guess what?, it suddenly stalls. I then start fumbling with the phone throttle, and off it goes, only to stall again on the next ping from the DCS.

I would expect the same sort of conflict in-consist. I'll try conflicting phone throttles today. Like I said, this is probably not specific to TCS, it's an unintended consequence of the WiFi architecture.

[jdcolombo]

Really interested in how well this throttle works.  After suffering through signal unreliability with the Digitrax wireless system (even the duplex radio proved unreliable with six operators in my basement), I switched over to WiFi, using both old iPhone 5's and two ESU Mobile Control II throttles.  Wi-fi just works.  Period.  I like the ESU throttles, but I really much prefer hard buttons to a touch screen.  Fortunately, the ESU throttles have a nice large knob and 4 programmable buttons (two on each side) that work well.  But the overall implementation and having to use the Engine Driver app via a base Android operating system is kind of clunky.  Probably is very slick with the ESU command station, but that's not what I have.

The TCS throttle is intriguing because it has plenty of hard buttons, and implements the Wi-Throttle protocol directly, instead of having to use the Engine Driver or Wi-Throttle apps. 

As for function keys - well, it's true that modern sound decoders implement 25 or more function keys.  But the truth is that I never use them, and neither do operators on my or other layouts that I have observed during op sessions.  In fact, I have pared down my function keys to 4: F0 (light), F1 (Bell), F2(Horn/whistle) and F8 (Sound on/off).  That's all anyone uses during op sessions.  All the other fancy stuff is neat for demonstrating sound capabilities, but I've yet to see anyone during an op session actually USE any of that stuff.  Maybe the problem is lack of standardization.  When you operate once a month on different layouts, who can remember where the Injector sound button is, or the Dynamics?  Different throttles, different sound decoders, different function mapping on each different layout.  It's too much when you're concentrating on not overrunning a signal or delivering the right car to the right siding.   The old KISS method still works best, IMHO.

John C.

[Maletrain]

That is also a general JMRI issue. Were they using JMRI, or their own interface (does TCS have one?)? It may be something they have no say in fixing.
...

In the clinic, they were using an NCE PowerCab for their command station, which (as of now) requires a connection to a computer running JMRI in order to have a WiFi connection.  So, yes, this is an issue with that system.

Other systems have direct WiFi input devices for their command station throttle buses, so how the TCS WiFi throttle works with those is still an open question, as is how it will work with the TCS command station when that finally becomes available.  TCS is very proud of how their throttles have great capabilities, and how it can address LCC as well as DCC systems.

I talked to Dick Bronson about this at Amherst, and he indicated that this is a known problem with a known solution.  But, I am not clear on what he thinks that solution is.  For a pure DCC system, there needs to be a central control device that decides (and keeps track of) which throttle can control which loco (or multiple locos in a consist).  But, LCC systems do not need a dominant device like that, so the solution would need to be some sort of protocol programmed into each throttle that makes them agree and keep track of which throttle is controlling which loco, or locos in a consist.

[greenwizard88]

How does the throttle connect to LCC? My understanding was that the withrottle protocol was DCC only - and that LCC had nothing to do with running trains.

[Maletrain]

How does the throttle connect to LCC? My understanding was that the withrottle protocol was DCC only - and that LCC had nothing to do with running trains.

That was not part of the clinic, so I don't know how it works with LCC.  I think it is probably the new command station, not yet available, that will communicate with LCC, and the throttle communicates with that. But, since it is WiFi based, if an LCC system has a WiFi input device on it, then who knows?  (Not me.)

[C855B]

How does the throttle connect to LCC? My understanding was that the withrottle protocol was DCC only - and that LCC had nothing to do with running trains.

LCC controls "accessories" such as turnouts, which are normally controlled from a comprehensive throttle in a DCC-only environment. In a JMRI setting, you'll select your turnout list and see turnout "xT371" (x = whatever network character you've assigned for the LCC side, given that 'L' is typically for LocoNet, not LCC), and the request will come from the throttle on WiFi, pass through JMRI, which will then route the command to the selected turnout over LCC.

Not simple in execution or configuration, but simple in end-user function.

[Ed Kapuscinski]

Strange question but... does the scroll wheel "click"?