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 just tried MCP-4A on my Window laptop, there's no options in it to set the baud or see what it's using. Also, while the CP210x virtual comport driver properties allow you to change the port's baud from 9600 to, say 57600, there didn't seem to be any change in cloning speed by doing so, nor could I see anything relevant in the USBPcap traces I took during a couple of tests.

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

Honestly, I prefer the D72's clone driver, as a full read or write operation takes <20 seconds total with it. That said, the driver was broken for several years due to a bug relating to VFO filtering (eventually fixed in #1611). While it works great now, anyone who tried to use it during the time it was busted are likely still using the live version, whether out of lack of trust or sheer habit.

The live version under the existing UI is ok too. It takes a few minutes to do the initial read, but then each edit gets instantly applied/rejected. My concern was mainly that the new UI greatly increases the amount of time to sync the changes back for the live driver, which some people might not be happy about :) However, if you can add the ability to just sync the dirty memories edited during the same session the radio was read during, that'd probably make it a non-issue.

That said, regardless of the impact to this specific radio/driver, the new UI still seems like a positive thing overall.

Cheers,

James VE7JWK