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

[Lynn W. Deffenbaugh (Mr)]

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
>