The first and primary thing a DIGI_NED digi can do is digipeating. But not just simply digipeating. DIGI_NED is a very flexible configureable digipeater. a DIGI_NED digi does support:
- Generic digipeating,
( with call substitution )
- Manipulation of digipeaterpath,
( TRACEn-n, WIDEn-n, SSID routing)
- Duplicate checking,
Using digipath manipulation it is possible to create new digipeater rules or algorithems. Mainly your digi-owner will configurate the basic digipeat rules as they are published by the APRS committee.
You do not have to contact the digi about digipeating. Digipeating and the digipeater path is set in the APRS client program. For information about how to configure your APRS client we refer to the manual of your APRS client. Beacuse we do deliver a default configuration to the DIGI_NED package we can say something about digipeating:
NOTE: the type of routing mechanism is subject of change ! For up to date information about the routing mechanism check the APRS SIG (Special Interest Group) on http://www.tapr.org.
NOTE2: Currently the new PARADIGM routing mechanisme is being implemented. Paradigm holds portions of the principles that ar described on these pages.
Generic digipeating with call substitution.
In APRS the digipeater-path is constantly manipulated. An APRS station uses generic calls out of your "via" list the digipeater path, such as 'RELAY', 'TRACE', 'WIDE' etc. This will be picked up by the digipeater, replaced by the digipeater's own call-sign and retransmitted. The clue is that an APRS station doesn't need to know which name a nearby digipeater has. The station just sends its frame with 'WIDE' in the via path and any digipeater in the area which responds to 'WIDE' will pick it up; there can be more digipeaters who do this at the same time. .
Intelligent digipeating: WIDEn-n TRACEn-n
The WIDEn-N format needs some special handling which is done by so called "intelligent" digipeaters such as DIGI_NED.
When a station starts with a digipeater like WIDE5-5 in the via path, the first "intelligent" digipeater that takes this frame will be change the call to WIDE5-4 as soon as it passes it. On the second "intelligent" digipeater it will become WIDE5-3 and so on until after the 5th digipeater the call has become WIDE5-0 (in other words WIDE5). Then the "digipeated" bit will be set (visible in most monitors by a '*' indication) and the next digipeater call in the via list will become due. TRACEn-N works similar. There is a lot to talk about this but that's out of context here.
All kind of manipulation can be done on the digipeater path, such as replacement with a completely new path, addition of digipeater calls to the via list etc.
When mobile or portable the range of your transmitter is limited due to fysical limitations of the surrounding area. In that case it is importand to increase the chance of the reception of your packets bij a RELAY or even a WIDE. This can be obtaind by creating a packet radio frame as short as possible. The common frame with all digipeaters is not short so SSID digipeating is a solution.
Even using the 'mike-encoded' or compressed APRS format it is possible to use the SSID of the address.
- -8 will go north-bound,
- -9 will go south-bound,
- -10 will go east-bound,
- -11 will go west-bound,
Using SSID routing it is also possible to give your APRS packets a direction.
- -12 will go north-bound with additional WIDE,
- -13 will go south-bound with additional WIDE,
- -14 will go east-bound with additional WIDE,
- -15 will go west-bound with additional WIDE.
To prevent APRS frames from 'singing around' due to faulty digipeater paths a intelligent digipeater is capeable of checking wethever a frame is repeated or not. A DIGI_NED digi uses for this two mechanisms:
Call substitution: By replacing the digipeater call or alias in the digi-path for his own callsign the digi prevents it self from transmitting a frame which it did send allready. the digi checks if his own call is in the digipath it will not transmit it again.
Duplicate checking: From every frame a DIGI_NED digi is transmitting the checksum is stored in a table. When a frame is received which should be re-transmitted it's checksum is compared to the one in the table. When there is a match the frame is already transmitted and so discarded