[aprssig] Aprx v2 beta, now with Viscous Digipeater

Thu Oct 22 21:52:00 EDT 2009

Matti,

Thanks for not taking offense at my comments.  Your replies are
very informative and well written.

>>> The results [for viscous digipeating] are 
>>> visible on this article, [and] its graphics:
>>>   http://wiki.ham.fi/Viscous_APRS_Digipeater

>> I assume it is a location suitable to be called a FILL-IN
digi?

> This is no such thing.... top of a high-rise
> (10 floors,... say about 40 m (120 feet) AGL.
> 
>> 2) Also the exact environment of that FILL-IN 
>> digi needs to be -well- quantified, or the 
>> data is meaningless.  Such as:
>> 
>> 3) How many WIDE-AREA digis does the FILL-IN hear?
>> [and what is their relative RF signal strength?]
[[ this must be known to asses whether this location]]
[[ will hear mutually destructive collisions when the]]
[[ other digis transmit at the same time...]]

>> 4) How many of those packets were heard 
>> DIRECT from users before the first hop?

> During first 21 hours of today, this digi+igate 
> received 14500 packets from radio channel, and 
> eventually chose to transmit 352 packets.
> 
> ... directly heard by my receiver were 741.
> Also packets already digipeated were chosen 
> to be digipeated, when they were not heard 
> from anywhere else.  There were 84 of those.

I guess they were heard once from some digi, but not heard
digipeated a second time by another digi?... BUT were still
eligible for digipeat.  So this digipeater is also acting as a
FLOOD-IN digi too.  OK, that is probably of value to locals
too..

> [IF] "viscously digi only first heard packets",
> then transmit count in the sample logs would 
> have been 268.  Or 1.8% of heard packets.  
> Now the share was 2.4%

Good.  So it is 67% a FILL-IN digi and 33% a FLOOD-IN digi.
That seems good too.

> What is more interesting is that a normal 
> non-delay digipeater retransmits some 20-30% 
> of packets it hears, even when the receiver
> is excellent and hears multiple big tower 
> digis and does not do any advanced filtering 
> based on content.

But in most cases, this is not a problem at all, since those
transmissions are occuring at exactly the same time as all the
other digis.  This is how the APRS network was designed, so that
all of the outward bound RETRANSMISSION of a user's Packet all
occurs at the same instant for that tier of outward bound
digipeaters.  SO all of these extra copies do not in anyway
interfere with the further propogation of the packet outward,
nor do they interfere with any other user's packets.

But if you DELAY until this is all over, and then transmit a
delayed packet, you are now DOUBLING the QRM potential of that
original packet, and have a very hig probablity of colliding
with the next user's packet and ruining his chances of being
heard in all directions.

> We plan to put one digi on a tall chimney...
> with area filter digipeating from boats 
> sailing on Gulf of Finland, but not cars
> driving on land.

A novel approach to a FILL-IN digi...

>> 5) IMPORTANT: What is the relative RF signal 
>> strength of each of the surrounding digis as 
>> heard on the FILL-IN exact antenna location.  
>> This is VERY important.  Because if any two 
>> of them are within say 13 dB of each other, 
>> then this FILL-IN will NEVER HEAR *any* packet 
>> heard by those two digis simultaneously and
>> will COMPELTELY skew the data to the point 
>> of being useless.

> You will not like this, but we usually let TNCs 
> to do carrier avoidance here.  In this regard 
> your instructions are conflicting, APRS end-users 
> should do carrier avoidance, but digis should not?

Let me clarify.  All DIGI's still do carrier avoidance, But ALL
of them in one area hear the channel go quiet at the same time..
The D-WAIT parameter only applies to digipeaters.  By having
D-WAIT set to zero, all of these digis that have heard the
original USER'S packet will all GRAB the channel (before any
other users) and will all transmit at the same time.  This
assures maximum channel efficiency for APRS digipeated packets.

User packets are held off an additional time period and that is
why the DIGI's always get the channel first. While these digi's
are all passing the original packet OUTWARD at the same time,
all of the other USERS stations are holding off until all of the
digi's are quiet again.  THen ALL of the users in the  area of
ALL of these digipeaters are all looking for the quiet so they
can transmit.

This is when your DElAYED FILL-IN then  decides to transmit, and
it collides with ALL users that were waiting to send their data.
This is the number one problem with a delayed DIGI of any kind.

>>  A) The first chart is ALL packets heard? 
> Yes.  All packets heard from that interface.
> 
>>  B) The second one is...
> No.  It is count of packets rejected by the 
> Rx-iGate system as unsuitable to be relayed 
> to APRSIS.

What could these be?  I thought the design of the APRS-IS was
that ALL packets heard would be injected into the APRS-IS.  I
gues these are already APRS-IS packets forwarded back to RF
already from the APRS-IS?  If so, then this is the LOOP flter I
guess...

>>  C) The third are the packets that the FILL-IN 
>> did not hear from any other source, and so   
>> it delayed and transmitted them?
> Yes.  Usually acting as only digipeater to do so...

> > > Really an excellent reducer of transmissions 
> > > for systems considered to be in a "fill in" role.
> > 
> > Depends on the exact environment... Can I ask you to add
> > clarification. FILL-IN to me has always meant a
one-way-outward
> > function to help get weak mobiles in bad areas OUT to the
> > network.  Maybe here, you are talking about letting the
FILL-IN
> > be a two-way-fill-in for all high level traffic and
digipeating
> > it again locally (and adding QRM and collisions with other
users
> > elsewhere)?  If so, this needs to be clearly indicated.
> > 
>> I wonder how the function of all these... rules 
>> are going to be unambiguously conveyed to the 
>> user who wanders into the footprint of this digi 
>> and begins to see inconsistent results to
>> his normal expectations?

> ... but some morons just can not be clued in about 
> correct behaviour without a 20 pound sledgehammer...
> Now try to do that to somebody two _countries_ away...
> 
> When designing these "dragonian" rules, we did 
> consider digipeating those packets with all 
> requests marked completed - perhaps leaving
> via-field SSID values unchanged.

Yes, this is the only way the originator and all of his friends
can see how he is wrongly configured...

> We chose not to.  Because when original WIDE7-7 
> has been digipeated down to WIDE7-3, there really 
> is no point in doing anything but drop
> it.   Local users we can educate, those far away 
> people are not reachable.

Good point.  But please DO digipeat at least once, the ORIGINAL
first hop bad packets (marked for no further digipeating) so
these can be educated to the sender and FIXED by him  or his
neighbors with a sledgehammer.

>>> Further links:
>>>   http://wiki.ham.fi/Aprx.en
>>>   http://ham.zmailer.org/oh2mqk/aprx/
>> 

Good work! Thanks
Bob, Wb4APR