<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Bob:<br><br>Along with adding support for raster maps to YAAC (for your spelunking project), I have also added support to display non-default RR bits, and RF-forward the bits unmodified. The build containing these changes should be out by tomorrow.<br><br>Do we need a way to manually specify non-default RR bit values for test injection? If so, how would you like it done?<br><br>Andrew Pavlin, KA2DDO<br><br><div><div id="SkyDrivePlaceholder"></div>> From: bruninga@usna.edu<br>> Date: Tue, 4 Dec 2012 12:18:31 -0500<br>> To: aprssig@tapr.org<br>> Subject: Re: [aprssig] AX.25 RR bit test - Holy Grail (KWD)<br>> <br>> Don't' know yet. Ill keep track of reports. As soon as someonc can set<br>> up a transmit test, (and have a client that can receive and display the<br>> bits) then we can test a kenwood digipeater.<br>> <br>> Bob<br>> <br>> -----Original Message-----<br>> From: aprssig-bounces@tapr.org [mailto:aprssig-bounces@tapr.org] On Behalf<br>> Of Lynn W. Deffenbaugh (Mr)<br>> Sent: Tuesday, December 04, 2012 12:11 PM<br>> To: TAPR APRS Mailing List<br>> Subject: Re: [aprssig] AX.25 RR bit test - Holy Grail (KWD)<br>> <br>> Ignore but copy from inbound path to outbound path in the event of a<br>> Kenwood-based digipeater? Or do they reconstruct the path components,<br>> possibly clobbering the received RR bits?<br>> <br>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>> <br>> <br>> On 12/4/2012 11:55 AM, Robert Bruninga wrote:<br>> > Kenwood confirms that their radios all will ignore the RR bits and so we<br>> > can use them for future features without impacting current functions.<br>> ><br>> > I will keep tabs of the results of all tests of the RR bits as we prove<br>> > that<br>> > The network is presently transparent to their future use. Please test<br>> and<br>> > report.<br>> ><br>> > I have now added both of these new proposals (Preemptive digipeating and<br>> > RR bits) to the APRS version 1.2 web page:<br>> > http://aprs.org/aprs12.html<br>> ><br>> > Bob, WB4APR<br>> ><br>> > -----Original Message-----<br>> > From: Robert Bruninga [mailto:bruninga@usna.edu]<br>> > Sent: Friday, November 30, 2012 3:07 PM<br>> > To: TAPR APRS Mailing List<br>> > Cc: Robert Bruninga<br>> > Subject: RE: [aprssig] AX.25 RR bit test - Holy Grail (reply)<br>> ><br>> > Your comments are all well received. But so far, none of the comments<br>> > have shown a reason why not to explore future use of these bits for<br>> future<br>> > constructs:<br>> ><br>> >> it would not work with existing software..<br>> > Never intended to "work". Only intended to be "transparent" or<br>> "ignored"<br>> > by existing software. The Future use of those bits is only for FUTURE<br>> > concepts which of course would require FUTURE code to take advantage of<br>> > it. But nothing that exists now would be impacted (if present hardware<br>> is<br>> > AX.25 compliant and transparent to them as they should be).<br>> ><br>> >> these bits are in AX.25 headers. _not_ in<br>> >> [packets] sent through APRS-IS...<br>> > SO therefore, by definition, they do not break anything that exists in<br>> the<br>> > APRS-IS and are 100% backwards transparent with the entire APRS-IS. It<br>> is<br>> > only backwards transparency that is a concern.<br>> ><br>> >> Also, there is no construct in the APRS-IS packet<br>> >> format to embed the values of those bits in the APRS-IS...<br>> > Sure there is. We can easily add into the APRS-IS pseudo header without<br>> > breaking anything that exists. I am sure that the clever minds that<br>> came<br>> > up with the Q construct can think of some similar way to indicate these<br>> > bits [11].<br>> ><br>> >> and not available in any clients speaking to command-mode TNC's.<br>> > But again, "are not available" does not block any future use and also<br>> > implies existing transparency.<br>> ><br>> >> Only KISS-mode TNC's would be able to pass such non-standard packets<br>> > First, GREAT! This means that every software or client that uses a KISS<br>> > interface can be updated to use these bits if desired.<br>> ><br>> > Second, these bits *are* STANDARD AX.25. "The bits ... may be used in<br>> an<br>> > agreed-upon manner in individual networks". And if that is not APRS,<br>> then<br>> > I don't know what else would be..<br>> ><br>> >> There's just WAY too many things using the TNC2<br>> >> humanly readable packet format, not just the APRS-IS,<br>> >> that would need/benefit from access to this information.<br>> > Again, that is FUTURE BENEFIT. Of course, FUTURE code would need to be<br>> > updated to take advantage of FUTURE use of these bits. But that is how<br>> we<br>> > move forward as long as it does not break anything that exists now.<br>> ><br>> >> But to me the death knoll is compatibility.<br>> >> There are just too many devices for this to ever<br>> >> be proven not to be harmful.<br>> > They are in the spec, the spec authorizes their use, every spec<br>> compliant<br>> > TNC, Radio, Hardware, etc should handle them just fine. We should not<br>> be<br>> > afraid to use something in the AX.25 spec that was put there just for<br>> this<br>> > kind of special network use, but we overlooked for so long? We simply<br>> need<br>> > to test them before using them.<br>> ><br>> > Of course, we would not move forward if ANY existing hardware failed to<br>> be<br>> > transparent to these bits. But that is no reason not to at least<br>> perform<br>> > the test and find where we stand.<br>> ><br>> >> I urge you to withdraw this part of the proposal...<br>> > But, until someone can show that a piece of hardware fails to pass these<br>> > packets, then I think it should remain on the table and worthy of<br>> > exploring and testing.<br>> ><br>> > So few of us can actually generate an AX.25 packet at the bit level,<br>> that<br>> > this testing can only be done by people who can test their AX.25<br>> > transmitting code. Maybe Byonics or Argilent, or any of the software<br>> TNC<br>> > authors can take a crack at testing it.<br>> ><br>> > So again, the only thing that matters now is TRANSPARENCEY of these bits<br>> > to all existing APRS and AX.25 hardware and firmware. Future use that<br>> > does not break anything that exists, seems to me to be a worthy area to<br>> > explore for future use for future (not presently existing) capabilities.<br>> ><br>> > Just brain storming...<br>> ><br>> > Bob, WB4APR<br>> ><br>> > _______________________________________________<br>> > aprssig mailing list<br>> > aprssig@tapr.org<br>> > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig<br>> ><br>> <br>> <br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@tapr.org<br>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig<br>> <br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@tapr.org<br>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig<br></div> </div></body>
</html>