;
;  Copyright (C) 2000-2001  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 another 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 proceed checking from there. In case of matching with
;  WIDE the '*' will skip the 'I' and 'D' characters and proceed comparison
;  at the 'E'. In case of matching with W0EXT the '*' skip over the '0'
;  character and also proceed 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 own 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 miss interpretation.
;
;    "DigiSsid:" is used to repeat a frame if it has a desired TO field
;    just like "DigiTo:". It is only evaluated when there only 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.
;
;    If a "DigiSsid:" rule hits the "Digipeat:" rules will not be executed,
;    the "DigiSsid:" 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...
;
;  * 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 wont 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
;    send 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.
;
;    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. The all
;    <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.
;
;    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 (do the first
;    binary value bit is "Busy". Logical high is a '1' in the telemetry
;    message.
;
;    For 'lpt' also a 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.
;
;  * 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 an receive.
;
;    In DOS COM1 to COM4 can be used with the following mapping:
;
;    COM1 = IOA=0x3f8, IRQ=3
;    COM2 = IOA=0x2f8, IRQ=4
;    COM3 = IOA=0x3e8, IRQ=3
;    COM4 = IOA=0x2e8, IRQ=4
;
;    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>
;
;| * 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 creates 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 to the value of the variable.
;|
;|   The variables created this way can be embedded in a string which is
;|   send my 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
;|          max60   -> max over 60 minutes, passed 1 hour
;|          min60   -> min over 60 minutes, passed 1 hour
;|          sum60   -> sum over 60 minutes, passed 1 hour
;|          max120  -> max over 120 minutes, passed 2 hours
;|          min120  -> min over 120 minutes, passed 2 hours
;|          sum1440 -> sum over 1440 minutes, passed 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 you 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 imaginations, 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 functionalty.
;|
;  * Messages
;
;    DIGI_NED can send a number of responses to queries. Some of
;    those responses are defined in a text-file. The file is defines
;    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 remembers 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 this distance a DX bulletin
;    is never send and above this distance 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: 20 all DIGI_DEST,WIDE,WIDE3-3
digibcon.ini
;|
;  Send our station identification every 5 minutes. Note that this may be
;  required to fulfill 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
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, usign 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
;
;------------------------------------------------------------------------------
;
;  Commands to execute directly after the .ini file is processed. These
;  command are send through the message parser as if they were send over
;  the air. The purpose is to initialise output ports used for remote control
;  to a certain state.
;
;command: !out 2 10101011
;
;------------------------------------------------------------------------------
;
;  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
;
;  The same for trace,wide and apgate, shows that you can specify
;  more condensed rules. All rules are expanded in memory, so it
;  does not save memory at run-time.
;
digipeat: all relay,trace,wide all
;------------------------------------------------------------------------------
;  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: 1 local 1
;------------------------------------------------------------------------------
;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
;------------------------------------------------------------------------------
;
;  Inteligent digipeating rules
;
;  Handling of WIDEn-N
;  -------------------
;
;  General rule: calls of digipeaters shall not appear in the digipeater list.
;                last hop is WIDEn-1, then WIDEn shall be marked as "used"
;
;  Example: packet with WIDE3-3 should progress as follows
;
;  -- 1st hop on WIDE3-3 --
;  all ==> PE1XXX-1>APXXX PE1YYY* WIDE3-3 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY* WIDE3-2 XXXX XXXX
;
;  Rule: digipeat: all wide3-3 all swap0 wide3-2
;
;  -- 2nd hop on WIDE3-2 by "DIGI_2" --
;  all ==> PE1XXX-1>APXXX PE1YYY* WIDE3-2 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY* WIDE3-1 XXXX XXXX
;
;  Rule: digipeat: all wide3-2 all swap0 wide3-1
;
;  -- 3rd hop on WIDE3-1 by "DIGI_3" --
;  all ==> PE1XXX-1>APXXX PE1YYY* WIDE3-1 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY WIDE3* XXXX XXXX
;  (Hijack removed the call DIGI_3 from the list)
;
;  Rule: digipeat: all wide3-1 all swap wide3
;
;------------------------------------------------------------------------------
;
;  7 Hops
;
digipeat: all wide7-7 all swap0 wide7-6
;
;------------------------------------------------------------------------------
;
;  6 Hops
;
digipeat: all wide7-6 all swap0 wide7-5
digipeat: all wide6-6 all swap0 wide6-5
;
;------------------------------------------------------------------------------
;
;  5 Hops
;
digipeat: all wide7-5 all swap0 wide7-4
digipeat: all wide6-5 all swap0 wide6-4
digipeat: all wide5-5 all swap0 wide5-4
;
;------------------------------------------------------------------------------
;
;  4 Hops
;
digipeat: all wide7-4 all swap0 wide7-3
digipeat: all wide6-4 all swap0 wide6-3
digipeat: all wide5-4 all swap0 wide5-3
digipeat: all wide4-4 all swap0 wide4-3
;
;------------------------------------------------------------------------------
;
;  3 Hops
;
digipeat: all wide7-3 all swap0 wide7-2
digipeat: all wide6-3 all swap0 wide6-2
digipeat: all wide5-3 all swap0 wide5-2
digipeat: all wide4-3 all swap0 wide4-2
digipeat: all wide3-3 all swap0 wide3-2
;
;------------------------------------------------------------------------------
;
;  2 Hops
;
digipeat: all wide7-2 all swap0 wide7-1
digipeat: all wide6-2 all swap0 wide6-1
digipeat: all wide5-2 all swap0 wide5-1
digipeat: all wide4-2 all swap0 wide4-1
digipeat: all wide3-2 all swap0 wide3-1
digipeat: all wide2-2 all swap0 wide2-1
;
;------------------------------------------------------------------------------
;
;  1 Hop
;
digipeat: all wide7-1 all swap wide7
digipeat: all wide6-1 all swap wide6
digipeat: all wide5-1 all swap wide5
digipeat: all wide4-1 all swap wide4
digipeat: all wide3-1 all swap wide3
digipeat: all wide2-1 all swap wide2
digipeat: all wide1-1 all swap wide1
;
;------------------------------------------------------------------------------
;
;  0 Hops, these are not repeated (commented out)!
;
;digipeat: all wide7 all swap DIGI_CALL
;digipeat: all wide6 all swap DIGI_CALL
;digipeat: all wide5 all swap DIGI_CALL
;digipeat: all wide4 all swap DIGI_CALL
;digipeat: all wide3 all swap DIGI_CALL
;digipeat: all wide2 all swap DIGI_CALL
;digipeat: all wide1 all swap DIGI_CALL
;digipeat: all wide0 all swap DIGI_CALL
;
;------------------------------------------------------------------------------
;
;  Strange WIDE formats
;
digipeat: all wide-7 all swap0 wide-6
digipeat: all wide-6 all swap0 wide-5
digipeat: all wide-5 all swap0 wide-4
digipeat: all wide-4 all swap0 wide-3
digipeat: all wide-3 all swap0 wide-2
digipeat: all wide-2 all swap0 wide-1
digipeat: all wide-1 all swap wide
;
;------------------------------------------------------------------------------
;
;  Handling of TRACEn-N
;  ---------------------
;
;  General rule: calls of previous intelligent digipeaters stay in the
;  digipeater list (note that on overflow calls are dropped!).
;
;  Example: packet with TRACE3-3 should progress as follows
;
;  -- 1st hop on TRACE3-3 --
;  all ==> PE1XXX-1>APXXX PE1YYY* TRACE3-3 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY DIGI_CALL* TRACE3-2 XXXX XXXX
;
;  Rule: digipeat: all trace3-3 all swap DIGI_CALL,trace3-2
;
;  -- 2nd hop on TRACE3-2 by "DIGI_2" --
;  all ==> PE1XXX-1>APXXX PE1YYY DIGI_CALL* TRACE3-2 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY DIGI_CALL DIGI_2* TRACE3-1 XXXX XXXX
;
;  Rule: digipeat: all trace3-2 all swap DIGI_2,trace3-1
;
;  -- 3rd hop on TRACE3-1 by "DIGI_3" --
;  all ==> PE1XXX-1>APXXX PE1YYY DIGI_CALL DIGI_2* TRACE3-1 XXXX XXXX
;  all <== PE1XXX-1>APXXX PE1YYY DIGI_CALL DIGI_2 DIGI_3* TRACE3* XXXX XXXX
;
;  Rule: digipeat: all trace3-1 all swap2 DIGI_3,trace3
;
;------------------------------------------------------------------------------
;
;  7 Hops
;
digipeat: all trace7-7 all swap DIGI_CALL,trace7-6
;
;------------------------------------------------------------------------------
;
;  6 Hops
;
digipeat: all trace7-6 all swap DIGI_CALL,trace7-5
digipeat: all trace6-6 all swap DIGI_CALL,trace6-5
;
;------------------------------------------------------------------------------
;
;  5 Hops
;
digipeat: all trace7-5 all swap DIGI_CALL,trace7-4
digipeat: all trace6-5 all swap DIGI_CALL,trace6-4
digipeat: all trace5-5 all swap DIGI_CALL,trace5-4
;
;------------------------------------------------------------------------------
;
;  4 Hops
;
digipeat: all trace7-4 all swap DIGI_CALL,trace7-3
digipeat: all trace6-4 all swap DIGI_CALL,trace6-3
digipeat: all trace5-4 all swap DIGI_CALL,trace5-3
digipeat: all trace4-4 all swap DIGI_CALL,trace4-3
;
;------------------------------------------------------------------------------
;
;  3 Hops
;
digipeat: all trace7-3 all swap DIGI_CALL,trace7-2
digipeat: all trace6-3 all swap DIGI_CALL,trace6-2
digipeat: all trace5-3 all swap DIGI_CALL,trace5-2
digipeat: all trace4-3 all swap DIGI_CALL,trace4-2
digipeat: all trace3-3 all swap DIGI_CALL,trace3-2
;
;------------------------------------------------------------------------------
;
;  2 Hops
;
digipeat: all trace7-2 all swap DIGI_CALL,trace7-1
digipeat: all trace6-2 all swap DIGI_CALL,trace6-1
digipeat: all trace5-2 all swap DIGI_CALL,trace5-1
digipeat: all trace4-2 all swap DIGI_CALL,trace4-1
digipeat: all trace3-2 all swap DIGI_CALL,trace3-1
digipeat: all trace2-2 all swap DIGI_CALL,trace2-1
;
;------------------------------------------------------------------------------
;
;  1 Hop
;
digipeat: all trace7-1 all swap2 DIGI_CALL,trace7
digipeat: all trace6-1 all swap2 DIGI_CALL,trace6
digipeat: all trace5-1 all swap2 DIGI_CALL,trace5
digipeat: all trace4-1 all swap2 DIGI_CALL,trace4
digipeat: all trace3-1 all swap2 DIGI_CALL,trace3
digipeat: all trace2-1 all swap2 DIGI_CALL,trace2
digipeat: all trace1-1 all swap2 DIGI_CALL,trace1
;
;------------------------------------------------------------------------------
;
;  0 Hops, these are not repeated (commented out)!
;
;digipeat: all trace7 all
;digipeat: all trace6 all
;digipeat: all trace5 all
;digipeat: all trace4 all
;digipeat: all trace3 all
;digipeat: all trace2 all
;digipeat: all trace1 all
;digipeat: all trace0 all
;
;------------------------------------------------------------------------------
;
;  Strange TRACE formats
;
digipeat: all trace-7 all swap DIGI_CALL,trace-6
digipeat: all trace-6 all swap DIGI_CALL,trace-5
digipeat: all trace-5 all swap DIGI_CALL,trace-4
digipeat: all trace-4 all swap DIGI_CALL,trace-3
digipeat: all trace-3 all swap DIGI_CALL,trace-2
digipeat: all trace-2 all swap DIGI_CALL,trace-1
digipeat: all trace-1 all swap2 DIGI_CALL,trace
;
;------------------------------------------------------------------------------
;
;  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
digiend: 1 pe1mew-2 1
;
;------------------------------------------------------------------------------
;
;  Handling of destination-SSID based digipeating
;  ----------------------------------------------
;
;  Uses:
;  digito: <rx port> <to-call> <tx port> <replacement ssid> <...>
;  digissid: <rx port> <to-call> <tx port> <replacement ssid> <...>
;  ssid_ignore_prefix: <character>[<character>...]
;
;  digito: rules are only executed when there are no digipeaters specified
;  in the path. For SSID digipeating that will be the when the frame was
;  not repeated before. In these rules the own call is added in this case
;  and the SSID is decremented. The own call does not have the 'digipeated'
;  bit set.
;
;  digissid: rules are only executed when there are only unused digipeaters
;  in the path. This will be the case on SSID digipeating after the first
;  hop has been taken. In these rules the SSID is decremented.
;
;  ssid_ignore_prefix: if the payload starts with one of the characters
;  defined with this rule then the digito: and digissid: rules will be
;  ignored for the frame. This is for example used to ignore UIview
;  messages which start with a "~" character.
;
;  SSIDs have a meaning:
;  *-1  will be repeated with ssid 0,
;  *-2  will be repeated with ssid 1,
;  *-3  will be repeated with ssid 2,
;  *-4  will be repeated with ssid 3,
;  *-5  will be repeated with ssid 4,
;  *-6  will be repeated with ssid 5,
;  *-7  will be repeated with ssid 6,
;
;  On the first hop DIGI_CALL is added without a '*'.
;
;  On the first hop there are no DIGIs in the path, add our own call
;
;  Alternative 1, use if surrounding digis also understand SSID digipeating
;  ------------------------------------------------------------------------
;
digito: all *-1 all 0 add DIGI_CALL
digito: all *-2 all 1 add0 DIGI_CALL
digito: all *-3 all 2 add0 DIGI_CALL
digito: all *-4 all 3 add0 DIGI_CALL
digito: all *-5 all 4 add0 DIGI_CALL
digito: all *-6 all 5 add0 DIGI_CALL
digito: all *-7 all 6 add0 DIGI_CALL
;
;  On subsequent hops the first digi will have added its call, the
;  path only contains unused digipeaters. Just decrement the SSID.
;
digissid: all *-1 all 0 keep
digissid: all *-2 all 1 keep0
digissid: all *-3 all 2 keep0
digissid: all *-4 all 3 keep0
digissid: all *-5 all 4 keep0
digissid: all *-6 all 5 keep0
digissid: all *-7 all 6 keep0
;
;  Alternative 2, use if surrounding digis do not understand SSID digipeating
;  --------------------------------------------------------------------------
;  (if you want to use this, comment out the digito: and digissid: rules
;   of alternative 1 and uncomment the following 7 digito: rules)
;
;digito: all *-1 all 0 add2 DIGI_CALL,WIDE1
;digito: all *-2 all 1 add DIGI_CALL,WIDE2-1
;digito: all *-3 all 2 add DIGI_CALL,WIDE3-2
;digito: all *-4 all 3 add DIGI_CALL,WIDE4-3
;digito: all *-5 all 4 add DIGI_CALL,WIDE5-4
;digito: all *-6 all 5 add DIGI_CALL,WIDE6-5
;digito: all *-7 all 6 add DIGI_CALL,WIDE7-6
;
; SSID directional digipeating
; ----------------------------
;
;  In this example I have omni-directional antennas. This means that
;  North, South, East and West al go to the same ports.
;
;  To make this really work you should change the rules. I cannot supply a
;  default since this depends on your local situation. For each rule add
;  a path of about 2 or 3 hops that will work towards the given direction
;
;  *-8  will go north-bound, Add a path in north direction to make it work
;  *-9  will go south-bound, Add a path in south direction to make it work
;  *-10 will go east-bound,  Add a path in east  direction to make it work
;  *-11 will go west-bound,  Add a path in west  direction to make it work
;
;  I will give an example for my station in commented form. The default
;  uses generic calls and will go in every direction if you don't change it.
;  I have a small antenna, so all data is routed first through the nearby
;  WIDE first.
;|
;digito: 1 *-8 all 0 add PI1APA,PD0JEY-2,PA3EMS-2
;digito: 1 *-9 all 0 add PI1APA,PE1ABT-4,PE1SAY-2
;digito: 1 *-10 all 0 add PI1APA,PE1OWG-2,PA0JWX-2
;digito: 1 *-11 all 0 add PI1APA,PI1APK,PA1HBL-2
;|
;  Active default rules using WIDE calls:
;
digito: 1 *-8 all 0 add WIDE,WIDE
digito: 1 *-9 all 0 add WIDE,WIDE
digito: 1 *-10 all 0 add WIDE,WIDE
digito: 1 *-11 all 0 add WIDE,WIDE
;
;  *-12 will go north-bound same as *-8 but with an additional WIDE
;  *-13 will go south-bound same as *-9 but with an additional WIDE
;  *-14 will go east-bound  same as *-10 but with an additional WIDE
;  *-15 will go west-bound  same as *-11 but with an additional WIDE
;
;  My example should become:
;|
;digito: 1 *-12 all 0 add PI1APA,PD0JEY-2,PA3EMS-2,WIDE
;digito: 1 *-13 all 0 add PI1APA,PE1ABT-4,PE1SAY-2,WIDE
;digito: 1 *-14 all 0 add PI1APA,PE1OWG-2,PA0JWX-2,WIDE
;digito: 1 *-15 all 0 add PI1APA,PI1APK,PA1HBL-2,WIDE
;|
;  Active default rules using WIDE calls:
;
digito: 1 *-12 all 0 add WIDE,WIDE,WIDE
digito: 1 *-13 all 0 add WIDE,WIDE,WIDE
digito: 1 *-14 all 0 add WIDE,WIDE,WIDE
digito: 1 *-15 all 0 add WIDE,WIDE,WIDE
;
;  ssid_ignore_prefix:
;
;  This rule is used to ignore UIview messages which start with a "~"
;  character. UIview messages use as destination address the address
;  of the opposite station. These adresses can have a SSID and are
;  still using PID F0 for normal AX.25 messages. We should avoid to start
;  SSID digipeating on those packets which changes the destination SSID.
;  The data of all UIview messages start with a "~", if the payload data
;  starts with a "~" no SSID digipeating will be done.
;
ssid_ignore_prefix: ~
;
;------------------------------------------------------------------------------
;
;  Digipeat frames with these TO calls and no existing digipeaters.
;  Pick up these packets if they didn't have any "path"
;
;  On AP check explicitly for SSID 0
;
digito: 1 AP*-0,WX,CQ all 0 add DIGI_CALL,WIDE
digito: 2 AP*-0,WX,CQ 2 0 add DIGI_CALL
;
;------------------------------------------------------------------------------
;
;  Preemptive digipeating. If one of the unused digis matches with
;  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 RELAY IGNORE
preempt: all DIGI_CALL
;
;  If the next call appears in a preempted digipeater list and is not
;  already used then retain the call by relocating the call after the
;  preempted call.
;
preempt_keep: PA*,PE*,PD*,PI*
;
;  some calls should never be relocated, even they match with
;  "preempt_keep:". These are named in here.
;
preempt_never_keep: RELAY*,WIDE*,TRACE*
;
;------------------------------------------------------------------------------
;
;  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 send
;  out as a normal digipeated frame using the same digipeater path
;  manipulations as also used for none-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 own 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 own 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 with 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: 5213.61N 00600.00E
;
;  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 port 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 with 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 that the name is limited in size, otherwise
;  it is truncated. Up to 5 characters appear on a TH-D7 screen, up to
;  10 characters 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: 1 VHF
;dx_portname: 2 UHF
;
;dx_portname: 1 144.800
;dx_portname: 2 431.0375
;
;------------------------------------------------------------------------------
;
;  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: 10
;
;  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: +2
;
;  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, minimum 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,min1,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 100rths 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 100rths of inch
;|wx_var: p,sum1440,lpt1_8/3,0,3.937,0
;|
;| rainfall since midnight from lpt1 port 3, convert from mm to 100rths 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 100rths 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
;
block: 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: 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 MAILL and FBB put out by an FBB BBS. On all other port
;  there are no restrictions. (note this line is commented out, its
;  just an example)
;
;allow_to: 2 MAIL*,FBB*
;
;  If allow_from: is defined only packet 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 port
;  there are no restrictions. (note these lines are commented out, its just
;  an example)
;
;allow_from: 1,2 PE*,PA*,PI*
;allow_from: 2 PD*
;
;  Calls that are not allowed to query the digipeater
;
msg_block: 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 build-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 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 no 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
;
;------------------------------------------------------------------------------
;
;  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 that 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: PE1DNN,PE1DNN-7,PE1DNN-9,PE1MEW,PE1LIF
;|
;------------------------------------------------------------------------------
;
;  The enable-exit option enables the possibility to stop DIGI_NED remotely.
;  DIGI_NED will exit with exit-code 2, 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: 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 de
;  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: PE1DNN-2
;
;  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 alfanumeric 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
;|
digi_dest: APND0V
;|
