What is "TNC Channel Switching"?

[Andrew Pavlin]

Greetings, all.

I was slogging through the APRS spec, and came upon a mention that the ASCII characters '|' and '~' were reserved for TNC channel switching, and couldn't appear in any messages or even as a symbol code.

What does this mean, and is it still applicable? Will I break the APRS-IS or some ancient TNC somewhere if I send those characters in an APRS message?

Just curious.

Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry

[Robert Bruninga]

The pipe and tilde characters were sensed as a STREAM switch in the
Kantronics dual-band TNC's.
I figured it was good to aovid them so that these TNC's could not get
inadvertently switched into the wrong mode.
Seemed like a good idea at the time.

Bob, WB4APR

-----Original Message-----
From: aprssig-bounces-***@public.gmane.org [mailto:aprssig-bounces-***@public.gmane.org] On Behalf
Of Andrew Pavlin
Sent: Friday, April 11, 2014 9:23 AM
To: aprssig-***@public.gmane.org
Subject: [aprssig] What is "TNC Channel Switching"?

Greetings, all.

I was slogging through the APRS spec, and came upon a mention that the
ASCII characters '|' and '~' were reserved for TNC channel switching, and
couldn't appear in any messages or even as a symbol code.

What does this mean, and is it still applicable? Will I break the APRS-IS
or some ancient TNC somewhere if I send those characters in an APRS
message?

Just curious.

Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry

[Andrew Pavlin]

Could one then presume that such TNC's could not participate in any binary radio network (such as TCP/IP over AX.25 or OpenTRAC), since the binary payload might contain those characters?

Seems kind of archaic, especially with KISS having a means to send such commands without reserving byte values in the data stream.

Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Steve Dimse <sdimse-***@public.gmane.org>
Date: Fri, 11 Apr 2014 09:33:46
To: AndrewEMT-***@public.gmane.org<AndrewEMT-***@public.gmane.org>; TAPR APRS Mailing List<aprssig-***@public.gmane.org>
Subject: Re: [aprssig] What is "TNC Channel Switching"?

The KAM Plus was a dual band TNC, so one serial port could give you access to two radios at the same time, generally HF and VHF. It also could automatically gate between the two. I think the same scheme was used on the 9612 which was 1200 and 9600 baud simultaneous. The stream switch would tell the TNC which band to send a packet. I don't recall if they listened for stream switches from the RF side. You definitely should not send them on a serial port unless you have a way to disable it or unless you state your code is incompatible with the KAM and KPC 9612. There still are some floating around. Generally, best to follow the spec on things like this.

Steve

Sent from my iPhone

Post by Andrew Pavlin
Greetings, all.
I was slogging through the APRS spec, and came upon a mention that the ASCII characters '|' and '~' were reserved for TNC channel switching, and couldn't appear in any messages or even as a symbol code.
What does this mean, and is it still applicable? Will I break the APRS-IS or some ancient TNC somewhere if I send those characters in an APRS message?
Just curious.
Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Stephen H. Smith]

Post by Andrew Pavlin
Could one then presume that such TNC's could not participate in any binary radio network (such as TCP/IP over AX.25 or OpenTRAC), since the binary payload might contain those characters?
Seems kind of archaic, especially with KISS having a means to send such commands without reserving byte values in the data stream.

Long before KISS, AX.25 packet communications meant keyboard-to-keyboard
conversations using TNCs operated from dumb ASCII devices like Teletype
machines, ADM3 "glass TTYs" and VT-100 terminals. Then with dumb-terminal
emulating software like ASCII Express, ProComm, Hyperterminal, etc. [The
reason TNCs have considerable firmware "intelligence" is that, in the
beginning, the devices connected to them were completely dumb keyboards; i.e.
not computers.)

The user typed either commands to control the functions of the TNC, or text to
be transmitted over-the-air, all from the same keyboard. You typed the command
"CONV" (converse) before typing text over the air, and "Ctrl-C" before typing a
command to the TNC's internal firmware.

There WAS NO binary data to be transmitted -- only what could be typed from a
basic keyboard; i.e. 7-bit classic ASCII. Later, full 8-bit bytes with values
above 127 decimal or $7F were transmitted by using various means of expressing
them as printable ASCII characters; i.e. something like hex dumps.

[This is similar to how email works even today. The actual transmission of
email still uses the original 7-bit ASCII coding; binary file attachments and
UniCode text are converted into strings of printable ASCII text for
transmission, and then converted back to 8-bit bytes at the receiving end. The
effect of this is that an attached "1 megabyte" file actually causes typically
about 1.5 megabytes to be sent over the TCP/IP link.]

