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