Bug #10473
openNewest version of ChirpNext resets Yaesu-FT70D when trying to upload data
0%
Description
Download from the FT70D is working fine, but when I want to upload the data to the FT70D upload stops with "Radio did not ack block 1".
After rebooting the device, it was reset to factory settings and I had to enter my callsign to move forward. Tested this several times, same result.
I am using the latest release of ChirpNext (CHIRP next-20230322 on Python 3.10.8 wxPython 4.2.0 msw (phoenix) wx Widgest 3.2.0)!
Files
Updated by Dan Smith over 1 year ago
- Has duplicate Bug #10973: November versions of ChripNext resets Yaesu-FT70D when trying to upload data added
Updated by Chris Martin about 1 year ago
I believe the factory resets happen on the FT-70D regardless of computer software if a computer->radio transfer fails. I observed this on Windows with the Yaesu-provided software as well as CHIRP when the radio's receive would time out. Perhaps the solution is to reduce the timeout on CHIRP or have CHIRP repeatedly try again. Aside from that, frankly it seems like a radio software design fault on Yaesu's part.
Updated by PERRY RAMSEY about 2 months ago
I have this same bug. Other people have had it, too.
It failed to upload, then blew away all my existing programming.
I was eventually able to recover everything using legacy chirp, so whatever the issue is was introduced with next.
There ought to at least be an asterisk next to the FT-70D on the compatibility list as a warning that there's a known issue with serious consequences.
Updated by Dan Smith about 2 months ago
- I read the instructions above set to Yes
This is the first I'm hearing that legacy chirp works and chirp-next does not. There have been reports of similar issues with legacy chirp, so I'm a bit skeptical. Also, there are people very clearly using the ft70 with chirp-next with no problem, which tells me there are two versions of the ft70 firmware out there with different behaviors. Thus, adding a warning about the driver wouldn't be universal.
Finally, there is no difference in the cloning routines of the ft70 driver between chirp legacy and next, and it is based on a common module that provides clone support for all the VX-* models (of which the FT-70 is based on the VX-6) and those drivers report no such problem. For these reasons, I'm highly skeptical about legacy working and next not, as I just can't explain it.
Can you attach a debug log from legacy showing it work, and then a debug log from next showing it fail using the exact same image data? I'm not sure if there's enough info in there to make any determination, but it might be interesting to compare.
I'm also happy to post a test version of the ft70 driver with the serial timeout cranked up, if someone has a real suspicion that next is being too impatient.
Updated by Dan Smith about 2 months ago
Here's a module you can load with LoadingTestModules that will bump the ft70 upload timeout to 1000ms (four times the default). Note that the default in chirp-legacy is the same 250ms as in chirp-next, so if this helps, I can't explain why (but it'll be interesting regardless).
Updated by Josh Ludwig about 2 months ago
I was able to get mine to work with "CHIRP next-20240901 on python 3.10.8 wxPython 4.2.0 msw (phoenix) wxWidgets 3.2.0)" but was unable to with "chirp-next-20250307". I mine would read from just fine. but the current version will not write.
Updated by Dan Smith about 2 months ago
Josh, can you (or anyone else) test with this version:
https://archive.chirpmyradio.com/chirp_next/next-20250131/
and if it works there, test with this version:
https://archive.chirpmyradio.com/chirp_next/next-20250207/
and confirm it is broken there? I have a hunch that a cleanup to another module may have made the difference we're seeing here. Since it's not in a driver it's hard to give you something to test, but the above two versions should be the before/after we're looking for.
I'm planning a build tomorrow so if you can confirm quickly I can get that revert pushed in for tomorrow.
Updated by Dan Smith about 2 months ago
I decided to put the change into the build anyway. Please test today's build and see if it's back to working (for those that it worked before).
Updated by Matt Parker about 1 month ago
I am having this issue as well. I cannot get the radio to upload or download. It worked earlier today but now nothing.
Updated by Matt Parker about 1 month ago
I wonder if your changes earlier today Dan was what made mine quit working.
Updated by Matt Parker about 1 month ago
I was able to use the Yaesu ADMS software to download from the radio that had been reset. Then I entered one repeater into the programming in ADMS and uploaded it. Next I went back into chirp and it uploaded after I did it in ADMS. Then I was able to use my ISO from Chirp and upload all of my repeaters. It was a horrible experience but those with reset FT-70D radios may have to use the Yaesu software to get it out of some weird fault. Once reset with software, it may work again. At least it did for me. As a back up, I then went back into the ADMS software and uploaded alll of my repeaters from the radio. Now I have a back up if Chirp keeps making me update the software and it fights my FT-70D again.