To establish a connection to APRS-IS, establish a TCP connection to a port on an
APRS-IS server that provides the type of feed you desire. If your client software
is bidirectional (sends and receives), turn off the
Nagle algorithm when connecting to APRS-IS as it can introduce significant
All core servers
support port 10152 as a full feed port. Use this feed judiciously as the
packets per second and the overall bandwidth requirements will quickly overrun
most APRS clients and may overrun your ISP's capabilities. Most
servers support the HTML status port of 14501 which can be used to inform you of
other ports available on that server. Simply connect to that port with a
browser (http://aprsserver:14501) to view the page.
All core servers and most javAPRSSrvr servers (see the APRS Server page
elsewhere on this site) support port 14580 as a user-defined filter port.
This port begins by only sending message packets addressed to the client or
addressed to stations gated to APRS-IS by the client. As with ALL
bidirectional ports, ALL packets passed from the client are passed to APRS-IS on
a verified connection (more on that later). Most javAPRSSrvr servers use
javAPRSFilter to provide the server-side filtering capability.
javAPRSFilter is an additive filter. In other words, you start by
receiving almost nothing. When you add a filter, you now receive the
original few packets plus the packets that meet your filter definition.
See the Filter Definition page for more information.
WebSocket protocol. If a server has a
HTTP Send-Only port
it can support the WebSocket protocol (currently supported by the aprs-is server). The WebSocket protocol appears to the client just like any other TCP port with the following caveats:
- Supports no protocol indicator, or readwrite or history protocols only.
The default is readwrite which is the same as a user-defined filter port (port 14580).
- If the history protocol is requested, the port behaves like a user-defined filtered history port where the filter must be defined in the login line.
- The server sends binary messages only due to non-conforming packets. The client can send either text or binary messages.
Sysops request that the software name in the APRS login sequence be the web site if initiated from a web page or the application name if from a self-contained application.
Once you have connected to a server TCP port, you must log in after the server's
identification line is displayed (see
). The login
is formatted ( is optional, underlined words are keywords):
vers softwarename softwarevers[
- mycall-ss=your unique callsign-SSID (-SSID is optional but equates to
zero if omitted, see below). This must be unique throughout APRS and AX.25.
See below for formatting restrictions.
- passcode=computed passcode for your callsign. -1 is used for
receive-only. It is the responsibility of each software author
to provide the proper passcode to their individual users on a request basis. This is to aid in
keeping APRS-IS restricted to amateur radio use only.
While the algorithm to generate the passcode is available
from some open-source locations, I will not publish it here. If you are an
Amateur Radio operator writing software for APRS-IS, contact me directly for the
algorithm; otherwise, contact the software author for your passcode.
- softwarename=one word name of the client software. Do not use spaces.
- softwarevers=version number of the client software. Do not use spaces.
- udpport=UDP port number that the client is listening to
- servercommand=any command string (spaces OK) understood by the server.
This will normally be something like
to cause all packets from stations with 25 km of 33N 96W to be passed to the
A sample receive only log in sent to a server TCP port 14580 might be:
user AE5PL-TS pass -1 vers testsoftware 1.0_05 filter r/33.25/-96.5/50
javAPRSSrvr responds to a connection with a line starting with a # and
acknowledges the login with another line starting with a # (see
). Lines starting
with # are considered comments and ignored. Most servers will also
periodically send lines beginning with a # to check the connection if there has
been no activity on the TCP port.
All "packets" sent to APRS-IS must be in the TNC2 format terminated by a
carriage return, line feed sequence. No line may exceed 512 bytes including the
CR/LF sequence. Only verified (valid passcode) clients may send data to APRS-IS.
See the IGate document regarding gating packets to APRS-IS. Packets
originating from the client should only have TCPIP* in the path, nothing more or
less (AE5PL-TS>APRS,TCPIP*:my packet). For compatibility, the following
rules are for any station generating packets:
- q constructs should never appear on RF. Only the qAR and qAO constructs may be
generated by a client (IGate) on APRS-IS.
- The I construct should never appear on RF. This is an out-dated IGate
construct which should no longer be used.
- Except for within 3rd party format gated packets, TCPIP and TCPXX should not be used on RF.
Login Format Rules
Station logins/callsigns generally follow the TNC2/AEA standards for textual representations.
Logins/callsigns must be alphanumeric ASCII characters only (may be upper/lower/mixed case).
Logins/callsigns may contain a single hyphen followed by one or two alphanumeric ASCII characters.
A SSID of zero is assumed if the callsign does not have a SSID; therefore never explicitly define -0 as a SSID.
SSIDs may be 1 or 2 ASCII alphanumeric characters only.
Total length of logins/callsigns may not exceed 9 characters including the SSID if present.
The minimum length of the callsign only (preceeding the hyphen if present) is 3 characters.
RF and APRS-IS clients may convert lower or mixed case callsigns and SSIDs to upper case.
APRS-IS servers consider all callsigns-SSID combinations as unique regardless of case.
Callsigns (preceeding hyphen if present) are converted to upper case for passcode calculation.
Future APRS-IS servers may restrict logins to international
callsign format rules forcing uppercase for the callsign. The regex for
international callsigns is: