APRSISCE/32 currently supports a UITRACE style digipeating. That is to say that it supports the callsign insertion and SSID decrementing digipeat request on a specified alias.

A packet asking for a WIDE2-2 hop request will be digipeated where the resulting change in the hop request will take this form: MYCALL*,WIDE2-1

APRSISCE/32 uses a rule based routine, where each specific hop request to be acted upon is explicitly defined, as well as the resultant output. This allows for a higher degree of control over the aliases acted upon, but also requires more work to be set up.

Digipeaters like the Kantronics line make it difficult to limit the number of hops supported, and it is easy to circumvent the pseudo-limits imposed by such means. In the APRSISCE/32 rule based digipeater, it is impossible to get the digipeater to act upon any hop request that is not explicitly defined.

To be able to configure APRSISCE/32 to support digipeating, you will need to shut down the program and edit the XML file.

Read about Editing the XML file Editing XML

Note that <DigiXform> elements are currently only honored OUTSIDE of an <RFPort> and are considered to be global in their application. This means:

<!- -RFPort[0]- ->
<RFPort Name="AGW">
<!- -DigiXform- -><!— NOT this one! —>
<!- -RFPort[0]- ->

<!- -RFPort[1]- ->
<RFPort Name="KISS">
<!- -DigiXform- -><!- - NOT this one! —>
<!- -RFPort[1]- ->

<!- -DigiXform- -><!- - THIS One! - ->

Home fill-in digipeaters are set up so that they only act upon a single specific subset of the WIDEn-N requests, namely the WIDE1-1 request.

A WIDE1-1 digi would be configured as thus:


A wide area digipeater that forms a part of the full infrastructure in the local APRS network, but limit the number of hops supported to 2 or less would need to be configured to support WIDE1-1 as above, but also WIDE2-2 and the second hop WIDE2-1.

A WIDE2-N digi would be configured as thus:


It is very easily possible to bypass the psuedo hop limits that are implemented in the Kantronics style digipeaters by using a non-standard hop request. These non-standard requests are also sometimes accidentally entered by people that just don't understand the basic premise of digipeating and hop requests. Non-standard hop requests would look something like this: WIDE2-4

The configuration shown above would simply ignore these non-standard hop requests. The configuration below would act upon a non-standard hop request, but would decrement the SSID down to zero, effectively stopping any further digipeats.

A WIDE2-N that wanted to truncate paths would be configured as thus:


To Regenerate a path (You really DON'T want to do this!):


Or even (WORSE!):


Longer Answer: I've got some interesting ideas on cross-band digipeating, but am currently working through the configuration of the beast so that mere mortals have a chance at making it work, while at the same time, it would be difficult to configure it badly which can have severe ramifications on our shared channels.

The work I'm doing now with renovating the AGW/KISS/TEXT interface implementation is being done with exactly that focus, cross-band digipeating and bi-directional IGating, but with varying paths per interface and individual enables of each feature.

Consider the following snippet of a configuration file I'm working on for VHF digipeating. And then figure out how to apply such a configuration approach to a cross-band, actually X-way cross, digipeater. Like a single APRSIS32 instance with KISS to 2m VHF, AGW to 30m AX.25, TEXT to 30m PSK-63 (via APRS Messenger), and some other interface to listen to the ISS and be a Sat Gate…


UIFlood (sort of)
