Order Tray | Contact Us | Home | SIG Lists

[aprssig] Sample Digi-Ned ini file for the new no relay/wide system

Wes Johnston aprs at kd4rdb.com
Mon Apr 11 18:46:51 UTC 2005

Don't confuse UI-Digi with DIGI_NED..... UI-Digi needs a PROM and a TNC2
clone, and DIGI-NED runs on a PC. 

But he does have a prom burner...

Christensen, Eric Harlan wrote:

>Do you have a prom burner?  We up here in Eastern North Carolina would
>like to do the same thing but don't have a way of creating the proms.
>Eric KF4OTN
>kf4otn at amsat.org
>>-----Original Message-----
>>From: aprssig-bounces at lists.tapr.org 
>>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Gale D. Wilkinson
>>Sent: Monday, April 11, 2005 13:51
>>To: aprssig at lists.tapr.org
>>Subject: [aprssig] Sample Digi-Ned ini file for the new no 
>>relay/wide system
>>This is a copy of my digi_ned.ini file showing how we have it 
>>set here 
>>in central South Carolina.  It is configured to do the 
>>following: 1.  Relay & Wide are ignored. 2.  Wide1-1 is 
>>treated as the old Relay was. 3.  If a packet is received 
>>directly (max 1 hop away) and the n-n is 
>>excessive (7-7, 6-6, etc) it will have the path changed to 
>>Wide2-1 (one 
>>hop completed by this digi and one to go) as 2 hops will cover a good 
>>portion of the state.  Plus the fact is that I am also an I-Gate so a 
>>long path is not needed.
>>4.  If a packet is received that is on its 3rd or later hop, 
>>then is an 
>>unwanted dx packet and is dropped on the floor.
>>What all of this does is allow any visitors wandering through with 
>>excessive paths to get out (and to an I-Gate), but will drop 
>>all of the 
>>out of state and non local area traffic.  Since we have 
>>implemented this 
>>here we have had over 40% less packets on rf, and the local 
>>mobiles are 
>>getting in much better.
>>Note that Henk was a lot of help in getting this to do 
>>exactly what we 
>>wanted here.  Thanks Henk!
>>    Gale
>>    KC4PL
>>; digi_ned.ini
>>; PE1DNN
>>; Added logfile to show you what happens with various calls
>>; and paths...
>>;logfile: kc4pl.log
>>version: 2.1
>>;this stops my second port from transmitting (receive only 
>>port from the 
>>mic-e system
>>; uhf link on our local repeater)
>>command: !ptt x0xxxxxx
>>send: 30 all WIDE2-2
>>send: 10 all ID
>>digipeat: all DIGI_CALL all
>>; PE1DNN
>>; About: "digipeat: all relay,wide,sc all"
>>; 1) I think Bob doesn't want plain WIDE anymore
>>; 2) So we only want to react to on RELAY, WIDEn-N, SCn-N
>>;    and our own call. We already had our own call and
>>;    WIDEn-N and SCn-N are all mentioned below
>>; 3) We only want to act on relay if it is the first
>>;    digipeater in the list
>>; Conclusion, we only need RELAY and use digi_first:...
>>; KC4PL
>>;  As we do not want to do relay here, but do want to use
>>;  the new wide1-1 replacement, the relay in the following
>>;  statement was replaced by wide1-1
>>digifirst: all wide1-1 all
>>; If a mobile happens to wander through the local
>>; area with a monster path, we want them to be
>>; digi'd, but with a more reasonable path.  So if
>>; the path is a wideX-X where both values are the
>>; same (first hop) then digi the packet, but
>>; change the wide value to 2-1 (2-2 with one hop
>>; completed). Or if it is the second hop (from
>>; outside the local area) do the same thing
>>; However, if this packet is from outside of the
>>; local area and has already made 2 hops or more
>>;to get to us, the drop it on the floor.
>>; In short, we want to ignore anything that takes
>>; more than 2 hops to get to us as it is more
>>; than likely that is is from out of state and is
>>;definitely not from our "local" area.
>>digipeat: all wide7-7 all replace DIGI_CALL,wide2-1
>>digipeat: all wide7-6 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide7-5 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide7-4 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide7-3 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide7-2 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide7-1 all replace2 DIGI_CALL,wide2
>>digipeat: all wide6-6 all replace DIGI_CALL,wide2-1
>>digipeat: all wide6-5 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide6-4 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide6-3 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide6-2 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide6-1 all replace2 DIGI_CALL,wide2
>>digipeat: all wide5-5 all replace DIGI_CALL,wide2-1
>>digipeat: all wide5-4 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide5-3 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide5-2 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide5-1 all replace2 DIGI_CALL,wide2
>>digipeat: all wide4-4 all replace DIGI_CALL,wide2-1
>>digipeat: all wide4-3 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide4-2 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide4-1 all replace2 DIGI_CALL,wide2
>>digipeat: all wide3-3 all replace DIGI_CALL,wide2-1
>>digipeat: all wide3-2 all replace DIGI_CALL,wide2-1
>>;digipeat: all wide3-1 all replace2 DIGI_CALL,wide2
>>digipeat: all wide2-2 all replace DIGI_CALL,wide2-1
>>digipeat: all wide2-1 all replace2 DIGI_CALL,wide2
>>; Note that Wide1-1 is commented out below.  This is
>>; because it is already being handled by the
>>; digifirst command at the top of the ini file.
>>;digipeat: all wide1-1 all replace2 DIGI_CALL,wide1
>>;Handle SCN-N with no special handling required
>>; PE1DNN
>>; 1) I assume that if the packet has not been digipeated
>>;    before, we should leave our call as entry-digi. The
>>;    others will work as WIDEn-N used to work in the past
>>;    digifirst: will work if the call is found and the
>>;    packet has never been digipeated by anybody before
>>;    diginext: will work if the call is found and the
>>;    packet has been digipeated by somebody before
>>; 2) We should use "replace0" when we don't want the
>>;    SCn-N to marked as "used" before N reaches zero.
>>; KC4PL
>>; For the SS (state) paths, we don't really care about
>>; the path length as it will never get out of the state
>>; to QRM digi's in the surrounding area.  Though in
>>; reality, for a state the size of ours, 4 hops would
>>; probably be a more practical limit.
>>digifirst: all sc7-7 all replace DIGI_CALL,sc7-6
>>diginext: all sc7-7 all replace0 sc7-6
>>digipeat: all sc7-6 all replace0 sc7-5
>>digipeat: all sc7-5 all replace0 sc7-4
>>digipeat: all sc7-4 all replace0 sc7-3
>>digipeat: all sc7-3 all replace0 sc7-2
>>digipeat: all sc7-2 all replace0 sc7-1
>>digipeat: all sc7-1 all replace sc7
>>digifirst: all sc6-6 all replace DIGI_CALL,sc6-5
>>diginext: all sc6-6 all replace0 sc6-5
>>digipeat: all sc6-5 all replace0 sc6-4
>>digipeat: all sc6-4 all replace0 sc6-3
>>digipeat: all sc6-3 all replace0 sc6-2
>>digipeat: all sc6-2 all replace0 sc6-1
>>digipeat: all sc6-1 all replace sc6
>>digifirst: all sc5-5 all replace DIGI_CALL,sc5-4
>>diginext: all sc5-5 all replace0 sc5-4
>>digipeat: all sc5-4 all replace0 sc5-3
>>digipeat: all sc5-3 all replace0 sc5-2
>>digipeat: all sc5-2 all replace0 sc5-1
>>digipeat: all sc5-1 all replace sc5
>>digifirst: all sc4-4 all replace DIGI_CALL,sc4-3
>>diginext: all sc4-4 all replace0 sc4-3
>>digipeat: all sc4-3 all replace0 sc4-2
>>digipeat: all sc4-2 all replace0 sc4-1
>>digipeat: all sc4-1 all replace sc4
>>digifirst: all sc3-3 all replace DIGI_CALL,sc3-2
>>diginext: all sc3-3 all replace0 sc3-2
>>digipeat: all sc3-2 all replace0 sc3-1
>>digipeat: all sc3-1 all replace sc3
>>digifirst: all sc2-2 all replace DIGI_CALL,sc2-1
>>diginext: all sc2-2 all replace0 sc2-1
>>digipeat: all sc2-1 all replace sc2
>>digipeat: all sc1-1 all replace sc1
>>ssid_ignore_prefix: ~
>>; PE1DNN
>>; About: preempt: all RELAY IGNORE
>>; 1) Preempt works by examining every VIA call in sequence against
>>;    all preempt rules. The first hit wins. When we have a "preempt"
>>;    rule for RELAY and RELAY is the first in the VIA list then a
>>;    match is found immediately. So the digipeater will not look
>>;    further for our own call, WIDEn-N or SCn-N. If we want this
>>;    then the only way to have this is not to preempt on RELAY.
>>; 2) When dropping "preempt" for RELAY try skip over RELAY by
>>;    preempting on DIGI_CALL, WIDE* and SC*.
>>; PE1DNN
>>; 1) In case of KC4PL,RELAY it will handle KC4PL but unfortunately
>>;    leave RELAY. This is not what we want, but I don't know how
>>;    to prevent it, since:
>>; 2) We cannot have KC4PL rewrite the path to overwrite RELAY since
>>;    the path may be something like KC4PL,KD4RDB or KC4PL,SC3-3 and
>>;    of course the malicious KC4PL,RELAY.
>>; 3) When we receive something like ACALL*,RELAY the digipeater
>>;    will ignore the packet, so we at least make sure it doesn't
>>;    work on our digipeater.
>>preempt: all DIGI_CALL
>>; PE1DNN
>>; 1) We also want to skip over RELAY etc if there is a 
>>WIDEn-N or SCn-N
>>;    call in the list.
>>; 2) WIDE* and SC* digipeat rules will overwrite the path, do 
>>no worries
>>;    about RELAY's located after the WIDEn-N or SCn-N.
>>; 3) Using WIDE* and SC* will also preempt a single WIDE and 
>>SC, we only
>>;    want it to react on WIDE and SC with a digit. A ! will 
>>match a digit
>>preempt: all WIDE!*
>>preempt: all SC!*
>>; PE1DNN
>>; 1) If we skip over call normally the calls skipped over are 
>>put after
>>;     the call we preempted. We don't need it since we are going
>>;     to replace the remaining calls anyway. So keep nothing...
>>preempt_never_keep: *
>>size_heard_list: 100
>>size_heard_show: 16
>>keep_time: 540
>>short_keep_time: 10
>>data_prefix: :?
>>message_file: digi_ned.mes
>>message_keep_time: 900
>>; PE1DNN
>>; 1) WIDE is gone, so message path should not be WIDE...
>>message_path: all WIDE1-1
>>max_msg_hops: 2
>>kenwood_mode: 2
>>digi_owner: KC4PL-1
>>enable_exit: 1
>>digi_call: KC4PL
>>; PE1DNN
>>;OLD: digi_dest: APND0S
>>; 1) I see APDN0S which is for version 0.2.8, the latest is 0.3.5
>>;    I hope all the features I used work on that one...
>>digi_dest: APND0Z
>>No virus found in this outgoing message.
>>Checked by AVG Anti-Virus.
>>Version: 7.0.308 / Virus Database: 266.9.6 - Release Date: 4/11/2005
>>aprssig mailing list
>>aprssig at lists.tapr.org 
>aprssig mailing list
>aprssig at lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.tapr.org/pipermail/aprssig/attachments/20050411/b8500582/attachment.htm 

More information about the aprssig mailing list