SEARCH
TOOLBOX
LANGUAGES
ON0DAS-4 CrossDigi config: digi ned.ini

ON0DAS-4 CrossDigi config: digi ned.ini

From ON0DAS

Jump to: navigation, search
;
; Edit by ON4SAX & ON8TT for ON0DAS-4
; v20080331_01
;
;  Copyright (C) 2000-2007  Henk de Groot - PE1DNN
;
;  This program is free software ; you can redistribute it and/or modify
;  it under the terms of the GNU General Public License as published by
;  the Free Software Foundation ; either version 2 of the License, or
;  (at your option) any later version.
;
;  This program 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.  See the
;  GNU General Public License for more details.
;
;  You should have received a copy of the GNU General Public License
;  along with this program ; if not, write to the Free Software
;  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
;  Please note that the GPL allows you to use the driver, NOT the radio.
;  In order to use the radio, you need a license from the communications
;  authority of your country.
;
;------------------------------------------------------------------------------
;
;  DIGI_NED Digi
;
version: 2
;
;(Changes marked with  ;| in the text, as far as possible. When rules changed
; the line before and after the changed rule is marked. Search for "|" to
; quickly find the changes with respect to the previous version)
;
;  * Place this file wherever you like, the file will be read by
;    DIGI_NED at startup. Default location is in the same directory
;    as the executable, any other location can be used if you supply
;    the filename at the command line.
;
;  * The numbers in the Digipeat lines represent channels on the
;    AX25_MAC Medium Access Layer TSR or (for LINUX) the AX25 ports
;    supplied at the command-line.
;
;  * Wild cards:
;
;    Wildcards may be used to match the incoming callsigns.
;      *  Matches any 0 or more character(s).
;      ?  Matches any 1 character.
;      @  Matches any alpha character.
;      !  Matches any digit.
;
;  DIGI_NED can be setup to match characters in callsigns and aliases. Neat?
;  Some common ones are WIDE* and AP*. Be careful when doing this as some
;  callsign fields use things like GPSODN and MIC-E's use random characters
;  in their "to:" field (for possible destination calls and related Icons
;  look at Appendix 2 of the APRS Specification).
;
;  When '*' is used and additional characters follow after the '*' then
;  characters in the callsign to check will be skipped until a match is
;  found again, from that point checking will proceed.
;
;  Example:
;  Using W*E will match WIDE but not W0EXT ; after the '*' the code will
;  look for an 'E' and continue checking from there. In case of matching with
;  WIDE the '*' will skip the 'I' and 'D' characters and continue comparison
;  at the 'E'. In case of matching with W0EXT the '*' skip over the '0'
;  character and also continue comparison at the 'E'. Since 'E' is not
;  equal to 'EXT' the match will fail for W0EXT. Typical use for this,
;  and the prime reason why this is implemented, is to enable checking on
;  SSIDs. You can use '*-4' to match any call with 'SSID' '4'. This is for
;  digipeating on destination-call SSIDs
;
;  * Include the contents of a file:
;
;    Used with "send:" and "beacon:" commands. The line following the send
;    beacon token is the name of a file. "send:" and "beacon:" will send
;    the current contents of that file at regular intervals. "beacon:"
;    will also send the contents of a file on a "?APRS?" broadcast or
;    query.
;
;  * Port List:
;
;    A comma separated list of port numbers "1,3,5,7" or "All" or "AllBut".
;    "All" means all ports.
;    "AllBut" means all ports EXCEPT the port where the frame was heard.
;
;  Port numbers refer to the AX25_MAC ports (TNCs),
;    as shown at startup of AX25_MAC or the order of the ports specified
;    on the commandline in LINUX..
;    It is used to specify receive or transmit ports.
;
;  * Call List:
;
;    Comma separated list of callsigns.
;
;    Use commas to separate CALLSIGNS.
;
;  * Special call
;
;    The call DIGI_CALL in lists will be replaced by the digi_call of the
;    DIGI_NED digi. This makes it easier to change the call and replicate
;    a configuration (be careful though!)
;
;    The call DIGI_DEST in lists will be replaced by the digi_dest of the
;    DIGI_NED digi.
;
;  * Alter the digipeater list:
;
;    Be very careful if you use more than one option to specify
;    how frames will be repeated between a given pair of switch ports.
;
;    Repeat a frame if we are next in the digipeater list.
;    Use "Digipeat:". Assume we select on a digipeater field of WIDE.
;
;    For incoming frame: A>B,C,D*,TRACE,E,F
;
;    <none> will do normal digipeating, aliases are replaced by the
;    DIGI_CALL.
;    e.g. <none>          gives:  A>B,C,D,DIGI_CALL*,E,F
;
;    "Add" will do normal digipeating and add new digipeaters at the end
;    of the digipeater list
;    e.g. Add     X,Y     gives:  A>B,C,D,DIGI_CALL*,E,F,X,Y
;
;    "Replace" will do normal digipeating and replace the not yet used
;    digipeaters with a new list of digipeaters.
;    e.g. Replace DIGI_CALL,X,Y     gives:  A>B,C,D,DIGI_CALL*,X,Y
;
;    "New" will replace the whole digipeater list with a new one. The
;    DIGI_CALL is put first in the list
;    e.g. New     DIGI_CALL,X,Y     gives:  A>B,DIGI_CALL*,X,Y
;
;    "Swap" will replace the digipeater call that was supposed to handle
;    the packet with a new callsigns. The first callsign will be the 'sender'
;    (note that with this operation you can avoid callsign substitution
;    with the DIGI_CALL call)
;    e.g. Swap    RELAY,X,Y     gives:  A>B,C,D,RELAY*,X,Y,E,F
;
;    "Hijack" removes the previous digipeater call from the list and will
;    then perform the "Swap" operation. If there is no previous digipeater
;    then it will behave like Swap does (note that with this operation you
;    can avoid callsign substitution with the DIGI_CALL call)
;
;    "Erase" removes all digipeater calls from the digipeater list.
;
;    "Keep" will keep the digipeater list unchanged, with a number
;    you can specify how many digipeaters should be marked as "used"
;    e.g. Keep    gives:  A>B,C,D,TRACE*,E,F
;         Keep0   gives:  A>B,C,D*,TRACE,E,F (i.e. unchanged path)
;
;    "Shift" will remove all "used" digis except the last used one and
;    replace the unused digi in the digi list with new calls of the
;    digipeater list.
;    e.g. Shift   DIGI_CALL,X,Y  gives:  A>B,D,DIGI_CALL*,X,Y
;
;    All the operations can take an optional number to specify how many
;    digipeater calls shall be marked as "used" by the DIGI_NED. Default
;    is 1, but you can specify a number from 0 to 8. With 0 no digipeater
;    call is used up (used for WIDEn-N digipeating), with 8 all digipeater
;    calls are used up. The value 2 is used for the last hop on TRACEn-N
;    digipeating, both the DIGI_CALL and the remaining TRACEn shall be
;    marked as used on this last hop.
;
;    For incoming frame: A>B,C,D*,WIDE4-3,E,F
;    e.g. Swap0    WIDE4-2     gives:  A>B,C,D*,WIDE4-2,E,F
;
;    For incoming frame: A>B,C,D*,TRACE4-1,E,F
;    e.g. Swap2    DIGI_CALL,TRACE4     gives:  A>B,C,D,DIGI_CALL,TRACE4*,E,F
;
;    "DigiTo:" is used to repeat a frame if it has a desired TO field. It
;    is only evaluated when there are no digipeaters at all in the path.
;    This is useful for picking up packets that usually have no digis on
;    them at all. Some settings are CQ, ID and BEACON.
;    Assume we select on a TO field of ID.
;    For incoming frame: A>ID
;    Add     X,Y gives:  A>ID,X,Y
;
;    There is something special about "DigiTo:". "DigiTo:" supports
;    destination-call SSID replacement used for intelligent digipeating
;    on destination-call SSID. For incoming frame: A>ID-3 and replacement
;    SSID '2' the output will be A>ID-2
;
;    "DigiTo:" does not add DIGI_CALL automatically, you have to add this
;    yourself if you want it. It is possible to use "Add", "Replace", "New",
;    "Swap", "Hijack", "Erase" and "Keep" operations. If you don't want
;    the packet to digipeat on SSID set the destination call SSID to 0 to
;    avoid problems and missinterpretation.
;
;    "DigiSsid:" is used to repeat a frame if it has a desired TO field
;    just like "DigiTo:". It is only evaluated when there are unused
;    digipeaters in the path. This is useful for implementing SSID
;    digipeating the correct way. Just like "DigiTo:" this rule can
;    change the SSID.
;
;    "DigiSsid:" does not add DIGI_CALL automatically, you have to add this
;    yourself if you want it. It is possible to use "Add", "Replace", "New",
;    "Swap", "Hijack", "Erase" and "Keep" operations. If you don't want
;    the packet to digipeat on SSID set the destination call SSID to 0 to
;    avoid problems and miss interpretation.
;
;    "DigiSsid:" rules override "Digipeat:" rules, i.e. the "DigiSsid:" rule
;    has a higher priority.
;
;    "DigiEnd:" is used to repeat a frame when we heard it from it's last
;    digipeater in the path. Assume we select on a digipeater field of
;    DIGI_CALL.
;    For incoming frame: A>B,C,D,WIDE,E,DIGI_CALL*
;    New     X,Y gives:  A>B,DIGI_CALL*,X,Y
;
;    "DigiEnd:" is used to "pick up" a packet that died due to lack of
;    any more path. This is useful when seeing a packet come a couple hops,
;    such as the beacon of a distant digi, picking it up and ADDING more
;    path to it and re-sending it out.
;
;    With "Block:" you can define FROM callsigns that should not be
;    repeated. This is for calls like MYCALL, N0CALL etc. or misbehaving
;    Hams... Optionally you can block calls at specific ports.
;
;    "DigiFirst:" works just like "Digipeat:" but only acts on digis that
;    are first in the digipeater path.
;
;    "DigiNext:" works just like "Digipeat:" but only acts on digis that
;    are not the first in the digipeater path.
;
;    "DigiFirst:" and "DigiNext:" are mutually exclusive, a "Digipeat:" rule
;    can be subsituted by 2 rules using "DigiFirst:" and "DigiNext" and have
;    a compatible behavior. Usage it to act differently when a call is first
;    in the list ; it has been designed for adding the digipeater call where
;    the packets enters the APRS system when the user starts his digipeater
;    list with WIDE4-4 for example:
;
;    Old rule:
;    digipeat: all wide4-4 all swap0 wide4-3
;
;    PA0ABC>APRS,WIDE4-4 will be digipeated as PA0ABC>APRS,WIDE4-3
;
;    In this case it is not visible where the packet entered the system. Now
;    replace the digipeat: rule by 2 new rules:
;
;    New rules:
;    digifirst: all wide4-4 all swap DIGI_CALL,wide4-3
;    diginext: all wide4-4 all swap0 wide4-3
;
;    PA0ABC>APRS,WIDE4-4 will now be digipeated as
;    PA0ABC>APRS,DIGI_CALL*,WIDE4-3
;
;    When WIDE4-4 is not the first in the digi list the "Diginext:" rule will
;    catch it and that one uses the same operation as the old "Digipeat:" rule.
;
;  * Note that the node callsign replaces any alias or callsign
;    used to digipeat, or is added into the digipeater list as
;    required to allow DIGI to detect potential digipeat loops.
;    e.g. (WIDE,WIDE,WIDE)
;
;    Yes, DIGI_NED does callsign swapping, and won't repeat its own packet.
;    With the more advanced rules you can make rules without callsign
;    swapping. To prevent loops, DIGI_NED remembers the CRC of recently
;    sent packets. The parameter "keep_time" defines how long it takes
;    until DIGI_NED forgets the CRC. There are special measures of
;    "short_keep_time" and a filter to remember certain types of data
;    for a shorter period (i.e. messages which are repeated).
;
;  * Preempt commands
;
;    "Preempt:" enables you to take packets you hear although there
;    are unused digipeaters before you in the via-list.
;
;    Example. Say you receive a packet with the following path:
;    A>B,C*,D,E,F
;
;    Assume you are digi 'E' but you happen to hear the packet from
;    'C' directly. Normally the digi would not do anything because
;    the next digi due is 'D'. If you specify a "preempt:" rule like
;    this:
;
;    preempt: all E
;
;    Then packets received from "all" ports will be searched for the
;    occurrence of unused digi-call "E". When found the received packet
;    will be changed by removing all unused digipeater calls before the
;    call you searched. If there are no unused digipeaters before
;    the call you searched then preempt will do nothing. So with the
;    example A>B,C*,D,E,F and the above "preempt:" rule, the packet
;    will be modified to: A>B,C*,E,F
;
;    So the next unused digipeater is now 'E'. Further processing of
;    the packet is done by applying the normal "digipeat:" rules to
;    the modified packet. So "preempt" is a kind of pre-processing.
;
;    So the unused calls are just removed from the digi-list. In some
;    cases you want to keep a call. This can be achieved by the
;    "preempt_keep:" rule. All digipeaters in the "preempt_keep"
;    rules are relocated in the via-list.
;
;    Assume you have this:
;
;    preempt_keep: D
;
;    In this case digipeater D will remain in the via-list after
;    preempting. So with the example A>B,C*,D,E,F and the previously
;    described "preempt:" rule, the packet will be modified to:
;    A>B,C*,E,D,F
;
;    So all unused digipeater calls are removed but the ones defined
;    in "preempt_keep:" are inserted again after the preempted call.
;    The kept digis will remain in sequence.
;
;    Example:
;
;    preempt: all H
;    preempt_keep: D,E,G
;
;    Packet A>B,C*,D,E,F,G,H,I will be modified to A>B,C*,H,D,E,G,I
;
;    WARNING: Never use generic calls like "RELAY" or "WIDE" in
;    "preempt_keep:" unless you really want to get yourself into
;    trouble...
;
;    "preempt_keep:" can take wildcards. For example to keep all
;    Dutch, German and Belgian calls you can specify:
;
;    preempt_keep: P*,D*,O*
;
;    To prevent that generic calls are also kept there is another
;    rule called "preempt_never_keep:". With "preempt_never_keep:"
;    calls are specified that shall never be kept on preempting,
;    regardless if the call matches with "preempt_keep:". This is
;    useful to avoid re-insertion of generic calls when wild-cards
;    are used in the "preempt_keep" rule. Example:
;
;    preempt_keep: *
;    preempt_never_keep: RELAY*,WIDE*,TRACE*
;
;    In this example all calls are kept in the via-list when
;    preempting, except all calls that start with RELAY, WIDE or
;    TRACE.
;
;    One advanced feature is that the preempted call can be exchanged
;    for a new call during the preempt preprocessing. Example:
;
;    preempt: 1 E Z
;
;    Then packets received from port "1" ports will be searched for the
;    occurrence of unused digi-call "E". When found the received packet
;    will be changed by removing all unused digipeater calls before the
;    call you searched. If there are no unused digipeaters before
;    the call you searched then preempt will do nothing. The digipeater
;    call E will be replaced by Z. So with the example A>B,C*,D,E,F and
;    the above "preempt:" rule, the packet will be modified to: A>B,C*,Z,F
;
;    One of the tricks you can do with this is to have a rule like:
;
;    preempt: all RELAY IGNORE
;
;    Inbound packets will be searched for RELAY. Since preempting is only
;    done when there are unused digipeaters before the searched call, this
;    means that this preempting only takes place when RELAY is not the
;    first digipeater! Example:
;
;    Inbound packet: A>B,WIDE,RELAY,WIDE3-3
;
;    is preempted to: A>B,IGNORE,WIDE3-3
;
;    Now make sure there is no "digipeat:" rule for a digipeater called
;    "IGNORE" and none of the digipeating rules will match. Result: the
;    frame is not digipeated...
;
;  * Send and Beacon command
;
;    These are where DIGI_NED gets the position beacon text. You can have
;    multi path beacons if you want. The format for the setting reads as
;    follows:
;
;    send: 20 all DIGI_DEST,WIDE,TRACE4-4
;    c:\data\send_data
;
;    beacon: 20 all DIGI_DEST,WIDE,TRACE4-4
;    c:\data\send_data
;
;    Send beacons with an interval of 20 minutes to all ports
;    with DIGI_CALL (that's the call of this DIGI_NED) to
;    the first call in the path given in the send command. The next
;    calls in the path of the send command are the digis, in this
;    case WIDE,TRACE4-4. The next line is a file from which the
;    data to be send is read. The file will be read every time
;    "send:" or "beacon:" starts the transmission.
;
;    It is also possible to send beacons at a specific time when
;    prefixing the interval with '@' (at). For example:
;
;    beacon: @20 all DIGI_DEST,WIDE,TRACE4-4
;    c:\data\send_data
;
;    Sends the same information as above, but exactly 20 minutes past the
;    hour, every hour. The time can be between 0 and 59 ; when using @60 it
;    will send exactly on the hour but skip every other hour. So if you
;    want to send every other hour at 20 minutes past the hour, use @80
;
;    Some conversion is performed on the file. After reading all
;    <CR> characters will be removed. The result of this is that
;    only <LF> characters remain as line terminators. All the
;    <LF> characters are changed to <CR> characters which is the
;    line termination used for packet-radio use. Note that only
;    up to 256 characters are read from the beacon-file, this is
;    as much as will fit in an AX.25 frame. If the text is not
;    terminated by a <CR> the DIGI_NED will add it.
;
;    When the file does not have any path then digi_ned will look for it
;    in the same directory as where the executable is.
;
;    DIGI_CALL>DIGI_DEST,WIDE,TRACE4-4:contents of named file
;
;    The difference between "send:" and "beacon:" is that the "beacon:"
;    rules are also triggered when an "?APRS?" broadcast or query is
;    received. The "send:" rules will not be executed in that case.
;
;  * Telemetry command
;
;    This commands starts transmission of telemetry data by DIGI_NED
;    which can be used to transfer binary data read from an LPT port.
;    You can connect your own hardware to the LPT port to give meaning
;    to the signals.
;
;    telemetry: 20 all off,off,off,off,off,lpt2 DIGI_DEST,WIDE,TRACE4-4
;
;    This means: send telemetry data with an interval of 20 minutes to
;    all ports with DIGI_CALL (that's the call of this DIGI_NED) to the
;    first call in the path given in the telemetry command. The other
;    calls in the path of the telemetry command are the digis, in this
;    case WIDE,TRACE4-4.
;
;    Note that an interval of 0 will not cause any transmissions. This
;    can be used to specify ports with the "telemetry:" for use with
;    the "?tlm" query but without the automatic transmissions.
;
;    It is also possible to send telemetry data at a specific time when
;    prefixing the interval with '@' (at). For example:
;
;    telemetry: @20 all off,off,off,off,off,lpt2 DIGI_DEST,WIDE,TRACE4-4
;
;    Sends the same information as above, but exactly 20 minutes past the
;    hour, every hour. The time can be between 0 and 59 ; when using @60 it
;    will send exactly on the hour but skip every other hour. So if you
;    want to send every other hour at 20 minutes past the hour, use @80
;
;    The telemetry data to send is read from the control data address of
;    the given ports. Up to 6 sources can be specified, the first 5 are
;    analog and the 6th port is a digital port.
;
;    In the command as shown the analog inputs are not connected to a
;    port. "off" is a dummy port, used as placeholder.
;
;    The source for the digital port is in the above example the parallel
;    port. The address of the used LPT port is read from DOS in case DOS
;    is used, in Linux LPT1 (/dev/lp0) is mapped to base address 0x3BC,
;    LPT2 (/dev/lp1) to 0x378 and LPT3 (/dev/lp2) to 0x278. This
;    corresponds with the order used in the "lp" driver in Linux (at
;    least with 2.0.36 kernel). Note that for example LPT1 in DOS may
;    not be the same as port 0x3BC in Linux. DOS assigns the ports in
;    a different order depending on the available hardware.
;
;    The telemetry data is transmitted as an APRS type 'T' identifier.
;    The sequence number starts at 000 and is increased each transmission.
;    When the number 999 is reached the counter restarts at 000. The LPT
;    port data will be in the "Digital Value" part. The dummy "off" ports
;    will give 999 as value in the analog part or all '1' when used in the
;    binary value. You can change the telemetry command to this:
;
;    telemetry: 20 all lpt2 DIGI_DEST,WIDE,TRACE4-4
;
;    In this case the value read from lpt2 is put into the first analog
;    field. The telemetry command will not send more data then needed.
;
;    In the future more telemetry ports will be added, currently only the
;    dummy 'off' and the 'lpt' ports are supported.
;
;    For 'lpt' 5 bits input can be used. The value is read from the 'lpt'
;    status port as input. The inputs are "Busy" = D7, "Ack" = D6,
;    "Paper Out" = D5, "Select In" = D4 and "Error" = D3. The binary value
;    in the telemetry data is send out with high byte first (so the first
;    binary value bit is "Busy"). Logical high is a '1' in the telemetry
;    message.
;
;    For 'lpt' also an 8-bit input can be used. For multiplexing, the
;    'strobe' signal is used. When the 'strobe' signal on the connector
;    is logical low then the lower nibble of the 8 bytes is read from
;    the status port (inputs "Busy" = D3, "Ack" = D2, "Paper Out" = D1,
;    "Select In" = D0). When the 'strobe' signal on the connector is
;    logical high then the higher nibble of the 8 bytes is read from
;    the status port (inputs "Busy" = D7, "Ack" = D6, "Paper Out" = D5,
;    "Select In" = D4). There is at least 1ms time between changing the
;    strobe signal on the port and actually reading the nibble from the
;    port.
;
;    If you want to use 8 bit input use "lpt<x>_8",for example 8 bit input
;    from "lpt2":
;
;    telemetry: 20 all off,off,off,off,off,lpt2_8 DIGI_DEST,WIDE,TRACE4-4
;
;    DIGI_NED contains support for multiplexing via the lpt port. When
;    reading the port the port number (which is 0 based and runs from 0
;    to 5) is put on bits 1, 2 and 3 of the control port. These bits
;    correspond with the "Auto Linefeed", "Initialize Printer" and
;    "Select Printer" outputs of the LPT port. The association of port
;    numbers put on the 3 bit address lines of the control port can be
;    overruled. For example to completely reverse the numbers, so the first
;    value is read from address 5, the next from 4 etc, you can specify:
;
;    telemetry: 20 all lpt2_8/5,lpt2_8/4,lpt2_8/3,lpt2_8/2,lpt2_8/1,lpt2_8/0...
;
;    (path truncated to be able to fit the example on 1 line...)
;    The 3 bit address on the control port can take values 0..7.
;
;  * Automessage command
;
;    This command internally sends a query to DIGI_NED. You can use this
;    to port regular bulletins automatically, have maintenance to
;    update the satelite database and since queries can also start up
;    programs you can use it to automate maintenance.
;
;    automessage: 30 1,2
;    ?bln
;
;    This sends the query "?bln" internally to DIGI_NED two times, once
;    originating from port 1 and once originating from port 2.
;
;    DIGI_NED will handle this the same way as if the message entered from
;    one of the ports. There is one exception, direct replies to the
;    originator appear on screen (and only once, even if you have more ports).
;
;    Replies to others and bulletins are transmitted the normal way, as do
;    objects.
;
;    One use could be to keep the satellite tracking running, like this
;
;    automessage: 100 all
;    ?trk no44
;
;    Every 100 minutes the tracking is triggered, this will keep it running
;
;    Another great use it to run an external program once in a while, for
;    example:
;
;    automessage: 1440 all
;    ?sysop
;
;    This will once a day trigger the response programmed under 'sysop' in
;    the sample 'digi_ned.mes' file. This is programmed like this:
;
;        ?sysop
;        !!echo Ok, you are Sysop > tmpxyz
;        >tmpxyz
;        !rm tmpxyz
;
;    So it runs the program 'echo' to put a text into a file, then it
;    reads the file and sends the contents to the originator of the query
;    (so it ends up on the screen). Then the 'rm' program is run to remove
;    the created temporary file.
;
;    The number 30 in the first example rule above is the interval, every
;    30 minutes. Like 'send:', 'beacon:' and 'telemetry:' above adding an '@'
;    to the interval specifies an absolute time, i.e. every 30 minutes past
;    the hour in this case. Example:
;
;    automessage: @0 1,2
;    ?bln
;    automessage: @30 1,2
;    ?bln
;
;    This automatically executes the 'bln' query at every full and half hour.
;
;  * Serial command
;
;    With these rules DIGI_NED can send data from a GPS, Ultimeter or other
;    device connected via a serial line. You can sent multiple sentences if
;    you want. The format for the setting reads as follows:
;
;    serial: 10 all com3 4800 GPSODN,WIDE,WIDE3-3
;    $GPRMC $GPGGA
;
;    If the wanted type of sentence is not specified (empty line following
;    the "serial:" rule) all the data on the serial input is accepted (if
;    it doesn't fail the checksum). Note that DIGI_NED will only output the
;    most recently read complete line in this case.
;
;    In the example serial data is send with an interval of 10 minutes to
;    all ports. The data is read from COM3 (under Linux /dev/ttyS2) at 4800
;    baud in this case. Supported baudrates are 1200, 2400, 4800 and 9600
;    baud. The serial line uses hardware-flowcontrol on send and receive.
;
;    In DOS COM1 to COM4 can be used with the following mapping:
;
;    COM1 = IOA=0x3f8, IRQ=4
;    COM2 = IOA=0x2f8, IRQ=3
;    COM3 = IOA=0x3e8, IRQ=4
;    COM4 = IOA=0x2e8, IRQ=3
;
;    As usual the DOS restriction not to have active traffic on 2 COM ports
;    using the same IRQ applies. The IOA and IRQ are fixed. I might add it
;    if there is demand to have this configurable. In DOS only 1 serial port
;    can be assigned at a time due to limitations in the used driver code.
;
;    In Linux COM1 to COM9 can be used with the following mapping:
;
;    COM1 uses /dev/ttyS0
;    COM2 uses /dev/ttyS1
;    COM3 uses /dev/ttyS2
;    COM4 uses /dev/ttyS3
;    ...
;    COM9 uses /dev/ttyS8
;
;    If a checksum is present in the DATA, DIGI_NED will validate the sentence
;    and ignore corrupted sentences. When no checksum is present data is
;    used as is. The data is transmitted with the call DIGI_CALL (that's
;    the call of this DIGI_NED) to the first call in the path given in
;    the serial command. The next calls in the path of the serial command
;    are the digis, in this case WIDE, WIDE3-3. The next line in the .ini
;    file specifies the sentences to be picked up from the serial line for
;    transmission. Multiple sentence types can be specified. All sentences
;    are transmitted at the same time.
;
;    DIGI_CALL>GPSODN,WIDE,WIDE3-3:$GPRMC<RMC sentence follows>
;    DIGI_CALL>GPSODN,WIDE,WIDE3-3:$GPGGA<GGA sentence follows>
;
;    Like 'send:', 'beacon:', 'telemetry:' and 'automessage:" above adding
;    an '@' to the interval specifies an absolute time.
;
;  * WX support
;
;    This functionality is used to make all kinds of packets based on
;    telemetry information. Primary reason for creating this function is
;    to build a weather station (with home-made sensors!). All data is
;    retrieved from an LPT port. It uses the same type of multiplexing
;    as the telemetry ports.
;
;    The way it works is with variables (a symbol a..z or A..Z etc), which
;    are associated with a port. They are created with a "wx_var:" rule.
;    Besides its association with a telemetry port each variable has
;    specific properties. First of all the kind of variable. It can use
;    the raw value but also a maximum or minimum value over an amount of
;    time. It can also sum up differences between measurements to support
;    rain-meters etc. The period is selectable in minutes, up to 32676
;    minutes timespan.
;
;    Secondly the variable has a set of equation parameters. Using the
;    formula "a (x*x) + b x + c" where "x" is the value read from the
;    telemetry port the variable has constants for "a", "b" and "c" to
;    convert the read value from the port to the value of the variable.
;    Note that the fraction of the resulting floating point value is
;    truncated when conversion to an integer is done. When you want
;    rounding make sure to handle that in the formula by adding 0.5 to
;    the value of "c" of the equation.
;
;    The variables created this way can be embedded in a string which is
;    sent with a new rule called "wx:". You can use different types of
;    formatting to create exactly the output string you want. Say your
;    variable is "v" and has the value 123. The following formatting
;    instructions yield the following output:
;
;    "%v"   -> formatted to "123"  (takes as much space as needed)
;    "%4v"  -> formatted to " 123" (always 4 characters)
;    "%-4v" -> formatted to "123 " (always 4 characters, left aligned)
;    "%04v" -> formatted to "0123" (always 4 characters, zero padding)
;    "%02v" -> formatted to "23"   (always 2 characters, truncates the value)
;    "the value of v=%v" -> "the value of v=123"
;
;    There is also a second kind of variables. These do not read data from
;    a telemetry port but are used to display the current date and time.
;    There are a number of formats available, but by truncating the
;    variables during formatting you can create other formats too. Both
;    zulu and local time are supported, note that these only generate
;    correct values when either the timezone information (TZ) is set
;    correctly or the digi_utc_offset: is filled in (DOS only)
;
;    The following kind of variables can be created using the "wx_var:"
;    rules:
;
;    kinds: val     -> direct value
;           max     -> max since midnight
;           min     -> min since midnight
;           sum     -> sum since midnight
;           avg     -> pseudo average since midnight
;           max60   -> max over past 60 minutes (1 hour)
;           min60   -> min over past 60 minutes (1 hour)
;           sum60   -> sum over past 60 minutes (1 hour)
;           avg60   -> pseudo average over 60 minutes (1 hour)
;           max120  -> max over past 120 minutes (2 hours)
;           min120  -> min over past 120 minutes (2 hours)
;           sum1440 -> sum over past 1440 minutes (24 hours)
;           avg1440 -> pseudo average over past 1440 minutes (24 hours)
;           dhm     -> day, hour, minute value
;           hms     -> hour, minute, second value
;           ymd     -> year, month, day value
;           ydm     -> year, day, month value
;           dmy     -> day, month, year value
;           mdy     -> month, day, year value
;           mdh     -> month, day, hour value
;           mdhm    -> month, day, hour, minute value
;
;    When you want to use this functionality some planning is needed. You
;    have to know which values are present on which ports. Then you need
;    to find the equations to calculate the values as they should appear
;    on the output. It is also good to plan which variables to use.
;    Variables van be "a-z", "A-Z" (case sensitive!) and symbols like "#",
;    "$" etc. If you want to include a % sign in the output use \%, the
;    "\" is an escape character. To include a backslash use "\\". Planning
;    of variables is needed to avoid using the same variable twice. If you
;    define a variable twice, only the last one will be evaluated.
;
;    To illustrate how it works I created a configuration example below
;    with several equations. The final string is a positionless WX string
;    as described in the APRS specification (You need a copy of this to
;    create a correctly formatted string for WX use). Due to the
;    flexibility, use of this WX mechanism is not restricted to weather
;    stations. Use your imagination, this can couple any data from an LPT
;    port to a beacon transmission.
;
;    Note that the sample below in this file is commented-out, it depends
;    on the hardware you connect how to set it up. It is just to show-off
;    the rules used for this functionality.
;
;    Note that beacons created with the "wx:" rule are transmitted when
;    the query "?WX?" is received, both with a message to the digi and
;    with a WX broadcast reception.
;
;    Like 'send:', 'beacon:', 'telemetry:', 'automessage:' and 'serial:'
;    above adding '@' to the interval specifies an absolute time.
;
;  * Messages
;
;    DIGI_NED can send a number of responses to queries. Some of
;    those responses are defined in a text-file. The file is defined
;    with:
;
;    message_file: digi_ned.mes
;
;    When the file does not have any path then digi_ned will look for it
;    in the same directory as where the executable is.
;
;    DIGI_NED will remember the query from a station so that DIGI_NED
;    does answer only once on query. If the acknowledge of the query
;    message does not reach the originator then the originator retransmits
;    his message. This retransmission should not be auto-answered.
;
;    message_keep_time: 900
;
;    This remembers received messages for 900 seconds - 15 minutes
;
;    The "message_path:" defines the route that reply-messages should
;    use.
;
;    message_path: all TRACE,WIDE
;
;    In the above example the auto-response will be send to all ports
;    using TRACE,WIDE as digipeater path.
;
;    It is allowed to have multiple "message_path:" definitions for one
;    port. Each "message_path:" definition causes an transmission to
;    the ports, each having the defined path. Definition of
;
;    message_path: 1 TRACE,WIDE
;    message_path: 1 PI1APA
;
;    Causes 2 transmissions to port 1 for each reply of DIGI_NED, on
;    with the digipeater path "TRACE,WIDE" and one using "PI1APA".
;    As with everything in the DIGI_NED configuration the user is
;    responsible for proper usage of this feature.
;
;    A related parameter is "max_msg_hops:". This is the maximum
;    number of "used" digipeaters that may appear in the received
;    frame containing the query from the originator. When more
;    digipeaters are marked as "used" the query will be ignored.
;
;    Answering a query that arrived via more hops would be useless
;    since the answer will not get back to the originator according
;    to the message_path settings and would only cause QRM. This
;    "hop" limit does not take intelligent digipeaters into account,
;    but at least stops some useless traffic.
;
;    When not defined "max_msg_hops:" will be 8, which means no limit
;    because 8 is the maximum number of digipeaters that will fit into
;    an AX.25 frame. The "max_msg_hops:" will, when used, normally
;    correspond with the number of hops defined in the longest
;    "message_path:" setting.
;
;  * DX function
;
;    With the DX function DIGI_NED can generate DX messages. To be able
;    to measure the distance, the digi position must be set. This is done
;    with Digi_Pos:, example
;    digi_pos: 5213.61N 00600.00E
;
;    Alternatively DIGI_NED can read the position specified in an APRS
;    beacon text so that you have only one place to specify the digipeater
;    position, example:
;    digi_pos_file: digibcon.ini
;
;    The method with reading the beacon-file is now default.
;
;    You can query for DX stations on a port. It gives the best and second
;    best station over a period of time. This period is determined by
;    Dx_Times: and is specified in hours. 'all' can be used to get the
;    best DX of all entries in the Mheard list. More times can be specified.
;    example:
;    dx_times: all,24,1
;
;    Distances are default in 'km' but can be changed with 'Dx_Metric:'
;    to 'mi' for statue miles or 'nm' for nautical miles. Example:
;    dx_metric: km
;
;    DX bulletins are generated when a new best DX is received. There
;    is a minimum and maximum distance, below the minimun a DX bulletin
;    is never send and above the maximum the range is considered to be
;    bogus. This maximum range is optional. The time over which this best
;    DX is determined is set in hours.
;
;    'Dx_Level:' is used for this and can be defined per port. You can have
;    more Dx_Level: commands for one port if you want. Use 'all' to define
;    the level for all ports. Example (for all ports with 25km/mi/nm minimum
;    limit [see dx_metric] and 2000 km/mi/nm maximum limit and 'looking back'
;    1 hour):
;    dx_level: all 25-2000 1
;
;    With Dx_Path: the destination address and path is determined for
;    the Dx bulletins. Example:
;    dx_path: all DX,TRACE,WIDE
;
;    With Dx_Portname: you can give a port a more descriptive name the
;    default name is "Portx" where 'x' is the port number. Note that the
;    TH-D7 will only display the first 5 characters of the name. Maximum
;    length transmitted are 10 characters - this just fills up a complete
;    80 character line. Example:
;    dx_portname: 1 2 mtr
;
;------------------------------------------------------------------------------
;
;  Start of the rules, start with the beacons.
;
;  Send our position as beacon, this transmission also takes place when an
;  "?APRS?" broadcast or query is received.
;
beacon: 30 all DIGI_DEST,WIDE1-1
digibcon.ini
;
;  Send our station identification every 5 minutes. Note that this may be
;  required to fulfil your license requirements. In this case I did not
;  add any digipeaters since this is only a local identification.
;  Upon reception of an "?APRS?" broadcast or query this beacon is not
;  transmitted. If that is needed change the "send:" rule into a "beacon:"
;  rule.
;
send: 5 all ID,WIDE1-1
digi_id.ini
;
;------------------------------------------------------------------------------
;
;  Serial line handling
;
;  Since there is no default the examples are commented out
;  COM1 is in Linux /dev/ttyS0, COM2 is /dev/ttyS1 etc.
;
;  Tip: to accept all the data on the serial input leave the line following
;       the "serial:" rule empty. In that case all the data on the serial
;       input is accepted (if it doesn't fail the checksum). DIGI_NED will
;       only output the most recently read complete line in that case.
;
;serial: 10 all com3 4800 GPSODN,WIDE,WIDE3-3
;$GPRMC $GPGGA
;
;------------------------------------------------------------------------------
;
;  Telemetry transmission. Telemetry data to send is read from a LPT port.
;
;  NOTE: These lines are commented out since there is no sensible default
;  You have to adapt the beacon telemetry text and connect the hardware you
;  want to control. Please read the TELEMETRY section in the APRS
;  specification (to be found on "http://www.tapr.org"). If you do not
;  understand this, please leave all the telemetry stuff commented!!!
;
;  In this example the data from lpt2, using address 1 on the control line
;  outputs, is put into the analog A1 channel and in the binary channels
;  (B1..B8) (using the default port address 5).
;
;telemetry: 15 all lpt2/1,off,off,off,off,lpt2_8 DIGI_DEST
;
;  Send telemetry specification at regular intervals
;
;  This information is formatted as a message to the digi itself (the
;  digi sends a message with as destination the digi itself). These
;  messages specify what telemetry is transmitted. Care has to be taken
;  with the layout. Fields are limited in length. The information how
;  to use this can be found in the APRS protocol specification in the
;  telemetry chapter.
;
;  The information in "digi_tlm.ini" defines the names of all parameters,
;  the units in which they are expressed, equations to be used on the
;  analog values and a bit-pattern to define when a digital bit should be
;  regarded as 'active' or 'on'. If you don't understand this please read
;  the APRS specification. It's no use to duplicate the information here
;  and it will not make the topic more simple.
;
;beacon: 30 all DIGI_DEST
;digi_tlm.ini
;
;  We use the beacon file also as our own source of information to
;  answer on 'tlm' queries. This is needed to format the responses.
;
;tele_info: digi_tlm.ini
;
;------------------------------------------------------------------------------
;
;  Automessage, automatically start query to DIGI_NED itself
;
;  Automessage automatically sends a message to DIGI_NED itself, so
;  it can regulary do actions like posting an object, keep the tracker
;  running for a specific satellite or, since messages can startup a program,
;  run a program at regular intervals. In the example below DIGI_NED keeps
;  tracking satellite NO44 (APRS satellite PCSat). Every 100 minutes the
;  tracking is restarted so it will never expire.
;
;automessage: 100 all
;?trk no44
;
;------------------------------------------------------------------------------
;
;  Commands to execute directly after the .ini file is processed. These
;  command are sent through the message parser as if they were sent over
;  the air. The purpose is to initialise output ports used for remote control
;  to a certain state.
;
;command: !out 2 10101011
;
;  It can also be used to make a port read-only at startup, for example
;  port 4:
;
; ## ON4SAX ## Disable PTT on ports 1 & 2 for RX-Only operation (0DASv5-tmp)
command: !ptt 00xxxxxx
;
;------------------------------------------------------------------------------
;
;  Digipeat frames with these digipeater calls.
;
;  Digipeat data to this call from any port one back out onto all ports.
;  Don't add anything (except mycall of course).
;
;  XXXX XXXX = whatever comes next after this
;
;------------------------------------------------------------------------------
;all ==> PE1XXX-1>APXXX PE1YYY* DIGI_CALL XXXX XXXX
;all <== PE1XXX-1>APXXX PE1YYY DIGI_CALL* XXXX XXXX
;
digipeat: all DIGI_CALL all
;------------------------------------------------------------------------------
;all ==> PE1XXX-1>APXXX PE1YYY* RELAY XXXX XXXX
;all <== PE1XXX-1>APXXX PE1YYY* DIGI_CALL* XXXX XXXX
;
;------------------------------------------------------------------------------
;  Digipeat data to this call only to the port where it came from.
;
;1 ==> PE1XXX-1>APXXX PE1YYY* LOCAL XXXX XXXX
;1 <== PE1XXX-1>APXXX PE1YYY* DIGI_CALL* XXXX XXXX
;
digipeat: all local all
;
; on digiend repeat everything from each port but the port itself to get a complete view on the other port.
digiend: all * allbut
;------------------------------------------------------------------------------
;2 ==> PE1XXX-1>APXXX PE1YYY* LOCAL XXXX XXXX
;2 <== PE1XXX-1>APXXX PE1YYY* DIGI_CALL* XXXX XXXX
;
;digipeat: 2 local 2
;------------------------------------------------------------------------------
;  Digipeat data to this call from any port one back out onto all ports
;  except the one it came from.
;
;all ==> PE1XXX-1>APXXX PE1YYY* WORM XXXX XXXX
;all(except in-port) <== PE1XXX-1>APXXX PE1YYY* DIGI_CALL* XXXX XXXX
;
;digipeat: all worm allbut
;------------------------------------------------------------------------------
;
;  Intelligent digipeating rules
;
;  Handling of WIDEn-N
;  -------------------
;
; new paradigm 20080331(on4sax)
;
;  Under the new paradigm, WIDEn-N will work as TRACEn-N under the old
;  paradigm. The maximum allowed hop-count for the new paradigm is 2.
;
;  We now drop all WIDEn-N packets with a higher hopcount than 2.
;
;  We don't drop any trailing calls after the WIDE2-N. Reason for this is
;  because we do not want to loose additions like "IGATE" or "RFONLY" at the
;  tail of the digipeat list.
;
;  If dropping trailing calls is more important to you use operation "replace"
;  instead of "swap" in the rules below.
;
;  General rule: calls of previous intelligent digipeaters stay in the
;  digipeater list (note that on overflow calls are dropped!).
;
;  Example: packet with WIDE2-2 should progress as follows
;
;  -- 1st hop on WIDE2-2 --
;  all ==> PE1XXX-1>APXXX PE1YYY* WIDE2-2 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY DIGI_CALL* WIDE2-1 XXXX XXXX
;
;  Rule: digipeat: all wide2-2 all swap DIGI_CALL,wide2-1
;
;  -- 2nd hop on WIDE2-1 by "DIGI_2" --
;  all ==> PE1XXX-1>APXXX PE1YYY DIGI_CALL* WIDE2-1 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY DIGI_CALL DIGI_2 WIDE2* XXXX XXXX
;
;  Rule: digipeat: all wide2-1 all swap2 DIGI_2,wide2
;
;------------------------------------------------------------------------------
;
;  WIDE2-N handling
;
digipeat: all wide2-2 all swap DIGI_CALL,wide2-1
digipeat: all wide2-1 all swap2 DIGI_CALL,wide2
;
; handle wide>2 but show INVLID
;
;digipeat: all wide3* all swap DIGI_CALL,INVLID
;digipeat: all wide4* all swap DIGI_CALL,INVLID
;digipeat: all wide5* all swap DIGI_CALL,INVLID
;digipeat: all wide6* all swap DIGI_CALL,INVLID
;digipeat: all wide7* all swap DIGI_CALL,INVLID
;
;------------------------------------------------------------------------------
;
;  WIDE1-N handling ; Special case, used as RELAY replacement
;  Special conditions:
;  - Only allowed if first in the path
;  - Doesn't leave a WIDE1 behind, just does normal digipeating replacing
;    the WIDE1-1 with the digipeater callsign
;
digifirst: all wide1-1 all
;
;
;------------------------------------------------------------------------------
;
;  Handling of TRACEn-N
;  ---------------------
;
; convert to wide2-2
;
digipeat: all trace2-2 all swap DIGI_CALL,wide2-1
digipeat: all trace2-1 all swap2 DIGI_CALL,wide2
;
; handle trace>2 but show INVLID
;
;digipeat: all trace3* all swap DIGI_CALL,INVLID
;digipeat: all trace4* all swap DIGI_CALL,INVLID
;digipeat: all trace5* all swap DIGI_CALL,INVLID
;digipeat: all trace6* all swap DIGI_CALL,INVLID
;digipeat: all trace7* all swap DIGI_CALL,INVLID
;
;------------------------------------------------------------------------------
;
;  If a packet "ended" at WIDE or TRACE, pick it up, and add LOCAL and
;  send it back out.
;
;digiend: all wide*,trace* 2 add LOCAL
;
;------------------------------------------------------------------------------
;
;  Preemptive digipeating. If one of the unused digis matches the call
;  in the "preempt:" rule, and there are other unused digipeater
;  before this call then the digipeater will remove all unused digipeater
;  calls up to but not including the matching call. The modified packet
;  header will then be digipeated by applying matching "digipeat:" rules.
;
preempt: all DIGI_CALL
;
; new paradigm 20080331(on4sax)
;
;  If WIDEn-N or SSn-N appears anyware in the path we use that. This way
;  we will skip over RELAY in case comebody still uses it. We also want to
;  skip over WIDE1-1 since that is the replacement for RELAY, we accept any
;  WIDEn-N where n is greater than 2. There higher hopcount WIDEn-N digi
;  paths are then ignored since there are no futher rules for it. This
;  prevents abuse where a low hopcount path is followed by a high
;  hopcount path.
;
preempt: all WIDE2*
preempt: all WIDE3*
preempt: all WIDE4*
preempt: all WIDE5*
preempt: all WIDE6*
preempt: all WIDE7*
preempt: all SC!*
;
;  Do not relocate any preempted calls.
;
preempt_never_keep: *
;
;------------------------------------------------------------------------------
;
;  Local ports. Digipeated packets to a local port will not have
;  "unused" digipeaters in the path (they are stripped off) ; i.e.
;  the packets will not be repeated by other digipeaters anymore
;  (unless they have a digiend: rule that picks the packets up
;  again). Only packets that are send directly to the digipeater
;  (did not pass another digipeater before reception) will be sent
;  out as a normal digipeated frame using the same digipeater path
;  manipulations as also used for non-local ports). This feature
;  can be used to fill-in black spots in the network without causing
;  unneeded traffic in neighboring digipeaters.
;
;local: 2
;
;------------------------------------------------------------------------------
;
;  How many calls kept in the digipeater software.
;
;  The "size_heard_list" defines how many calls are remembered
;  for the "mheard" and "dx" queries. If it is too small then
;  the DX function cannot give accurate long-term reports.
;
size_heard_list: 150
;
;  The "size_heard_show" defines how many calls are shown on
;  the "mheard <port>" query. There are 4 calls shown per line.
;  This means that with 40 calls on the same port you get up to
;  10 lines with responses. If not defined, "size_heard_show:"
;  is the same as "size_heard_list".
;
size_heard_show: 40
;
;------------------------------------------------------------------------------
;
;  How many seconds old data transmissions are remembered to prevent loops.
;  Use '0' to switch-off (then DIGI_NED only looks for its DIGI_CALL in the
;  digi-list)
;
keep_time: 300
;
;  If the received data starts with a particular character then we can opt
;  to use a shorter keep_time. The first character in UI data specifies
;  the kind of data, with this we can give certain type of data a short
;  time to repeat. This is especially useful for messages and acks on
;  messages which are repeated frequently at the start. Note that you can
;  not use <space> as data prefix. Use 0 to forget immediately.
;
short_keep_time: 10
data_prefix: :?~
;
;------------------------------------------------------------------------------
;
;  This command specifies the file from which message query/answers are
;  read. If no path is given DIGI_NED looks for the file in the same place
;  as the executable. If a path is given DIGI_NED will look there ; i.e.
;  ".\digi_ned.mes" will direct DIGI_NED to the current directory,
;  "\tmp\digi_ned.mes" will make DIGI_NED to look for the file in the
;  "tmp" directory. Forward or backward slashes are interpreted correctly
;  for the platform you run on (DOS or Linux).
;
message_file: digi_ned.mes
;
;  How many seconds old message receptions are remembered to prevent loops.
;  Use '0' to switch-off (then DIGI_NED only looks for its DIGI_CALL in the
;  digi-list)
;
message_keep_time: 900
;
;  Message path contains the digis appended to messages transmitted by
;  DIGI_NED. This path has to be defined per port, more definitions for
;  one port are possible. Also "message_path: 1" works, no digipeater
;  definitions are used in that case. Messages are never transmitted
;  on ports which do not have any matching "message_path:" definitions.
;
message_path: all WIDE
;message_path: 2 PI1APA
;
;  If the number of digipeaters marked as "used" in the digipeater
;  list exceeds the next specified value then the digipeater ignores
;  the message from the user. Reason is that the answer will never
;  get back anyway with the above specified "message_path:" settings.
;  It would only cause extra QRM to attempt it.
;
max_msg_hops: 2
;
;------------------------------------------------------------------------------
;
;  DX function handling.
;  ---------------------
;
;  Define the position of the digipeater, from this point distance and
;  bearing calculation on directly received stations takes place.
;  First latitude, then longitude. The format shall be the same way
;  as used in the APRS uncompressed position format, otherwise it will
;  not be accepted by the program.
;
;digi_pos: 5097.76N 00505.22E
;
;  The digipeater position can also be taken from the first line of a beacon
;  file, now you only have to change the beacon file. Since this is less
;  prone to errors it is the default now.
;
digi_pos_file: digibcon.ini
;
;  Define what to return on a DX query. "all" returns the best DX of
;  all entries of a given port, "1" returns the best DX of the last hour,
;  etc.
;
dx_times: all,24,1
;
;  Dx metric defines the presentation of distances and the threshold
;  for distances in the dx_level: rule. Options are "km" for kilometers,
;  "mi" for statue miles and "nm" for nautical miles. Default is "km".
;
dx_metric: km
;
;  The next command defines when we report a station as DX. The first
;  parameter is the port for which this is true (DX on 6m a is something
;  different then DX on 2m, and DX on 70cm is different again). All applies to
;  all ports but a single digit or comma separated digits are also possible.
;  The second parameter is a threshold, in this example everything below
;  25 km is not DX. Everything above 2000 is also thrown away as distances
;  above 2000 are highly unlikely on 2m and 70cm. This will block a majority
;  of bogus positions (note that the position 0000.00N/S 00000.00E/W is
;  always blocked). The last parameter it the time in hours to look
;  back. When a station is received which is the "best DX" for the last
;  hour (1) and is further away then the threshold (100 km) then it is
;  reported. The unit of distance is determined by "dx_metric:", default
;  is "km".
;
dx_level: all 25-2000 1
;
;  DX path contains the destination call and digis to be appended to
;  DX messages transmitted by DIGI_NED. This path has to be defined
;  per port, more definitions for one port are possible. Also
;  "dx_path: 1 DX" works, no digipeater definitions are used in that case.
;  DX messages are never transmitted on ports which do not have any
;  matching "dx_path:" definition.
;
dx_path: all DX,WIDE
;
;  DX portname contains the name of the port to be reported with the DX
;  reports and queries. It contains the port number and the rest of the
;  string is the name. Beware - the name is limited in size, otherwise
;  it is truncated. Up to 8 characters appear on a TH-D7 screen and
;  are transmitted on air. The commented examples show some alternatives
;  to the defaults I used.
;
dx_portname: 1 2 mtr
dx_portname: 2 70 cm
dx_portname: 3 inet
;
;dx_portname: 1 VHF
;dx_portname: 2 UHF
;
;  Its common for DX clusters to use the frequency in kHz, so use that
;
;dx_portname: 1 144800.0
;
;dx_portname: 2 430512.5
;
;------------------------------------------------------------------------------
;
;  Satellite Tracking Attributes
;  -----------------------------
;
;  The following attributes are used by the satellite-tracking module of
;  DIGI_NED. Make sure that digi_pos is defined either in the DX function
;  handling portion of this file or below. Alternatively, you can also
;  specify the position in the digibcon.ini file, but don't forget to
;  include the "digi_pos_file: digibcon.ini"-rule. The latter method is
;  preferred because then you only have to specify (and change, if
;  necessary) the position of the digi only once. This position information
;  together with the other attributes are needed for satellite tracking
;  calculations.
;
;  (commented out, already present above)
;  Position of the digi...
;digi_pos: 3256.84N 08001.92W (KG4ECV-10)
;  ...or specify as:
;digi_pos_file: digibcon.ini
;
;  Altitude of the digi in meters (1 meter is approx. 3.28 feet, not critical).
digi_altitude: 65
;
;  Use local time (1) or UTC for the display of AOS time in objects.
digi_use_local: 1
;
;  UTC offset for the digi (EST = -5). Make sure to correct this for
;  daylight savings.
;
;  This value is only used when there is no timezone information in the
;  system for DOS. Linux will either use by Linux's zoneinfo or by
;  interpreting the TZ environment variable. In DOS the TZ variable can
;  also be used. You can create one in DOS using the format:
;
;  set TZ=EST+5EDT
;
;  Where in this case UTC is 5 hours ahead of EST (watch the sign!) and
;  Daylight saving is used. Note that in Europe the Daylight saving rules
;  are different than the USA so it may not work. In that case just use
;  TZ=EST+5 or when in Daylight saving TZ=EST+4.
;
;  When in a DOS environment the TZ  is not set then the next value will
;  be used. Internally a TZ string will be used in the form:
;  TZ=UTC-<digi_utc_offsert>, in my case TZ=UTC-2 during the summer. For
;  the EST example the digi_utc_offset should be -5 and the internally
;  generated TZ string will be UTC+5.
;
digi_utc_offset: +1
;
;  Time (in minutes) between transmission of satellite objects when satellite.
;  is in range.
sat_in_range_interval: 1
;
;  Time (in minutes) between transmission of satellite objects when satellite
;  is out of range.
sat_out_of_range_interval: 10
;
;  Duration time (in minutes) of tracking.
track_duration: 105
;
;  Name of the satellite information database.
satellite_file: digi_ned.sat
;
;  Name of the TLE file to update the satellite information database from.
update_tle_file: digi_ned.tle
;
;  Sat Object format, Satellites can be transmitted the following way
;
;  The number specifies the format of the sat-object:
;  0) Show plain as "AO40    E" (where E is for the Elevation column)
;
;  1) Show plain as "AO40 126E" (where 123 is the epoch of the used kepler
;                                data and E is for the Elevation column)
;  2) Show plain as "AO40 0805" (where 0805 is the ddmm date of the used
;                                kepler data)
;  3) Show plain as "AO40 0508" (where 0508 is the mmdd date of the used
;                                kepler data)
;  Default is 0.
;
sat_obj_format: 2
;
;------------------------------------------------------------------------------
;
;  WX support (and other applications you may think off..)
;  -------------------------------------------------------
;
;  Example configuration for a WX station using many sensors connected
;  to a multiplexing interface on the LPT port. For more information
;  about interfacing to the LPT port look at the DIGI_NED web-site which
;  can be reached via http://www.qsl.net/digi_ned. Also look at the links
;  on this site. There are projects by other hams which can now be supported
;  through this interface. Sole purpose is to stimulate home made equipment.
;  Building a weather station and connect it to APRS is very rewarding!
;
;  Note: don't take a too narrow view! This functionality can also be
;  used to transmit information from direction finders, formatted
;  telemetry data etc, it doesn't have to be WX at all!
;
;  Having said this, here is the example!
;
;  Assume a telemtry module on LPT1 with 8 multiplexed ports
;
;  lpt1 port 0:
;  lpt1 port 1: temperature in centigrade
;  lpt1 port 2: course in steps of 30 degrees (0 = 0, 1 = 30, 2 = 60 etc)
;  lpt1 port 3: encounting rainfall value in mm
;  lpt1 port 4: humidity in steps of 10%
;  lpt1 port 5: barometric pressure, in hPa offset 900 (100 = 1000 hPa)
;  lpt1 port 6:
;  lpt1 port 7: wind speed in beaufort
;
;  course from lpt1 port 2, multiply by 30 to get degrees
;wx_var: c,val,lpt1_8/2,0,30.0,0
;
;  speed from lpt1 port 7, average over last min, convert from beaufort to mph
;  aproximation beaufort to knots: 0.3*(x*x)+2.2*x+0
;  multiply with 0.8689762 to get from knots to mph
;  final formula beaufort to mph: 0.2607*(x*x)+1.9117*x+0
; wx_var: s,avg1,lpt1_8/7,0.2607,1.9117,0
;
;  gust from lpt1 port 7, maximum over 5 min, convert from beaufort to mph
;wx_var: g,max5,lpt1_8/7,0.2607,1.9117,0
;
;  temperature from lpt1 port 1, convert from centigrade to fahrenheit
;wx_var: t,val,lpt1_8/1,0,1.8,32
;
;  rainfall last hour from lpt1 port 3, convert from mm to 1/100 of inch
;wx_var: r,sum60,lpt1_8/3,0,3.937,0
;
;  rainfall last 24 hours from lpt1 port 3, convert from mm to 1/100 of inch
;wx_var: p,sum1440,lpt1_8/3,0,3.937,0
;
;  rainfall since midnight from lpt1 port 3, convert from mm to 1/100 of inch
;wx_var: P,sum,lpt1_8/3,0,3.937,0
;
;  humidity from lpt1 port 4, multiply by 10 to get percentage
;wx_var: h,val,lpt1_8/4,0,10.0,0
;
;  barometric pressure from lpt1 port 5, 10ths of hPA: multiply by 10 add 9000
;wx_var: b,val,lpt1_8/5,0,10.0,9000
;
;  raw rain counter, convert mm to 1/100 of inch
;wx_var: #,val,lpt1_8/3,0,3.937,0
;
;  time variable type MDHM in zulu time
;wx_var: D,mdhm,zulu
;
;  Positionless WX string, use in conjunction with a normal position beacon
;
;wx: 5 all APRS,WIDE,WIDE
;_%08Dc%03cs%03sg%03gt%03tr%03rp%03pP%03Ph%02hb%05b#%03#xDned
;
;  Example complete WX string (if you use this, shut down the normal beacon,
;  this WX packet will replace that function!):
;
;  time variable type DHM in zulu time
;wx_var: T,dhm,zulu
;
;wx: 5 all APRS,WIDE,WIDE
;@%06Tz5213.61N/00600.00E_%03c/%03sg%03gt%03tr%03rp%03pP%03Ph%02hb%05b#%03#xDned
;
;  Time formats example
;
;  Supported formats DHM, HMS, YMD, YDM, DMY, MDY, MDH, MDHM zulu or local time
;
;  A number of variables in Zulu time
;
;wx_var: T,dhm,zulu
;wx_var: S,hms,zulu
;wx_var: Y,ymd,zulu
;wx_var: W,ydm,zulu
;wx_var: F,dmy,zulu
;wx_var: M,mdy,zulu
;wx_var: O,mdh,zulu
;wx_var: D,mdhm,zulu
;
;  A number of variables in Local time
;
;wx_var: U,dhm,local
;wx_var: R,hms,local
;wx_var: Z,ymd,local
;wx_var: X,ydm,local
;wx_var: E,dmy,local
;wx_var: N,mdy,local
;wx_var: Q,mdh,local
;wx_var: G,mdhm,local
;
;wx: 5 all WX,WIDE,WIDE
;>time: %06Tz (DHM) %06Sz (HMS) %06Yz (YMD) %06Wz (YDM)
;wx: 5 all WX,WIDE,WIDE
;>time: %06Fz (DMY) %06Mz (MDY) %06Oz (MDH) %08Dz (MDHM)
;
;wx: 5 all WX,WIDE,WIDE
;>time: %06Ul (DHM) %06Rl (HMS) %06Zl (YMD) %06Xl (YDM)
;wx: 5 all WX,WIDE,WIDE
;>time: %06El (DMY) %06Nl (MDY) %06Qz (MDH) %08Gl (MDHM)
;
;  By using combinations and restricting the output of a variable other
;  strings can be build... Example:
;wx: 5 all WX,WIDE,WIDE
;>date: %02Y-%02W-20%02F time: %02O:%02T:%02S zulu
;
;------------------------------------------------------------------------------
;
;  Calls we don't want to repeat. These are also not kept in the MHeard list
;  and no DX messages are generated for these calls. Optionally you can
;  specify a port number, only packets from those ports with the specified
;  calls are blocked. (e.g. block: 1 CALL). When no port is specified then
;  "all" is assumed to be backwards compatible.
;
block: all N0CALL,NOCALL,MYCALL
;
;  Here we can block calls that already went through a specific digi,
;  for example to block mass-distribution of IGate traffic through the
;  digi. "via_block:" also considers calls in the third-party header.
;  It only considders the most recent 3rd party header, not recursive
;  when the embedded packet contains another 3rd party header. It
;  considers all calls in the 3rd party header including originator
;  and destination calls. Optionally you can specify a port number, packets
;  from those ports with the specified calls are blocked and no packets
;  with the specified call will be send to that port. For example:
;
;  via_block: 1 TCPIP
;
;  The digipeater doesn't accept packes with TCPIP from port 1 and will not
;  send any packets with TCPIP to port 1. Port 1 could be a HF port for
;  example. When no port is specified then "all" is assumed to be backwards
;  compatible with older versions.
;
;via_block: all TCPIP,IGATE
;
;  Add usage restrictions for a port, allow_to: and allow_from:. These can
;  be used if you want to create special setups with cross-band where you
;  only want to pick up specific packets from one band to another. If not
;  defined (default) all "from" and "to" calls are allowed (if not blocked).
;
;  If allow_to: is defined only calls with a specific destination address
;  are accepted on this port. This can be use if you only want to pick up
;  certain packets from a port. For example on port 2 you only want to pick
;  up packets to MAIL and FBB put out by an FBB BBS. On all other port
;  there are no restrictions. (Note this line is commented out, it's
;  just an example.)
;
;allow_to: 2 MAIL*,FBB*
;
;  If allow_from: is defined only packets from a specific station are
;  accepted. For example only allow only Dutch stations on port 1 and 2,
;  on port 1 do not allow non-novice stations (PDxxxx). On all other ports
;  there are no restrictions. (Note these lines are commented out, it's just
;  an example.)
;
;allow_from: 1,2 PE*,PA*,PI*
;allow_from: 2 PD*
;
;  Calls that are not allowed to query the digipeater. Optionally you can
;  specify a port number, only queries from those ports with the specified
;  calls are blocked. (e.g. msg_block: 1 CALL). When no port is specified
;  then "all" is assumed to be backwards compatible.
;
msg_block: all N0CALL,NOCALL,MYCALL
;
;------------------------------------------------------------------------------
;
;  Kenwood mode.
;
;  It appears that at least the TH-D7E can not handle formatted
;  packets with a total length of more than 195 octets. The
;  formatting used internally seems to be the same as the monitor
;  format used by the built-in TNC.
;
;  SOURCE>ID,PATH,PATH*,PATH:Hey look at me, this is my long ID<CR>
;  <--------------------- Max 195 characters --------------------->
;
;  This problem applies to at least to UI packets with PID=F0 (normal
;  packet unproto frames). I've seen on a normal link that the
;  TH-D7E's APRS function also stops on other packets, but I could
;  not determine which packet types. Maybe all packets with lengths
;  above what the TH-D7E can take cause problems. I have no
;  information if other Kenwood models behave the same way as the
;  TH-D7E v2.0 does.
;
;  Long UI packets are legal to appear on the air. These are for
;  example FBB unproto packets, ID packets with a long length, APRS
;  packets with a long third party header or one of the few APRS
;  packets that do not have a length limit.
;
;  There are 3 kenwood_mode settings that have an effect on UI packets
;  with PID=F0 (normal AX.25 UI frames):
;
;  0 = switch off, allow UI frames with size 256
;  1 = switch on, too long frames are truncated before transmission
;  2 = switch on, too long frames are not transmitted at all
;
;  Default is 1. In almost all cases it is just comment that is too long,
;  truncating that is no problem. But you can change it if you disagree.
;
;  When you choose anything else then 0, then only UI packets with PID=F0
;  are digipeated (normal AX.25 UI frames) and no other packets like I,
;  RR, REJ, SABM etc. are digipeated. Also UI packets for NetRom,
;  IP and ARP are not digipeated when using this "kenwood_mode".
;  This is done because these packets are usually long and truncating
;  or not transmitting these packets causes corruption of data.
;
kenwood_mode: 1
;
;------------------------------------------------------------------------------
;
;  There is a new APRS like protocol called Opentrac. It uses PID=77.
;  DIGI_NED will digipeat those, unless you disable it here. Opentrac
;  packets are also digipeated when "kenwood_mode:" is other than zero.
;  The opentrac packets will not be truncated since that would damage the
;  packet. Set opentrack_enable: to 0 if you do not want to digipeat
;  opentrac packets (for example because you have another application doing
;  that) or when opentrac packets causes problems for kenwoods.
;
;  There is currently no other specific opentrac support, only rule-based
;  digipeating. Opentrack envisions new and better ways of digipeating.
;  Look at http://www.opentrac.org/ to find out more about this project.
;
opentrac_enable: 1
;
;------------------------------------------------------------------------------
;
;  DIGI_OWNER is the owner of the digi, used in the ?owner command and for
;  the ?exit command on the digi. You can supply multiple calls, separated
;  by commas. The first defined call is that call which will be reported
;  as owner when the digi is interrogated. The idea is that the call of
;  the owner is the call of the person or group that owns the license for
;  the digipeater so that the responsible person can be contacted in case
;  there is a problem with the digi. At least one call specification is
;  mandatory.
;
;  You can use this to supply your other calls with SSID or to assign
;  co-maintainers with the same right to stop the digi to allow remote
;  maintenance.
;
digi_owner: ## Removed for Security Reasons ##
;
;------------------------------------------------------------------------------
;
;  The enable-exit option permits stopping DIGI_NED remotely.
;  DIGI_NED will exit with exit-code 2, and with a .bat file this can be
;  used to restart the digipeater.
;  The following checking is done:
;  * The originator shall be the owner-call (SSID is significant!)
;  * The target address is the DIGI_CALL.
;  * There shall be no digipeaters (only direct access)
;  * This feature has to be set to enabled to work
;
;  Use 1 to enable, 0 to disable this feature.
;
enable_exit: 0
;
;------------------------------------------------------------------------------
;
;  The digi knows a few remote command that the owner can send to the digi
;  These are the !ptt command to enable or disable transmission on a port and
;  the !out command to change signals on the LPT port of the digipeater. With
;  the following two commands you can disable these features, by default they
;  are enabled. When enabled the following checking is done before accepting
;  a command:
;  * The originator shall be the owner-call (SSID is significant!)
;  * This feature has to be set to enabled to work
;
enable_ptt_command: 1
enable_out_command: 1
;
;------------------------------------------------------------------------------
;
;  To be able to check the output of the program, the output can be logged to
;  a file. All the output will be put into the file. Be careful not to
;  use this when running normally, the file will grow until the filesystem
;  is full. It is meant for testing only! When no name is specified nothing
;  is logged. At the start of the program an existing log is overwritten.
;
;  When no path is specified then the logfile will be created in the same
;  directory as where the program itself is stored.
;
;logfile: digi_ned.log
;
;  In the tnclogfile recieved and transmitted messages are written in the
;  TNC format, which is also used by many, many other programs.
;
;tnclogfile: digi_ned.tnc
;
;------------------------------------------------------------------------------
;
;  DIGI_CALL of the digi and the destination to which the DIGI_NED digi
;  can send beacons.
;
digi_call: ON0DAS-4
;
;  New format destination addess:
;
;  DIGI_NED now uses destination address APNDxx. The prefix APN can be
;  shared with other intelligent digipeaters. The prefix APND is reserved
;  for DIGI_NED now in coordination with the APRS protocol workgroup.
;
;  The DIGI_NED version number is now compressed in 2 alphanumeric bytes.
;  For this count base 36 is used to have enough numbers to identifiy
;  DIGI_NED versions, I.e counting goes:
;
;  01,02,...,09,0A,0B,...,0Z,10,11,..,1Z,20,...,etc
;
;  where 01 is version 0.0.1, 0Z is version 0.3.5 and 10 is version 0.3.6
;  etc. It is not as clear as the old numbering, but this leaves space for
;  other applications using the APN prefix.
;
;  Table (for versions 001 to 036 with corresponding base 36 numbers):
;
;  001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018
;   01  02  03  04  05  06  07  08  09  0A  0B  0C  0D  0E  0F  0G  0H  0I
;
;  019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036
;|  0J  0K  0L  0M  0N  0O  0P  0Q  0R  0S  0T  0U  0V  0W  0X  0Y  0Z  10
;|
;| 037 038 039 040 041 042 043 044 043 046 047 048 049 050 051 052 053 054
;|  11  12  13  14  15  16  17  18  19  1A  1B  1C  1D  1E  1F  1G  1H  1I
;|
digi_dest: APND13
;|