[chirp_devel] [PATCH 2 of 2] Address slow uploads for radios programmed by btech.py driver module

[Jim Unroe]

> Oh man, yeah that's way better right? If that works reliably that's much less complex and contains much less potential for timing related issues, IMHO. Should we try to solicit some people with these radios to load the modification as a module and see if it's stable for all of them?

Right! And yes, testing would be good.

I have been working with Matthew to get a new MCU Version added to
CHIRP for his QYT KT-8900R. He provided a sample driver that he had
modified on his own to get his radio going. It happened to be a very
old driver so it didn't have the #3993 change that really slowed
things down. When I provided a driver for him to test, he mentioned
that it worked but he noticed the slow down. This morning I attached
another test driver using these proposed changes. It,
btech_M3B064_fast.py, can be acquired from issue #9816.

I can do quite a bit of testing myself. I have the following radios
available: BTech UV-2501, UV-2501+220, UV-5001, WACCOM MINI-8900,
LUITON LT-588UV, BTech UV-25X2, UV-25X4, UV-50X2, GMRS-50X1, QYT KT-8R
and an Anysecu WP-9900 that I am currently working on. I am also able
to test with Windows, Linux and macOS (if I have to).

I have also had John LaMartina (the webmaster of the miklor.com
website) assist with the testing of the previous batch that just got
merged.

What would be your recommendation for expanding testing to a wider
group of radio owners?

> The only thing I might comment on is the sleep(0.002) after the ident. That's really (really) short and I wonder if it should be just a little longer without causing trouble? Like 0.1 maybe (100ms) or something. I can't imagine the radio requires that kind of turnaround and the 2ms you have is only two character timing units at 9600 baud.

I changed the sleep(0.002) to sleep(0.1) this morning. So far I have
encountered no issues with any testing that I have done since making
that change.

Jim