Bug #5647
closedFT-70D INCOMPLETE IMAGE RECEIVED FROM RADIO
0%
Description
FT-70D Incomplete image received from radio, driver is installed from Yaesu ADMS software and properly works with it.
I have attached my debug file.
Radio is brand new.
Windows 10 PRO new install from cd.
Computer is I5 Intel.
Files
Updated by Bill Broadley almost 7 years ago
Art E wrote:
FT-70D Incomplete image received from radio, driver is installed from Yaesu ADMS software and properly works with it.
I have attached my debug file.
Radio is brand new.
Windows 10 PRO new install from cd.
Computer is I5 Intel.
It claims you used 0.4.0, the FT-70DR supports is very new, I recommend the newest daily version of chirp. Currently that's 20180314.
Updated by Art E almost 7 years ago
When I click about on the chirp program it says 20180314.
Updated by Art E almost 7 years ago
[2018-03-15 15:39:56,105] chirp.logger - DEBUG: CHIRP daily-20180314 on WinVista/7 (Python 2.7.10)
Updated by Nicolas Pike almost 7 years ago
Thanks for your feedback. Just to triple check - Are you using the USB cable or a separate interface? This driver has only been tested with the USB cable.
Thanks!
Updated by Art E almost 7 years ago
usb cable supplied.Drivers say Yaesu 70D in Control Panel.
Updated by Harold Espeldoorn almost 7 years ago
Same problem here.
Yaesu FT70D with latest firmware release.
Yaesu adms software works fine.
Updated by Nicolas Pike almost 7 years ago
- Assignee set to Nicolas Pike
- Model affected changed from (All models) to FT-70D
Testing on Windows 10 - I have found one possible cause - If the radio is not put into clone (ADMS) mode from cold each time a download to Chirp is done then this error occurs.
The radio appears to allow multiple downloads from ADMS just by pressing the band button as it goes into TX and does indeed send data, but not the whole file(?), causing this error.
[2018-03-16 22:01:04,559] chirp.drivers.yaesu_clone - DEBUG: Read 64864/65555
[2018-03-16 22:01:04,559] chirp.drivers.yaesu_clone - DEBUG: Read 64896/65555
[2018-03-16 22:01:04,559] chirp.drivers.yaesu_clone - DEBUG: Read 64928/65555
[2018-03-16 22:01:04,559] chirp.ui.reporting - DEBUG: Reporting exception
[2018-03-16 22:01:04,559] chirp.ui.common - ERROR: -- Exception: --
[2018-03-16 22:01:04,559] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 249, in run
File "chirp\drivers\yaesu_clone.pyo", line 235, in sync_in
File "chirp\drivers\yaesu_clone.pyo", line 100, in _clone_in
If the radio is put into ADMS mode from cold. Then it all works
[2018-03-16 13:27:57,516] chirp.drivers.yaesu_clone - DEBUG: Read 65184/65555
[2018-03-16 13:27:57,516] chirp.drivers.yaesu_clone - DEBUG: Read 65216/65555
[2018-03-16 13:27:57,766] chirp.drivers.yaesu_clone - DEBUG: Read 65217/65555
[2018-03-16 13:27:58,016] chirp.drivers.yaesu_clone - DEBUG: Read 65217/65555
[2018-03-16 13:27:58,266] chirp.drivers.yaesu_clone - DEBUG: Read 65217/65555
[2018-03-16 13:27:58,516] chirp.drivers.yaesu_clone - DEBUG: Read 65217/65555
[2018-03-16 13:27:58,766] chirp.drivers.yaesu_clone - DEBUG: Read 65217/65555
[2018-03-16 13:27:59,016] chirp.drivers.yaesu_clone - DEBUG: Read 65217/65555
[2018-03-16 13:27:59,016] chirp.drivers.yaesu_clone - DEBUG: Clone completed in 12 seconds
[2018-03-16 13:28:00,250] chirp.drivers.yaesu_clone - DEBUG: Checksum 0000-FEC9 (@FECA): OK
[2018-03-16 13:28:07,153] chirp.ui.clone - DEBUG: Clone thread ended
Also note that
- The download ADMS instructions in Chirp must be followed, as other combinations may give ADMS on the display but will not work.
- The Chirp memory display can take a while to load, best to limit the memory display and unclick "Show Empty".
Of course this may not be the issue you have(!) - Please advise.
Thanks again for you feedback.
Updated by Robi Akerley-McKee almost 7 years ago
Also having same problem. Windows 10, Yaesu USB Cable, Yaesu FT-70D Firmware 1.11 DSP 6.02 Works with Yaesu software. Incomplete using CHIRP. Used Chirp 2018-03-16 and 2018-03-14. Intel Core 2 Duo T6600 2.2Ghz 4GB RAM
Updated by Robi Akerley-McKee almost 7 years ago
Unplug Battery, Hold AMS, plug in power cable, ADMS on screen, press band after 3 seconds of hitting download.
Updated by Harold Espeldoorn almost 7 years ago
Thank you for the info.
I tried the suggested workflow but it comes back with the same incomplete download message .
My ft70d is the export version for europe.
In my setting screen, i have 63 settings where the weather channel watch is missing (63) in comparison to the us version which has 64 settings.
My firmware version is 1.11 and the dsp version 6.01, i can not find the update for that yet.
Harold.
Updated by Art E almost 7 years ago
I also tried playing with the time after it says to press the Band button still says the same.
My firmware is also 1.11 dunno the dsp version but its from the factory radio as new.
Updated by Nicolas Pike almost 7 years ago
Finally reproduced the issue on Windows. Block length increased as a temporary fix. Need to investigate further. Seems all data being read as checksum passing, but more block reads required than on Mac). Patch submitted.
Updated by Nicolas Pike almost 7 years ago
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 is handling the requests.
I have 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.....
Thanks everyone!
Nicolas
Updated by Nicolas Pike over 6 years ago
Should now be fixed by patch to yeasu_clone.py
Please can people test. Thanks for everyones work on this.
Updated by Robi Akerley-McKee over 6 years ago
Nicolas Pike wrote:
Should now be fixed by patch to yeasu_clone.py
Please can people test. Thanks for everyones work on this.
Working here! YAY!!
Updated by Nicolas Pike over 6 years ago
- Status changed from New to Closed
Yaesu_clone updated. Reported working now on FT-70 and other Yaesu radios. Thanks.