Australian APRS-IS Internet Server ports.

Updated: 12/03/2007

The Australian APRS-IS servers support the following ports for the TCP distribution of APRS data.

It is recommended that all clients connecting to this server use port 14580 with a user-defined filter setting to reduce traffic loads on their internet connection.

Port 14580

• Provides user defined filtered feed for APRS data.
• Can be defined using these commands.

Port 14579

• Provides filtered feed of only VK* and ZL* internet data.
• Will display only stations and objects that are located within 4500km of 34S 146E, plus any VK* and ZL* anywhere in the world.
• This port reduces internet connection traffic.

Port 14578

• Provides filtered feed of only ZL* internet data.
• Will display only stations and objects that are located within 1000km of 37S 175E, plus any ZL* anywhere in the world.
• This port reduces internet connection traffic.

Port 10149

• Provides filtered feed of only ARISS and PCSAT data.
• Will display only stations and objects that have been digipeated by ISS or PCSAT
• Will display Telemetry beacons from PCSAT
• Bi-Directional so SATGATES may send downlink data from the sats into this port.
• May be configured as Tx Only.

Port 14570

• Provides filtered feed of IRLP Node Status data.
• Tx Only

WX Only Port 2323

• Provides weather only filtered  feed data.

HTTP Port 14501

• Function: Supplies server status information in HTML format. This port is accessed with any web browser by entering the URL: http://first.aprs.net.au:14501/ (replace "aprs.net.au" with the domain name of the aprs server you want ) To refresh the data click the RELOAD button on your browser.

Less common ports.

Other ports have been configured on the APRS-IS Core servers to provide additional filters and connection types. Information on these servers can be found here http://core.aprs.net/

It is not recommended you use the APRS-IS Core servers unless you are experienced with APRS-IS. Instead follow the information above. Follow this link http://www.aprs2.net/ if you want to know more about the Tire Two servers.

REFORMATTING

Data from AEA TNCs is converted to TAPR format before being sent to clients.

Station to station messages of the 3rd party kind:

If it came from a logged on verified registered user.
and
The originator was not seen on the TNC RF data stream in the past 30 minutes.
and
The destination HAS been seen on the TNC RF data stream in the past 30 minutes and doesn't have "GATE*" in his path and has been repeated less than 3 times.

For each 3rd party message delivered to RF the latest position report packet of the originating station will also be sent after reformatting the path in 3rd party format. The program pulls the posit from the history list.

eg:
VK3JFK>AP0917,VK3MY-1,WIDE:=3415.99N/11844.34WyAPRS+SA
becomes:
}VK3JFK>AP0917,TCPIP,VK3SB*:=3415.99N/11844.34WyAPRS+SA
(assuming "IGate Call" is VK3SB )

During a series of messages the position packet will only be sent with a message every 10 minutes unless the station emits a new one.

This server will NOT igate a 3rd party reformatted message from RF to the Internet. This is strictly one way.

Users of unregisterd client programs can send their own station-to-station messages to other Internet users. These messages will not go out on the TNC RF channel and the path will be modified (TCPIP* is changed to TCPXX*) so other hubs will know not to send these messages out on their RF channels. Unregistered users cannot Igate packets other than their own. In other words, the ax25 source call in their packets must match their logon call.

eg; assume VK3ABC is unregistered and attempts to send the following into the server.

VK3ABC>APRS,TCPIP:>TESTING This will be converted to VK3ABC>APRS,TCPXX*:>TESTING and gated to other users (but not to RF ever!)

However... VK3XYZ>APRS,TCPIP:>TESTING will be deleted and not sent anywhere.

Telnet users must provide a user name or call sign before any of their data can be relayed to the internet. They need to enter "user callsign pass -1" so the server will accept the data. The ax25 FROM call in packets they send must match the call sign they logon with. If they provide a valid password full privileges are granted since they used the keyboard to emulate a client program logon string. (Not that anyone would want to do this except for testing)

<BACK>

 Richard Hoskin VK3JFK