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

Jim Unroe
Sat Apr 2 00:08:36 PDT 2022


On Fri, Apr 1, 2022 at 9:02 PM Dan Smith via chirp_devel
<chirp_devel at intrepid.danplanet.com> wrote:
>
> > I do. I would like to solve this. I think I understand what you are
> > saying above and I think I am making some progress. Would you like to
> > see a diff against the original driver, what you just merged or the
> > complete driver to look at?
>
> Diffs against the current tree are best, yeah. I did merge what you had and that'll go out tomorrow regardless, so no rush on anything.

That is what I expected. Thanks. Unless something that I didn't expect
happens, I think everyone will be happy for the increased upload
speed. Before I made this change I would have to go do something else
because I couldn't stand waiting and watching while the 5+ minute
upload was progressing.

> I'm also just armchair monday-morning debugger'ing this, so I'm just trying to think up things to try :)

I appreciate it. This has bugged me for a long time (ever since Pavel
and I co-authored it 2015 or 2016). I wasn't able to make anything
that could read the new mobile radios so I was happy to have Pavel
help me.

I believe the attached patch is moving in the right direction. I
remove almost all of the timeout changes. The sleep() is now in the
only place where it is required. The data blocks are no longer sent
one byte at a time. So is this what you are looking for?

I tried reading and writing both a BTECH UV-25X4 radio (2017) and a
BTECH GMRS-50X1 (2019) radio with Windows 10 and Linux Mint 19.3.

Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.patch
Type: application/octet-stream
Size: 2509 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20220402/00e8d32b/attachment-0001.obj 


More information about the chirp_devel mailing list