[chirp_devel] [PATCH][BTECH] Bug fix about radios resetting on the download, fixes #3015

[Dan Smith]

>> I don't think we have to exactly follow the OEM software in this
>> regard either. It just adds a complication that seems to me as not
>> being necessary.

Agreed.

> After a few test this path is a no go.

Sorry, are you saying the patch as you sent to the list is a no-go, or
something about what Jim said is a no-go?

> When you ignore the read of the high mem zone that contains the second 
> ID, the radio answer to the first block read with a block without the 
> starting ACK (neither good or bad, just not ACK at all!) and add a 0xf0 
> at the end of the block, then stop responding.

I find that really strange. In all the other radios I've implemented
that appear to be based on the quasi-kenwood protocol, once you get them
into programming mode you can read and write blocks in any order that
you want without the radio caring, even blocks well past the end of the
memory, which are returned as just all 0xFF or something like that.

> So maybe the radio expects the read of this high mem block to move on 
> and we have to follow the OEM software on this.

What happens if you read the block on the radios where it doesn't matter?

> Checking the timing on the serial logs (portmon in crono mode) for the 
> affected radios, the patch for a smaller serial timeout makes sense, we 
> are doing things now (with the lower serial timeout) just like the OEM 
> does, and it works.

I'm not sure how you think you can infer that they're doing a similar
thing from that. Portmon is just showing you the timing of reads, not
anything about internal timers right?

> Dan, sorry for my insistence with this patch.
> 
> I'm a amateur in python programming with less than a year of experience 
> (I have a kind of experience on other languages), this is my first big 
> python project and I will like to test the way you mention about a 
> buffer, but I have not a reference for doing it.

Can you confirm the above, that you still want the patch as it is on the
list to be applied? I just want to make sure we haven't gotten wires
crossed with all the back and forth.

I'm really not happy with the patch as it is, but if it's better than
what we have I'm willing to apply it. I just don't want to stop us
seeking the better approach if we continue patching enough to make
"most" of the problems go away.

--Dan