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

Tue Dec 4 18:32:54 UTC 2012

Bob, et al,

I modified my KISSMonitor program to display the RR value for each
callsign. I extract the bits and divide the value by 32 to normalize
them to 0, so you will have a range of 0-3.

You can download the program at http://aprstw.blandranch.net/KISSMonitor.exe

When you start it, it takes a couple of packets for it to sync to the
flow, but it tells you on the screen what it's doing.

Chuck

On Tue, Dec 4, 2012 at 9:18 AM, Robert Bruninga <bruninga at usna.edu> wrote:
> 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