PTT control?

[f5mzn]

Hi Tobias,

I'm doing my first tests with remoteAudio. I like the idea to base the routing of the audio frames through Nats, and very impressed by the extremely low latency. For my test, I have a micro Keyer II connected to a Windows 10 machine, a Nats server running on a Raspberry 4, behind a Gb/s Ftth. My client is running on a macbook and connect to the Internet via a 4G wifi gateway.

For now, I didn't figured out how to remote control the PTT. I can see that PTT events are routed by Nats but as far as I understood it can just enable/disable the audio.tx messages for being processed. Is there is way to control the PTT in remoteAudio, maybe via the micro Keyer, at this step of the development?

Best regards and 73.

Olivier / f5mzn.

[dh1tw]

Hey Olivier!
Glad to hear that you consider remoteAudio useful! Your observations are correct. RemoteAudio doesn't handle the actual PTT signal of the radio. I excluded PTT handling deliberately because there are so many different ways PTT is interfaced with your actual radio, remote Controller, or 3rd party software (e.g. via Microkeyer, GPIO or other ways).

As a quick & dirty solution, you could enable VOX on your radio and use the VOX functionality in remoteAudio.

The easiest way to control remoteAudio is through it's REST Interface. Check out the wiki article
Integrate with 3rd party Software (REST Interface)

I personally use a TS480 with a OrangePiZero + Custom Hat PCB on each end. I wrote a small "proxy / bridge" application which relays PTT, CAT and WinKey from the Client to the Radio via NATS topics.
Basically the application reads the PTT state of a GPIO pin and then sends the state via a nats topic to the radio where the GPIO pin then drives again PTT. Simultaniously the application makes an HTTP REST call to enable / disable the TX Audio stream in remoteAudio.

I hope this helps!

73 Tobias, DH1TW

[K6TD]

I did the same, with almost the same hardware for a pair of 6700s @ K6MTU. The use of NATS saves a lot fo code - finding the output device, handling multiple input devices, etc. Some protection is needed in the TX end…I put in a TX timer of 20 min, as will as NATS disappeared. The 6700 has strange issues with multiple PTT sources, so that has to be handled as well. The K6MTU shack is very remote. We put LEDS on a panel, so if someone is in the shack, they can see a remote is pressing PTT. 73, K6TD

…

On May 5, 2023, at 3:45 PM, Tobias Wellnitz ***@***.***> wrote: Hey Olivier! Glad to hear that you consider remoteAudio useful! Your observations are correct. RemoteAudio doesn't handle the actual PTT signal of the radio. I excluded PTT handling deliberately because there are so many different ways PTT is interfaced with your actual radio, remote Controller, or 3rd party software (e.g. via Microkeyer, GPIO or other ways). As a quick & dirty solution, you could enable VOX on your radio and use the VOX functionality in remoteAudio. The easiest way to control remoteAudio is through it's REST Interface. Check out the wiki article Integrate with 3rd party Software (REST Interface) <https://github.com/dh1tw/remoteAudio/wiki/Integrate-with-3rd-party-Software-(REST-Interface)> I personally use a TS480 with a OrangePiZero + Custom Hat PCB on each end. I wrote a small "proxy / bridge" application which relays PTT, CAT and WinKey from the Client to the Radio via NATS topics. Basically the application reads the PTT state of a GPIO pin and then sends the state via a nats topic to the radio where the GPIO pin then drives again PTT. Simultaniously the application makes an HTTP REST call to enable / disable the TX Audio stream in remoteAudio. I hope this helps! 73 Tobias, DH1TW — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARCTTZGP5YPB23SJM7ZOGDXEV7JTANCNFSM6AAAAAAXOA4SXA>. You are receiving this because you are subscribed to this thread.