[aprssig] What is "TNC Channel Switching"?

[Stephen H. Smith]

On 4/11/2014 10:44 AM, Rick Green wrote:
> On Fri, 11 Apr 2014, Stephen H. Smith wrote:
>
>> 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.

>    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?

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.
>