Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: "Radio" communications and/or Text Train Orders #872

Open
ksfraser opened this issue Dec 26, 2021 · 3 comments
Open

Feature Request: "Radio" communications and/or Text Train Orders #872

ksfraser opened this issue Dec 26, 2021 · 3 comments

Comments

@ksfraser
Copy link

I appreciate that this FR is out of scope for controlling an engine; however with VSD sounds now being incorporated to enhance the operating experience, I thought this might also be worth considering. Unfortunately my attempts at Java programming in the past wasn't as successful as I would have liked, so this is beyond my current ability to contribute :(

It would be nice if there was a SIP client built into the throttle. Instead of having FRS radios or hard wired phone systems, the user could talk to other train crews / dispatcher / yard office / ... through the app.

Background: I have an Asterisk server setup with SIP phones around my house, and all of my cell phones have a SIP phone installed as well. When I started using Engine Driver on my cell to control loco's I also setup conference rooms on my Asterisk server; the dispatcher and trains had an extension; the "road channel" had a conference room. If you wanted to talk to the dispatcher, you phoned that extension. If you wanted to talk to a train, you phoned their extension. Each person logs into the train's account when taking control of the train; log out when tie-ing up. When not otherwise on a call, the crew listen in on (call) the road channel (conference).

The down side to this was having to switch apps to do so. Worked fine for a train sitting in the hole; less so for calling a train on the move - with our shorter runs and time between needing to do something in the throttle, the time spent switching between apps and actually conversing in the SIP client led to running past control points, etc.

To replace FRS, one could setup 1 conference room that everyone logs into, and a PTT button on the throttle. To simulate a multi channel setup, there could also be a channel button as well as config options that set channels to log into conference rooms. This would not need to be tied to Asterisk - there are any number of SIP providers with conference rooms. There are also other self hosting SIP providers.

Extra bonus points would be an integration into JMRI where a new call to the dispatcher extension also flashes in JMRI, but I get how this would be really stretching "in-scope".

In a similar method, SIP SIMPLE messages (text) could be used for sending text versions of clearances / train orders but I suspect that would require enhancement in JMRI unless the dispatcher also had a Cell (not as easy with traditional phones to send the text message). This does require a more recent version of Asterisk or a provider with SIMPLE turned on.

@mstevetodd
Copy link
Contributor

@ksfraser Thank you for the request.
If you don't mind, please separate the text suggestion into its own request, and provide more detail on what you're asking for.

Regarding SIP, I've no experience with such, so please provide more information.
For example, I don't understand why you'd need to switch apps once the initial connection is made. What (exactly) are you doing in the SIP client while your train is moving? If you switch back to ED, does it somehow interfere with the voice channel?
I'm not a fan of duplicating software, so I'd need to understand why the separate SIP client app isn't sufficient.
Also, are there competing "standards" for SIP? In other words, if we made it "work" with your setup, will it work with others?

@flash62au
Copy link
Contributor

I tend to agree.
I would be reluctant to include complex functionality that already exists as a separate app.
However integration with the other app would not be unreasonable if possible. (i.e. adding the PTT and channel buttons to ED)

@ksfraser
Copy link
Author

My usage scenario was less directly replacing the FRS and more like Canadian Pacific's Radios from 20 years ago - crew monitors the road channel for the segment of track they are on. They switch channels (i.e. dial a new extension) to talk to the dispatcher (which then flashes an alert on the dispatcher's screen). If the dispatcher calls them, they switch to a third channel. So I was using multiple extensions. Therefore, changing between apps (to dial a new extension) is fine while the train is stopped, less fine while moving due to the time involved and the short travel distance (ergo time) between stations/control points/signals/... on a model.

As to SIP, I don't believe there are multiple competing extensions. I have 2 SIP providers in addition to my self hosted Asterisk server and my sip client connects to all 3 with no difficulties.

A few years ago CSipSimple and gnuphone seemed to share a SIP library (I think it was PJSIP?). I am not a java programmer so don't know what integration would take.

I included the Text request in the original FR because SIP has the SIMPLE extension that allows sending text messages over SIP which if you were to integrate the library anyway, wouldn't need an additional add-on. That said, I can see how a web based text interface (e.g. text box + submit button) might be more easily integrated into JMRI itself. My thought was that train orders/clearances that are read over the radio could also be sent via text/http/... I know that the forms themselves are (maybe were I'm a decade away from the project) incorporated into dispatcher screens at CP and the dispatcher just fills in details, with the read and repeat highlighting text by hitting the space bar per word.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants