[chirp_devel] [PATCH] [FT-70] New Model #5329 Increased second block size

[Nicolas Pike]

Hi,

On 21 March 2018 at 22:07, Dan Smith via chirp_devel <chirp_devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20180321/bd1fadd4/attachment-0001.html