<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On 21 March 2018 at 22:07, Dan Smith via chirp_devel <span dir="ltr"><<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.<wbr>danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-7612014227494681446gmail-"><br>
> diff -r 61ba9c815170 -r c290bb32d9bf chirp/drivers/ft70.py<br>
> --- a/chirp/drivers/ft70.py Thu Mar 15 23:41:07 2018 +0000<br>
> +++ b/chirp/drivers/ft70.py Mon Mar 19 23:11:32 2018 +0000<br>
> @@ -466,14 +466,14 @@<br>
> @directory.register<br>
> class FT70Radio(yaesu_clone.YaesuClo<wbr>neModeRadio):<br>
> """Yaesu FT-70DE"""<br>
> - BAUD_RATE = 115200<br>
> + BAUD_RATE = 38400<br>
<br>
</span>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?<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-7612014227494681446gmail-">
> VENDOR = "Yaesu"<br>
> MODEL = "FT-70D"<br>
><br>
> _model = "AH51G"<br>
><br>
> _memsize = 65227 # 65227 read from dump ?<br>
> - _block_lengths = [10, 65555] # ????? Not sure why this works to match _memsize<br>
> + _block_lengths = [10, 65920] # ????? Not sure why this works to match _memsize<br>
<br>
</span>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...<br></blockquote><div><br></div><div><br></div><div><b>At 38400 or 15200 baud blocks were being returned with no data in them.</b></div><div><span style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px"><br></span></div><div><span style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">Investigated further with Fred and Mark</span><br></div><div><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">We are losing blocks at the beginning in the Chirp yaesu_clone method.</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">[2018-03-19 21:35:41,483] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920<br>[2018-03-19 21:35:41,733] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920<br>[2018-03-19 21:35:41,986] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920<br>[2018-03-19 21:35:42,236] chirp.drivers.yaesu_clone - DEBUG: Read 0/65920</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">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...</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">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...</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">Two examples</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">[2018-03-19 21:18:16,013] chirp.drivers.yaesu_clone - DEBUG: Read 49152/65920<br>[2018-03-19 21:18:16,263] chirp.drivers.yaesu_clone - DEBUG: Read 49152/65920</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">[2018-03-19 21:18:16,489] chirp.drivers.yaesu_clone - DEBUG: Read 53248/65920<br>[2018-03-19 21:18:16,739] chirp.drivers.yaesu_clone - DEBUG: Read 53248/65920</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">etc. Note the read figure has not changed, so as you said that block read did not return any data.</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">And guess what they are on 4k boundaries.....</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">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.</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">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.....</p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px">Fred has now done some great work investigating this further, for a full fix, as opposed to the temp of just reading more blocks.<br></p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px"><b>Freds observations</b></p><p style="color:rgb(72,72,72);font-family:Verdana,sans-serif;font-size:12px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.800000190734863px">Think I found what the problem is with read. </span></p><div style="font-size:12.800000190734863px">chirp sets the time out to .25 secs I changed it to 2 secs and seems to work.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">I did not make a patch, there seems to be numerous changes with hg diff </div><div style="font-size:12.800000190734863px">anyway from context you will see where the changes are.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px"><div> _model = "AH51G"</div><div><br></div><div> _memsize = 65227 # 65227 read from dump ?</div><div> <font color="#ff0000">_block_lengths = [10, 65217] </font># ????? Not sure why this works to match _memsize</div><div> _block_size = 32</div><div> _mem_params = (900, # size of memories array</div><div> 900, # size of flags array</div><div> )</div><div><br></div><div> _has_vibrate = False</div><div> _has_af_dual = True</div></div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px"><div> <font color="#ff0000"> # not sure of correct place to set timeout</font></div><div><font color="#ff0000"> def sync_in(self):</font></div><div><font color="#ff0000"> self.pipe.timeout=2</font></div><div><font color="#ff0000"> super(FT70Radio, self).sync_in()</font></div><div><br></div><div> def process_mmap(self):</div><div><br></div><div> mem_format = MEM_SETTINGS_FORMAT + MEM_FORMAT + MEM_CALLSIGN_FORMAT + MEM_CHECKSUM_FORMAT</div><div><br></div><div> self._memobj = bitwise.parse(mem_format % self._mem_params, self._mmap)</div><div><br></div></div></div><div><br></div><div>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</div><div><br></div><div>Phew!</div><div><br></div><div>Nicolas </div></div></div></div>