[aprssig] Aprx v2 beta, now with Viscous Digipeater

[Matti Aarnio]

On Thu, Oct 22, 2009 at 11:47:09AM -0400, Robert Bruninga wrote:
> > The results [for viscous digipeating] are 
> > visible on this article, [and] its graphics:
> >   http://wiki.ham.fi/Viscous_APRS_Digipeater
> 
> First let me say that this is great info!  And I want to give
> full support to this kind of research and testing.  We need more
> rigorous research and testing in APRS and such testing needs to
> be done to good standards...  (to avoid the downside of
> meaningless testimonials)...
> 
> So, I hope you don't mind if I critique the study for
> clarification and add some very strong CAUTIONS.  Such data
> needs to stand up to the full rigor of review, such as...
> 
> 1) It needs clarification about what the station IS?  I assume
> it is at a location suitable to be called a FILL-IN digi?  If
> so, this needs to be stated specifically.  

This is no such thing.  I have antennas on top of a high-rise
(mere 10 floors, but high in this part of the world), 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?

As I understand the fill-in is that it retransmits packets out from
a coverage hole - in downtown concrete canyons or out there in the
boondocks.  Now if Big Digis have heard the packet, then this viscous
fill-in will not be sending anything, as Big Digis have already done
it, and the fill-in heard both the original, and the repeat.


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

Running the "digi" on a big computer with disk storage has its benefits,
I log everything in detail of what this thing hears and does...

During first 21 hours of today (by UTC time), this digi+igate received
14500 packets from radio channel, and eventually chose to transmit 352
packets.

What were accountable as directly heard by my receiver were 741.
However mere viscousness does not limit digipeating only on them.
Also packets already digipeated were chosen to be digipeated, when
they were not heard from anywhere else.  There were 84 of those.
So if one would add a rule of "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%

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.

On next round, the Aprx v2 gets content filters with syntax copied
from javAPRSSrvr adjunct filter.  Then I can add things like:
"Digipeat viscously only packets heard with coordinates within downtown
 city blocks, plus all APRS messages."

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

> 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?


> 6) The meaning of the plots is not perfectly clear.
> 
>  A) The first chart is ALL packets heard?

Yes.  All packets heard from that interface.

>  B) The second one is all packets NOT-Digipeated by this
>     FILL-IN?

No.  It is count of packets rejected by the Rx-iGate system as
unsuitable to be relayed to APRSIS.

The Aprx (v1) is primarily an Rx-iGate, after all, and telemetry
for it is for Rx-iGate.  Fift telemetry channel was always kept
reserved for eventual transmit, but system does actually collects
much more data than is possible to present with telemetry packets.
( Any advanced program of mine tens to get tens or even hundreds
  of statistics counters...  weird things like subtle protocol
  detail observation counts. )

>  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, I might add.

....

> > The bottom graph is number packets sent (per 10 minutes) by that node.
> > At first with normal delayless digipeat, and then with 5 seconds of
> > viscousness configured in.
> 
> Ah, now I see.  The graph needs a POINTER to show the boundary.
> When I frist saw this, I thought the 5 second viscous delay
> applied to the whole chart and the label was only where it is
> because that is where it fit best.

OK. I added some black pixels to give a clue.

> > 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.
> 
> > The system has also tons of built-in default 
> > behaviours documented elsewhere, like 
> > limiting the total number of requested and 
> > completed hops to 4 each.
> 
> I wonder how the function of all these draconian 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?
> 
> > One can freely put in a request like: 
> >      OH2XYZ>APRS,WIDE2-2,WIDE2-2,WIDE2-2
> 
> Which violates the recommendations for APRS operations.

Sure it does, but some morons just can not be clued in about correct
behaviour without a 20 pound sledgehammer applied on their kit.
Now try to do that to somebody two _countries_ away...

> These violations should be fixed at the source by user education
> and feedback.  Otherwise, human nature and psychological theory
> predicts that this user will not know -why- he is not getting
> out as he expects, and will only INCREASE the number of hops in
> any way possible even up to 7-7,7-7,7-7 and just keep flooding
> the network with MORE attempts instead of fixing *the* problem.

When designing these "dragonian" rules, we did consider digipeating
those packets with all requests marked completed - perhaps leaving
via-field SSID values unchanged.

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.

"Best available technology" before Aprx v2 has been writing tons
of blocking rules on  digi_ned  configuration...

One can add such also to Aprx v2 -- do not digipeat if source
matches these regex patterns, or any of via fields matches these,
or ... But on most cases there is no need to use such.

> > Also if the New-N-request is written like:  
> > WIDE3-6,   this one considers it bogus, 
> > and drops it.
> 
> And then what?  Where is the mechanism for educating or feeding
> back to the user his abuse of the system?  If the user needs 6
> hops to attempt a DX packet, then he should use
> DIGI1,DIGI2,DIGI3,DIGI4,DIGI5,DIGI6 and his packet will go where
> intended with only 6 dupes on the system.  This 6 hop path
> generates only HALF the number of packet as the usual WIDE2-2
> (which would generate up to 12 copies in a typical area)...  Of
> course, anyone with any knowledge of packet should realize that
> the chance of that packet getting through is vanishingly small,
> but still it is possible, and it does generate little QRM.

Direct digi paths are accounted separately from TRACE and WIDE.
present code does not apply any limits on them, so if you really
want to make multihop DX packet by explicite node hopping, it
is permitted.

This comes as an incidental result from doing standard AX.25 1.x/2.0
digipeating for other packet types, than APRS.

> > Also, when this sees bogus UIDIGI output 
> > of  WIDE3  without H-bit, this one sets 
> > the H-bit and checks the next field for 
> > possible trace/wide operation.  
> 
> This is a good fix.  Because the above packets are unfortunately
> transmitted by some broken digipeaters or settings, and usually
> these cannot be fixed by anyone at the source.

These could be fixed by somebody with the source (of UIDIGI software,)
but you do know how radio amateurs love to keep using hardware that is
considered obsolete...

> If there is no next field, no digipeat is done.
> 
> Again, I am not trying to degrade this experimentation.  In
> fact, I like to see more of it.  But we must eliminate all
> ambiguity in how the results of the testing are presented so we
> can draw the proper conclusions.
> 
> > Further links:
> >   http://wiki.ham.fi/Aprx.en
> >   http://ham.zmailer.org/oh2mqk/aprx/
> 
> Good work! Thanks
> Bob, Wb4APR

73 de Matti, OH2MQK