Bug #4591
closedYaesu FT-7100M Fails to upload. Win7 or Linux Mint.
Added by Rick Brown over 7 years ago. Updated about 1 year ago.
100%
Description
Hope you can help.
I can download the image but cannot upload it back to the radio.
I'm using a generic CAT to RS232 lead with generic RS232 to USB adapter.
The Cat lead worked with a previous Win XP laptop (with serial port) and the RS232 adapter works with my FT7100 Data lead.
Here's the error in the console.
ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 247, in run
self.__radio.sync_out()
File "/usr/lib/python2.7/dist-packages/chirp/drivers/ft817.py", line 426, in sync_out
raise errors.RadioError("Failed to communicate with radio: %s" % e)
RadioError: Failed to communicate with radio: Radio did not ack block 2
ERROR: ----------------
ERROR: Clone failed: Failed to communicate with radio: Radio did not ack block 2
ERROR: --- Exception Dialog: Failed to communicate with radio: Radio did not ack block 2 ---
ERROR: None
ERROR: ----------------------------
Bad lead maybe?
Rick.
Files
debug.log (83.7 KB) debug.log | Rick Brown, 04/19/2020 02:06 AM | ||
debug.log (161 KB) debug.log | Rick Brown, 09/06/2020 01:39 AM | ||
debug.log (974 KB) debug.log | Jay Hamill, 11/23/2020 03:49 PM | ||
debug.log (161 KB) debug.log | Kevin Mount, 07/10/2021 04:49 PM | ||
ft7100.py (38.6 KB) ft7100.py | Dan Smith, 04/06/2023 04:14 PM | ||
chirp_debug-u5qpw26r.txt (12.4 KB) chirp_debug-u5qpw26r.txt | Bob Sumien, 04/07/2023 01:06 PM | ||
chirp_debug-sdv_toah.txt (93 KB) chirp_debug-sdv_toah.txt | Bob Sumien, 04/07/2023 01:10 PM | ||
chirp_debug-jtin_cvo.txt (100 KB) chirp_debug-jtin_cvo.txt | Bob Sumien, 04/07/2023 02:13 PM | ||
ft7100.py (38.6 KB) ft7100.py | 97cccec0 | Dan Smith, 04/07/2023 02:55 PM | |
chirp_debug-2jioh0fn.txt (104 KB) chirp_debug-2jioh0fn.txt | Bob Sumien, 04/07/2023 03:04 PM | ||
ft7100.py (38.6 KB) ft7100.py | 7215bc40 | Dan Smith, 04/07/2023 03:13 PM | |
chirp_debug-glq65j0_.txt (192 KB) chirp_debug-glq65j0_.txt | Bob Sumien, 04/07/2023 03:53 PM | ||
ft7100.py (38.5 KB) ft7100.py | 19d9fca8 | Dan Smith, 04/07/2023 04:00 PM | |
chirp_debug-64keg20u.txt (134 KB) chirp_debug-64keg20u.txt | Bob Sumien, 04/07/2023 04:13 PM | ||
chirp_debug-f5gdyhaq.txt (336 KB) chirp_debug-f5gdyhaq.txt | Bob Sumien, 04/07/2023 04:43 PM | ||
ft7100.py (38.6 KB) ft7100.py | d0885068 | Dan Smith, 04/07/2023 04:48 PM | |
chirp_debug-avev95vf.txt (447 KB) chirp_debug-avev95vf.txt | Bob Sumien, 04/07/2023 05:07 PM | ||
chirp_debug-oljmdhmg.txt (176 KB) chirp_debug-oljmdhmg.txt | Bob Sumien, 04/07/2023 05:22 PM | ||
FT7100-debug_magic_bytes.txt (2.8 KB) FT7100-debug_magic_bytes.txt | magic bytes and diff | Jesse Jarrell, 04/19/2023 09:02 PM | |
chirp_debug-ihp4czzj.txt (82.2 KB) chirp_debug-ihp4czzj.txt | Keith Oaks, 06/09/2023 12:08 AM |
Updated by Rick Brown over 7 years ago
Sorry, forgot to mention.
I'am using the latest "Today's build".
CHIRP daily-20170222
Rick.
Updated by Bernhard Hailer over 4 years ago
- Status changed from New to Feedback
- Chirp Version changed from 0.4.0 to daily
Have you been able to resolve this on your own since you submitted this?
Have you tried with a recent version since you submitted this?
It might very well be a cable issue, though.
Updated by Bernhard Hailer over 4 years ago
- Model affected changed from (All models) to Yaesu FT-897
Updated by Rick Brown over 4 years ago
Sorry for the delay in udpating this thread.
I can confirm that although the log suggests I was trying to upload to an 897 I did most certainly use the 7100 option.
As a matter of interest, I do use Chirp with an 897 and that works perfectly well.
Unfortunately I can no longer produce the problem as I've now switched entirely over to Windows 10 and have found the old Yaesu tool works fine anyway, so I no longer need to try Chirp for this radio.
I will, however, try my Windows 10 install of the latest Daily Build to upload to the FT7100 as before.
Update to follow.
Rick.
Updated by Rick Brown over 4 years ago
OK, just tried again with a completely different Windows 10 PC using CHIRP daily-20200409 and the problem is exactly the same.
I can download the image, but not upload.
"Clone error on the radio"
and Ack error in chirp.
See log file.
Cheers!
Rick.
Updated by Bernhard Hailer about 4 years ago
Sorry for the time this response took.
The log says you were trying to upload your data selecting the FT-7100 as model?
Can you provide another log, please?
Updated by Rick Brown about 4 years ago
Morning Bernhard.
Just to clarify, once again, this is for the +FT-7100M+, +NOT+ the +FT-897+.
The fault is still present with today's daily build, ie. downloads image ok and allows editing, but no upload, ACK error.
I now use Windows 10 with the same cable as before. The genuine Yaesu software actually works on W10, but doesn't have the functionality of Chirp.
It would be good to resolve this.
Debug file attached.
Cheers,
Rick.
Updated by Bernhard Hailer about 4 years ago
- Subject changed from FT897 Fails to upload. Win7 or Linux Mint. to Yaesu FT-7100M Fails to upload. Win7 or Linux Mint.
- Model affected changed from Yaesu FT-897 to Yaesu FT-7100M
Thanks for the feedback! I've corrected title and device info accordingly. A developer will have to review.
Updated by Bernhard Hailer almost 4 years ago
#6641 suggests a patch, which needs to be reviewed by a developer.
Updated by Jay Hamill almost 4 years ago
Having the same issue with a Prolific cable. Running on an older XP Pro x86 laptop. I can successfully write the radio using the old Vertex FT-7100M 1.01 software. So, I know the cable works.
Updated by Rick Brown almost 4 years ago
I can confirm that the problem is still present with the latest daily build, 20201125, when using Windows 10 64bit and my original Prolific usb to serial adaptor and original Yaesu cable.
I haven't bought another cable yet, as I'm not convinced that is the issue. Yet...
Rick.
Updated by Stevan Obradovic almost 4 years ago
Hi all, I've spent 4 hours typing frequencies, shifts, and all other settings for my FT7100M, only to find out the same thing as you all... So, on the latest version 20201128, when using WIN 10 64bit, upload to the radio still doesn't work... Download works fine.
Stevan
Updated by joshua taggart over 3 years ago
also having this same problem. latest version 01/10/2021 still not working. any solutions?
have downgraded driver on prolific chip as well as upgraded.
RadioError: Failed to communicate with radio: Failed to read ACK. No response from radio.
[2021-01-17 22:08:10,173] chirp.ui.common - ERROR: ----------------
[2021-01-17 22:08:10,173] chirp.ui.clone - ERROR: Clone failed: Failed to communicate with radio: Failed to read ACK. No response from radio.
[2021-01-17 22:08:10,194] chirp.ui.clone - DEBUG: Clone thread ended
[2021-01-17 22:08:10,197] chirp.ui.reporting - DEBUG: Reporting model usage: Yaesu_FT-7100M,upload,True
[2021-01-17 22:08:10,201] chirp.ui.reporting - DEBUG: Reporting exception
[2021-01-17 22:08:10,201] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Failed to communicate with radio: Failed to read ACK. No response from radio. ---
[2021-01-17 22:08:10,204] chirp.ui.inputdialog - ERROR: Traceback (most recent call last):
File "chirpw", line 68, in
AttributeError: 'NoneType' object has no attribute 'split'
[2021-01-17 22:08:10,204] chirp.ui.inputdialog - ERROR: ----------------------------
Updated by Rudolph Gutzerhagen over 3 years ago
Does the radio need to be toggled to receive from Chirp?
To clone from one transceiver to another, use the following procedure:
...
3. On the “destination” radio, press the [REV] key. The “CLONE RX” indicator will appear on the display.
Updated by Rick Brown over 3 years ago
Yes it does need to be toggled and no, it doesn't make any difference.
Many thanks.
Rick.
Updated by Kevin Mount about 3 years ago
have we found out how to fix Failed to communicate with radio: Failed to read ACK. No response from radio. yet? im having the same issue
Updated by Rick Brown about 3 years ago
I personally haven't found a work around.
Luckily I still have the original Yaesu software (and it runs on Windoz 10), so I can still program the radio.
Chirp would be a better solution though. It has far more flexibility than the Yaesu software.
Rick.
Updated by Kevin Mount about 3 years ago
I purchased the radio used so it did not come with Yaesu software. I bought the cable from Mark Dunkle of bluemax just so I could use chirp. I could buy yaesu software and a cable for about the same price as this cable. do you have a resource that I could download Yaesu's software? I really wanted to use chirp. Use it on my other radios.
Updated by Kevin Mount about 3 years ago
Also what does status feedback mean? shouldn't be a open issue?
Updated by Bob Sumien over 1 year ago
This right here fixed it for me. MACOS 12.6.3 Show Package Contents>Contents>Resources>Chirp>Drivers save your old FT-7100.py and .pyc and delete them replace it with the FT-7100.py you download from this post re download from radio and then reupload that download. Open your saved file (because you saved one before you figured out it wasn't going to upload like me......) then upload to the FT-7100. Works.
Updated by Dan Smith over 1 year ago
Bob, I assume you're using chirp-legacy? The ft7100 driver hasn't been converted/fixed for next yet.
If you can test for me, attached is a converted driver with the fix from #6641 in it. Take extra care, as I haven't been able to test this against a radio since I don't have one. Be sure to maintain a backup you can use with chirp-legacy if this fails. Please try it, attach a debug, and let me know if it works or not.
Instructions for loading this into chirp-next are here: LoadingTestModules .
cc @Bob Sumien
Updated by Dan Smith over 1 year ago
Tagging @Bob Sumien in case he didn't see the above.
Updated by Bob Sumien over 1 year ago
@Daniel Fiechter Smith yes legacy. I had to install python 2.7 to get back up and running. Hadn't used CHIRP in a few months at least. I'd be happy to test for you. I see the instructions for loading test modules but Idon't see an attachment. Feel free to email me if that makes things easier.
Updated by Bob Sumien over 1 year ago
Bob Sumien wrote in #note-24:
@Daniel Fiechter Smith yes legacy. I had to install python 2.7 to get back up and running. Hadn't used CHIRP in a few months at least. I'd be happy to test for you. I see the instructions for loading test modules but Idon't see an attachment. Feel free to email me if that makes things easier.
@Dan Smith not sure what happened I guess I tagged the wrong person in my previous comment. Hopefully this tags you.
Updated by Bob Sumien over 1 year ago
@Dan Smith I am so sorry it has been a bad week around here. I see the attachment now. I was looking for it at the bottom and not the top. I'll try to test it tomorrow or Saturday at the latest! Thank you.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-u5qpw26r.txt chirp_debug-u5qpw26r.txt added
@Dan Smith It errored trying to d/l from the radio to CHIRP. Log attached.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-sdv_toah.txt chirp_debug-sdv_toah.txt added
It also errors when I open the file created and successfully uploaded to the FT-7100 through CHIRP Legacy. All things are equal, same FT-7100, same MacBook, same port on the MB, same cable and adapter. If you want to start an email string instead of back and forth here we can. I'm happy to help test. I also have a couple other radios I haven't checked them to see if they've been converted for CHIRP-next yet however.
Updated by Dan Smith over 1 year ago
Bob, neither of your logs show that you've loaded the module I attached. Please follow the instructions in LoadingTestModules.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-jtin_cvo.txt chirp_debug-jtin_cvo.txt added
I had loaded it last night, maybe it was in that log. I also shut the app down and reopened it today. Does it drop the test module? Anyhow, I reloaded it and tried both up and down. The log with the addition of the module starts at 16:03.
Updated by Dan Smith over 1 year ago
Yeah, as noted at the bottom of the LoadingTestModules a module is only active for the current session. If you close chirp you have to re-load it.
Found a couple more things, so here's an updated one to try.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-2jioh0fn.txt chirp_debug-2jioh0fn.txt added
Sorry LOL! I got to step 5 and stopped reading.
New log.
Updated by Dan Smith over 1 year ago
Okay, the way this driver has to hand-feed bytes to the radio requires a little more change for python3. Here's another.
Sorry, but without a radio to test with, this is annoyingly iterative for the both of us. Thanks for your patience.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-glq65j0_.txt chirp_debug-glq65j0_.txt added
No problem. I look at it this way, I enjoy tinkering with electronics and if I help I'm giving back. There are so many guys along the way that have helped me tinker with home servers, websites, modding this that or the other. I'm happy to run as many tests as you need. I also have an FT-1802 laying around SOMEWHERE. Once I put my hands on it I'll help with that one too. :)
New log. I noticed it seemed to fail quicker when I had the volume knobs turned down. I think it's the Boefeng or Wuxoun handheld that needs the volume up so I figured I'd give that a shot.
Updated by Dan Smith over 1 year ago
Okay, there's a lot going on in that log so it's hard to tell exactly what all is happening. However, the last download attempt before the end of the log shows it got past the earlier segment we were stuck on and on to another python3-required change. A fix for that is attached.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-64keg20u.txt chirp_debug-64keg20u.txt added
Ok. I'll run 1 attempt at down from the radio followed by 1 attempt up to the radio for simplicity.
Updated by Dan Smith over 1 year ago
Okay, that last one has what looks like a timing bug that isn't relevant to the conversion nor the fix from the other bug we're trying to integrate. It probably just makes the driver flaky in general (I didn't write this driver by the way, so I'm building context as we go). Now that I realize what you're doing, I think that explains some of the confusion in the earlier one. We can look at that issue separately, but if you could just try a download again with the same driver that'd be good. Since you seem to be looking at the logs, when you see this:
[2023-04-07 18:11:03,356] chirp.loaded.loaded-8932-bk1eyznc - DEBUG: Header:
000: 56 61 72 74 65 78 20 53 Vartex.S
008: 74 61 6e 64 61 72 64 20 tandard.
016: 41 48 30 30 33 4d 20 4d AH003M.M
024: 2d 4d -M......
[2023-04-07 18:11:03,356] chirp.loaded.loaded-8932-bk1eyznc - DEBUG: len(header) = 26
[2023-04-07 18:11:03,607] chirp.loaded.loaded-8932-bk1eyznc - DEBUG: Header:
000: 61 70 20 56 30 34 ap.V04..
That's the additional bug I'm describing, where it reads the header in two chunks and since neither looks complete, it throws it away as garbage and keeps waiting. So in that case, you just need to try again. The driver needs to be, well, smarter than that, but it's not currently.
Also, no need to try an upload unless the download succeeds and looks good.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-f5gdyhaq.txt chirp_debug-f5gdyhaq.txt added
I tried again and it immediately failed. I figured I'd try again but this time I did a factory reset on the radio before trying. It worked and here is the log. I'm sitting down to dinner but after I plan on trying again without the factory reset to see if it continues working or not. This is just the successful d/l and u/l.
Updated by Dan Smith over 1 year ago
When you say "it immediately failed" do you mean CHIRP stopped waiting or the radio gave an error? If the latter, then that's likely the same issue. It's just a race between you, chirp, and the radio and python3 will make it more likely that you'll lose that race. It's hard to tell without the log, but I feel pretty confident that's what's happening and that the factory reset didn't have anything to do with it.
I say that because Yaesus (at least all the ones I've ever looked at closely) don't actually reset their memories, they just mark everything as unused. That makes it really difficult to get back to a clean state once something has gone wrong.
The other problem is this silly dance you have to do where you put chirp into download mode and push the button on the radio. Yaesu is the only manufacturer that still builds radios like this (instead of letting the computer negotiate the full start of the procedure). That means the driver has to be designed in a special way (and this one wasn't) to make it work properly.
Don't get me started on Yaesus.
Anyway, attached is my attempt to fix the start race in the driver, and correct one other logging issue I see in your latest log. If you can try that after dinner, I'd appreciate it, but it looks like we're close?
Updated by Bob Sumien over 1 year ago
- File chirp_debug-avev95vf.txt chirp_debug-avev95vf.txt added
I'll try that new one now but here is the log with the d/l attempt. I didn't shut down CHIRP. The radio went into error before CHIRP. Here is that log. The fail starts at 19:01.
Updated by Dan Smith over 1 year ago
Okay, well, that attempt got nothing at all from the radio. However, that could be that there was some junk queued on the serial line that the radio read as soon as it started up. They're also quite sensitive to that, since there isn't any negotiation back and forth between the computer and the radio, a single unexpected byte will stop it.
Updated by Bob Sumien over 1 year ago
- File chirp_debug-oljmdhmg.txt chirp_debug-oljmdhmg.txt added
Back to back 1st attempt through ERROR on the radio screen. 2nd attempt was after a factory rest. 2nd attempt completed.
Updated by Dan Smith over 1 year ago
Okay, the first attempt still got nothing at all from the radio. You're not doing any uploads between successive successful downloads right? If not, nothing is being written to the radio so I can't explain why it would need a reset in between. When you start chirp waiting, it's literally just waiting for the radio to send something, never hears anything, and times out. So it's hard to imagine how chirp could be doing anything to cause the radio to error out.
So, if you haven't tried an upload, please do that and let me know if that's working.
If we can't explain the issue with the download and the resets, I'm hesitant to proceed further. If the radio fails to transmit the image and chirp is still waiting and you push the TONE button again, what happens? Are you doing anything with the cable (unplugging, etc) in between tests?
Updated by Bob Sumien over 1 year ago
Ok. The one before the last I d/l, u/l and then tried to d/l again. The first d/l and u/l after the factory reset worked then the next d/l failed. When I push the Tone button it failed and presented ERROR on the screen of the radio immediately. Those are the times when CHIRP is getting nothing from the radio. As far as the cable the only thing I do is unplug it from my MBP and then plug it back into the same USB port. The cable remains attached to the 7100. I'll test more tomorrow. Would having logs from legacy vs next help? I'm not sure how to get the legacy log.
Updated by Dan Smith over 1 year ago
There's nothing being logged during this part so there's nothing to compare it to in legacy. I want to know if you can do multiple downloads in a row without the factory reset, without any uploads in between. It's also useful to know if that doesn't work in -next but does in -legacy (although there's really nothing useful that will tell me).
Why are you unplugging it from your computer in between successive download attempts? If the radio is in clone mode when you do that it can definitely confuse the radio and it should definitely not be necessary.
Updated by Bob Sumien over 1 year ago
Testing and making notes as I test.
CHIRP Legacy
Seems like you can do multiple downloads but then when you try to upload after several it fails.
Looks like you have to download before you can upload even if the image was successfully uploaded previously.
Once you upload you have to shutdown and power back up in clone before you can download or upload again.
CHIRP Next
Also seems you can do multiple downloads.
You have to make a change to the download or switch images to be able to upload to the radio.
Same in that you have to shut down and reboot into clone before you can do another d/l or u/l.
Shut down CHIRP and brought it back up, loaded the module and was able to u/l without d/l first.
I was not unplugging it from the computer between u/l or d/l attempts. I was unplugging between testing sessions. Moving between the couch and the radio. :D The other thing I noticed was that with next I was having to push Tone or Rev twice to get it to either TX or RX the image. When d/ling the 2nd attempt I was only having to push Tone once. Not sure that makes any sense or difference but with Legacy I always only had to push Tone or Rev once for it to get into mode. For some reason today I was not having to do a factory reset to get it to work.
I put hands on my FT-1802M and it does not have a computer programming port so I won't be able to help with that one.
Updated by Dan Smith over 1 year ago
- Assignee set to Dan Smith
- Target version set to chirp-py3
CHIRP Next
Also seems you can do multiple downloads.
You have to make a change to the download or switch images to be able to upload to the radio.
I don't know what this means. What does "make a change to the download or switch images" mean?
Same in that you have to shut down and reboot into clone before you can do another d/l or u/l.
Shut down CHIRP and brought it back up, loaded the module and was able to u/l without d/l first.
Okay, this driver is definitely not super robust, but I also think what you're experiencing is sensitivity on the part of the radio to any junk on the cable during any of this. With an Icom or a Kenwood (or really anything else), starting the download on the chirp side causes chirp to tell the radio "okay give me your memory". If there was junk on the line due to cable noise or another program opening the port in between, the radio will say "huh?" and chirp will just try again. On you (and all) Yaesu, the radio will just fail and stop.
Anyway, sounds like this set of changes at least makes the driver usable in next, so I'll merge it.
Thanks for your help.
Updated by Dan Smith over 1 year ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset github|f12f1985636d258292f86a403ce229a4bf4005aa.
Updated by Jesse Jarrell over 1 year ago
Using the latest build, I was able to download from my FT-7100, but uploading seems to die just after the magic bytes. I captured the magic bytes from the download which did not match what was recently changed in the code, so I attempted the use the ones from my radio instead but got the same results. It seems the radio goes into error mode after sending the magic bytes which I figure is why I get the failed ACK error.
Also spotted an error where echo needed to be checked vs. data, which is included in the diff attached. Supposedly the magic bytes are static, but I'm wondering if they are firmware based and not static to the radio model.
Since I have the actual radio and the RT-29B cable, if anybody has other suggestions to try I'm willing to give it a test.
Thanks,
Jesse
Updated by Keith Oaks about 1 year ago
June 2023
I as well am still having an issues with this bug. I have tried old and new software, both windows 10 and MAC. The DL works perfect. UL will fail moments after the ok button is pressed and "ERROR" is shows on the radio screen. Reading through this page and the other associated tickets I believe I am performing all of the steps in the correct order. I am using a factory USB-29B cable
Is there any information or support I can provide or is there a known resolution I have not been able to find yet
Thank you
Keith
Updated by Keith Oaks about 1 year ago
- File chirp_debug-ihp4czzj.txt chirp_debug-ihp4czzj.txt added
Debug log attached
Updated by Dan Smith about 1 year ago
- Has duplicate Bug #10653: Yaesu FT-7100 reads once, but fails to upload added