OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   11.10.03 09:59l 232 Lines 9608 Bytes #999 (0) @ WW
BID : 2126-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 08, 2/5
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<IK1ZNW<IR0NET<VK3TE<GB7YFS<
      GB7BHM<ZL2BAU<ZL3VML
Sent: 031010/1110Z @:ZL3VML.#80.NZL.OC #:10119 [Chch-NZ] FBB7.00i $:2126-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: nc4cv path?
From: Wes Johnston <wes@johnston.net>
Date: Tue, 07 Oct 2003 22:43:48 -0400
X-Message-Number: 42

Does anyone know how to reach nc4cv?  His path is RELAY,RELAY,WIDE,WIDE
..... and he's killing us here in central SC.

Wes

----------------------------------------------------------------------

Subject: Re: interesting phenomena
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 08 Oct 2003 11:41:42 +0200
X-Message-Number: 7

Hello Wes,

At 22:37 7-10-03 -0400, Wes Johnston wrote:
>My station digipeated it.....
>KC4PL-9>SSUY2S,KD4RDB*,WIDE2-2: <<UI>>:'l9Zl!L>/]"4w}
>
>His home station digipeated the original packet...
>KC4PL-9>SSUY2S,KC4PL*,WIDE2-2: <<UI>>:'l9Zl!L>/]"4w}

Both KD4RDB and KC4PL got the same original packet and seem to transmit it 
in sequence instead of simultaneously, so you hear both. Bob would say that 
they should have transmit this packet simultaneously, this however gives 
you a second chance in case a packet is lost (trading reliability for 
bandwidth).

Of course one may wonder why KC4PL is acting as RELAY when there is a 
digipeater covering the same area. If KC4PL is filling a black hole then it 
is just coincidence that KC4PL-9 hit both the KC4PL relay and the KD4RDB 
wide. Most packets of KC4PL-9 will however only hit one or the other (if, 
and only if, KC4PL really fills a black hole). If KC4PL-9 always hits both 
then obviously KC4PL should not have been a RELAY; hitting both should be 
an exception.

>My station digipeated his home station's copy of the packet...
>KC4PL-9>SSUY2S,KD4RDB*,WIDE2-1: <<UI>>:'l9Zl!L>/]"4w}
>
>Now, if dupe checking were working correctly, my station should have 
>digipeated the packet one time.  When his home station TXed a copy of it, 
>my station should have realized that it had already digipeated that packet 
>and NOT TX'ed again.... but it did.... why?

Apparently duplicate checking doesn't work, but I don't quite understand 
how digipeating takes place if your station was transmitting the last 
packet you showed.

According to your analysis your digi got:
KC4PL-9>SSUY2S,KC4PL*,WIDE2-2:

and send this out as:
KC4PL-9>SSUY2S,KD4RDB*,WIDE2-1:

(KC4PL* replaced by KD4RDB* and WIDE2-2 decremented to WIDE2-1)

I expected this to go out instead:
KC4PL-9>SSUY2S,KC4PL*,WIDE2-1:

(only WIDE2-2 decremented to WIDE2-1 and no other changes)

It looks KD4RDB* filled the position that was previously allocated for 
"RELAY" and was changed to KC4PL* before.

Are you sure the last packet you showed is not digipeated by another WIDE? 
When another WIDE is digipeating the packet your station send before - 
which makes sense since your station was the first to digipeat it - then 
the packet contents is correct, that WIDE only decremented WIDE2-2 to 
WIDE2-1 and KD4RDB* will be in the "RELAY" position since you digipeated 
the packet first.

If your observation is correct then something is broken. It should not have 
send the packet the second time and it should not have overwritten KC4PL*
call.

Kind regards,

Henk.

----------------------------------------------------------------------

Subject: A multi-threaded solution
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 08 Oct 2003 06:51:54 -0400
X-Message-Number: 8

Is "the problem with APRS" one of technology or people's use of it?  Maybe
a little of both?

A (firewall) technology based solution requires a major overhaul of the
network in terms of digi-reconfiguration and inter-digi coordination.  Digi
owners will need to not only coordinate their efforts but also police
others as they decide to establish digi's of their own (digi's that may not
play nicely against a sub-region's firewall system).  Even so, there is
nothing to keep someone from R,W,W,T,W,W,R'ing it to death anyway.

The APRSteward (education based) solution requires only that an APRS
sub-region agree as to what the best path is for a given area and (1)
advertise it regularly as a BLN, (2) analyze RX'd paths, sending APRS
screen msgs to those that exceed the area 'best path', (3) notify area digi
owners if continued/long term abuse occurs.  In effect, APRSteward "sniffs
and tells" 24/7/365. Something that no human can do.  We humans observe
only the biggest violators because we are poor mental analyzers.  An
automated UI-View plug-in, activated in each region, would go a very long
way to help clean up the RF clutter through user education.  The end
result?  No need to rebuild the network ... yet.  Digi owners SUPLIST big
offenders.  All of this buys us time until the "next generation of APRS
technology " can be deployed.

