Bug #6677


Added by Angelo Marcone over 1 year ago. Updated about 1 month ago.

Status:Closed Start date:04/09/2019
Priority:Normal Due date:
Assignee:Bernhard Hailer % Done:


Target version:- Estimated time:2.00 hours
Chirp Version:daily Platform:All
Model affected:Yaesu FT-65


Hi to Everyone,

I'm working with a Yaesu FT-65 and I did some check with chirp and original Yaesu SW.
It seems to me that CTCSS tone information read from the radio are not correct in chirp (the TONE type and the TONE value as well).

I manually stored VHF repeaters (R0, R1alfa, R2, ....R7alfa, split -600Khz for all) with 71.9 CTCSS tone enabled in TX to access these repeaters.
The original sw (in windows) read correctly the configuration, chirp (in linux enviroment) does not. Frequency values are OK.

Someone with the same problem?

Thanks and 73 from Italy.

Angelo IK8VRQ

Related issues

related to Bug #7605: [Yaesu FT-4, FT-65, FT-25] Automatic duplex value selecti... Closed 01/24/2020

Associated revisions

Revision 3298:d841aaba1977
Added by Bernhard Hailer 5 months ago

[ft4] driver restructure (#7615)

While implementing two more radios of the Yaesu FT-4 family (the FT-25, see #7543, and the FT-4V, see #7387), I found that with some moderate reorganization, implementation of new radios will become easier. The proposed reorganization implements one more interstitial layer of inheritance to support the sub families of FT-4 (containing the FT-4X and FT-4V) and FT-65 (containing FT-65 and FT-25). Also, some variable assignments have been moved from the individual radio classes to the SCU-35 base class and to the interstitial classes named above.

This change also adds the infrastructure for adding European or Asian models, and as such prepare for addressing a number of currently open issues (6.25kHz tune step issues on EU models, frequency limitations; see #6619, #6651, #6677, #6761, #6869). It will also make it easier for a few additional fixes for issues which were found during my work on this driver (#7601, #7603, #7605). I will submit these fixes in additional patches.

Fixes: #7615

Revision 3352:8a707d754ab0
Added by Bernhard Hailer 5 months ago

[ft4] Automatic duplex value selection not working. Fixes #7605

This family of radios (like other brands and models) has a feature which
automatically determines whether an offset is to be applied in positive
or negative direction. When a user programmed the radio manually and didn't
explicitly select positive or negative offset, then the radio saved the fact
that it was automatically pre-selected, and not the actual selection. The
driver was able to read that, but didn't know what to do with it.

Data from an FT-65R (for North America models) and a FT-4XE (for European
models) was obtained, and a table built from it. Code to determine the
correct value for "duplex" (0 for +, or 2 for -, instead of 5 for auto) has
been added. Now, instead of saving "auto", the image will be saved with the
correct selection for duplex (something Yaesu should have done in the first

Mentioned in #6677.


Updated by Thom Barker over 1 year ago

@Angelo IK8VRQ

Is your FT-65 the european version (FT-65E) or the USA one (FT-65R)?
Do you know this: https://chirp.danplanet.com/issues/6619

Updated by Angelo Marcone over 1 year ago

yes it's the european version (FT-65E).
I thought the problem was only related to use of 6.25 Khz channels and not to use the rig without these channels.
Probably there are significant differences in the memory map.
Thank you for the answer.
73 de Angelo IK8VRQ

Updated by Daniel Clemmensen over 1 year ago

Which daily version are you using? An early version had some bugs in the CTCSS handling. Please download the latest, then provide
the tone setting as displayed on the radio and the tone value as displayed by CHIRP.

Updated by Daniel Clemmensen over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Daniel Clemmensen
  • Estimated time set to 2.00

Another user privately reported that if you enter a channel using the radio keys, the duplex mode defaults to "auto" instead of "+", "-", "" (i.e., simplex) or "split". Since the CHIRP UI does not know about Yaesu's "auto" and the developer (me) did not know much either, "auto" is defaulted (poorly) to a version of "simplex". I will add "auto" as a custom "property" since it cannot be added to the UI's "duplex" column without a massive effort across all 100 or so of the drivers or a major kludge in the UI or both, all to support Yaesu's non-standard mode: we will not do that. Remember that the fundamental mission of CHIRP is to allow sharing of channel data across all radio models. A non-standard mode is not compatible with that mission.

The workaround is to enter the duplex mode from CHIRP, or if you must enter it from the radio, then force it to either "+" or "-".

Updated by Dan Smith over 1 year ago

Huh, interesting. Most other radios I know of that have an "auto" setting just use that to calculate the duplex in the VFO, but when you store the channel, they store/set the duplex they chose. Not sure what the point of storing "auto" is with a memory is, since it shouldn't ever change.

But I agree with your planned approach, thanks!

Updated by Bernhard Hailer 6 months ago

I Think I might have a fix for the duplex = auto issue; a patch is currently in review. It might need some polish on 70cm, or on European models; but we'll see.

@Angelo: I would be very interested in getting an image of your FT-65E. Any image would be fine, even one obtained right after a factory reset.

Updated by Bernhard Hailer about 1 month ago

  • Status changed from In Progress to Closed
  • Assignee changed from Daniel Clemmensen to Bernhard Hailer
  • Model affected changed from FT-65 to Yaesu FT-65
  • Platform changed from Linux to All

This is done.

Also available in: Atom PDF