[aprssig] AX.25 RR bit test - Holy Grail (KWD)

Tue Dec 4 13:23:07 EST 2012

Bob:

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.

Do we need a way to manually specify non-default RR bit values for test injection? If so, how would you like it done?

Andrew Pavlin, KA2DDO

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20121204/35737411/attachment.html>