Re: [chirp_devel] [PATCH][BTECH] Bug fix about radios resetting on the download, fixes #3015
El 06/04/16 a las 10:27, Jim Unroe escribió:
Pavel: No, I have confirmation by the first ID that this radio is the model I know it's; but the OEM reads the second ID of the radio and we are copying this behavior... and now I realize that maybe we don't need to do that, as we know for sure that this is the radio it's.
Jim, we will test in that way this night.
Sure.
[.....]
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.
Jim
After a few test this path 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.
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.
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.
The other mentioned way of a short read and then a serial flush is a more complicated version of the one in the actual patch, so I think you will reject it also.
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.
I was testing a kind of buffer on other context and after a few tests and deep thinking it's a no go here for a few reasons, can you please take a time and guide me or elaborate more on the buffer version concept for me to understand it?
Cheers Pavel.
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
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.
participants (3)
-
Dan Smith -
M.Sc. Pavel Milanes Costa -
Pavel Milanes (CO7WT)