Keep Port Open

[Josh Glottmann]

No. Operating systems don't allow two applications to bind to the same UDP port.

A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.

[Brin Brody]

A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.

I did some thinking about this when Toby was trying to solve it months ago...  Didn't think about muting the mic, but did think about pressing the PTT every 30 seconds for about a half second, just to keep it awake.  I think the issue then became trying to figure out the particular code to do that (from my inexperienced perspective).  If anyone has that ability, maybe they can take a whack at it?  Seems like this could be a useful thing to have fixed.

[Andrew Morkunas]

Not an ideal solution but if all you want to do is send a PTT every 'x' amount of seconds AutoHotKey https://autohotkey.com/ works.  I use this script to keep my screen saver from running.  It presses the right shift key every 1 minute, 60000 milliseconds.  You could easily modify to what ever keystroke you wanted.

Code: [Select]

CoordMode, Mouse, Screen

Loop
{
     Send {RShift}
     Sleep 60000
}


[Matthew Kosmoski]

No. Operating systems don't allow two applications to bind to the same UDP port.

A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.

Easier solution is the port forward.  What you're asking for is a rather convoluted solution that adds several new risks and failure modes.

[Sergio Lopez]

No. Operating systems don't allow two applications to bind to the same UDP port.

A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.

Easier solution is the port forward.  What you're asking for is a rather convoluted solution that adds several new risks and failure modes.

But he cannot do a port forward due to the internet he is using, that's why he is looking for an alternative.

[Matthew Kosmoski]

But he cannot do a port forward due to the internet he is using, that's why he is looking for an alternative.

I get that.

Unfortunately, there isn't much of an alternative.  A dedicated IP VPN would be easier than the aforementioned suggestions.

[Matt Bromback]

No. Operating systems don't allow two applications to bind to the same UDP port.

A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.

Would running a Macro program solve this? I.E have it hit your PTT every 30 seconds for 1 second?

[Matthew Kosmoski]

No. Operating systems don't allow two applications to bind to the same UDP port.

A solution idea - some lightweight software which would mute your mic input to vSTARS/vERAM/VRC and press your push to talk every 30 seconds or so. When you manually press your PTT, it works normally.

Would running a Macro program solve this? I.E have it hit your PTT every 30 seconds for 1 second?

Sure it would, but there's risk associated with that.  Most of us have other things going on while we control, and if you have that going and you pick up the errant swear, it's bad for everybody.

The next logical step would be to have that macro also mute your mic to mitigate that risk, but as we add complexity, we reduce reliability and resiliency, and we'll be back at square one before we know it.  New risks, same problems, unfortunately.

[Robert Shearman Jr]

I've just run into an interesting related problem as I have just started training for ATC again within the last month.  I fly on one PC in my household and control on another, as my flight sim setup has the keyboard in a position that's not convenient to do a lot of typing on.  My router forwards the appropriate port to my flight sim PC to avoid PTT issues while flying, but the other day while controlling Ground at a very slow airport, I had the issue come up on my controlling PC.

I don't suppose there's a way to open the port on my router to both machines?  I'm certainly not a tech guru so maybe there is.  Otherwise, I'm going to try Andrew's suggestion and will report back in a few weeks, I guess.

[Daniel Hawton]

I don't suppose there's a way to open the port on my router to both machines?  I'm certainly not a tech guru so maybe there is.  Otherwise, I'm going to try Andrew's suggestion and will report back in a few weeks, I guess.

No.. because when "stuff" comes into that port that isn't part of an already established connection, the router won't know which computer to push it to.  So when the connection gets dropped, there isn't an established.. so it defaults to the forwarded port setting.  If you were able to have more than 1, well, it won't know where to send it.

[Robert Shearman Jr]

I don't suppose there's a way to open the port on my router to both machines?  I'm certainly not a tech guru so maybe there is.  Otherwise, I'm going to try Andrew's suggestion and will report back in a few weeks, I guess.

No.. because when "stuff" comes into that port that isn't part of an already established connection, the router won't know which computer to push it to.  So when the connection gets dropped, there isn't an established.. so it defaults to the forwarded port setting.  If you were able to have more than 1, well, it won't know where to send it.

Gotcha.  That was my understanding, but I didn't know if it perhaps could be sent to both where it would be ignored by one.  But I appreciate the confirmation.

[Robert Shearman Jr]

Question -- if using AutoHotKey to send a {LCtrl} every so often, should I see the "Tx" light light up on my primary frequency?  Because, I don't.  I'm seeing it when I physically press Left-Control, but not at any other time.  I even modified the script to (a) reduce the wait time to 15 seconds, just for testing purposes, and (b) included a "SoundBeep" command just for testing so I would know when it was being sent.  I hear the beep every 15 seconds but I see no activity on the Transmit light.  I'm aware that AutoHotKey sends only to the "Active" window and I am sure that the VRC window has the primary focus at the time.  Any advice is appreciated.  Otherwise, maybe I'll just be sure to control when the frequency isn't bound to be so dead, lol...

[Matthew Kosmoski]

Question -- if using AutoHotKey to send a {LCtrl} every so often, should I see the "Tx" light light up on my primary frequency?  Because, I don't.  I'm seeing it when I physically press Left-Control, but not at any other time.  I even modified the script to (a) reduce the wait time to 15 seconds, just for testing purposes, and (b) included a "SoundBeep" command just for testing so I would know when it was being sent.  I hear the beep every 15 seconds but I see no activity on the Transmit light.  I'm aware that AutoHotKey sends only to the "Active" window and I am sure that the VRC window has the primary focus at the time.  Any advice is appreciated.  Otherwise, maybe I'll just be sure to control when the frequency isn't bound to be so dead, lol...

Yes.  If the AHK is actually hitting it and causing the client to burp a Tx, you'll the Tx light.  If it's so quick you don't see it for some reason, you could have a buddy get on your freq when you're doing this and tell you if they see or hear the rx flag.