Previous- Index- Web- next- page
The DIGI_NED FAQThe DIGI_NED FAQ, Version 1.02-032 Date: January 14, 2002 By: PE1MEW (pe1mew@qsl.net).
First layout by jean-philippe, F5SMZ.
About this manual
Preamble.
These are the DIGI_NED FAQ. This manual is intended to be the reference for APRS users using the near-by DIGI_NED digipeater and for DIGI_NED digipeater owners who wish to build and maintain their DIGI_NED APRS digipeater.
Contens of this MANUAL.
Availability and version number.
This manual uses the available documentation released with the DIGI_NED executeable and source distribution. In the top part of each page you can find the version number and release date.
Disclaimer.
This manual is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Comments and contributions.
If you have any additional comments or corrections to this documentation feel free to contribute.
To verify and add your contibution stick to these little rules:
Send your comments to the DIGI_NED team: digi_ned@qsl.net
The DIGI_NED FAQ
(based on released 0.3.0 "APND0U" - 03 June 2001)
Q: My beacon shows up at the wrong place,
is this a bug?
A: DIGI_NED does nothing intelligent with the beacon text and just sends it. One gotcha may be that the degrees and minutes are base 60 but the seconds value is base hundred. So if your location is N40o29'15", W105o04'54" then that will be 4029.25 and 10504.90 in the beacon file. So for this position it should be something like:
=4029.25NN10504.90E#PHG2110/DIGI_NED: N0ABC-2
Back to Questions List
Q: In the ini file I see the line -
digipeat: all DIGI_CALL all
Do I replace 'DIGI_CALL' with the callsign of my DIGI_NED station or is that
done within the code?
A: That's done within the code, this is replaced by whatever you specified with:
digi_call: n0abc-2
So this is equivalent to:
digipeat: all n0abc-2 all
Back to Questions List
Q: Here's some captured text from the
DIGI_NED.
*****begin quote*****
from:1 KF0ZH > APR819 via GATE* FTCOL* UIv PID=F0 68 bytes @291427z4447.06N/09329.48W_267/002g001t054r000p000....h97b10
173dU2k
===========
DigiEnd: Digipeater last done 'FTCOL', hop 2
No matching rule: ignore frame
*****end quote*****
FTCOL is a local digipeater with the tactical call FTCOL. There is another local
digi with the tactical call CSU (Colorado State University). It looks like DIGI_NED
is not doing anything with packets with FTCOL in the path, is this correct?
A: As you can see by the '*'
after each digipeater call, all digipeaters along the path already handled the
packet. The packet is now at the end of its journey.
In this case DIGI_NED will search for a 'digiend:' rule. DigiEnd is used to
pick up packets that have no unused digipeaters. The rules act on the last digipeater
in the chain. In this case there are no unused digipeaters (they all have a
'*' mark) and DIGI_NED will search for a rule with
a call that matches 'FTCOL'. It doesn't find such a rule, there isn't any.
There are only a few packets in the default .ini file that are picked up again
after they were already at their final destination. I have an example in the
.ini file which I use to feed packets to another QRG.
Those two are:
digiend: all wide*,trace* 2 add LOCAL
digiend: 1 pe1mew-2 2
The first one picks up all the packets received from any port where the last call was WIDE or TRACE or WIDEn-N or TRACEn-N etc (the '*' is a wildcard). I will do the 'add' operation which means that first of all the digipeater call is added and an then in this case LOCAL is appended to the digipeater path. This modified packet is send out through port 2, which is in my case a local 70 cm QRG.
The second picks up all packets which are received on
port 1 and ended at our local digipeater. There are no further operations so
now it does the default behavior, which is adding the own digipeater call and
send the packet our through port 2.
So if you want to pick up the packets that ended at FTCOL and repeat those,
then you have to add a rule for this. Normally packets which are finished should
be left alone, but reasons to pick it up could be to cover a black spot or,
as in my example, feed the packets to another QRG.
Example for you that does the trick:
digiend: 1 FTCOL 1
This picks up packets from port 1 where the last digipeater was FTCOL, adds your digipeater call (default behavior) and sends it back out to port 1. This is what you should see on transmission:
to:1 KF0ZH > APR819 via GATE* FTCOL*
N0EQ-2* UIv PID=F0 68 bytes @291427z4447.06N/09329.48W_267/002g001t054r000p000....h97b10
173dU2k
You could do the same for CSU:
digiend: 1 CSU 1
Of course you need to judge for yourself if these packets
need to be repeated and if it is not causing loops.
Back to Questions List
Q: Do I understand the following correctly:
digipeat: all DIGI_CALL all
All packets received by my DIGI_NED will be digipeated
and have my DIGI_NED station callsign inserted into the packet. Is this correct?
A: No. Assume "digi_call:" is
set to N0ABC-2.
The rule is specifying: Packets from all ports where the next digipeater call
in the via-list that shall be used is N0ABC-2, shall be send out to all ports
again. There is no further specification so it will do normal digipeating. This
is that that the call of the digipeater in the via path which is to be used
up is replaced by the callsign of the digipeater (in this case N0ABC-2 is replaced
by N0ABC-2 - no effect) and then the modified packet is send out through all
ports (you can have up to 8 ports).
You can also explicitly take packets from one port and send it out through another.
Example:
digipeat: 1 relay 2
This means: packets received from port 1 where 'relay'
it the next digipeater in the via path that shall be used shall be send out
through port 2. Also here not further actions are given so this is also normal
digipeating. That means that 'RELAY' is substituted by 'N0ABC-2' and the modified
packet is send out through port 2.
So if you receive this on port 1:
W0ABC>APRS,GATE*,RELAY,WIDE
Then the second 'RELAY' call is the next digipeater to
act on (the GATE call is marked with an '*' so is
already passed). Relay is substituted by your call so:
W0ABC>APRS,GATE*,N0ABC-2*,WIDE
is the path that is transmitted on port 2. Note that your
own call also gets a '*' because this hop in the via
list is now handled. The next digipeater will act on the 'WIDE' call.
Back to Questions List
Q: How can I prevent transmission of
bad paths?
Let's say I receive a packet from a station who's UI-path is RELAY,RELAY,RELAY,WIDE,WIDE,WIDE,
an obvious bad path. What and how would I modify in the ini file to convert
that to a more acceptable path?
A: It depends on how far the packet already progressed
in the chain, so the digipeater call following the "*"
symbol on reception. If there is no '*' on any call
you are the first to receive it. Now lets assume you are the first to receive
this.
In the default digi_ned.ini file "RELAY" is just does normal digipeating. So
this is what happens in your case: in:
PE1DNN>APRS,RELAY,RELAY,RELAY,WIDE,WIDE,WIDE
rule:
digipeat all RELAY all
out:
PE1DNN>APRS,PE1DNN-2*,RELAY,RELAY,WIDE,WIDE,WIDE
Now you can make this smarter if you have miss behaving
users in your area. You know that 'RELAY' should only be used once as the first
digipeater call. Now you can force a path on every station that uses "RELAY"
by redefining the path in the digi.
in:
PE1DNN>APRS,RELAY,RELAY,RELAY,WIDE,WIDE,WIDE
rule:
digipeat all RELAY all new WIDE3-3
out:
PE1DNN>APRS,PE1DNN-2*,WIDE3-3
Now all the stations that repeat through you using "RELAY"
will get the same path that is in this case your own call and WIDE3-3. So it
doesn't matter what your users fill in, after your digipeater relayed it, it
is "repaired".
Fixing paths like this is only something that should be done at the source.
When you get this frame:
in:
PE1DNN>APRS,RELAY,RELAY,RELAY,WIDE,WIDE*,WIDE
then there is nothing you can do to fix the path, is has
already progressed almost to the end.
Something you can do is for example avoid long digipeater paths by replacing
TRACEn-N with WIDEn-N.
in:
PE1DNN>APRS,RELAY*,PE1MEW-2,TRACE5-4
rule:
digipeat: all TRACE5-4 all swap0 wide5-3
out:
PE1DNN>APRS,RELAY*,PE1MEW-2,WIDE5-3
So now it is not tracing anymore, keeping the path short
and preventing it to grow longer.
So you can do this kind of things. You cannot make smarter rules saying for
example 'if RELAY appears more than 1 time then...', maybe when there is a need
for it I might add it, but I think it will make it even more difficult to understand
how it works.
Currently, and that is important to understand, DIGI_NED acts on the repeater
that is due for its 'digipeat:' rules.
'digiend:' works on the last digipeater when they are all used up, 'digito:'
acts on the destination call when there are no digipeaters in the chain and
'digissid:' acts on the destination call when there are only unused digipeaters
in the chain. Since "digipeat:" and
"digissid:" could both act on the same packet the
"digissid:" rules have a higher priority. When a "digissid:"
rule hits, "digipeat:" processing is skipped.
Back to Questions List
Q: In the default mode, using the ini
file(s) supplied, does DIGI_NED digi all packets?
A: Well I think (and hope) I covered the APRS generic
digipeater calls. If you want to digipeat just everything one simple rule would
be:
digipeat: all * all
But that does call-replacement on all calls and no smart
digipeating.
Back to Questions List
Q: .Can I change the digi_dest:
address APND0U to something else?
A: Yes, you can. I encourage you only to change it if
you want to use your digi in an ALTNET (read the APRS specification, this is
voor closed user-groups using an alternative "to" call). I think you should
otherwise stick to the default call since this address is assigned to DIGI_NED
in coordination with the APRS specification. The APNDxx call conveys information
that this is a DIGI_NED digi and this information is understood world wide by
APRS applications. Read the specification about the "APRS Software Version Number".
APN is now assigned for Intelligent Digi software. The 4th letter 'D' indicates
DIGI_NED. The '0U' at the end means version 0.3.0 (in base 36 notation), which
will of course be different in newer versions of the software.
Back to Questions List
Q: Can we somehow do remote maintenance
on DIGI_NED?
A: You as an owner can send an ?exit command to stop DIGI_NED
(if you have enabled this feature in digi_ned.ini). On our local digipeater
we start NetCHL after the DIGI_NED stopped running.
With TCP/IP we can upload new releases, new configurations, beacons etc. After
NetCHL exits the digipeater is restarted. This enables maintenance of a digipeater
when you don't have easy physical access to it. Use of external tools like NetCHL
gives more control and power over the system then I could ever build into the
digipeater itself. Under Linux you can of course do much more since you can
run multiple programs in parallel.
Back to Questions List
Q: Can we ?ping?
ourselves or force an output beacon?
A: Yes, you can send ?APRS? as a message which behaves
the same as the ?APRS? broadcast by sending all its
beacons.
If you use the DOS version you can type ?aprs?
on the keyboard to force a beacon.
Back to Questions List
Q: Can I use the queries locally from
the keyboard?
A: Yes for the DOS version, not for Linux. You can type
any query at the keyboard in DOS. DIGI_NED will use a fake source "KEYBOARD"
and destination "SCREEN". If you cannot see what you are typing or don't see
the response because the verbose logging scrolls the text off the screen you
can use ALT-V to switch off the verbose messages. When you are finished you
can do ALT-V once more to switch it on again. The keyboard queries will not
result in transmissions on the radio, except for ?APRS? which will cause beacon
transmissions on the first port.
The Linux version does not need all this, you can use a local loopback and XASTIR
to query the digi for example. Linux is a multi-tasking/multi-user system so
you can run other programs while DIGI_NED is running which gives you much more
power anyway.
Back to Questions List
Q: Can I make new queries and responses?
A: Yes, you can add/modify the "digi_nes.mes" file (or
another file defined with "message_file:" in digi_ned.ini).
When I want to add a query "?blah" which answers "Hello,
World!" I have to add the following to the file:
?blah
Hello, World!
It is as simple as that. If the message "?blah" or
"blah" is send to your DIGI_NED then DIGI_NED will answer to the originator
with "Hello, World!"
When I want to use a short cut for my query I can assign aliases for the command,
separated by a pipe symbol '|'. Assume I want a 'b'
as shortcut besides 'blah' then I have to change my
addition to the following:
?blah|b
Hello, World!
This query now responds to '?blah', 'blah',
'?b' and 'b' and answers to the originator
of the query with "Hello, World!".
Back to Questions List
Q: Can we use a second port to feed
received data to another APRS program. I.e. can we feed the DIGI_NED data to
WinAPRS and have the WinAPRS program function as a second terminal/station?
I guess it would be like using DIGI_NED as a LAN hub or router.
The different software(s) would all look to the DIGI_NED software for it's data
and in turn feed their own data to DIGI_NED to repeat back to the TNC for transmit.
A: Yes you can, the owner of our local digipeater uses
this. The easiest way is to use KISS on the second port. In AX25_MAC use the
flag -PKISS2 to create a 9600-baud KISS link on COM-2.
Let the APRS program you want to use connect to this port in KISS mode via a
null-modem cable (cross cable).
You can extend this even more, if you add the parameter -PKISS3
also to the AX25_MAC command line you will create a second KISS port on COM-3
etc.
So now you have:
AX25_MAC -PKISS1 -PKISS2 -PKISS3 -F -C17 -BU50
The first port will be a KISS port on COM-1 which connects to a KISS TNC, the
second port is a KISS port on COM-2 and the third port is a KISS port on COM-3.
You can connect APRS programs to COM-2 and COM-3. You can also connect a second
KISS TNC to one of these ports to create a cross-band digipeater.
If the APRS program you want to use supports BPQ frames over Ethernet than you
can use that too. On the DIGI_NED side you need an FTP software compatible packet
driver for your LAN card and use the '-PBPQ' flag
in AX25_MAC to create a BPQ over Ethernet port.
In Linux you can use a local loopback as also described for connecting an IGATE
to DIGI_NED. Instead of the IGATE software you can run for example Xastir at
the other end of this internal loopback.
Back to Questions List
Q: Can I start a DOS shell without leaving
DIGI_NED, I want to make changes to the beacon file.
A: Yes, you can in the DOS version (in Linux you can always
start another shell or run DIGI_NED in background or use Ctrl-Z to stop a running
program etc.).
If you type ALT-D a DOS command interpreter is started. Since DIGI_NED is not
so big you have enough memory left to do an editing job. If not then the program
'shroom' may help you, I haven't tested this though.
DIGI_NED is using the COMSPEC environment setting to determine which interpreter
to start. If COMSPEC is not specified the function will fail. Before starting
DIGI_NED you can do the following from the DOS prompt:
C:> set COMSPEC=C:\COMMAND.COM
COMSPEC now indicates that the DOS command processor is on C:\COMMAND.COM.
Of course COMMAND.COM must exist, otherwise the function still fails obviously...
Back to Questions List
Q: Can I make a small KISS network with
your software do I can connect an APRS program?
A: Yes. You can do something like this:
On PC number 1 you have to do the following:
1) Kick the TNC into KISS mode, how this is done depends on the TNC type.
2) If applicable change AX25_MAC.INI to set TX-Delay to match your TRX.
3) Load AX25_MAC the following way:
AX25_MAC -PKISS1 -PKISS2 -F -C17 -BU50
-PKISS1 is a port, type KISS on COM1
This is the first specification, will be port 1
-PKISS2 is a port, type KISS on COM2 - second spec
This is the second specification, will be port 2
-F forces AX25_MAC to read the AX25_MAC.INI file
-C17 is a visual indication, you can leave it out
-BU50 gives the Mac-layer 50 AX.25 frame buffers,
default is 100 so you can leave it out also.
This will load the driver with 2 kiss ports, one on COM1 and one on COM2. I
have not specified a baudrate, default is 9600 baud.
For more information about what you can have on the command-line reading see
the AX25_MAC documentation.
Next you have to configure DIGI_NED:
4) Change the "digi_call:" parameter in digi_ned.ini.
Change the digibcon.ini and digi_id.ini files to reflect your call and position
5) Start DIGI_NED and it should start digipeating! If you use the
'-v' flag on the command-line of DIGI_NED you should see the received
data and the actions DIGI_NED takes on it.
Frames received by DIGI_NED will be digipeated via COM1 to the radio and via
COM2 to the connected second PC. You may have to add a 'digiend:'
rule to forward the packet that ended its journey, to COM2. Normally a packet
with no unused digipeaters left is not repeated anymore, so they would also
not arrive at COM2. With 'digiend' you can digipeat
packets that are normally spoken 'at the end' so you can still see them on the
screen of your APRS program. The default configuration file already contains
two lined for this. The first line is:
digiend: all wide*,trace* 2 add LOCAL
This will digipeat all packets where the last digicall was WIDE... or TRACE...
once more, it adds another digipeater call 'LOCAL'. The first
'all' means "from all ports" the '2' means
"to port 2". So packets received from COM1 are send out via COM2; packets received
from COM2 are also send out also via COM2. This was setup for cross-band use,
you may want to change this to:
digiend: 1 wide*,trace* 2
Now only packets received from port 1 are send to port 2. If your local digipeater
does call-substitution then you may want to add that call. The second 'digiend:'
rule does this for me. 'PE1MEW-2' is our local digipeater. The rule looks as
follows:
digiend: 1 pe1mew-2 2
This means that all packets received on port 1 (the port is associated with
the first -P parameter of AX25_MAC, so the KISS port on COM1 in this case) are
send out via port 2, which is the second KISS port.
6) Setup your APRS program on the second PC and set it up to use a KISS TNC.
Now the frames from your APRS program should flow through the DIGI to the TNC
connected to COM 1. Frames that appear on COM 1 are repeated on COM 2 and end
up at the screen of your APRS program.
Back to Questions List
Q: How about using Bob Bruninga's idea
for a ZIP-lan, can I do that (for information about ZIP-lan see the DosAPRS
distribution)
A: I think you can use this ZIP-lan setup without modification
with DIGI_NED as master.
There are three important differences though:
1) The packet exchange between the stations is done in KISS instead of plain
text.
2) Packets from the slave stations are digipeated to the TNCs, this means that
the stations must have a real call and not a pseudo call. You can use pseudo
calls to block transmission from slaves if you want to, you then have to add
the call to the 'block' list. You can also set a slave to 'NOCALL', that's in
the 'block' list already. For the stations you want to have transmission you
can use a distinct SSID.
Another option is use specific digipeater call. Use for example
PE1DNN>APRS via ZIPLAN
If there is no rule in DIGI_NED for 'ZIPLAN' then it will not be digipeated.
Then you can make another one
PE1DNN>APRS via ZIPTNC
And add the following rule to the DIGI_NED.INI file:
digipeat: 1 ZIPTNC 1 new WIDE,WIDE2-2
Then packets received from port 1 where the next digi to be used is ZIPTNC are
send out through port 1 with a new path WIDE,WIDE2-2 (example only!).
3) Packets from the slave are not send as 'third party' messages, DIGI_NED prevents
loops by not repeating packets that it transmitted already by looking for its
own call in the digipeater list and by remembering CRCs of already repeated
data. That's enough to prevent loops. DIGI_NED never repeats its own packets.
The setup of the DIGI is as I described already, see the question above about
the KISS network. This time you need only 1 KISS port. You can also use 2 ports,
one with the TNC and one with the ZIP-Lan. That way you can shield the slaves
even more, you can set it up so that all transmissions from the slave are not
digipeated unless it is via 'ZIPTNC'. With a one-wire solution the slave can
still use 'WIDE' as destination and will be digipeated. So two wires is a little
bit more fool-proof and resistant against accidents if a slave still has a 'normal'
path.
Of course you have to realize that collisions on the ZIP-lan corrupts packets,
but this is not different for KISS than it is for plain text, this is the simplicity
of the ZIP-lan. There is a chance that these corrupt packets are transmitted.
You have to experiment with this but when looking at it I currently don't see
any problem why it should not work. I'll be very interested to hear practical
results on this.
Back to Questions List
Q: I think I found a bug, what do I
do?
A: Please report to me at "pe1dnn@amsat.org".
Also read "Bugs.txt" to find out more.
Back to Questions List
Q: DIGI_NED does not digipeat my AX.25/IP/NETROM/ARP
packets anymore, is this a bug?
A: No. DIGI_NED now has a so-called "Kenwood mode". This
will truncate packets that are to long to save the APRS mode on the TH-D7E from
failing. The default is "kenwood_mode: 1", which truncates
packets which are too long to be handled by the TH-D7E.
Since you don't want the digi to truncate normal AX.25 traffic packets or any
other packet, these packets are not digipeated in this mode.
If you specify:
kenwood_mode: 0
in the .ini file, than the digipeater will not truncate packets anymore and
behave the same as earlier versions of DIGI_NED.
Another option is "kenwood_mode: 2", in that case
packet are not truncated but they are ignored. Also in this mode you cannot
make an AX.25 connection or send IP, NETROM or ARP packets via the digipeater.
Back to Questions List
Q: I think that DIGI_NED is a great
idea but I feel not stoppng a packet like the Kantronics TNC is something that
needs to be changed.
A: All the transitions done by DIGI_NED are programmed
as "rules" in a file (default digi_ned.ini). It can easily be changed to behave
equal to what the Kantronics TNC does. The only thing that needs to be done
is for example for WIDEn-N digipeating the rules used for the last hop:
;
; 1 Hop
;
digipeat: all wide7-1 all swap0 wide7
digipeat: all wide6-1 all swap0 wide6
digipeat: all wide5-1 all swap0 wide5
digipeat: all wide4-1 all swap0 wide4
digipeat: all wide3-1 all swap0 wide3
digipeat: all wide2-1 all swap0 wide2
digipeat: all wide1-1 all swap0 wide1
;
All I did was add a "0" to the swap operation. This
number specifies how many digipeater calls should be marked as "used". Default
if not specified is 1. But if a 0 is specified no additional digipeaters are
marked as "used". This way the final WIDEn call will be left like the Kantronics
TNC seems to do. This is however not corresponding with the specification, so
this is why it is not the default in the supplied DIGI_NED.INI.
You could also refuse to propagate anything with WIDE4-N or more by removing
all rules for that. Then the DIGI only accepts WIDE1-N, WIDE2-N and WIDE3-N
calls.
Back to Questions List
Q: How do I update the kepler data for
the satellite tracker?
A: Put raw 2 line element data in digi_ned.tle. I just concatinate all the bulletins I get from KEPLER@AMSAT on the packet BBS in that file, including headers, text etc. Then send the query "?utle" to the digipeater, you have to be owner to do that or type it in at the keyboard if keyboard input in enabled. Upon reception of the "?utle" query DIGI_NED will filter the kepler data from the digi_ned.tle file and update digi_ned.sat if newer data is found. Finally DIGI_NED will read-in this new data and start to use it.
Q: Sometimes I see these error messages appearing:
Invalid Destination call in received packet
Invalid Originator call in received packet
Unfortunatly there is no other information in the log file, so I don't know who it was that sent the packets, or what the actual problem was.
A: Yea, thats a chicken and egg problem. DIGI_NED uses defensive programming. During formatting of the AX.25 packet I check the layout of the callsigns:
When a "call" doesn't make it through this check then it can be anything, ranging from use of illegal characters to just plain junk (control-characters, characters that influence your terminal etc, I just don't know - I only know its not a valid call). As soon as an invalid call is found decoding of a packet is terminated. I have to because I have no clue what other junk may follow. So you can feed random noice to DIGI_NED and DIGI_NED will only act if the calls are valid.
here is no point in pinpointing somebody - because the packet appears to be corrupt you cannot rely on anything. I think the main cause will be character loss on the KISS link and such failures. The only thing I could do is dump the packet in hex, but I think a lot of people will not be able to understand what it means. I think most implementations will just throuw such packets away, DIGI_NED shows that it received something but with an invalid call (checks on originator, destination and digi-calls). On non-KISS links this will be rare because of the CRC check, but on a KISS line there is no CRC in a lot of cases and corruption is not detected. This checking fixes this a little bit.
Q: -
A:-