Connecting to APRS-IS


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 delays (TCP_NODELAY).

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 and it is javAPRSSrvr, it can support the WebSocket protocol. It is currently supported by srvr.aprs-is.net:8080 and ametx.com:8888 (secure). The advantage of using the WebSocket protocol is the built-in support for proxies at the client end. Also, some wireless carriers allow for extended HTTP data vs. inline data. The WebSocket protocol appears to the client just like any other TCP port with the following caveats:

Once you have connected to a server TCP port, you must log in after the server's identification line is displayed (see Server Design ). The login is formatted ([] is optional, underlined words are keywords):

user mycall[-ss] pass passcode[ vers softwarename softwarevers[ UDP udpport][ servercommand]]

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

With the release of javAPRSSrvr 4.3.2b76, some servers now support encoding the login line using Base64. While this is NOT secure, it does obscure the login line from plain text sniffers. This was done so javAPRSSrvr properly implements RFC 7235 with the added benefit that any login line can be encoded. This is currently only implemented in javAPRSSrvr 4.3.2b76 and later.

javAPRSSrvr responds to a connection with a line starting with a # and acknowledges the login with another line starting with a # (see Server Design ). 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:

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:
(?>[1-9][A-Z][A-Z]?+[0-9]|[A-Z][2-9A-Z]?[0-9])[A-Z]{1,4}+

SSID and callsign restrictions vary depending on intended use. Assume that if you are going to message or use a station on RF, the callsign and SSID must be upper case. If you are going to transmit on RF directly (directly to the TNC, not via 3rd party gating), you must use a SSID from 0 to 15 (-0 is never used, no SSID represents a zero SSID) (AX.25 SSID). If you are going to message to some Yaseu radios, you must use an AX.25 SSID as they will not respond to a non-AX.25 SSID even if contained in a 3rd party packet. SSIDs are a maximum of 2 alphanumeric characters, period. This maintains compatibility across all software and hardware. Some software does not differentiate between lower and upper case. Always use upper case for callsign and SSID.