Digipeater Preferences

Digipeater Preferences Screenshot


Checking the box will enable digipeater functionality. However, before packets will be digipeated, one or more routes need to be defined.

Digipeater Routes

A digipeater route consists of 3 elements:

  1. From - This is the connection that packets will come from.
  2. To - This is the connection that packets will be repeated to.
    • It is completely normal and expected to have the same connection as the From and the To parameters; it simply means that packet will be digipeated on the same connection that they were heard on.
  3. Alias - This is the digipeater alias(es) that QTH.app will respond to.
    • This defaults to WIDE1-1 for a simple fill-in digipeater, but it does support regular expressions, such as WIDE[0-3]-[0-3].

Automatic New-N Support

Any aliases that have the pattern ALIASn-N will automatically have the last number decremented before digipeating.

Internet Gateway (IGate)

Enabling the checkbox will cause QTH.app to pass traffic to and from the RF networks and APRS-IS network.


All packets will be gated to APRS-IS EXCEPT if any of the following are true:

  1. 3rd-party packets with TCPIP or TCPXX in the 3rd party header.
    • These are packets that have already visited the Internet. No need to send them back.
  2. Generic queries (data type ? )
    • These queries are only intended for the local area and would generate far to much traffic if gated to the Internet.
  3. Packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header
    • Stations can include these aliases in the via path to prevent packets from being gated to the Internet.


ONLY the following packets will be gated from APRIS-IS to RF:

  1. Messsages destined for stations that have been recently heard on RF.
    • In the case where there are multiple RF connections, the connection where the station was most recently heard will be selected and the packet will only be transmitted out that connection
  2. Positions from stations who have recently had a message from #1 gated to RF

QTH.app operates as a two-way IGate unless there are no Local-scope connections thaht have been enabled for transmit. For the benefit of the APRS network, if you are going to operate an IGate, it is recommended that it should be a two-way IGate, not a receive-only IGate.