Skip to content

Using VAFM

VAFM is Vexillum’s analog FM linking mode.

It allows analog audio clients, radio interface nodes, link radios, and repeater adapters to connect to a Vexillum reflector using a software client. Instead of using a digital voice radio mode directly, VAFM carries analog FM audio through the reflector using encoded audio over the network.

For most users, VAFM feels like a networked analog voice channel: connect, configure your audio devices, press PTT, talk, release PTT, and listen.

Behind the curtain there is packet framing, Opus audio, sessions, keepalives, and other machinery. Fortunately, users should not need to care unless something breaks, which naturally it will, because audio devices are tiny portals to madness.

To use VAFM, you need:

  • A VAFM-compatible client
  • Your amateur radio callsign
  • The reflector hostname or IP address
  • The VAFM port
  • The transport type: UDP or TCP
  • A microphone, sound card, or radio audio input
  • A speaker, sound card, or radio audio output
  • Optional shared passphrase, if required by the reflector operator

If you are connecting a radio, repeater, or link node, you may also need:

  • A radio interface device
  • PTT control
  • COR, COS, or squelch detection
  • Audio level adjustment
  • Proper isolation between radio and computer audio
  • A reliable network connection

The reflector operator should provide the VAFM connection settings.

Typical settings include:

SettingExample
Hostnamevexillum.example.net
UDP port43000
TCP port43000
CallsignYour callsign
PassphraseProvided by the operator, if required

Vexillum’s common VAFM defaults are:

TransportDefault port
UDP43000
TCP43000

The operator may use different ports. Always follow the reflector’s published connection details.

VAFM can use either UDP or TCP.

TransportWhen to use it
UDPLower overhead, usually preferred for real-time voice
TCPEasier through some firewalls and tunnels, but may behave worse under packet loss

For normal real-time audio, UDP is usually the better choice. Voice can tolerate an occasional lost packet better than it tolerates delayed packets arriving late in a neat little TCP traffic jam.

Use TCP if:

  • UDP is blocked
  • You are testing through a tunnel
  • Your network only allows TCP outbound
  • The operator specifically tells you to use TCP

Use UDP if:

  • Both transports are available
  • You want the most typical real-time voice behavior
  • You are connecting a link node or radio interface

The exact setup depends on your VAFM client, but the general process is:

  1. Install or open your VAFM client.
  2. Enter your callsign.
  3. Enter the reflector hostname.
  4. Select UDP or TCP.
  5. Enter the correct VAFM port.
  6. Enter the shared passphrase, if required.
  7. Select your input audio device.
  8. Select your output audio device.
  9. Connect to the reflector.
  10. Verify that received audio plays through the correct output.
  11. Test transmit with a short call.

Do not start by changing every audio setting at once. Change one thing, test it, then move on. Audio troubleshooting rewards patience and punishes optimism.

Configure your normal amateur radio callsign in the client.

Use uppercase letters if the client does not automatically normalize it.

Good examples:

KC1AWV
N0CALL
W1AW

Avoid putting extra text, names, locations, or comments in the callsign field unless the client specifically supports that behavior.

Some VAFM reflectors may require a shared passphrase.

If a passphrase is required, the operator should provide it separately from the public connection details.

If authentication fails, check:

  • You entered the passphrase exactly.
  • There are no leading or trailing spaces.
  • You are connecting to the correct reflector.
  • You are using the correct transport and port.
  • The operator has not changed the passphrase.

Treat the passphrase as private. Do not post it in public chats, web pages, Git repositories, screenshots, or issue reports. Yes, screenshots count. They always count. The pixels remember.

Your audio input is what VAFM transmits.

This may be:

  • A microphone
  • A USB sound card
  • A radio interface input
  • A repeater receiver audio path
  • A virtual audio device

For voice use, select the device that carries the audio you want to transmit.

If your client has an input meter, speak normally and confirm that the meter moves without staying pinned at maximum.

Your audio output is where received VAFM audio plays.

This may be:

  • Speakers
  • Headphones
  • A USB sound card
  • A radio interface output
  • A repeater transmitter audio path
  • A virtual audio device

If you are using a radio interface, make sure received audio is routed to the correct transmit audio input on the radio or repeater path.

Audio levels matter.

Too low and nobody can hear you. Too high and you distort, splatter, clip, or otherwise make everyone regret owning headphones.

Start with moderate levels:

  • Set microphone gain low to moderate.
  • Avoid clipping.
  • Avoid aggressive software boost.
  • Disable unnecessary audio “enhancements.”
  • Use a test transmission only when the channel is clear.
  • Ask another operator for an audio report.

For radio interfaces:

  • Adjust receive audio from the radio into the computer.
  • Adjust transmit audio from the computer into the radio.
  • Avoid overdriving the radio input.
  • Confirm PTT timing is correct.
  • Confirm squelch or COR detection behaves properly.

Most VAFM clients use push-to-talk behavior.

Typical flow:

  1. Listen first.
  2. Press or activate PTT.
  3. Wait a brief moment.
  4. Speak.
  5. Release PTT.
  6. Wait for the other station to respond.

Leave a short pause before speaking after pressing PTT. This gives the client, reflector, and remote receive path time to start cleanly.

Also leave a short pause between transmissions. Reflectors are shared systems, not full-duplex conference calls wearing a callsign badge.

Current VAFM beta behavior allows one active talker at a time in a shared room.