The bottom line is that there are holes in all of the plans so far floated
(there's nothing that would keep two APRStweards from being setup in the
same area with each sending a different "best path"!).  Mr. Hollingsworth
has made it plain that Amateur Radio's future is built on our ability to
get along and not consume massive amounts of federal resources.

If this (abusive paths) is truly an issue to deal with, we need to approach
the problem in the same way.  How can it be solved without consuming a vast
amount of APRS resources (both technology and people)?  APRSteward is a
good place to start, while the infrastructure (and a way to
manage/coordinate it) is explored.

73,
Ev, W2EV

----------------------------------------------------------------------

Subject: High Speed APRS
From: "Leon S. Ciereszko III" <n4tcw@yahoo.com>
Date: Wed, 8 Oct 2003 15:49:17 +0600
X-Message-Number: 9

Greetings to the group,
I am installing a D700A in my work vehicle but have a small problem.  It is
a rental so I cannot drill any holes but need to be able to withstand
sustained speeds of 160 kph(100mph) wit occasional speeds of
200kph(125mph). I don't think that a mag mount will cut it, but perhaps a
lip mount?  The vehicle is a hatch back.  You got to love the German
Autobahn!

Lee N4TCW

----------------------------------------------------------------------

Subject: Re: interesting phenomena
From: Wes Johnston <wes@johnston.net>
Date: Wed, 08 Oct 2003 08:20:39 -0400
X-Message-Number: 10

Agreed there should not be two wides that close..  I am working with him to
get a linux box going that we can run digi ned on at a 3rd site so we can
use his and my sites only for remote RX and use internet to get packets up
to the digined site.

HOWEVER, I gotta take issue with two relays being that close together.  We
are on opposite sides of town from one another.... We both hear completely
different stations... My contention is that the digipeaters should not have
duped the packet.  His and my dwaits are set to 0... his held off
transmitting b/c he heard a station in the distance that my station
didn't... so much for fracticide.

You state that this is a mix of callsign sub and widen-n- flooding... but
for NOID to work, we HAVE TO HAVE THAT initial call of relay.... it is the
only way a callsign can get substituted so we know the all important entry
point into the network which you have harped about so much.

I contend that the network is broken. - welll at least the digipeater
firmware.... as much as I like kpc products, I gotta say that as long as we
run kpc3 digipeaters we will have dupes...

Wes

At 12:22 AM 10/8/2003, you wrote:
>This is normal.  And is what I have been saying for 2 weeks now. Two
>digipeaters heard the original packet and so that launched two packets.
...snip...

----------------------------------------------------------------------

Subject: Abusive User paths
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 8 Oct 2003 09:11:55 -0400 (EDT)
X-Message-Number: 11

>Pardon my raving, but this is yet another example of why we have to quit
>using obsolete technology  to deal with modern situations:

ALl these ravings about new digs and new software and new protocols etc
have NOTHING to do with fixing the fundamental problem of everyone trying
to FLOOD an existing network with 10 times more traffic than it can
handle.  And I have shown how with the new n-N paradigm, we can FIX
that problem WITH EXISTING digs, with just a few simple commands WITHOUT
having to FIX the users..

Yet, many (this is NOT directed at the originator above) want to just sit
on their hands and complain, and wring their hands about new twidgets
which will take 5 to 10 years to migrate through the system.

I am ALL FOR new 802.11 wireless high data rate LANS, and the ICOM D-STAR
and ANY OTHER high data rate HAM radio systems that we can field to
provide wider bandwidth and longer range to the HAM radio community.

But lets stop complaining and get out there and THINK about our LOCAL
APRS networks, WHAT LOCAL Service we want it to perform, over WHAT AREA,
and covering no more than the nearest 50 to 100 users in that AREA.  FOr
longer RANGE, then program LINKn-N's to move traffic great distances
between other ALOHA concentrations.  SYSOPS, Take control of your LAN.  It
is within your power...

Use the new n-N paradigm to limit FLOODING and make the network IMMUNE to
user errors and abusive paths while making it universal.

>Digi_ned or even better software.

Yes, I am all for upgrading digis.  But I am saying we can do 90% of what
we need to do with all the existing THOUSAND digis we already have in
place.  I fear the attitude for "improving the digis" is so that people
can CONTINUE to FLOOD even more efficiently!  This concept of distributing
everyone's packets everwhere with almost hundreds of copies each MUST STOP
on 144.39.

de WB4APR, Bob

----------------------------------------------------------------------



Read previous mail | Read next mail


 26.10.2026 10:27:10lGo back Go up