[Xastir-dev] Q regarding Xastir's habit of sending of control c in normal command mode TNCs

[Tom Russo]

I'm wondering what the justification was for having Xastir send control C
at the beginning of every single line it sends to a normal command-mode TNC
even in subroutines where it sends multiple lines all in a row.

In "output_my_aprs_data," in the 
            case DEVICE_SERIAL_TNC_AUX_GPS:
            case DEVICE_SERIAL_KISS_TNC:
            case DEVICE_SERIAL_MKISS_TNC:
            case DEVICE_SERIAL_TNC:
            case DEVICE_AX25_TNC:

block of the big switch statement, xastir prepares and sends three lines:

  MYCALL
  UPROTO
  K (or conv)
and then later sends the  actual posit.

For each of these lines, it prepends Control-C just to get the TNC back into 
CMD mode, but why all three?  If the first, before MYCALL, didn't do the job, 
then we're already scrod, so why keep doing it?

This is inspired by the question from Stefano on the users' mailing list 
where his KAM isn't going to CONV mode, and the blog post he referenced where
another ham was having fits getting his KAM to work with Xastir, because it,
too, never got into CONV mode after Xastir sent "control-c" and "k".  That
blog claims that when he entered the k manually through a terminal emulator
it worked fine, so this is not a "K vs. CONV" issue like with the KPC-2.  It
may be an issue where the TNC is doing something funky because of the control-C,
an idea that the blog poster was trying to explore but couldn't get anywhere
on because he couldn't find where in the code to add a delay between the 
control C and the "k".

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick