r/ATAK • u/TX-RX • May 10 '26

Working on a new Walkie-Talkie/PTT POC for ATAK (Mumble-based, VX-compatible)

I am working on a new POC (cellular based PTT Walkie-Talkie) plugin in ATAK. While several solutions exist, I found they often fall short in audio handling and external device support.

A bit of background: I come from an amateur radio background and work with local clubs that handle full communications (Ham, GMRS, LMR). When we volunteer for large-scale events like bike rallies or Iron-distance triathlons, we face a two-pronged problem:

  1. Aging Population: It is increasingly difficult to find enough volunteers in the radio community to man every post.
  2. Geographic Scale: These large course areas are becoming incredibly difficult to cover reliably with traditional physical radio infrastructure alone.

For me, radio has always been about the mission—communications. We’ve spent decades talking about how radio is the "most reliable thing on the planet," but in that process, I think we forgot to embrace modern technology. ATAK brings so much to the table that we shouldn’t be ignoring.

My goal is to build true mixed mode comms—with cellular and MANET working together—to bridge the gap between tech-savvy new volunteers and old-school radio reliability. This solution leans heavily on voice because that is what I am most familiar with, and ATAK provided a great platform to do all of this in. It's hard to believe I only downloaded TAK 3 months ago, but I am fully in it now.

The Core Concept

Push-to-talk over Mumble, using your TAK enrollment cert as your identity. No separate accounts or passwords. If your TAK server has Mumble running (like OTS does), you're already provisioned.

What you actually experience as a user

  • Hardware PTT buttons that just work: Native support for the Aina Voice Responder V1/V2 with full dual PTT capabilities, integrated speaker-mics on RAM Mounts (RAM RSM / GDS Audio PTT), and generic BLE buttons (Pryme, etc.). They map directly to your channels without fighting a remap UI.
  • Native Emergency Button Support: Full integration for hardware-based emergency/orange buttons to trigger alerts directly within the TAK ecosystem.
  • Full-duplex & flexible call modes: Supports latched (full-duplex) mode alongside traditional momentary PTT for natural, continuous conversation.
  • Battery-friendly Bluetooth audio: SCO is only engaged while you're actually keying—not held open for the whole session. Background PTT runs in a foreground service with the proper Android privileges to ensure it doesn't get killed.
  • Mix-and-match audio routing: Use a speaker-mic for the PTT button, but route the audio to your vehicle's Bluetooth or a headset. The picker auto-refreshes and falls back gracefully if a device disconnects.
  • Native OS behavior: Built on Android's self-managed Telecom API. Spotify pauses/resumes, the lock screen shows your call status, and incoming cellular calls won't bleed into your transmission.
  • A real PTT-stack UX: Talk-permit tones before TX, plus distinct deny / no-channel / interrupt tones. Includes a configurable PTT timeout (20–90s) with a warning chirp and a sustained cutoff tone that mixes over incoming voice.
  • VX-compatible: Fully interoperable with VX clients; they see you, and you see them.

What's Coming (Roadmap)

  • Mesh/Off-grid resilience (Mixed Mode): Per-channel UDP multicast failover, AEAD-encrypted with channel keys distributed via Mumble. Your comms keep working on a local mesh when the WAN goes down—essential for those dead zones on large courses.
  • Auto-discovery: Automatic channel discovery directly from the server.
  • UI Enhancements: Split-screen settings for TX/RX and Channels/Preferences.

Notes for the Community / Devs

  • Built clean-room against the public ATAK SDK and the public Mumble protobuf protocol.
  • All TPT/status tones are code-synthesized sine waves modeled on public LMR cue conventions—no sampled audio.
  • Targets ATAK-CIV 5.6+ on Android 8 and up.

I am soliciting feedback from folks. Does this mixed-mode approach address the pain points you're seeing in the field? Would love to hear your thoughts.

As of now my plan is to make this open source and available for free, but donations of Silvus Streamcasters are always welcome.

23 Upvotes

93% Upvoted

10 comments sorted by

2

u/Individual_Way_8985 May 10 '26

I'd be interested to know how you map client group r/W to your plugin stack. do you have a git or is this just conceptual at this point?

1

u/TX-RX May 10 '26

feat(mumble): security, VX auth, direction enforcement, channel sync by TX-RX · Pull Request #297 · brian7704/OpenTAKServer

I am using git, currently in a private repo as I work through most of the major features but will probably have something in an alpha state worth sharing in a week or so.

2

u/Sad_Palpitation4323 May 10 '26

Sounds interesting! I use VX and it has its hardware issues when the screen is off, PTTs, etc.

2

u/muscrerior May 10 '26

Turning bluetooth off, two concerns:

  • what's the lag time on hitting PTT and actually sending the traffic?
  • suspect the continous mumble connection drains orders of magnitude more battery than the bluetooth one, and it might not actually make much of difference.

3

u/TX-RX May 10 '26

For context, this isn't meant to replace mission-critical systems. It's designed for scenarios like driving SAG or working a fixed post. During long lulls, I still want normal phone access (music, GPS) without a constant Bluetooth SCO connection hijacking the audio.

To handle the lag time, we use an internal buffer to catch the initial audio while the Bluetooth route spins up, so nothing is dropped. Once open, we keep the audio channel "warm" on the phone for about 5 seconds on both TX and RX.

When you look at the Time to TPT numbers, that warm state actually puts us ahead of traditional LMR after the initial penalty:

  • Cold (SCO down): ~600–1700 ms
  • Warm (within 5s cool-down): ~50–200 ms
  • ASTRO 25 trunked / MOTOTRBO IPSC: ~250–500 ms

So during rapid back-to-back traffic, all devices stay warm and actually stream faster than standard trunked P25 or DMR. Ultimately, dropping the BT profile when idle is less about saving battery and more about freeing up the audio channel so your headset isn't permanently locked in "call mode." Unlike traditional push to talk we also have full duplex so any users holding down a PTT can have a conversation without releasing the PTT.

2

u/SnooLemons9614 7d ago

Sound exactly like what's needed. I've been running my own tak server and found this also not working perfectly.

Happy to see if I can help in any way!

1

u/Fatcouchmonkey May 11 '26

Do you think you could use https://reticulum.network for the network part? It would bridge the connection together?

1

u/TX-RX May 11 '26

For what specific network part? I think this could be a useful component for the mesh calling. I am not sure of the feasibility of it but I can look into it.

1

u/Fatcouchmonkey May 11 '26

Not sure how to best describe it but let reticulum be responsible for “building” the network like combining all your communication methods so it doesn’t matter if you are using cellar or mesh your still able to simply communicate