Hi,

On 21 March 2018 at 22:07, Dan Smith via chirp_devel <chirp_devel@intrepid.danplanet.com> wrote:

> diff -r 61ba9c815170 -r c290bb32d9bf chirp/drivers/ft70.py
> --- a/chirp/drivers/ft70.py   Thu Mar 15 23:41:07 2018 +0000
> +++ b/chirp/drivers/ft70.py   Mon Mar 19 23:11:32 2018 +0000
> @@ -466,14 +466,14 @@
> @directory.register
> class FT70Radio(yaesu_clone.YaesuCloneModeRadio):
>     """Yaesu FT-70DE"""
> -    BAUD_RATE = 115200
> +    BAUD_RATE = 38400

Does the radio really magically operate at either of these two rates? Or do you set it in the radio before you do the clone? Otherwise, I can't think of why this could have been set to the old value, or be set to this new value without breaking things. We have a couple of radios that can be at one of several rates and we probe until we determine the proper one. Just launching into a clone at whatever rate you pick here seems unlikely to work. Can you explain more?

The FT70 has a built in USB interface The Chirp driver is only intended to be used with this, no baud rate is set on it. Using a higher baud rate made a slight difference in speed, But initially thought this might now be causing other issues, so changed back to 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
> +    _block_lengths = [10, 65920]  # ????? Not sure why this works to match _memsize

This writes less data to the radio, that's it. It should be very very not-operating-system specific. If you need to write the same amount of data in smaller chunks, you need to set _block_size to something else (although it's really small by default already). However, this looks really suspicious to me...


At 38400 or 15200 baud blocks were being returned with no data in them.

Investigated further with Fred and Mark

We are losing blocks at the beginning in the Chirp yaesu_clone method.

[2018-03-19 21:35:41,483] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920
[2018-03-19 21:35:41,733] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920
[2018-03-19 21:35:41,986] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920
[2018-03-19 21:35:42,236] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920

I thought the rest of the download was working, hence the puzzle of how are we short at the end. Which did not make sense if we were only losing blocks at the beginning...

After increasing the size last night it worked and then we realised that blocks must be being returned with no data during the rest of the download. Slight confusion of the debug info as that shows the running total - not the bytes read for each block - errors will show as an unchanged value not as zero... Loaded it into a spreadsheet this morning and behold we are losing a dozen or so blocks...

Two examples

[2018-03-19 21:18:16,013] chirp.drivers.yaesu_clone - DEBUG: Read 49152/65920
[2018-03-19 21:18:16,263] chirp.drivers.yaesu_clone - DEBUG: Read 49152/65920

[2018-03-19 21:18:16,489] chirp.drivers.yaesu_clone - DEBUG: Read 53248/65920
[2018-03-19 21:18:16,739] chirp.drivers.yaesu_clone - DEBUG: Read 53248/65920

etc. Note the read figure has not changed, so as you said that block read did not return any data.

And guess what they are on 4k boundaries.....

Slightly different behaviour on Mac vs Windows but only how many blocks get lost... Which as Fred says gets us to how the O/S or radio are handling the requests.

I submitted a patch to increase the size - for the time being - but it seems that yaesu_clone needs looking at. This doubtless explains the odd number in the FT1 driver which the FT-70 driver is "very" loosely based on - I never did understand how that number was arrived at.....

Fred has now done some great work investigating this further, for a full fix, as opposed to the temp of just reading more blocks.

Freds observations

Think I found what the problem is with read.  

chirp sets the time out to .25 secs I changed it to 2 secs and seems to work.

I did not make a patch,  there seems to be numerous changes with hg diff 
anyway from context you will see where the changes are.

  _model = "AH51G"

    _memsize = 65227  # 65227 read from dump ?
    _block_lengths = [10, 65217]  # ????? Not sure why this works to match _memsize
    _block_size = 32
    _mem_params = (900,  # size of memories array
                   900,  # size of flags array
                   )

    _has_vibrate = False
    _has_af_dual = True


  # not sure of correct place to set timeout
    def sync_in(self):
        self.pipe.timeout=2
        super(FT70Radio, self).sync_in()

    def process_mmap(self):

        mem_format = MEM_SETTINGS_FORMAT + MEM_FORMAT + MEM_CALLSIGN_FORMAT + MEM_CHECKSUM_FORMAT

        self._memobj = bitwise.parse(mem_format % self._mem_params, self._mmap)


We are going to test this further and submit another patch. I submitted the previous patch as a temp measure, as it was broken on many - (but not my!!) Windows installs

Phew!

Nicolas