[aprssig] AX.25 Digipeating precise timing?

[Lynn W Deffenbaugh (Mr)]

I'm not a spec writer, but it seems to me that the intent behind 
digipeating is to RE-transmit a packet to improve reception potential 
for a different coverage area. Since the digipeated packet would be 
coming from the same radio on the same antenna, then the coverage area 
should be the same and the packet shouldn't waste the additional 
airtime.  Of course, local conditions may have changed between the 
original packet and reception of a digipeat, but really, I think a 
second transmission by the originating station is nothing but a waste of 
shared channel airtime.  Especially when the solution is simply to 
remember our original packet as if it had already been digipeated.

But that's only my $0.02 to be taken for whatever it is worth.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


On 7/22/2019 7:28 PM, spam8mybrain wrote:
> Digipeating one's own packets does sound like a bug, but it was the 
> documented algorithm for NewN-n digipeating. I know this, because I 
> followed that algorithm rigorously when I implemented my software.
>
> Should that spec be changed to state that locally-originated packets 
> should be loaded into the 30-second memory along with received packets 
> that haven't already been received within the last 30 seconds?
>
> Also, is 30 seconds still a good choice, or should it go out to 1 
> minute? Alas, nothing reasonable would protect us from the Kamtronics 
> delayed digipeater, since it delays by longer than that.
>
> Just curious.
>
> Andrew, KA2DDO
> author of YAAC (which could digipeat itself according to the spec)
>
>
> -------- Original message --------
> From: "Lynn W Deffenbaugh (Mr)" <KJ4ERJ at arrl.net>
> Date: 7/22/19 19:08 (GMT-05:00)
> To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
> Subject: Re: [aprssig] AX.25 Digipeating precise timing?
>
> Also keep in mind the Kenwood D710 digipeating bust:  A radio will
> digipeat its OWN packet if it receives a digipeated copy of it with hops
> remaining.  In other words:
>
> GDHILL-8 transmits packet X with HOP7-7,HOP7-7 and is enabled for HOP
> digipeating.
> MDMTNS-7 digipeats the packet with HOP7-6,HOP7-7
> GDHILL-8 receives that, and digipeats it as HOP7-5,HOP7-7.
> MDMTNS-7 receives the digipeated packet but does NOT digipeat it again
> because it is in the recently digipeated list.
>
> The issues is that originated packets are NOT put in the recently
> digipeated list, which IMHO should be a recently TRANSMITTED list to
> include originated packets as well as digipeated packets.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
>
> On 7/22/2019 12:15 PM, Robert Bruninga wrote:
> > AX.25 experts needed:
> >
> > We finished the Appalachian Golden Packet event with 15 hops to 
> Maine and
> > 14 hops back to Georgia.
> >
> > At 9600 baud each packet is 0.5 seconds and we think we can increase
> > throughput significantly by totally changing our beacon plan, messaging
> > plan and getting the 2X benefit of 9600 baud.
> >
> > This means we would like to better understand the exact AX.25 packet
> > timing.
> >
> > I just timed 9600 baud packets between three kenwoods as digipeaters and
> > conclude an end to end packet with no collisions woiuld take about 8
> > seconds.  I want to analyze the probability of success with say a packet
> > starting at each end and meeting in the middle, what is the chance of
> > anialation of one, or both.  This depends on the delay that all
> > digipeateers (with Dwait off) will wait before transmitting. It is only
> > during this window when a given digi, could hear two packets before it
> > transmits.
> >
> > Anyone remember this stuff?, or am I starting from scratch..
> >
> > Radios are set to TXD of 200ms...  But that is after the radio is 
> already
> > keyed.
> >
> > Bob, Wb4APR
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
> >
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org