When packet started being about connecting computers together, rather than dumb
keyboards and displays, the KISS protocal was added. KISS bypassed the command
interpreters in the TNC and truly used the TNC as just a dumb modem. KISS is
fully 8-bit transparent, but does provide it's own means of selectiong "logical
ports" on a single physical channel.

The Kantronics "stream switch" characters were a way of accommodating multiple
logical channels in the 7-bit ASCII world that predated KISS, by using two
typeable characters that were not used much (at least in American English and
if you weren't a Unix programmer!).

[Rick Green]

Post by Stephen H. Smith
The Kantronics "stream switch" characters were a way of accommodating
multiple logical channels in the 7-bit ASCII world that predated KISS, by
using two typeable characters that were not used much (at least in American
English and if you weren't a Unix programmer!).

That doesn't answer the OP's real question. Is it necessary to treat
these characters as 'reserved', and prohibit their use within APRS
packets?
To answer this, I feel we need to know the answers to two other
questions:
Were the Kantronics dual-TNCs sensitive to these characters in received
data on the radio side? Would they cut off the current stream and switch
the received data to the other radio in mid-packet??
Did the Kantronics command language provide any way of 'escaping' these
characters so that they could be embedded within packets? It was
mentioned that in practice they were 'prefixed' to a command to indicate
which stream this command is to apply. Is it possible that the TNC was
ONLY sensitive to a stream switch character immediately after a ctrl-C as
it enters command mode, or immediately after a carriage return if already
in command mode?

If it can be shown that the Kantronics TNCs are only sensitive to these
characters on the serial side, and as a prefix to a command, then there
is no reason to prohibit their use within the protocol itself.

[Andrew Pavlin]

Actually, there would be a reason to prohibit if the Kamtronics units couldn't handle it; they couldn't _transmit_ such packets to RF.

But what software could attempt to send such packets in Command or Converse mode on a KPC? Nothing modern. KISS mode wouldn't have a problem.

Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Rick Green <rtg-tF6Hi8N+***@public.gmane.org>
Sender: aprssig-bounces-***@public.gmane.org
Date: Fri, 11 Apr 2014 10:44:37
To: TAPR APRS Mailing List<aprssig-***@public.gmane.org>
Reply-To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Subject: Re: [aprssig] What is "TNC Channel Switching"?

Post by Stephen H. Smith
The Kantronics "stream switch" characters were a way of accommodating
multiple logical channels in the 7-bit ASCII world that predated KISS, by
using two typeable characters that were not used much (at least in American
English and if you weren't a Unix programmer!).

That doesn't answer the OP's real question. Is it necessary to treat
these characters as 'reserved', and prohibit their use within APRS
packets?
To answer this, I feel we need to know the answers to two other
questions:
Were the Kantronics dual-TNCs sensitive to these characters in received
data on the radio side? Would they cut off the current stream and switch
the received data to the other radio in mid-packet??
Did the Kantronics command language provide any way of 'escaping' these
characters so that they could be embedded within packets? It was
mentioned that in practice they were 'prefixed' to a command to indicate
which stream this command is to apply. Is it possible that the TNC was
ONLY sensitive to a stream switch character immediately after a ctrl-C as
it enters command mode, or immediately after a carriage return if already
in command mode?

If it can be shown that the Kantronics TNCs are only sensitive to these
characters on the serial side, and as a prefix to a command, then there
is no reason to prohibit their use within the protocol itself.

[Stephen H. Smith]

Actually, there would be a reason to prohibit if the Kamtronics units couldn't handle it; they couldn't_transmit_ such packets to RF.
But what software could attempt to send such packets in Command or Converse mode on a KPC? Nothing modern.

Decades old programs still in use such as APRSplus, WinAPRS, UIview, and more
recent ones that don't support KISS such as APRSpoint.


KISS mode wouldn't have a problem.

Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

By no means does everyone on APRS use KISS mode interfaces. For example, most
of the numerous generations of firmware for the MFJ 127x family of TNCs and
most generations of the "official" TAPR TNC2 firmware DON'T support KISS mode
at all. Many of these TNCs are still in use. Not to mention the Kenwood
D700 and TH-D7, who's KISS mode was basically unusable. When any of these
devices are used on APRS with external software, it will be in the classic
command-line mode.

Any APRS software fielded today STILL has to assume a significant number of
users will running in the terminal-like command-line mode instead of KISS.

[Remember that APRS is basically a kludge layered on top of a kludge to allow
machine-to-machine communications over a protocol originally designed for
human-typed keyboard-to-keyboard communications invented 35 years ago. All
being run on a lot of legacy hardware with unchangeable firmware that isn't
going away anytime soon!]

It's what IBM once called "the tyranny of the installed base" when the
radioal (for the time)and arguably significantly-improved hardware changes of
the PS/2 family PCs in the mid-to-late 1980's flopped massively. (ISA and PCI
cards wouln't fit into the "microchannel" slots of these machines.)

[Andre]

Post by Stephen H. Smith
Decades old programs still in use such as APRSplus, WinAPRS, UIview,
and more recent ones that don't support KISS such as APRSpoint.

unless i'm mistaken uiview actualy uses the ~ in it's native uiview to
uiview messaging so it's an bad exsample to use in this case.

73 de Andre PE1RDW

[Stephen H. Smith]

Post by Stephen H. Smith
Decades old programs still in use such as APRSplus, WinAPRS, UIview, and more
recent ones that don't support KISS such as APRSpoint.

unless i'm mistaken uiview actualy uses the ~ in it's native uiview to uiview
messaging so it's an bad exsample to use in this case.

Does anyone actually use UIview in it's native (rather than APRS-compatible)
mode? I'm not aware of anyone doing so, at least in North America.



By the way UIview does support KISS mode very well; indeed it's mandatory if
you want to use it's advanced smart digipeater functions.

However, many users still use the command-line mode instead, since many older
TNCs don't support KISS. (Particularly the MFJ 127x series TNCs that crammed
in numerous other modes, so that there wasn't enough room in the 27256 eprom
for KISS support. I have replaced the OEM firmware on countless MFJ 127x TNCs
with the final release "official" TAPR 1.1.9 firmware precisely to regain the
KISS capabilities.)

[On the Kenwood D700 and TH-D7, there is another incentive to NOT use KISS mode
besides the fact that it's buggy and unstable due to a too-small buffer -- the
GPS pass-through feature doesn't function in KISS mode.]

-------------------------------------------------------------

The bottom line is that:

There are still a lot of APRS installations NOT using the KISS interface
between the TNC and the computer for various reasons.

_____________________________________________________________


--

Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net


Long-Range APRS on 30 Meters HF
http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
http://wa8lmf.net/ham/imic.htm
http://wa8lmf.net/ham/uca202.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

[Greg D]

Post by Stephen H. Smith
However, many users still use the command-line mode instead, since
many older TNCs don't support KISS. (Particularly the MFJ 127x
series TNCs that crammed in numerous other modes, so that there wasn't
enough room in the 27256 eprom for KISS support. I have replaced the
OEM firmware on countless MFJ 127x TNCs with the final release
"official" TAPR 1.1.9 firmware precisely to regain the KISS
capabilities.)

Um, I have an MFJ 1278T TNC, and am running it in KISS mode under
APRSIS/32. Stock firmware on it, I believe, though I don't recall what
version.

Greg KO6TH

[Andrew Pavlin]

Funny. I have a 1278 as well, and was using it (in KISS mode) with JNOS back in 1998 when there was a multi-state TCP/IP radio net across the northeast US.

Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Greg D <ko6th.greg-***@public.gmane.org>
Sender: aprssig-bounces-***@public.gmane.org
Date: Sat, 12 Apr 2014 10:55:29
To: TAPR APRS Mailing List<aprssig-***@public.gmane.org>
Reply-To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Subject: Re: [aprssig] What is "TNC Channel Switching"?

Post by Stephen H. Smith
However, many users still use the command-line mode instead, since
many older TNCs don't support KISS. (Particularly the MFJ 127x
series TNCs that crammed in numerous other modes, so that there wasn't
enough room in the 27256 eprom for KISS support. I have replaced the
OEM firmware on countless MFJ 127x TNCs with the final release
"official" TAPR 1.1.9 firmware precisely to regain the KISS
capabilities.)

Um, I have an MFJ 1278T TNC, and am running it in KISS mode under
APRSIS/32. Stock firmware on it, I believe, though I don't recall what
version.

Greg KO6TH

[Stephen H. Smith]

Post by Stephen H. Smith
However, many users still use the command-line mode instead, since many older
TNCs don't support KISS. (Particularly the MFJ 127x series TNCs that
crammed in numerous other modes, so that there wasn't enough room in the
27256 eprom for KISS support. I have replaced the OEM firmware on countless
MFJ 127x TNCs with the final release "official" TAPR 1.1.9 firmware precisely
to regain the KISS capabilities.)

