The APRS/TNC speed is actually option 311, Int TNC->Data Speed, which is 1200 or 9600 only. AFAIK, option 331 is used for peripheral devices plugged into the USB port such as weather stations or GPS loggers.
Yeah, I meant the serial-side not radio-side TNC baud rate. I'm not sure how those physically interface with the radio (is the usb port repurposed?) but I expect(ed) that it didn't affect the actual using-USB-as-USB rate, which I think you've confirmed.
FWIW, the baud detection in kenwood_live.py:get_id() indeed only tries the baud rate there in ascending order and stops at the first successful one, but even when I manually invert the list, 9600 is the only one detected:
Wow.
That would've been my thought as well :) I'd be happy to try out any other tests you can think of.
Hrm, well, I don't have one here to poke at, but it sounds like you probably did what I would have. Have you tried the MCP program to see if it appears to only operate at 9600?
I guess the next question then is: why did you like the live mode when it's so slow? Is there something bad about the clone mode support? I like live mode for the radios that support it because you get instant feedback about memories being good, but the async nature of that indication has always been pretty janky. That, and my kenwoods all just do command mode (driver-wise at least).
--Dan