<div>I can't get the page to load to read the priority article. However, at first brush, I'm a little bewildered by this. In the past DWAIT 0 has been pushed and digipeaters are supposed to digi straight away. Digi's should not wait to digipeat a packet. Fracticide and the FM capture effect are supposed to keep me from hearing multiple digi's of my packet. An example of this is in the morning when the band is open, I often see my packet digipeated by two digi's simultaneously. Well to be more correct, I'm dead in the middle between two of them and can't decode either, but I do see the S9 digi drop first leaving a few milliseconds of the S3 digi's packet. This is how it's supposed to work.</div>
<div> </div>
<div>To say that a packet would have priority over other packets makes sense when you have lots of packets queued up and *could* reorder the queue and push the hi priority packets to the head of the line. But that's not how it works on 2m. Digi's are supposed to respond ASAP, one packet at a time. There is no possibility to hear a 2nd packet before digipeating in a properly configured digipeater. Are we to assume that a digi would intentionally delay a given packet just in case something of a higher priority came along in the next few seconds?</div>
<div> </div>
<div>Something that was suggested a few years ago focused on the low priority packets. Perhaps a different perspective of the same problem... instead of marking some packets as hi priority, let's mark some packets as low priority. Multiple packets could be accumulated and digipeated all at once at the end of some interval. For example, a WX station could be said to be low prority trafic. So the digipeater queues such packets and at the end of 120(??) seconds would spit all of them out. The savings would be (N-1) x txdelay seconds. Other opportunities for low priority traffic could the the beacons of other neighboring digipeaters.</div>
<div> </div>
<div>As far as where to indicate low priority, I believe it needs to be in the ax25 header, not embedded inside the data portion of the packet, UI-view bedamned.... (no offense to UI-View users intended). As far as I can see, fixed firmware digipeaters are more of a legacy problem than ui-view in any case.</div>
<div><br clear="all">Wes<br>---<br>Hitler gave great speeches too!<br><br><br></div>
<div class="gmail_quote">On Wed, Aug 19, 2009 at 10:05, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">APRS needs a priority bit so that the network can make decisions<br>about traffic during times of stress.<br>
<br>We have been looking for a way to include a PRIORITY bit in all<br>APRS packets for many years, and there are 3 available bits in<br>the standard packet, but they cannot be used until UI-view is<br>obsolete.<br><br>This last week we did find that one of these bits IS backwards<br>
compatible with UI-view and so we would like to move forward on<br>this issue. Please read:<br><a href="http://aprs.org/aprs12/priority-bit.txt" target="_blank">http://aprs.org/aprs12/priority-bit.txt</a><br><br>Basically, we will use the CASE of the OVERLAY byte to indicate<br>
ROUTINE or PRIORITY. If the overlay byte is UPPERCASE or<br>missing, then the packet is ROUUTINE. If the case of the<br>overlay byte is -lowercase- then the packet is PRIORITY.<br><br>Last week testing confirmed that UI-view and most other clients<br>
will display these lower case overlays, or can be updated to do<br>so, so this has now been added to the APRS12 addendum.<br><a href="http://www.aprs.org/aprs12.html" target="_blank">www.aprs.org/aprs12.html</a><br><br>This combined with the OPERATOR PRESENT bit which has been<br>
defined for years, gives operators an easy way to differentiate<br>assests of immediate value during times of stress and to<br>minimize or ignore routine or unattended systems as needed.<br><br>DIGIPEATER code can add a SYSOP parameter that allows a sysop to<br>
designate a local emergency and to implement a MINIMIZE function<br>that lets the digipeater make decisions on traffic load based on<br>packet priority or other parameters.<br><br>Bob, WB4APR<br><br><br>_______________________________________________<br>
aprssig mailing list<br><a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br><a href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</blockquote></div><br>