Project

General

Profile

Actions

Bug #10919

closed

Error Communicating - Yaesu FT-8800 with MARS CAP Mod

Added by Roger T over 1 year ago. Updated over 1 year ago.

Status:
Not a bug
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Chirp Version:
next
Model affected:
Yaesu FT-8800
Platform:
Windows
Debug Log:
I read the instructions above:
Yes

Description

Chirp is unable to communicate after applying the MARS/CAP mod to a Yaesu FT-8800. This appears to be the same issue as the FT-2900 with the mod to extend the frequency range. The issue was resolved by Revision 848e37b7.

Debug log:

[2023-10-29 11:32:00,206] chirp.wxui.clone - DEBUG: Using port 'COM5'
[2023-10-29 11:32:00,206] chirp.wxui.clone - DEBUG: Selected
[2023-10-29 11:32:00,220] chirp.wxui.clone - DEBUG: Prompt pre_download disabled for radio
[2023-10-29 11:32:00,326] chirp.wxui.clone - DEBUG: Serial opened: Serial(port='COM5', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=0.25, xonxoff=False, rtscts=False, dsrdtr=False) (rts=True dtr=True)
[2023-10-29 11:32:01,159] chirp.drivers.ft7800 - INFO: Download finished in 0 seconds
[2023-10-29 11:32:01,159] chirp.wxui.clone - ERROR: Failed to clone: index out of range
Traceback (most recent call last):
File "chirp\wxui\clone.py", line 69, in run
File "chirp\drivers\ft7800.py", line 328, in sync_in
File "chirp\drivers\yaesu_clone.py", line 262, in check_checksums
File "chirp\drivers\yaesu_clone.py", line 203, in get_existing
IndexError: index out of range
[2023-10-29 11:32:07,307] chirp.wxui.clone - WARNING: Stopping clone thread


Files

Yaesu_FT-8800_20231030.img (21.9 KB) Yaesu_FT-8800_20231030.img Roger T, 10/30/2023 11:48 PM
Actions #1

Updated by Dan Smith over 1 year ago

  • Tracker changed from CHIRP-next model report to Bug
  • % Done set to 0
Actions #2

Updated by Dan Smith over 1 year ago

I'm sure some work will be required to support the modded 8800, but I don't think that's actually your problem. It looks to me like the clone in stops immediately and never actually gets the radio image and fails the checksum calculation as a result. Does the radio proceed with the send procedure? Does chirp fail immediately once you push the button?

Actions #3

Updated by Roger T over 1 year ago

I solved the first problem, which was a PEBCAK error - Problem Exists Between Chair And Keyboard. I found another instance of Chirp running in the background. Once I closed all windows and verified only Chirp was running, I was successfully able to download from radio.

Attempts to upload to the radio fail due to the Radio Error: Radio did not ack block at 0
This appears to be a common problem with Yaesu radios. Here is the debug log:

[2023-10-30 21:25:26,471] chirp.wxui.clone - DEBUG: Prompt pre_upload disabled for radio
[2023-10-30 21:25:26,471] chirp.wxui.clone - DEBUG: Opening serial 'COM5' after upload prompt
[2023-10-30 21:25:26,564] chirp.wxui.clone - DEBUG: Serial opened: Serial(port='COM5', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=0.25, xonxoff=False, rtscts=False, dsrdtr=False) (rts=True dtr=True)
[2023-10-30 21:25:26,730] chirp.wxui.clone - ERROR: Failed to clone: Radio did not ack block at 0
Traceback (most recent call last):
File "chirp\wxui\clone.py", line 69, in run
File "chirp\drivers\ft7800.py", line 338, in sync_out
File "chirp\drivers\ft7800.py", line 216, in _upload
chirp.errors.RadioError: Radio did not ack block at 0
[2023-10-30 21:25:32,427] chirp.wxui.clone - WARNING: Stopping clone thread

Actions #4

Updated by Dan Smith over 1 year ago

It's a "common problem with Yaesu radios" because they have the most brain-dead cloning protocol and don't really allow the PC to do any negotiation. Thus any upload failure results in that message because we can't get anything more useful from the radio. In your case, it's likely because of the different ID string due to your MARS mod. Please attach the image you downloaded and I'll have a look.

Actions #5

Updated by Roger T over 1 year ago

Yes, definitely a problem on the Yaesu side of things.
Here is the .img I downloaded.

Actions #6

Updated by Dan Smith over 1 year ago

Thanks, but looking at that driver, it should actually be sending whatever ID string it got from your radio back to it during an upload. If you're doing the upload dance properly (i.e. starting chirp at the appropriate time for the radio being ready for it) then I'm not sure why it's not working. The driver works for me locally.

If you could describe in detail the steps you're doing as well as the exact behavior(s) of the radio at each step I might be able to spot something amiss.

Actions #7

Updated by Roger T over 1 year ago

Brilliant! The MARS/CAP mod reset the radio. From that point, I should have started with a new blank download for re-programming the channels. My mistake was to attempt using an .img file created prior to the mod. Those previous .img files are no longer recognized post-mod.

Thank you again for your patience and troubleshooting. This issue may be closed.

Actions #8

Updated by Dan Smith over 1 year ago

  • Status changed from New to Not a bug
  • I read the instructions above set to Yes

Ah, yep, Yaesu radios (of this vintage at least) basically change their identification when you modify them so that you can't clone a modified radio into an unmodified one or vice-versa. Since the aforementioned braindead clone protocol they use provides no feedback, chirp can't tell the difference between "radio is not connected", "radio rejected our proposal", or "radio is modified and the image is not." It's frustrating.

Anyway, sounds like you're good, thanks.

Actions

Also available in: Atom PDF