[chirp_devel] [PATCH] [FT-70] #5329 and issue #5647 Revise handling of empty chunks in yaesu_clone.py
# HG changeset patch # User Nicolas Pike nicolas.jon.pike@gmail.com # Date 1521827521 0 # Fri Mar 23 17:52:01 2018 +0000 # Node ID 9e3b0ff763087f08758900b006199e2ea60b57dc # Parent 96bc56916c955098f4a5b71cc174edeef1f090d9 [FT-70] #5329 and issue #5647 Revise handling of empty chunks in yaesu_clone.py #5647 Empty chunks no longer counted towards blocks read. #5329 Can now set correct memory size read request, as no getting empty blocks. Yaesu_clone change proposed by Dan - Thanks! I have only tested it on the FT-70, would be great to see it tested on other Yaesu radios. This replaces my last submitted patch.
diff -r 96bc56916c95 -r 9e3b0ff76308 chirp/drivers/ft70.py --- a/chirp/drivers/ft70.py Tue Mar 20 21:38:07 2018 -0400 +++ b/chirp/drivers/ft70.py Fri Mar 23 17:52:01 2018 +0000 @@ -466,14 +466,14 @@ @directory.register class FT70Radio(yaesu_clone.YaesuCloneModeRadio): """Yaesu FT-70DE""" - BAUD_RATE = 115200 + BAUD_RATE = 38400 VENDOR = "Yaesu" MODEL = "FT-70D"
_model = "AH51G"
- _memsize = 65227 # 65227 read from dump ? - _block_lengths = [10, 65555] # ????? Not sure why this works to match _memsize + _memsize = 65227 # 65227 read from dump + _block_lengths = [10, 65217] _block_size = 32 _mem_params = (900, # size of memories array 900, # size of flags array diff -r 96bc56916c95 -r 9e3b0ff76308 chirp/drivers/yaesu_clone.py --- a/chirp/drivers/yaesu_clone.py Tue Mar 20 21:38:07 2018 -0400 +++ b/chirp/drivers/yaesu_clone.py Fri Mar 23 17:52:01 2018 +0000 @@ -43,14 +43,22 @@
def _chunk_read(pipe, count, status_fn): + timer = time.time() block = 32 data = "" - for _i in range(0, count, block): - data += pipe.read(block) - if data: + while len(data) < count: + # Don't read past the end of our block if we're not on a 32-byte boundary + chunk_size = min(block, count - len(data)) + chunk = pipe.read(chunk_size) + if chunk: + timer = time.time() + data += chunk if data[0] == chr(CMD_ACK): data = data[1:] # Chew an echo'd ack if using a 2-pin cable - # LOG.debug("Chewed an ack") + # LOG.debug("Chewed an ack") + if time.time() - timer > 2: + # It's been two seconds since we last saw data from the radio, so it's time to give up. + raise errors.RadioError("Timed out reading from radio") status = chirp_common.Status() status.msg = "Cloning from radio" status.max = count
- _memsize = 65227 # 65227 read from dump ?
- _block_lengths = [10, 65555] # ????? Not sure why this works to match _memsize
- _memsize = 65227 # 65227 read from dump
- _block_lengths = [10, 65217]
I was going to complain that you just tweaked the comment on the memsize line unnecessarily, but... are you removing that "?" because you really weren't sure before and now you've got it figured out?
And, are you saying that you're confident now that 65217 is the right value for the last block after the yaesu_clone change? Like, 65555 was the magic value that worked for your own timing, with the zero-block reads you were getting before?
I assume this is confirmed to fix the problem the other person was having?
If all the above is correct, then...cool :)
diff -r 96bc56916c95 -r 9e3b0ff76308 chirp/drivers/yaesu_clone.py --- a/chirp/drivers/yaesu_clone.py Tue Mar 20 21:38:07 2018 -0400 +++ b/chirp/drivers/yaesu_clone.py Fri Mar 23 17:52:01 2018 +0000
So, this code hasn't changed in so long I'm a little nervous about changing it. Is there anyone else on the dev list here that can give it a sniff test? I'm not sure I have any yaesu radios I can easily test with, but I'll look.
If not, we'll just have to merge it and warn the users list to test it ASAP.
--Dan
On 23 March 2018 at 22:38, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
- _memsize = 65227 # 65227 read from dump ?
- _block_lengths = [10, 65555] # ????? Not sure why this works to
match _memsize
- _memsize = 65227 # 65227 read from dump
- _block_lengths = [10, 65217]
I was going to complain that you just tweaked the comment on the memsize line unnecessarily, but... are you removing that "?" because you really weren't sure before and now you've got it figured out?
Yep..
And, are you saying that you're confident now that 65217 is the right value for the last block after the yaesu_clone change? Like, 65555 was the magic value that worked for your own timing, with the zero-block reads you were getting before?
Yep.. Mem dump is 65227, first 10 then 65216 then strictly the 1 for the checksum, but I included that which seems to work fine. 65555 read enough "extra blocks" to make up for the ones we were losing.. at least on Mac(!)
From my first view of the FT1 I was concern, in the back of my mind why the
memory size and block size did not match up..
I assume this is confirmed to fix the problem the other person was having?
I have reproduced the error on another Windows machine, although mine worked(!)
If all the above is correct, then...cool :)
Cheers!
diff -r 96bc56916c95 -r 9e3b0ff76308 chirp/drivers/yaesu_clone.py --- a/chirp/drivers/yaesu_clone.py Tue Mar 20 21:38:07 2018 -0400 +++ b/chirp/drivers/yaesu_clone.py Fri Mar 23 17:52:01 2018 +0000
So, this code hasn't changed in so long I'm a little nervous about changing it. Is there anyone else on the dev list here that can give it a sniff test? I'm not sure I have any yaesu radios I can easily test with, but I'll look.
Completely agree. I would really like to see other people test this.
If not, we'll just have to merge it and warn the users list to test it ASAP.
Agreed
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Completely agree. I would really like to see other people test this.
I pulled out my FT-7800 and confirmed that it works with and without the change, so I think we're probably good. I'll plan to push it in after dinner and then we need to remember to reply to the build announcement tomorrow and ask for some extra validation from Yaesu owners.
--Dan
participants (3)
-
Dan Smith -
nicolas jon pike -
Nicolas Pike