[aprssig] APRS Digipeter Design Questions

[Robert Bruninga]

>>> jdw at eng.uah.edu 4/29/2005 7:52:09 AM >>>
>If you're specifying individual nodes in a path, 
>8 hops isn't all that bad.

Thanks for the STUMP opportunity...

This is true, as regards to QRM, because it is a directed
path and so there are only 8 copies which is much less
QRM than even a WIDE2-2.  But it also lets me pontificate
on the practical side of it... which is practically useless.

If the probability of a collision is 50%, then the probability
of getting a packet 8 hops is 0.5 to the 8th power or
only 0.004, meanning on average, the sender would
have to send it over 250 times inorder to have a 50:50
chance of delivery ONCE. 

Where as the probabiliy of it going 2 hops is 25% and
after 4 retries you have a reasonable chance of 
delivery.  (though your chance of an ACK is also now
25% so that on average for a MESSAGE over such
a 2 hop path, the end-to-end with ACK probabilty is
only 6% and needs 16 retries if the software does
not use SMART ACKING.  Only APRSdos, APRS+SA
APRSscs and XASITR (to my knowledge) do smart
acking...  WIth smart-acking, the probablity of an
ACK is about the same as the success of the 
message...

Bob


I would think 3 would be the absolute minimum, so that you'd have room

for a path that starts out RELAY,WIDE2-2 and ends up as 
DIGI1*,DIGI2*,WIDE2

> 3. I also have a number of questions with regard to duplicate 
> supression.
> 3A.  UIDigi does this by time interval.  While this is desirable, it

> is much more complicated to keep track of time than to keep track of

> the number of transmissions.
[snick]
> Does anyone see a serious problem with this?

I'd rather see a clock, however rough or inaccurate (no need for an 
external clock chip or a GPS connection here, a counter would do).

If the network load is constant this would not be a problem.  If the 
load varies a great deal, then the user's guess at X may cause packets

for fixed stations to get dropped unfairly if the network loads drops 
below a given level, or it could cause unnecessary duplicates if X is 
guessed too low or the load increases above normal.

This issue would only affect fixed stations that don't vary their 
packets between transmissions.  Since mobile (and weather) stations' 
data vary, there would be a different packet and a different CRC 
generated to keep them from getting ignored.

X is also another parameter that must be configured for each digi to 
work correctly.  Simpler is better.

> 3B.  If I do implement this as described above, what would be a 
> reasonable maximum value for X?

I haven't measured packets time-wise, but if you assume the smallest 
packet that can be transmitted is 0.5s long, and you want to keep at 
least 30s worth of dupe suppression information, then X would need to 
be 30.

> 3C.  What parts of a packet should I include in the CRC calculation?

Well, I guess it's conceivable that 2 stations could have exactly the 
same payload (2 mobile stations, especially if they're close and/or 
running position ambiguity?), so maybe originating callsign +
payload??

I have a TNC-X/Digi_Ned rig currently running as a fill-in digi, if you

need more beta testers. (:

-Jason
kg4wsv


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig