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

Tue Dec 4 14:00:09 EST 2012

Can someone show us how to quickly send some test packets to a KISS TNC:

Help me test the RR bits.  I have plenty of KPC-3 TNC’s.

I can place one into KISS mode.

I can program a PIC to send it KISS PACKETS for transmission.

Can Andrew or Lynn or anyone tell me the exact “string” to send to a KISS
TNC to send these packets:

WB4APR>APRSRR,DIGI:!3906.11N/07520.22W-test11

WB4APR>APRSRR,DIGI:!3906.11N/07520.22W-test10

WB4APR>APRSRR,DIGI:!3906.11N/07520.22W-test01

WB4APR>APRSRR,DIGI:!3906.11N/07520.22W-test00

And in each one of them, I will make the RR bits be 11, 10, 01,00 as
indicated.

Then I can test the kenwoods, and KPC’3s.  Any anyone else can do their own
tests too.

ARGH, I guess I also have to genereate a CRC which is NOT something easy to
do manyally. Hummh..

Or does the KISS do that for me I hope?

Bob, WB4APR

*From:* aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] *On
Behalf Of *Andrew P.
*Sent:* Tuesday, December 04, 2012 1:23 PM
*To:* aprssig at tapr.org
*Subject:* Re: [aprssig] AX.25 RR bit test - Holy Grail (KWD)

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/dbd92ef3/attachment.html>