<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>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.<div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Just curious.</div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC (which could digipeat itself according to the spec)</div><br><br>-------- Original message --------<br>From: "Lynn W Deffenbaugh (Mr)" <KJ4ERJ@arrl.net> <br>Date: 7/22/19 19:08 (GMT-05:00) <br>To: TAPR APRS Mailing List <aprssig@lists.tapr.org> <br>Subject: Re: [aprssig] AX.25 Digipeating precise timing? <br><br>Also keep in mind the Kenwood D710 digipeating bust: A radio will <br>digipeat its OWN packet if it receives a digipeated copy of it with hops <br>remaining. In other words:<br><br>GDHILL-8 transmits packet X with HOP7-7,HOP7-7 and is enabled for HOP <br>digipeating.<br>MDMTNS-7 digipeats the packet with HOP7-6,HOP7-7<br>GDHILL-8 receives that, and digipeats it as HOP7-5,HOP7-7.<br>MDMTNS-7 receives the digipeated packet but does NOT digipeat it again <br>because it is in the recently digipeated list.<br><br>The issues is that originated packets are NOT put in the recently <br>digipeated list, which IMHO should be a recently TRANSMITTED list to <br>include originated packets as well as digipeated packets.<br><br>Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br><br><br>On 7/22/2019 12:15 PM, Robert Bruninga wrote:<br>> AX.25 experts needed:<br>><br>> We finished the Appalachian Golden Packet event with 15 hops to Maine and<br>> 14 hops back to Georgia.<br>><br>> At 9600 baud each packet is 0.5 seconds and we think we can increase<br>> throughput significantly by totally changing our beacon plan, messaging<br>> plan and getting the 2X benefit of 9600 baud.<br>><br>> This means we would like to better understand the exact AX.25 packet<br>> timing.<br>><br>> I just timed 9600 baud packets between three kenwoods as digipeaters and<br>> conclude an end to end packet with no collisions woiuld take about 8<br>> seconds. I want to analyze the probability of success with say a packet<br>> starting at each end and meeting in the middle, what is the chance of<br>> anialation of one, or both. This depends on the delay that all<br>> digipeateers (with Dwait off) will wait before transmitting. It is only<br>> during this window when a given digi, could hear two packets before it<br>> transmits.<br>><br>> Anyone remember this stuff?, or am I starting from scratch..<br>><br>> Radios are set to TXD of 200ms... But that is after the radio is already<br>> keyed.<br>><br>> Bob, Wb4APR<br>><br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@lists.tapr.org<br>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br>><br><br><br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br></body></html>