Um, I have an MFJ 1278T TNC, and am running it in KISS mode under APRSIS/32.
Stock firmware on it, I believe, though I don't recall what version.
Greg KO6TH

That's a relatively late version of the MFJ-1270 family that (I think) finally
went to 27512 EPROMs instead the '256s of earlier versions and consequently has
a lot more room for code.

The original MFJ-1270 and the MFJ-1274 that I still have came OEM with
KISS-less firmware. I put the generic last-ever TAPR TNC2 V1.1.9 firmware in
both instead, to regain the KISS mode.

(I also hacked the eprom image to make the device power up defaulted to full
8-bit 8-N-1 instead of the archaic default 7-E-1 serial port settings, avoiding
having to constantly init with AWLEN 8, 8BITCONV OFF and PARITY 0.)

__________________________________________________________________


--

Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net


Long-Range APRS on 30 Meters HF
http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
http://wa8lmf.net/ham/imic.htm
http://wa8lmf.net/ham/uca202.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

[Ray Wells]

Post by Stephen H. Smith

Post by Stephen H. Smith
However, many users still use the command-line mode instead, since many older
TNCs don't support KISS. (Particularly the MFJ 127x series TNCs that
crammed in numerous other modes, so that there wasn't enough room in the
27256 eprom for KISS support. I have replaced the OEM firmware on countless
MFJ 127x TNCs with the final release "official" TAPR 1.1.9 firmware precisely
to regain the KISS capabilities.)

