[chirp_devel] [PATCH] [btech] Delayed retry on writing to radio in case of errornous response. Needed mostly on linux. Fixes issue #3993

Dan Smith dsmith at danplanet.com
Fri Sep 23 07:08:58 PDT 2016

>> 10ms inter-byte latency is crazy high. I also don't like making this
>> different on different platforms, even if we're doing it in response to
>> a short read.
> I agree that this is not the best solution, but it´s worth to mention:
> - as Pavel Milanes found out, the inter-byte delay is exactly what the
> OEM-Software is doing ( http://chirp.danplanet.com/issues/3993#note-24
> ), so obviously even the manufacturer knows that their radios are not
> able to handle 9600 baud (and has no better solution to deal with that
> error)

So then we should do it for all platforms and not do this detection logic.

> - we are not doing it different on different platforms (this was the
> first approach), but changed to: detect "short read" or
> "invalid-header"-errors, and slow down only then. This avoids the
> artificial delay with radios that are fast enough to handle pyserial on
> linux, and on the other hand fix the error also on windows-versions.
> (Where it may happen as well, but only very rarely).

We might as well simplify this code and not detect then, IMHO. It looks
much more like ~2ms from the logs to me.

> - The 10ms are indeed quite long. In a earlier version of this patch
> only 5ms were used, and this was tested by Jim Unroe and other users on
> 5 different radios ( http://chirp.danplanet.com/issues/3993#note-22 )
> and reported as OK. However, Pavel argued to use 10ms, to be safe. (The
> comment in the sources is his ;-) )

If the OEM software uses 10ms, then that's fine, but we should just do
it exclusively. Simplicity always wins.

>> Stray whitespace damage here.
> My I ask what exactly do you mean? (did I already mention that I am
> completely new to python and this project? ;-) )

It means that you touched a line that wasn't related to the change. It's
common with whitespace-only lines where someone adds or removes a tab
and doesn't realize it.

> What is the correct process to add the fixed patch? Should I mail it as
> a reply to this thread? Or should I create a new patch using mercurial?
> (which will lead to a new thread in the mailing-list?)

New patch against current tip until something gets applied. New thread
is fine, thanks.


More information about the chirp_devel mailing list