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. Turn off the
Nagel 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 all 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.
Once you have connected to a server TCP port, you must log in. The login
is formatted ([] is optional, underlined words are keywords):
user mycall[-ss]
pass passcode[
vers softwarename softwarevers[
UDP udpport][
servercommand]]
- mycall-ss is your unique callsign-SSID (-SSID is optional but equates to
zero if omitted). This must be unique throughout APRS and AX.25
- passcode is the computed passcode for your callsign. -1 is used for
receive-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.
- softwarename is the one word name of the software. Do not use spaces.
- softwarevers is the version number of the software. Do not use spaces.
- udpport is the UDP port number that the client is listening to
- servercommand is any command string (spaces OK) understood by the server.
This will normally be something like
filter r/33/-96/25
to cause all packets from stations with 25 km of 33N 96W to be passed to the
client.
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 #. 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 construct 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 gated packets, TCPIP and TCPXX should not be used on RF.