Um, I have an MFJ 1278T TNC, and am running it in KISS mode under APRSIS/32.
Stock firmware on it, I believe, though I don't recall what version.
Greg KO6TH

That's a relatively late version of the MFJ-1270 family that (I think)
finally went to 27512 EPROMs instead the '256s of earlier versions and
consequently has a lot more room for code.
The original MFJ-1270 and the MFJ-1274 that I still have came OEM with
KISS-less firmware. I put the generic last-ever TAPR TNC2 V1.1.9
firmware in both instead, to regain the KISS mode.
(I also hacked the eprom image to make the device power up defaulted
to full 8-bit 8-N-1 instead of the archaic default 7-E-1 serial port
settings, avoiding having to constantly init with AWLEN 8, 8BITCONV
OFF and PARITY 0.)
__________________________________________________________________

My MFJ1270B TNC's (x5) all had 27256 OEM EPROMs that came with both
native mode and KISS (with horrendous timing issues). I fitted them with
KISS only EPROMs; end of timing issues and always in KISS mode. No more
magic incantations to get into and out of KISS mode.

Ray vk2tv

[Greg D]

Post by Stephen H. Smith

Post by Stephen H. Smith
However, many users still use the command-line mode instead, since many older
TNCs don't support KISS. (Particularly the MFJ 127x series TNCs that
crammed in numerous other modes, so that there wasn't enough room in the
27256 eprom for KISS support. I have replaced the OEM firmware on countless
MFJ 127x TNCs with the final release "official" TAPR 1.1.9 firmware precisely
to regain the KISS capabilities.)

Um, I have an MFJ 1278T TNC, and am running it in KISS mode under APRSIS/32.
Stock firmware on it, I believe, though I don't recall what version.
Greg KO6TH

That's a relatively late version of the MFJ-1270 family that (I think)
finally went to 27512 EPROMs instead the '256s of earlier versions and
consequently has a lot more room for code.
The original MFJ-1270 and the MFJ-1274 that I still have came OEM with
KISS-less firmware. I put the generic last-ever TAPR TNC2 V1.1.9
firmware in both instead, to regain the KISS mode.
(I also hacked the eprom image to make the device power up defaulted
to full 8-bit 8-N-1 instead of the archaic default 7-E-1 serial port
settings, avoiding having to constantly init with AWLEN 8, 8BITCONV
OFF and PARITY 0.)

Yeah, I thought of that (being a more recent product). The unit was a
club "white elephant sale" acquision (pedigree unknown), and has been
working fine. It replaced a Baycom-type setup that stopped working
after upgrading my PC from DOS through Win95 to Win98SE and ultimately
to Linux many years ago. It came with the 2400 BAUD modem option board,
which is pretty much useless.

KISS mode seems to be sticky across power cycles, so I don't need to do
anything special. It just works.

Greg KO6TH

[Stephen H. Smith]

