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

[Pavel Milanes (CO7WT)]

El 08/04/16 a las 17:38, Dan Smith via chirp_devel escribió:
>
>> 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?


Sorry for the confusion.

I mean our local test about not reading the short high mem block, it 
shows that if you don't reads the short high mem block first, the 
following read are failed and  the radio stop responding, see the 
paragraph below.


>> 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.

Strange in deed.

Yes, I'm familiar with the kenwood protocol, but we have done a few 
tests with this and at least for this particular radios that the OEM 
does the read of the block in the high mem it does not work like that.

If you skip this an goes first to the main mem then you get a ACK less 
block as response and the radios stuck and not respond any more.

>> 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?

I have to test that.

>
>> 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?

Yes you are right, but that timing are similar in the pauses between 
request and response and the timeout with the sort block, etc.

>> 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.

Yes, I vote for applying the patch, as it's the only good solution I 
have at hand now.

> 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.

Yes, I know this is not the best solution, but is the one that fix the 
problem for now, we will continue exploring other variants.

The Waccom Mini-8900 still has a problem with the bad ack that arose 
only on linux, I hope when we get a dive onto this we can find a better 
understanding of the 'bad ack'  issue and maybe fix this too.

Pavel.