Definitely Interested!!!!
Dear Scott, Michael,
Having been inspired by the same YT clip some years ago,
and wrestling with the joys(???) of Android coding to get a JMRI/NCE conversion solution for a prototype Cattron Theimeg "AccuSpeed" bellypack unit
I am very interested in another-way to close the airgap between "Tactile User Interface" (TUI) and JMRI.
A few thoughts, If I may.
- If wireless, the handset is going to require some form of onboard battery power source. Aim for a significant runtime between charges, and integrated charging (plug in a USB cable?) directly to the handset.
- Whether the gauges are some form of "needle gauge", a simple LED, or a digit display,
the interface solution does indeed require both GPI (Human> System INPUT) and GPO (System> display/feedback OUTPUT) capability.
FWIW, If GPO was not required, a NCE MiniPanel or similar could probably achieve all the "Throttle INPUT command interface" required (I'm an NCE user),
but the desire to make the solution:
- wireless
- have appropriate GPOs
- and cross-DCC-system-compatible
is what kept pushing me down the 'Droid route
FWIW, if the underlying GPIO capabilities were sufficiently flexible, the selfsame RasPi interface could possible act as a platform on which to connect a "normal" throttle Tactile User Interface (TUI),
IE a speed-knob and reversing switch.
Much as such an interface has taken a bashing in recent times, a solution which _could_ support such a TUI would have far-wider applicability to a much-larger range of modellers,
(commercial success),
and could well overcome the major-hurdle many have to deploying "JMRI/Engine-Driver" throttle systems on their layouts. As has been said many times to modellers purchasing their first DCC system,
"...if you don't like, don't feel comfy with, or can't understand/user the throttle handset,
then no matter how powerful it is, the DCC system in question is not-for-you..."
- The Throttle is actually 9 logical and physical position, Notches 1-8 Plus IDLE. This is important when mapping a "notched throttle" TUI electrically to the 28-speedstep range of the typical DCC command/protocol
NWBatman overcame this "maths connundrum" by mechanically indexing the physical Throttle lever thru 9 detented "notches", to a potentiometer which matched that of the donor NCE CAB04p pot. This means that in NWBatman's case, each physical "notch" of the TUI throttle lever may not be a perfect-multiple of NCE-cab-buss "speed steps", and neither might the full 0-notch8 "throttle lever range" match the DCC-spec 0-28 speed-step range-of-values. However, because the loco decoder is speed-curve-tuned to the throttle output range, everything works as the TUI (throttle handset) implies it should.
- While a prototype has a "mid position" on it's reverser handle, the DCC protocol and decoder logic does not.
A decoder is always either in Fwd or Rev mode. Minor detail, but something that can mess with your head when trying to assilimate "proto controls" <> "model command protocol".
- Having the Brake as a slider or spring-switch is logical in terms of assimilating a tactile physical control to the DCC "Push-ON/Push-OFF" way a CAB0x / UT4 brake button works. Translating that to a 2-position level can be done, but opens the possibility of switch-bounce or "power-on initialised TUI state" causing the "Left = Brake Release, Right = Brake ON" functions to become inadvertently reversed...
That there is no explicit "Brake ON" and seperate "Brake OFF" command in either the DCC at-rail protocol,
or the typical decoder's firmware headspace makes this tricky to overcome... (not impossible, but tricky).
This is why in the NWBatman example YT, he has to "brake twice" repeatedly.
- First "brake application" = Brakes ON
- Second "brake application" = Brakes OFF
- If the brakes are "not in the state you want them in" right now, brake-again to toggle state.
(This is not logical to a prototype engineer with a 26NL airbrake stand,
where "Release" IS Always "Full Left",
"Emergency" IS Always "Full Right",
and there is NEVER a case where the Lever-Direction<> Action relationship can be flipped...)
- With some simple(?) manipulation of the Maths performed by the RasPi, before it transmits to JMRI,
It may well be possible to actually simulate a (Release, Set, Emergency) "3 position brake lever" operation.
(IE have a physical 3-position "Brake Lever", it appears to make the loco operate as if it has 3-brake positions,
but the intermediate maths is doing some "interpolation" to git-it-done inbetween).
- For the Cattron Bellypack implementation, there is no "Headlight" controls on the pack. The prototype instructions for settng up a loco for Remote operation state that all things such as Headlights should be configured in-cab _before_ the Operator heads-out with the Bellypack to start the shift.
This may be procedurally important, because it gives justification for the model RRer "control stand" user to have to stop by the JMRI "Power desk" (Motive Power Hostler's desk?)
and have the loco "assigned to the throttle",
rather than being able to "assign a loco to the throttle" themselves?
- Despite not having a "Headlight" control/switch,
what the Bellypack _does_ have is a 3-position switch which acts:
- Off
- Bell
- Momentary Horn
IE you can switch from "OFF" to the centre-position "Bell",
but to blow the horn you then have to "momentary push" the switch _beyond_ the "Bell" position to the "Horn" position,
and the switch spring-returns to the "Bell" position when released.
- As far as physical handset form-factor goes, IMHO NWBatman had the right idea. NCE, Digi, and many other US-based DCC manufacturers have had much success with the "pack of cigarettes size" handset in a "buddy-throttle" format. If the aim is to simply(LOL) replace a generic rotating knob-and-buttons TUI with a semi-proto-inspired set of Levers, then follow NWBatman's example and enjoy
In contrast, European DCC systems abound with "two handed throttle units" (B'mann Dynamis, ESU ECoS),
and seriously, How Many North-American modellers do you see consciously opting to use them, esp in "walkaround layout" situations?
Maybe it's because I'm based not-in-Nth-America,
but I get a far-wider "sample size" of Modellers <> systems-in-operation comparison opportunities down here,
(IE there are actually a significant number of Euro-made DCC systems in "live-fire use" here),
so failure-to-pickup-and-use-a-2-handed-throttle surveys cannot be simply put down to "yeah, but no-one hereabouts uses such systems",
and the maths still holds up. If the layout is a "walkaround with your train" configurations,
a "single-handed" handset TUI the size of a CAB0x or UT4 is the "throttle of choice" for the majority of modellers.
Furthur, I totally take the point that Bruce Kingsley is running a "near scale size" controlstand in his half-a-F-unit cab, and so too are numerous Trainz and MSTS fans
However, equally, those applications:
- explicitly do not expect "fully mobile walkaround-with-one's-train" capability,
- generally do not perform the kind of "Local Switching" which requires significant and frequent manipulation of the controls to perform (If it ain't easy to use, and you have to use it often/frequently/time-critically, then you're going to become a grumpy old model RRer rather quickly...)
- and in Bruce K's case, have prompted the parallel development of on-loco camera feedback
Indeed, it could be argued that Bruce K's application is more about "replicating the incab experience of a prototype locomotive" rather than "building a prototype-esque/inspired throttle for a model railroad".
Upshot: the Givens and Druthurs for Bruce K's F-unit Cab-Project are markedly different from Scott's "Improved interface to actually operate with" proto-esque throttle.
Different Missions, with different physical/TUI requirements, requiring different approaches.
...Apologies, waaaaaaaaaaaaaaaaaaay off topic....
Anyway, given Scott's initial starting-point inspiration (NWBatman YTs),
and stated aims,
I think a Cab0x/UT4 sized "semi-proto control stand" throttle handset is a very do-able idea...
I can't wait to see how this develops...
(and with the proven track-record of Michael and the ISE team,
I'm sure it'll be amazing... ).
Happy Modelling,
Aim to Improve,
Prof Klyzlr