Post by Stephen H. Smith
The Kantronics "stream switch" characters were a way of accommodating
multiple logical channels in the 7-bit ASCII world that predated KISS, by
using two typeable characters that were not used much (at least in American
English and if you weren't a Unix programmer!).

That doesn't answer the OP's real question. Is it necessary to treat these
characters as 'reserved', and prohibit their use within APRS packets?

Yes, because these TNCs are still in use.

Were the Kantronics dual-TNCs sensitive to these characters in received data
on the radio side?

NO. They were strictly between the TNC and the PC on the serial port link.


Would they cut off the current stream and switch the

received data to the other radio in mid-packet??

They only determine which TRANSMIITER port the packet to be sent is directed to
by the TNC, not which RECEIVER port is used. On receive, you will find these
characters pre-pended to received serial-port data streams from the TNC to the
APRS client (if such a TNC is being used).

Did the Kantronics command language provide any way of 'escaping' these
characters so that they could be embedded within packets? It was mentioned
that in practice they were 'prefixed' to a command to indicate which stream
this command is to apply. Is it possible that the TNC was ONLY sensitive to a
stream switch character immediately after a ctrl-C as it enters command mode,
or immediately after a carriage return if already in command mode?

Basically this is true. However, it doesn't address incoming (RECEIVED)
packets where the stream character is pre-pended to the RX data coming out of
the serial port.

If it can be shown that the Kantronics TNCs are only sensitive to these
characters on the serial side, and as a prefix to a command, then there is no
reason to prohibit their use within the protocol itself.

[Robert Bruninga]

Post by Rick Green
If it can be shown that the Kantronics TNCs are only sensitive to these
characters on the serial side, and as a prefix to a command,
then there is no reason to prohibit their use within the protocol

itself.

I disagree. It is on the serial port where they do the damage. When the
characters (if they were allowed to be part of theprotocol) have to get
from the PC to the TNC and that path in these TNC's is via the serial
port. Hence allowing these characters in the protocol means they will
travel via the serial port and so this is just setting up the network for
this problem to occur.

And it is well known and proved by Mr Murphy that if bad things can
happen, then they eventually will. Murphy's law.

That is why these two bytes were avoided in the protocol. I see no reason
to allow their use which would allow a known probem to infect our
networks.

Bob, Wb4APR



-----Original Message-----
From: aprssig-bounces-***@public.gmane.org [mailto:aprssig-bounces-***@public.gmane.org] On Behalf
Of Rick Green
Sent: Friday, April 11, 2014 10:45 AM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] What is "TNC Channel Switching"?

