[aprssig] AX.25 RR bit test - possible format

Tue Dec 4 18:04:45 EST 2012

Come to think of it, however we will display these bits, we cannot mess up
the present display of the FROM>TO calls and the display needs to
separately display the bits for each of the header callsign fields.

One method might be something like [RR:FFTTDDddDDdd...] inserted like
TNC's do when they display the MCOM <UI> and other such parameters

Where [RR:...] identifies the overall format of reporting the RR bits
Where FF are the values of the FROM RR bits
Where TT are the values of the TO RR bits
Where DD and dd ... are the values of each digi field (up to seven pairs)

Just a thought.  We cannot easily insert the [FF] and [TT] and [DD] in
every field without having to redo a lot of parsers, so I though putting
them all in one BRACKET field might be an idea...

Bob, Wb4APR

-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Charles Bland
Sent: Tuesday, December 04, 2012 1:33 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] AX.25 RR bit test - Holy Grail (KWD)

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

_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig