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

[Jim Unroe]

On Fri, Apr 1, 2022 at 7:00 PM Dan Smith via chirp_devel
<chirp_devel at intrepid.danplanet.com> wrote:
>
> > Uploads using this driver have always been slow. A patch submitted to
> > address issue #3993 made matters worse.
> >
> > Testing has indicated that the "sleep" that has been in use from the
> > begining and was increased in issue 3993 is only necessary during
> > downloading.
> >
> > This patch addresses the issue by only having the "sleep(0.002)"
> > effective during the download cloning process. Uploads with the
> > "sleep" removed have been tested to be just as fast as downloads.
>
> I've always been suspicious of the timing issues in this driver. I haven't had a radio to try to address them myself, nor do I really want to. The change you're making here doesn't make much sense to me because I would expect an upload, with a larger block of data, to be more of a problem for the slow radio than just sending the block request on the download side. But, since you've tested this and I can't, I merged it and I guess we'll see what, if any, response there is from the larger community and go from there.
>
> I'm curious though: did anyone try just putting a delay in between the higher-level messages on the download side? Like, maybe it's not so much about inter-byte timing, but turnaround time? If the radio emits a big block of data, and then takes a moment to recover from that and be ready for the next command or ack, maybe we're sending that back too quickly? Meaning, if that's the case, maybe the following algorithm would be better as:
>
>  1. Request block
>  2. Read block
>  3. Wait
>  4. Request next block
>
> As opposed to making the "Request next block" speak slowly. If the radio can consume a full block with no delays on upload, I just can't understand why the radio wouldn't be able to handle "please send block 2".
>
> It also looks like from the bug maybe that was happening on block zero. Maybe we're doing the ident/prog mode part and then too quickly requesting the first block?
>
> Anyway, I don't necessarily want to dredge it all up again, I just hate fiddling with tiny timing things like this, as it can really paper over the real case.

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?

>
> That said, thanks for continuing to care and for making this tweak. Hopefully it won't cause other problems :)
>
> --Dan

Jim