Post by Rick Green
The Kantronics "stream switch" characters were a way of accommodating
multiple logical channels in the 7-bit ASCII world that predated KISS,
by using two typeable characters that were not used much (at least in
American English and if you weren't a Unix programmer!).

That doesn't answer the OP's real question. Is it necessary to treat
these characters as 'reserved', and prohibit their use within APRS
packets?
To answer this, I feel we need to know the answers to two other
questions:
Were the Kantronics dual-TNCs sensitive to these characters in received
data on the radio side? Would they cut off the current stream and switch
the received data to the other radio in mid-packet??
Did the Kantronics command language provide any way of 'escaping' these
characters so that they could be embedded within packets? It was
mentioned that in practice they were 'prefixed' to a command to indicate
which stream this command is to apply. Is it possible that the TNC was
ONLY sensitive to a stream switch character immediately after a ctrl-C as
it enters command mode, or immediately after a carriage return if already
in command mode?

If it can be shown that the Kantronics TNCs are only sensitive to these
characters on the serial side, and as a prefix to a command, then there is
no reason to prohibit their use within the protocol itself.

--
Rick Green, N8BJX

We, the People of the United States of America, reject the U.S. Supreme
Court's
Citizens United ruling, and move to amend our Constitution to firmly
establish
that money is not speech, and that human beings, not corporations, are
persons
entitled to constitutional rights.

http://www.MoveToAmend.org

[Heikki Hannikainen]

That doesn't answer the OP's real question. Is it necessary to treat these
characters as 'reserved', and prohibit their use within APRS packets?

I don't think it's necessary to treat them as reserved any more, when
transmitted by other devices which are not using these TNCs. And in fact,
they have not been treated as reserved for a while, they're widely used
and do appear in packets today.

Were the Kantronics dual-TNCs sensitive to these characters in received
data on the radio side? Would they cut off the current stream and switch the
received data to the other radio in mid-packet??

They're sensitive to these characters when they get the packet off the
serial line from the PC only.

The characters are already allocated for use in Mic-E type codes:

http://www.aprs.org/aprs12/mic-e-types.txt

There's a very large fleet of Byonics trackers on the network worldwide,
and they're not having any trouble due to | appearing in the type code.

I can see a lot of ~ in the raw packets, too, since the Mic-E protocol
encodes some values with it, like this:

JF1SSW-9>SUURP3,JJ1MQF-1*,qAR,JG1FVF:`D,(nR~>/]"3p}=

Here are the numbers for yesterday:

***@soul2:/data/aprsis-archive/2014$ grep '~' aprsis-20140411.log |wc -l
24463
***@soul2:/data/aprsis-archive/2014$ grep '|' aprsis-20140411.log |wc -l
83441

If a station using one of these TNCs tried to transmit these characters,
that might cause a problem. I don't know if the TNCs require some pause
before the switch charater for triggering, like some similar escape
sequences do. Could someone with a TNC try it out?

When the Kantronics TNCs are used as stand-alone digipeaters, they treat
these characters just fine, digipeating packets from Byonics trackers
without blinking. Well, they do blink a led or two.

- Hessu

[Stephen H. Smith]

Post by Andrew Pavlin
Greetings, all.
I was slogging through the APRS spec, and came upon a mention that the ASCII characters '|' and '~' were reserved for TNC channel switching, and couldn't appear in any messages or even as a symbol code.
What does this mean, and is it still applicable? Will I break the APRS-IS or some ancient TNC somewhere if I send those characters in an APRS message?
Just curious.
Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

There are some classic serial-port-interfaced TNCs that actually have two
separate modems in a single box connected to a single serial port.

Notably the Kantronics "KAM" (Kantronics All Mode) which combines a 300-baud
multimode HF modem and a 1200-baud VHF packet-only modem. The Kantronics 9612
combined a 1200-baud packet modem similar to a KPC3 and a 9600-baud packet
modem into a single box. In either case, the two modems can be connected to
two separate radios and operated simultaneously via a single serial line
to/from the PC.

Commands typed from the PC console were prefixed with either the "pipe" symbol
or the tilde to indicated which of the two modems you wanted to send commands
(or text to be transmitted) to.

In the heyday of conventional packet, numerous third-party programs were
developed that "covered up" this clumsy command-line interface by providing
split-screen interfaces and/or "Radio1"/"Radio2" function key mappings to the
user that handled the "stream" switches for you.

_____________________________________________________________

[Chris Moulding]

The tilde "~" character is used in APRS Messenger as a "wrapper" before
sending the APRS packet over HF APRS over digimodes.

On transmit the CRC-16 checksum is calculated for the APRS packet and
the three figures generated are added to the end of the packet. A tilde
character is then added to each end of the packet and then it's
transmitted over PSK-63, PSK-250, GMSK-250 or MFSK-16 with a short
preamble of seven dots so that the AFC at the receive end has something
to lock in to.

On receive the data is saved and the APRS packet plus checksum is
extracted by looking for the text string between the tilde characters.
The three figure checksum is removed and the APRS packet is checked
against the checksum to confirm that it's been received correctly.

Without having the tilde character reserved in the APRS spec it wouldn't
be possible to do that. It's not likely to affect any Kantronics modems
as they can't decode the digimodes used.

Regards,

Chris, G4HYG

--
Chris Moulding
Cross Country Wireless
7 Thirlmere Grove, Bolton, Lancs, BL4 0QB, UK
Tel/fax: [phone]
Mobile: [phone]
Website: http://www.crosscountrywireless.net
Yahoo group: http://uk.groups.yahoo.com/group/cross_country_wireless/

Post by Stephen H. Smith

Post by Andrew Pavlin
Greetings, all.
I was slogging through the APRS spec, and came upon a mention that the
ASCII characters '|' and '~' were reserved for TNC channel switching,
and couldn't appear in any messages or even as a symbol code.
What does this mean, and is it still applicable? Will I break the
APRS-IS or some ancient TNC somewhere if I send those characters in an
APRS message?
Just curious.
Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

There are some classic serial-port-interfaced TNCs that actually have
two separate modems in a single box connected to a single serial port.
Notably the Kantronics "KAM" (Kantronics All Mode) which combines a
300-baud multimode HF modem and a 1200-baud VHF packet-only modem. The
Kantronics 9612 combined a 1200-baud packet modem similar to a KPC3 and
a 9600-baud packet modem into a single box. In either case, the two
modems can be connected to two separate radios and operated
simultaneously via a single serial line to/from the PC.
Commands typed from the PC console were prefixed with either the "pipe"
symbol or the tilde to indicated which of the two modems you wanted to
send commands (or text to be transmitted) to.
In the heyday of conventional packet, numerous third-party programs were
developed that "covered up" this clumsy command-line interface by
providing split-screen interfaces and/or "Radio1"/"Radio2" function key
mappings to the user that handled the "stream" switches for you.
_____________________________________________________________
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Andrew Pavlin]

So, this is an ugly but legitimate reservation of this character. I assume APRSMessenger doesn't support Spanish language (or others using the tilde in normal text) or Unicode?

Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Chris Moulding <chrism-acN+FkWt+1/VWE1giF+swAsWloVs/***@public.gmane.org>
Sender: aprssig-bounces-***@public.gmane.org
Date: Fri, 11 Apr 2014 15:18:23
To: <aprssig-***@public.gmane.org>
Reply-To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Subject: Re: [aprssig] What is "TNC Channel Switching"?

The tilde "~" character is used in APRS Messenger as a "wrapper" before
sending the APRS packet over HF APRS over digimodes.

On transmit the CRC-16 checksum is calculated for the APRS packet and
the three figures generated are added to the end of the packet. A tilde
character is then added to each end of the packet and then it's
transmitted over PSK-63, PSK-250, GMSK-250 or MFSK-16 with a short
preamble of seven dots so that the AFC at the receive end has something
to lock in to.

On receive the data is saved and the APRS packet plus checksum is
extracted by looking for the text string between the tilde characters.
The three figure checksum is removed and the APRS packet is checked
against the checksum to confirm that it's been received correctly.

Without having the tilde character reserved in the APRS spec it wouldn't
be possible to do that. It's not likely to affect any Kantronics modems
as they can't decode the digimodes used.

Regards,

Chris, G4HYG

--
Chris Moulding
Cross Country Wireless
7 Thirlmere Grove, Bolton, Lancs, BL4 0QB, UK
Tel/fax: [phone]
Mobile: [phone]
Website: http://www.crosscountrywireless.net
Yahoo group: http://uk.groups.yahoo.com/group/cross_country_wireless/

Post by Stephen H. Smith

Post by Andrew Pavlin
Greetings, all.
I was slogging through the APRS spec, and came upon a mention that the
ASCII characters '|' and '~' were reserved for TNC channel switching,
and couldn't appear in any messages or even as a symbol code.
What does this mean, and is it still applicable? Will I break the
APRS-IS or some ancient TNC somewhere if I send those characters in an
APRS message?
Just curious.
Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

There are some classic serial-port-interfaced TNCs that actually have
two separate modems in a single box connected to a single serial port.
Notably the Kantronics "KAM" (Kantronics All Mode) which combines a
300-baud multimode HF modem and a 1200-baud VHF packet-only modem. The
Kantronics 9612 combined a 1200-baud packet modem similar to a KPC3 and
a 9600-baud packet modem into a single box. In either case, the two
modems can be connected to two separate radios and operated
simultaneously via a single serial line to/from the PC.
Commands typed from the PC console were prefixed with either the "pipe"
symbol or the tilde to indicated which of the two modems you wanted to
send commands (or text to be transmitted) to.
In the heyday of conventional packet, numerous third-party programs were
developed that "covered up" this clumsy command-line interface by
providing split-screen interfaces and/or "Radio1"/"Radio2" function key
mappings to the user that handled the "stream" switches for you.
_____________________________________________________________
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Chris Moulding]

~ or | entered as text in APRS Messenger are filtered out before sending
as the spec says that they shouldn't be sent over APRS as they are used
as control characters for Kantronics TNCs.

I was under the impression that other APRS authors filtered them as well
but I'm ready to be corrected.

By the way Raynet Messenger is another program based on APRS Messenger
which uses a similar message format allowing CRC-16 checksum messages to
be digipeated but allows a message length up to 2000 characters. The
region of the world where it gets most use for emergency comms is South
America so the lack of the tilde character doesn't appear to be a
problem as far as I know.

Regards,

Chris, G4HYG

--
Chris Moulding
Cross Country Wireless
7 Thirlmere Grove, Bolton, Lancs, BL4 0QB, UK
Tel/fax: [phone]
Mobile: [phone]
Website: http://www.crosscountrywireless.net
Yahoo group: http://uk.groups.yahoo.com/group/cross_country_wireless/

Post by Andrew Pavlin
So, this is an ugly but legitimate reservation of this character. I assume APRSMessenger doesn't support Spanish language (or others using the tilde in normal text) or Unicode?
Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

[Stephen H. Smith]

The region of the world where it gets most use for emergency comms is South
America so the lack of the tilde character doesn't appear to be a problem as
far as I know.
Regards,
Chris, G4HYG

Raynet is being used in South America? I throught it was strictly a UK thing.

__________________________________________________________

--

Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net


Long-Range APRS on 30 Meters HF
http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
http://wa8lmf.net/ham/imic.htm
http://wa8lmf.net/ham/uca202.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

[Chris Moulding]

Yes, Raynet is the UK amateur radio emergency comms organisation. I
originally wrote Raynet Messenger for them but they tend to use Olivia
on FlDigi now.

Amateurs in South America started using the program as it was a very
easy digital mode program to set up and they can use a third station in
another country to digipeat messages across the HF skip zone. At some
point I'll do a Spanish translation of the program if I can find a
fluent Spanish speaker willing to translate a simple text list of
controls and labels used in the program.

The blog that started the interest in the program in South America is:

http://radioaficionadosenemergencia.blogspot.com.es/

Regards,

Chris, G4HYG

--
Chris Moulding
Cross Country Wireless
7 Thirlmere Grove, Bolton, Lancs, BL4 0QB, UK
Tel/fax: [phone]
Mobile: [phone]
Website: http://www.crosscountrywireless.net
Yahoo group: http://uk.groups.yahoo.com/group/cross_country_wireless/

Post by Stephen H. Smith
Raynet is being used in South America? I throught it was strictly a UK thing.

[Andrew Pavlin]

And how annoying that my own local ARES group has one of those KPC-9612 units in operation right now. I guess they are still pervasive.

Andrew, KA2DDO
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Steve Dimse <sdimse-***@public.gmane.org>
Date: Fri, 11 Apr 2014 09:33:46
To: AndrewEMT-***@public.gmane.org<AndrewEMT-***@public.gmane.org>; TAPR APRS Mailing List<aprssig-***@public.gmane.org>
Subject: Re: [aprssig] What is "TNC Channel Switching"?

The KAM Plus was a dual band TNC, so one serial port could give you access to two radios at the same time, generally HF and VHF. It also could automatically gate between the two. I think the same scheme was used on the 9612 which was 1200 and 9600 baud simultaneous. The stream switch would tell the TNC which band to send a packet. I don't recall if they listened for stream switches from the RF side. You definitely should not send them on a serial port unless you have a way to disable it or unless you state your code is incompatible with the KAM and KPC 9612. There still are some floating around. Generally, best to follow the spec on things like this.

Steve

Sent from my iPhone

Post by Andrew Pavlin
Greetings, all.
I was slogging through the APRS spec, and came upon a mention that the ASCII characters '|' and '~' were reserved for TNC channel switching, and couldn't appear in any messages or even as a symbol code.
What does this mean, and is it still applicable? Will I break the APRS-IS or some ancient TNC somewhere if I send those characters in an APRS message?
Just curious.
Andrew Pavlin, KA2DDO
Sent from my Verizon Wireless BlackBerry
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Stephen H. Smith]

Post by Andrew Pavlin
The KAM Plus was a dual band TNC, so one serial port could give you access to two radios at the same time, generally HF and VHF. It also could automatically gate between the two. I think the same scheme was used on the 9612 which was 1200 and 9600 baud simultaneous. The stream switch would tell the TNC which band to send a packet. I don't recall if they listened for stream switches from the RF side. You definitely should not send them on a serial port unless you have a way to disable it or unless you state your code is incompatible with the KAM and KPC 9612. There still are some floating around. Generally, best to follow the spec on things like this.

They didn't "listen" for the steam switch. When "normal" packets from either
radio were received, they were prefixed with the appropriate switch character
before being sent out the serial port to the attached terminal.

If the attached "terminal" was a dual-port-aware program running on a computer,
it could automatically direct the incoming packet to the correct half of a
split-screen display.

[Rick Bogdan]

I have a PacComm Tiny-2 that I replaced the stock eprom with a KISS only
eprom many years ago during the height of the tcpip network activity up
in the NE area and it worked great, even today it still works.
Just my 2 cents.
Rick ka1udx

Post by Andrew Pavlin
Re: [aprssig] What is "TNC Channel Switching"?

[Stephen H. Smith]

I have a PacComm Tiny-2 that I replaced the stock eprom with a KISS only eprom
many years ago during the height of the tcpip network activity up in the NE
area and it worked great, even today it still works.

Did the OEM eprom have any variant of KISS in it?

________________________________________


--

Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net


Long-Range APRS on 30 Meters HF
http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
http://wa8lmf.net/ham/imic.htm
http://wa8lmf.net/ham/uca202.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

[Ray Wells]

Post by Stephen H. Smith

I have a PacComm Tiny-2 that I replaced the stock eprom with a KISS only eprom
many years ago during the height of the tcpip network activity up in the NE
area and it worked great, even today it still works.

Did the OEM eprom have any variant of KISS in it?
________________________________________

Stephen,

FWIW, I have a copy of the tnc2118a.bin file and it references KISS.
Within the file contents are "Last mod:N2WX 03/20/92 Added 1.1.7b
KISS:WA7GXD 08/30/92"
I can't recall with any certainty if this used a 27256 or 27512 EPROM
but it occupies the same address space as the MFJ1270B OEM EPROM which
was a 27256 and contained KISS. The OEM version is tnc2128.bin which
contains "Last mod:N2WX 03/01/91"

I can send the bin files as attachment in a P mail if you want them.

Ray vk2tv

[Randy Love]

The limitation on the ~ and | were as the first character in the payload,
wasn't it?

That would be the only time that they would cause issue if you had null
modem cabled two TNC's together to get a crossband gateway.

Randy
WF5X