That means:

  • The first accepted transmission becomes the active stream.
  • Other users should wait until the current transmission ends.
  • If two people transmit at once, one may not be heard.
  • Releasing PTT properly helps the reflector clear the active stream.

Listen before transmitting and avoid doubling with another station.

When another user transmits, your client should receive and play audio automatically.

If you see receive activity but hear nothing:

  • Check output device selection.
  • Check system volume.
  • Check client output volume.
  • Check whether the wrong sound card is selected.
  • Check headphones or speakers.
  • Confirm the client is not muted.
  • Confirm the reflector is actually forwarding audio.

If you hear audio but it is distorted:

  • Reduce output level.
  • Check sample rate settings if exposed by the client.
  • Check the radio interface levels.
  • Ask whether other users hear the same distortion.

When you transmit, your client sends encoded voice audio to the reflector.

If others cannot hear you:

  • Confirm you are connected.
  • Confirm PTT is actually active.
  • Check input device selection.
  • Check microphone permission.
  • Check input level.
  • Confirm the client shows transmit audio activity.
  • Confirm the reflector requires no additional authentication.
  • Confirm you are not transmitting while someone else is already active.

If others hear silence, your PTT may be working but your audio input may be wrong. This is the classic “the button works, the sound does not” problem, because naturally those are separate ways to fail.

VAFM can be useful for analog radio linking, but radio interfaces require more care than a normal headset.

Check:

  • Audio input path from receiver to client
  • Audio output path from client to transmitter
  • PTT control method
  • COR/COS/squelch detection method
  • Ground isolation
  • Audio isolation
  • Transmit audio level
  • Receive audio level
  • De-emphasis and pre-emphasis behavior
  • Local regulations and station identification requirements

If you are connecting VAFM to a transmitter, repeater, or link radio, make sure your setup complies with amateur radio rules in your jurisdiction.

VAFM needs a stable network connection.

For best results:

  • Use wired Ethernet where possible.
  • Avoid weak Wi-Fi links.
  • Avoid overloaded VPN paths.
  • Prefer UDP for real-time voice when available.
  • Keep latency and packet loss low.
  • Avoid running large uploads on the same connection while using VAFM.

Symptoms of network problems include:

  • Choppy audio
  • Delayed audio
  • Dropped transmissions
  • Frequent reconnects
  • Audio that starts late
  • Audio that cuts off early

Use the client’s disconnect or quit function when finished.

A clean disconnect lets the client tell the server that the session is ending.

If the client crashes or the network drops, the server will eventually time out the session, but clean disconnects are better. Civilization is built on tiny acts of not making servers guess.

Before connecting:

  • Callsign is correct.
  • Hostname is correct.
  • Port is correct.
  • UDP or TCP selection is correct.
  • Passphrase is correct, if required.
  • Input audio device is selected.
  • Output audio device is selected.
  • Input level is not clipping.
  • Output level is comfortable.
  • You know how to activate PTT.

Before transmitting:

  • Listen first.
  • Make sure the channel is clear.
  • Keep the first test short.
  • Identify with your callsign.
  • Ask for an audio report if needed.

Check:

  • Reflector hostname
  • Port
  • UDP versus TCP setting
  • Internet connection
  • Firewall rules
  • Whether the reflector is online
  • Whether the VAFM service is enabled
  • Whether a passphrase is required

Try TCP if UDP appears blocked. Try UDP if TCP connects but audio behaves poorly.

Check:

  • Passphrase spelling
  • Leading or trailing spaces
  • Correct reflector
  • Correct port
  • Correct transport
  • Whether the operator changed the passphrase

Do not keep retrying rapidly. Fix the setting first. Authentication logs do not become more correct through repetition.

Check:

  • Output device
  • Speaker/headphone volume
  • Client mute setting
  • System mixer
  • Whether anyone is actually transmitting
  • Whether the reflector has other connected users
  • Whether audio is being routed to a radio interface instead of speakers

Check:

  • Input device
  • Microphone permission
  • PTT activation
  • Input gain
  • Whether the client shows audio activity
  • Whether someone else is already transmitting
  • Whether authentication is required
  • Whether the reflector is receiving your packets

Check:

  • Microphone gain
  • Radio interface level
  • Software boost
  • Input clipping
  • Output clipping
  • Overdriven transmitter audio
  • Audio processing or enhancement settings

Turn levels down first. More gain is not more better. It is just louder evidence.

Check:

  • Network latency
  • Wi-Fi quality
  • VPN behavior
  • TCP versus UDP selection
  • CPU load
  • Audio buffer settings, if exposed by the client

If using TCP and audio delay builds up during packet loss, try UDP.

Try:

  • Press PTT.
  • Wait a brief moment.
  • Then begin speaking.

Some audio paths need a small amount of time to open cleanly.

Try:

  • Speak.
  • Pause briefly.
  • Release PTT.

This can help make sure the last syllable is encoded and sent before the transmission ends.

When reporting a VAFM problem to the reflector operator, include:

  • Your callsign
  • Reflector hostname
  • UDP or TCP
  • Port
  • Client name and version
  • Operating system
  • Audio device used
  • Time of the problem
  • Whether receive worked
  • Whether transmit worked
  • Any error message shown
  • Whether other users had the same issue

A useful report gets fixed faster. A report that says “it broke” gets lovingly placed in the pile labeled “guesswork.”