New Model #4787

Yaesu FT-65 VHF/UHF hand held

Added by Clive Turner over 3 years ago. Updated over 1 year ago.

Status:Closed Start date:05/03/2017
Priority:Normal Due date:03/14/2019
Assignee:Daniel Clemmensen % Done:

100%

Category:-
Target version:- Estimated time:1.00 hour
Chirp Version:daily Equipment Loan Offered:No

Description

Yaesu has a new radio (details at https://www.yaesu.com/indexVS.cfm?cmd=DisplayProducts&ProdCatID=249&encProdID=79E6683CC766565D2CB197C293AB6219&DivisionID=65&isArchived=0)

The programming details are that a programming cable SC-35 is required. There are no details available for pinouts / CAT programming commands yet.

FT-65R_E_QM_ENG_EH066M551.pdf - Yaesu Quick Manual (4 MB) Clive Turner, 05/03/2017 03:04 am

d.py (7.4 kB) Daniel Clemmensen, 02/23/2019 12:28 pm

d (185 Bytes) Daniel Clemmensen, 02/23/2019 12:28 pm

dump.ft4 (8.3 kB) Daniel McIlroy, 02/23/2019 01:12 pm

p1m1p2m5p3m9p4m15.ft4 (250 Bytes) Daniel McIlroy, 02/23/2019 01:12 pm

p1m18p2m23p3m31p4m38.ft4 (126 Bytes) Daniel McIlroy, 02/23/2019 01:12 pm

prior (8.8 kB) Daniel McIlroy, 02/23/2019 01:12 pm

p1-4m1-4.ft4 (498 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m5-8.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m9-12.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m13-16.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m17-20.ft4 (250 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m21-24.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m25-28.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m29-32.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m33-36.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-2m37-38.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:20 am

p1-4m13-16take2.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:31 am

p1-4m17-20take2.ft4 (126 Bytes) Daniel McIlroy, 02/25/2019 06:31 am

v.py (2.6 kB) Daniel Clemmensen, 02/25/2019 11:27 am

FT-65R Notes.ods (54.6 kB) Ric Sanders, 02/26/2019 10:42 pm

freq-example.jpg (23.5 kB) radi _, 03/04/2019 02:16 pm


Related issues

related to New Model #6153: Yaesu FT-4XR Closed 10/10/2018

Associated revisions

Revision 3150:c25f78b9bcfd
Added by Dan Smith over 1 year ago

Fix unittest adapter class

The adapter was ignoring tests that collect and return multiple failures at once,
so any CopyAll failures were ignored. This makes the adapter just pick off the first
one and raise it.

Found while reviewing the driver for #4787

Revision 3167:346db1f31405
Added by Daniel Clemmensen over 1 year ago

[ft4] add driver for Yeasu FT-4 and eventually FT-65 #4787

ft4.py passes unit tests on main tip and on py3 branch

Revision 3175:a0b1e7b205fc
Added by Daniel Clemmensen over 1 year ago

[ft4] whitespace cleanup [#4787]
first of several patches. the next patches fix tone support,
improve FT-65 support, fix a py3 upload failure, and improve
version matching.

Revision 3177:0c2f0a0b61e5
Added by Daniel Clemmensen over 1 year ago

[ft4] improve serial i/o [#4787]
improved version ID checking code (more general, and
uses a radio type-specific id). Also, a bug that
prevented upload on the py3 branch is fixed

Revision 3178:f5966fdfa248
Added by Daniel Clemmensen over 1 year ago

[ft4] compander, 6.25 suppress, freq range fix [#4787]
a few fixups that dont fall into other categories.
the US fersons (FT-4XR and FT65R) don't allow the
6.25 KHz frequency step. The FT-65 has a feature the
FT-4 lacks (compander). The code had a leftover
"valid_frequencies statement.

Revision 3179:6d57bab4ad7b
Added by Daniel Clemmensen over 1 year ago

[ft4] programmable keys names for the FT-65 [#4787]
the namelist for the FT-65 programmable keys differes for the one for the FT-4

Revision 3176:7cade4518562
Added by Dan Smith over 1 year ago

Add ft4 to cpep8 manifest

Related to #4787

Revision 3182:790e63c3399a
Added by Daniel Clemmensen over 1 year ago

[ft4] make the tone code less ugly [#4787]
Tone encode and decode both now derive from A single shared mapping table.

This also patch includes whitespace changes, but only to pass cpep8. Another
patch follows to fix other whitespace and minor cleanups.

Revision 3195:3da27dd19d74
Added by Daniel Clemmensen over 1 year ago

[ft4] whitespace cleanup [#4787]
Comments only.

Revision 3196:0ab155789d42
Added by Daniel Clemmensen over 1 year ago

[ft4] put UI tones in normal order [#4787]

Revision 3197:ba16deb4cf38
Added by Daniel Clemmensen over 1 year ago

[ft4] fixups in FT65 support [#4787]

Revision 3209:9ba25a3c6a5e
Added by Daniel Clemmensen over 1 year ago

[ft4] enable FT-65 support [#4787]
This patch requires the .img file (supplied earlier)
Tested by me on a friend's FT-65, and some
testing by others.

Revision 3210:47704cc5d944
Added by Dan Smith over 1 year ago

Add test image supplied by Dan for FT-65

#4787

History

Updated by Frank D'Amato over 3 years ago

I also would like to see this model supported. It appears it's a single stereo plug instead of the dual type

Updated by Dennis Austin about 3 years ago

I also have a Yaesu FT-65 and would like support. Hard to divine Yaesu plans, but it appears it might eventually replace the FT-60.

Updated by Angela Rarick about 3 years ago

Really want to see the FT-65 supported. Chirp does not seem to talk to the FT-65 using FT-60 setting and the Yaesu SCU-36 clone cable on Win10. Even though I installed the older Prolific USB-to-Serial Comm Port Version: 3.2.0.0 driver. The error is "An error has occurred. Error reading echo. (Bad Cable?)".

Updated by Matthew Walker about 3 years ago

I can loan a radio and programming cable.

Updated by Clive Turner about 3 years ago

Thanks Matthew, I have ordered a cable but its still not available from the supplier. Your offer of a handset to the CHIRP team is very kind and much appreciated!

Updated by Fred Munden about 3 years ago

I have available memory map and a python3 script to read/write the radio and image file. I’m not interested in adding it to Chirp. Anyone who wants to work on it can eMail me and I’ll send you what I have. If you find any errors or omissions please let me know. The documentation is in MS Word 2010, should be able to open it in LibreOffice formatting may get messed up.

The memory map and r/w protocol for FT-65R is not like any other Yaesu I have looked at. You can query for ID and the memory map is record based with a checksum for each record. The protocol is documented in the python script.

Fred

Updated by Tommy Martinez almost 3 years ago

So, no one is interest in helping with Chirp support?

Updated by Brian George almost 3 years ago

I emailed Fred Munden to see what he has.
I have the radio and cable and some software engineering skills, but haven't ever worked with python.

Updated by Tommy Martinez almost 3 years ago

Thanks for that. I have the radio and some software skills, but, not python. I don't have a programing cable, as I refused to pay that much for the RT Systems programing software. I've contacted Yaesu, and, they stated that they have no intentions on releasing any software themselves. I'm by no means putting others out their, but, I feel that this radio will only be lacking due to no interest in giving it more. There seems to at least be a mars/cap mod for it now, released last night. Although can't access it due to the website errors.

Updated by Alexander Korotkevich almost 3 years ago

Found this thread yesterday, after winning Yaesu FT-65r/e with RT systems soft and USB-55 cable at the Socorro HamFest lottery. Will be glad to contribute. Don't use M$ Windoze, only Linux. Here is my first contribution:
how to make your RT Systems USB-55 cable to show up as a /dev/ttyUSBx port (x - some integer), which is a requirement for CHIRP to work with it. RT Systems use custom Vendor and Product IDs for USB, as a result the usual FTDI USB2serial chip is not recognized by the system. Here is what you need to do (ftdi_sio kernel driver has to be compiled as a module):
1) unplug the cable
2) execute under root or with sudo # modprobe ftdi_sio
3) execute under root or with sudo # echo 2100 9055 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
4) plug in the cable. You should now have /dev/ttyUSB0 (or some other number at the end) serial device for CHIRP to communicate with.

This should work for other RT Systems cables as well. As far as I know all of them are based on FTDI chip. Just replace VendorID and ProductID. Here is how to find them (two equivalent methods). Plug in the cable, then do one of the following:
1) execute lsusb command, which will give you several lines, with one of them similar to:
Bus 001 Device 012: ID 2100:9055 RT Systems

Compare with the "echo" command above and replace accordingly.

2) execute dmesg command and at the end you'll find something like that:
[88281.574236] usb 1-1: new full-speed USB device number 12 using xhci_hcd
[88281.749024] usb 1-1: New USB device found, idVendor=2100, idProduct=9055
[88281.749025] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[88281.749026] usb 1-1: Product: CT55 Radio Cable
[88281.749027] usb 1-1: Manufacturer: RT Systems
[88281.749027] usb 1-1: SerialNumber: RT1CZAZ1

You can easily see both product and vendor IDs.

Hope it helps.

Will be glad to help with the driver. Did a lot of programming with different languages. Last 15 years mostly in C. Don't think that learning some Python will be a big deal.

Updated by Marvin Nauman almost 3 years ago

I have the Yaesu SCU-35 cable & Radio available for this.

Updated by Tommy Martinez over 2 years ago

I'm just curious, by the way. RT Systems says that only the USB-55 (RT Systems ADMS-65 Programing Cable) is compatible with the RT Systems Programing Software. And, Yaesu says that they don't plan on releasing any programing software. So, does anyone know the purpose of Yaesu's SCU-35 Programing Cable? I've got no response from Yaesu when I asked.

Updated by Morris Beverly over 2 years ago

I just bought the ft-65R and Yaesu programming cable at HRO, not realizing that chirp doesn't support it. I have a bit of java and c++ experience and have recently started working in python. I'd be happy to help however I can with either programming or testing or whatever will help. I'm also willing to loan you the radio and cable for a few weeks if that will help.

thanks, morris

Updated by Bora Yurtoren over 2 years ago

Ok, am I the only one that can see and download a programming software on yaesu web site? Just go to yaesu.com, find the ft-65 page, look under "files" tab. It is there as two versions, one for eu/us version, one for exp (export) version.

Updated by Keith Wilson over 2 years ago

I also downloaded the US version of the Yaesu software for FT-65 programming. It seems to program fine, although cut, copy, and paste seem to be limited. Sometimes an entire line is copied/pasted when only one cell was intended. But there appears to be a bug affecting reading the radio, as 2 meter band splits programmed as 0.60 MHz are read as 0.55 MHz. I checked the radio, and the radio is using the intended 0.60 MHz split, so this appears to only affect reading from the radio, and does not appear to affect writing to the radio. I sent a note to Yaesu tech support so they are aware of the bug. I would prefer to use CHIRP when it is available.

Updated by Tommy Martinez over 2 years ago

Bora Yurtoren wrote:

Ok, am I the only one that can see and download a programming software on yaesu web site? Just go to yaesu.com, find the ft-65 page, look under "files" tab. It is there as two versions, one for eu/us version, one for exp (export) version.

Thank you for mentioning that. At the time this request was created, as well as my last message here, there was no programing software in the Files area on Yaesu website, just the two pictures, Leaflet, and the manuals. And, when I contacted Yaesu, they responded to me that they have no interest in releasing programing software, and directed me to the RT Systems. I'm glad Yaesu decided to release software.

Thanks again for mentioning it.

Updated by Tommy Martinez over 2 years ago

Tommy Martinez wrote:

Thanks for that. I have the radio and some software skills, but, not python. I don't have a programing cable, as I refused to pay that much for the RT Systems programing software. I've contacted Yaesu, and, they stated that they have no intentions on releasing any software themselves. I'm by no means putting others out their, but, I feel that this radio will only be lacking due to no interest in giving it more. There seems to at least be a mars/cap mod for it now, released last night. Although can't access it due to the website errors.

Edit: The MARS/CAP Mod that I mentioned was spam, by the way. Just incase anyone decides to contact me for more details. The problem is that users cannot view any mods without registering a logging in, so, I didn't know it was spam until doing so. The mods are not verified by admins and any registered user can submit mods. Apologies everyone.

Updated by Jose Fer over 2 years ago

Do you know anything about Chip's development for the Yaesu FT 65? It would be nice to have a Chrip on this radio, we'll wait for news.

Updated by Rob de Santos over 2 years ago

I'd also like to see this radio supported by Chirp.

Updated by Tony Minetti about 2 years ago

I would also like to have Yaesu FT-65R programming support in Chirp.

Updated by Philip Barr almost 2 years ago

Has anyone started work on this yet? I don't have programming skills but perhaps I can help some other way. Contact me if there's anything I can do.

I really like my -65 and would love to see Chirp (especially for mac) available.

Updated by Darryl Newberry almost 2 years ago

#metoo. I have an FT-65R and USB cable, and I know C and a little python. If somebody could guide me through setting up for development, I could give it a shot. Make a lot of folks happy to have FT-65 support in chirp. I can develop for Linux and Mac, but I don't do Windows, sorry.

Updated by Darryl Newberry almost 2 years ago

Ok, I got tired of waiting on someone else to do it, so I am adding support for the Yaesu FT-65.

I started today.

I'm working on a mac using PyCharm, which is probably overkill, could probably get by with just printing debug info to the console. It's actually not a whole lot of code involved, mostly just requires a lot of trial and error to reverse out the handshaking and memory layout.

As a start, I copied ft60.py to ft65.py and will massage it from there.

I need some help with a couple of things:

1) Need a serial port sniffer for mac. I googled but didn't find
anything free for OSX. If there's an open source solution let me
know, I have built stuff with brew from time to time.

2) need to know cmd line to launch chirp from osx terminal

(note: i posted something similar to the chirp dev mailing list, but echoing here in case anyone can help)

73 de AE0BQ Darryl

Updated by Craig Stodolenak almost 2 years ago

Thank you so much, Darryl! Just picked up a 65R today and disheartened to learn CHIRP can't talk to it... yet.

1) DTrace might be your best bet, although it may not "see" everything, which then would require a hardware sniffer.
2) '/Applications/chirp-daily-20180906.app/Contents/MacOS/chirp', obv. replacing the daily filename with whatever you have installed.

Updated by Luke Bryan over 1 year ago

I have 65R model and Linux laptop, much experience developing in Python.
Is there anything I may help with? I don't have a programming cable and I'm not yet familiar with how a task like this is accomplished.

Updated by Daniel Clemmensen over 1 year ago

I have an FT-4XR. It uses the same cable. Does anyone have specs for the cable and its underlying protocol? Is is just UART, 8N1, 9600, 3.2 volt, and if so, how do TX-RX-GND map to tip-ring-sleeve? I'm too cheap to buy a cable and I don't do Windows. I do have hardware and Python experience.

Updated by Daniel Clemmensen over 1 year ago

OK, I gave up and ordered a cable, which should arrive in two days. If all else fails I will use it on my wife's Windows machine. I downloaded the free Yaesu software and I will try to run it under Wine on Linux first. The Yeasu download package includes a manual an inataller, a device driver for the cable, and the actual program. The device driver is for a Prolific PL2303 and appears to be identical to the one on the Prolific site, so presumably Yaesu did not modify it. This gives me hope that the Linux driver will just work. If everything goes well I will then interpose slsniff between the Yaesu app and the real serial port and watch.

Updated by Daniel Clemmensen over 1 year ago

I finished installing Wine. (Since I foolishly insist on running GDentoo, this was an adventure). The Yaesu app installs and runs under Wine. Now I just need for the cable to arrive to see if I can get Wine to present the cable to the app as a serial port like it's supposed to.

Updated by Daniel Clemmensen over 1 year ago

OK, received cable. Good news: I can use the Yaesu app in wine to read from the FT-4XR, modify the data, and send it back to the radio. Bad news: I have not yet succeeded in a software sniff, but it's clearly 9600 8n1. I am now setting up for a hardware sniff. I have the T-R-S broken out, and it appears to be a 3.3V system and GND is on the sleeve. With a hardware sniff it's hard to exactly correlate the timing of TX versus RX, but maybe I can fake it somehow.

Updated by Daniel Clemmensen over 1 year ago

After sleeping on it I realized that a kernel-level capture might work. Research: YES! kernel makes "usbmon" available, and Wireshark can monitor it. Installed Wireshark, ran it, ran the Yaesu app, and captured the interactions. Learned how to use the wireshark display filter, and now I have the capture of just the USB interactions with the Prolific device. The bad news: mapping this back to actual serial port send/receive is non-trivial. During initialization, Someone (probably the Linux prolific driver) sends to three different sub-devices. During the early setup, someone (probably the Yaesu program) is causing interactions with these same three sub-devices. Finally we settle down into reading serial characters. Each character read is a USB command followed by a response: The response is a single character. Next up: I must write a script to print theses characters in a reasonable format while indicating what else is happening. What fun. (Interestingly, the radio appears to identify itself as an FT-35R).

Updated by Daniel Clemmensen over 1 year ago

I finally learned enough about Wireshark to make some progress. I now have a trace of the serial data flow during a read operation from the FT-4XR. I have not decoded the control commands,just the serial I/O. The protocol seems quite simple. The host sends a command and the radio responds. For the read sequence, there are a total of four command types: PROGRAM, <stx>, Raaall, and END. The radio responds to a command by first repeating it back, then adding any data, then sending the ASCII <ack> (0x06) byte. The response to PROGRAM is PROGRAMQX<ack>. This is the first command/reaponse of the session. The <stx> is a single byte with value 0x02, and the response from my radio is
024946542d333552000056313030000006
Which as you see starts with the <stx> and ends with the <ack>. In ASCII, this is
IFT-35R<0><0>V100<0><0><ack>
whatever that is supposed to mean.

The response to END is END<ack>. This is the last command of the session. After the <stx> command/response and before the END command/response, there are 538 commands 4-byte commands of the form form Raaaall. the las byte (ll) is always 0x10. the middle two bytes (aaaa) appear to be a big-endian hexadecimal number that starts at 0x0010 and increments by 0x10, with the aaaa in the last R command being being 2140

I chose to name these aaaa and ll because they look very much like the address and length fields of every microprocessor and PROM programmer since before the beginning of time: what we used to call "KIMBIN format."

The radio's response to an R command is always 26 bytes long. the first four bytes echo the response and the las byte is an <ack>. The next byte is an ASCII W (0x57). The next three bytes echo the aaaall (again). Then, there appear to be 16 data bytes. the last bye before the <ack> appears to be a checksum.

Since I have only programmed a very few channels, I do not know the mapping of the memory addresses to the radio channels. I can tell that the frequencies are stored in BCD (e.g., frequency 147.015 is codes as 0x14701500, that is one decimal digit per nybble).

Next steps: I need some guidance. Should I tackle the control stuff, the content mapping, or the host-write-to-radio as my next steps?

Updated by Daniel Clemmensen over 1 year ago

The byte prior to the <ack> is in fact a checksum. Specifically, it's the sum of the 19 byte values starting with the address and len bytes immedialtely prior to the 16 data bytes.

Updated by Daniel Clemmensen over 1 year ago

OK, I now have a python program provided by another experimenter that reads and writes the memory for his FT-65R (tested by him) and modified for my FT-4XR (tested by me). I have his memory map, but I do not have a memory map for the FT-4XR, nor do I know much about building one or about integrating into CHIRP. I proceed boldly, armored in my cloak of massive ignorance!

Updated by Daniel Clemmensen over 1 year ago

I'm still working on this. I took a holiday break to play with the grandkids. I have now joined the developer's mailing list and studied how to do CHIRP development and how to discover the memory map. Slow progress. My initial goal is support for the FT-4XR, but if I succeed then someone with access to other family members (FT-65, etc.) can easily add them, I hope.

Side note: It's now clear that the SCU-35 programming cable is a "two-wire" type. That is, TxD and RxD are tied together and "wire-or'ed". Thus, the computer receives every character that it sends (and presumably the radio receives every character that it sends.) This explains why the protocol seems to have a silly amount of redundancy: those "extra" response characters are not being echoed by the radio.

Updated by Daniel Clemmensen over 1 year ago

OK, the serial transfer protocol is identical to the protocol implemented in th9000.py, which supports radios in the TYT TH-9000 and LUITON LT-580 families. Since I had already implemented the protocol in a new module, I will not attempt to merge FT-4/FT-65 into that module until after I analyze the memory maps. There is no necessary correlation between the transfer protocol and the contents of the memory. I note that the protocol in the anytone_ht.py modules is also the same except that its cable is not wire-or'ed. that module supports the AnyTone OBLTR-8R and TERMN-8R radios.

I now know the correct module structure and conventions for supporting multiple radios in a family, so that's another tiny step forward.

Updated by Philip Barr over 1 year ago

I don’t have any programming knowledge, so I’m not sure how I can help, but I want to say thank you for working on this. If there’s anything I can do, let me know!

Updated by Daniel Clemmensen over 1 year ago

I'm still working on this. I now have the CHIRP development environment loaded. I have written a new driver module (ft4.py) and I am beginning the debugging process. I have validated the per-channel portions of the memory map. I have not yet done a field-by-field validation of the "settings" portion, which has more individual field types than the per-channel portion. I decided to debug the channel portion first.

It's slow going, because my knowledge of Python, Ham radio, and CHIRP conventions are all weak. At this rate it will be at least another week before I submit the module, and I suspect that the dev group will take some time with a new module from a new developer.

It turns out that that another member of my Ham club has an FT-65, so I will be able to add it in after I get the FT-4 working.

Updated by Daniel Clemmensen over 1 year ago

I'm still working on this. Code is complete and debugging is nearly so. I can read the radio, modify all fields, and write the radio. Now I must figure out how to run CHIRP's automated unit test system. The biggest problem was understanding CHIRP's tone scheme. The FT-4 implements all but two of the 11 possible CHIRP tone mode, which makes the FT-4 very feature-rich compared to many others. CHIRP encodes the tone mode as a (tone,cross) tuple. To see how hard this is, look at https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes.

Updated by Daniel Clemmensen over 1 year ago

OK, it's ready to go except for the port to Python3, and I will need a tester for the FT-65. Much of the delay was to add support for the progammable keys, (P1,and P2 on the FT-4, or P1 thru P4 on the FT-65). I gave up and implemented a brute-force approach. I hope the Python 3 work will be quick. If not I will release for the current CHIRP (Python 2) and deal with Python 3 later.

Updated by Daniel Clemmensen over 1 year ago

OK, I got it working on both Python2 and Python3 and submitted it. We will see what happens.

Updated by Shannon Landsberger over 1 year ago

Thanks for all your hard work on this. If you still need someone to test it out a bit, let me know.

Updated by Daniel Clemmensen over 1 year ago

Shannon: if you have a Yaesu SCU-35 programming cable and a FT-4 or FT-65, you can try it. I suspect it's buggy even though it passes the unit tests, so save your current config using the Yaesu-supplied software. The driver module is available as an attachment on an e-mail on the chirp-devel mailing list if you wish to try it before it becomes part of the current build. to "install" the driver, just put it in the "drivers" subdirectory of the chirp directory (exact location will depend on how you installed CHIRP in the first place). CHIRP will magically find the driver the next time you run it. This is not for the faint-hearted.

Updated by Clive Turner over 1 year ago

Hi Daniel,
Thanks for having a go at this, I'm amused that its taken a couple of years for anyone to tackle it and jolly glad that someone has. CHIRP is a lot more useful than Yaesu's own software.

Good on you for this, I think a lot of folk will appreciate your efforts very much!

G1WZM / Clive.

Updated by Philip Barr over 1 year ago

I've got the latest mac chirp downloaded and the right cable (I think), but don't see FT-65 on the drop down list. Am I missing something?

Updated by Philip Barr over 1 year ago

I'll be watching the download site for the update with the FT65, will do a run through and report.

Updated by Daniel Clemmensen over 1 year ago

The driver is now on the build! The FT-4 model advertizes itself and can be used! BUT -- the FT-65 model does not. Dan Smith, the guy who has been running the CHIRP development since its inception, feels that we should not advertize the FT-65 until I (or someone) can actually test it. If you are very brave and are willing to act as a tester for the FT-65, you can use a text editor to un-comment the line near the end of the ft4.py module. remove the first two characters '# ', leaving @directory.register starting in column 1, then just run CHIRP as usual. Since CHIRP is written in Python, the source code is recompiled on the fly every time it runs, so the change takes effect when you start CHIRP: no "install" in needed.

The module is in chirp/drivers and is named ft4.py

NOTES:
It's probably buggy.
Use the Yaesu software to save a copy of your memory so you can recover if my software trashes your radio config.
Tone modes may not work properly: let me know.
The code for the programmable keys (P1, P2, P3, and P4) is "interesting". If you the key to "mem" then
you can choose from a list of memories (1-200 and L01-U20). If you choose something other than "mem", you are choosing
a "set mode" shortcut based on the setmode name. The FT-65 internal setmode NAMES are the same as the FT-4 setmode NAMES,
but the internal NUMBERS are different. I made a wild guess that the FT-65 actually uses the FT-4 NUMBERS internally. If
I was wrong, then your results will not look right. This will not affect your radio unless you use the software to change
the programming for one of these keys.

Updated by Dan Smith over 1 year ago

Daniel, if he's on windows he won't be able to edit the file. You can post a tweaked ft4.py here and he should be able to "Load module" it from within chirp if he turns on dev tools.

Updated by Philip Barr over 1 year ago

I'm on a mac, and for some reason in this new download (2/20), the USB driver isn't showing up. It was there with the 2/19 download, what might be going on?

Otherwise, screw it, I'm totally willing to guinea pig this thing.

Updated by Dan Smith over 1 year ago

No changes related to serial ports in this build. USB-serial devices are extremely finicky on MacOS. Try rebooting.

Updated by Daniel McIlroy over 1 year ago

i have a FT-65. I have downloaded the 2/20 build and have commented out the @directory.register line but i am getting a Clone failed: Failed to communicate with radio: Incorrect ID. Error. I have some experience with python and am running Linux fedora 29 currently. I will try to trace it down some more the error is coming from outside of the ft4.py module. i need to figure out were the debug log is to see what ID it is giving

Updated by Daniel Clemmensen over 1 year ago

Daniel Mcllroy: that error is propagating out of ft4.py and being reported to you from up the stack. The error is almost certainly caused because the ft4.py module checks for a particular string (i.e., IFT-35R) at the very beginning of the download: I guessed that this string was the same for the FT-65 as for the FT4, and I was apparently wrong. The actual string (in hex) is supposed to end up in the debug log. I do not know how you enable that log or where you find it. I think it is enabled as part of "enable developer functions" in the help menu.
If I am correct you can proceed by changing the comparison string (expected_id) to match your actual result for now. If we can use your string to puzzle out the actual Yaesu ID convention, I have "improved"(?) the code to use it better(?) in the current version.

Updated by Daniel Clemmensen over 1 year ago

  • File d.py added
  • File d added

Please do save your config using the Yaesu software. I don't know of a way that my software could mess up your radio, but I don't have any experience with this stuff, either.
You can also use this very crude tool (d.py) to download the image. It also prints the "version" string. It's based on the serial I/O code
from an earlier iteration of ft4.py. Hack the proper comms port name into the correct spot in the test() function near the bottom
of the file. Since you are running Linux, you may choose to also use the bash script (d) to make repeated runs after making a single config change to the radio after each run. runt it with a desired name for the diff file for this run (e.g, d p1battsave) I especially need to know what happens when the reprogrammable keys (P1, P2, P3, P4) are reprogrammed. The questions to answer are:
Are these values stored where a think they are for the four keys?
When saving a setmode shortcut, what number is saved for each setmode name?
You can answer both question quite quickly. Pick four setmodes (with widely-spaced setmode numbers). run the program twice, with a setmode on P3 and a different setmode on P4. We can puzzle it out from there. If you are willing to do the complete tedious stuff, then do all of the setmodes. Use all four keys (P1, P2, P3, P4) and make a single run for each of set of four.

The first run of the script will create a full dump in hexdump format. Subsequent runs will produce diffs, so they are quite small.

Updated by Daniel McIlroy over 1 year ago

ok ran d once with no args then ran twice more after changing modes assignments then uploaded generated files hope these will help

Updated by Daniel McIlroy over 1 year ago

Version=IH-420V100

this is the version string as well forgot in first post

Updated by Daniel Clemmensen over 1 year ago

Thanks!
I speculate that "IFT-35R" derives from the pre-release internal Yaesu marketing name for the FT-4. I cannot cannot make a guess about
where "IH-420" comes from. (Now to go off and analyze your files...)

Updated by Daniel Clemmensen over 1 year ago

The good news: The keys' locations are exactly where we expected. The bad news: The numbers being stored are simply the FT-65 setmode numbers. This means the list you see in the UI for these keys is incorrect, because it is the FT-4 list. No big problem, but you
should not try to use the UI to program these setmodes until I fix it. It should be OK to play with programming them for memory shortcuts.

Unfortuately this also means we will need to validate all of the setmodes instead of just the sample, to make absolutely sure that this is in fact what it it doing. I would be grateful if you have the time to do this. I just need the diffs, not the full dumps. I felt like I was going to wear out the on/off switch on my FT-4 when I did this, but at least you can do them 4 at a time instead of two at a time. the FT-4 only has P1 and P2, not P3 and P4.

To build the setmode list, I will use the FT-65 Yaesu manual. I have no way to validate that the manual matches the actual FT-65 radio.

Updated by Daniel McIlroy over 1 year ago

ok thats good i can create the list if needed also if u can explain what u mean to build setmode list from the manual i can likely verify that as well if needed do u mean each setting in each mode eg mode 5 beep -> has 'key + sc', 'key', and 'off'

Updated by Daniel McIlroy over 1 year ago

also for the setmode do u need me to do eq p1m1p2m1p3m1p4m1, p1m2p2m2p3m2p4m2 .... or would p1m1p2m2p3m3p4m4, p1m5p2m6p3m7p4m8 .... be ok either way i can do it later tonight or tomorrow morning

Updated by Daniel Clemmensen over 1 year ago

Thanks for doing this work. No, we do not need to have each of the 39 modes on each key. We only need each mode once, so you will need to do ten total diffs.

For cross-validating the names, just look at the Yaesu FT-65 operating manual at the Set (Menu) Mode table starting on page 40 (of the one I'm looking at) and make sure your radio is displaying those identical names for each setmode number. I have the new code ready to go after you validate this.

For the version: please change the print statement in d.py. Use:
print(b"Version=" + repr(version))
or some such so I can see the hex characters. (sorry about that, my bad) There are non-printing characters in there.

Updated by Daniel McIlroy over 1 year ago

Version='IH-420\x00\x00\x00V100\x00\x00'

I checked the set mode to my copy of the manual only one i don't have that was in the manual is 39 SCRAMBLE it doesn't show on my radio in the set mode / function menu

It looks to me like the set mode number is just the mode number in hex in those diffs
hope this is good info for you.

If u need any other testing patched let me know otherwise I'm looking forward to the patched ft4.py for me to test

thanks for all the hard work into getting these radios into chirp

Updated by Daniel McIlroy over 1 year ago

ok i noticed on p1-4m17-20.ft4 more stuff changed in the diff i went back and redid it i think when i was setting the modes i must of changed another setting because when i did it again it only changed the expected stuff in the diff these are the second files

Updated by Daniel Clemmensen over 1 year ago

Thanks a lot! We got the expected result, so my guess was correct and my latest updates are good. Without your work we would never know until someone messed up their radio. I submitted a patch to Dan a few days ago but before my very latest update. I intend to wait until that patch goes in, and then submit the patch for this stuff.

Updated by Daniel Clemmensen over 1 year ago

Colleagues, I need your help with the version string. If you have an FT-65 or FT-4 and you have a Yaesu programming cable for it, and you are sufficiently brave, then please download and run my new tiny little python program to read the version string. The program is named v.py. Run it in a console with a command line that has the serial port name as argument. On Linux (and probably Mac OS) like:

  python v.py /dev/ttyUSB0

On Windows, I'm not sure. Port names might be like com1, but I think they are like COM1:

  python v.py COM1

The program prints one line. I know of no way that this can harm your radio, but I don't have that much experience.
I need multiple people to do this because we simply don't know that all these radios use the same version string. Please report your results here. Provide the version output line and also provide the exact nomenclature for your radio. For example, an FT-4XR is not the same as a FT-4XE,and the version strings may (or may not) be the same. Every report I get will be useful, whether the string is the same or different than the only two I already have.

v.py will run under either Python 2 or Python 3, so the above commands should work no matter how your system is configured, as long as you have any Python installed.

Updated by Daniel McIlroy over 1 year ago

the one that I have is a FT-65R that gives

Version= 'IH-420\x00\x00\x00V100\x00\x00'

I brother has another radio but they were bought at the same time next time I see him I'll see if I can check the version number on it as well.

one other thing if you are new to usb serial ports on linux and get permission errors It is usually fixable by adding your user to the DIALOUT group

eq under Fedora u can run

sudo usermod -a -G dialout $USER

u have to log out and log back in for the changes to take effect

for debian based distros i believe it is differnt

Updated by Ric Sanders over 1 year ago

Daniel Clemmensen wrote:

Colleagues, I need your help with the version string. If you have an FT-65 or FT-4 and you have a Yaesu programming cable for it, and you are sufficiently brave, then please download and run my new tiny little python program to read the version string...

Hello, I have an FT-65R, with an SCU-35 cable and ran the v.py. My version string is the same: Version= 'IH-420\x00\x00\x00V100\x00\x00'

I pulled the latest Chirp down and got it to run and pulled down some test data just to see how it worked. I noticed that the offset column didn't seem to be wired up properly...so I looked over the raw data for each of my channels that I created. Not sure if this is where I should post this, but I would like to contribute, so here we go.

I'm including a LibreOffice file for everyone's perusal.

Thank you everyone who is working on this!

Ric

Updated by Johan Sisno over 1 year ago

Got a new ft-4x. Tried it with the recent app, it works perfectly. The thing is when I program the frequencies and when I upload it to the radio and test the memory it will say ERROR when I press the PTT. Can someone help me? Thank you

Updated by Johan Sisno over 1 year ago

Got a new ft-4x. Tried it with the recent app, it works perfectly. The thing is when I program the frequencies and when I upload it to the radio and test the memory it will say ERROR when I press the PTT. Can someone help me? Thank you

Updated by Daniel Clemmensen over 1 year ago

Johan, if is says ERROR then the software NOT working perfectly. I am am the software developer and (other than you) the only tester so far, but I'm not an experienced Ham. can you please provide more specifics?

If you have the time, please try to configure your radio to the same configuration either using the radio's buttons or using the Yaesu software to see if your desired configuration will work when CHIRP is not used.

Testing is tedious, but if you have the time, you might try this:
1) use the radio's buttons or the Yaesu software to get your radio onto a valid state
2) use CHIRP to save download a save a memory image file in this state.
3) without modifications, upload that same config to the radio.
4) Verify that the radio still works as expected
5) In CHIRP, a small modification to only one channels, one that gave you the ERROR msg
6) upload again
7) see if the ERROR occurs. If so, download the image from the radio and send me both the
last working image and the failing image.
8) if no ERROR occurs, save the image and go back to step 5.

Updated by Johan Sisno over 1 year ago

Found the problem. I loaded the radio using Yaesu's software. the TX frequency is empty. Had to fill in the TX frequencies, now it's working fine :D thanks :D

Updated by Daniel Clemmensen over 1 year ago

Thanks for the report, Johan! I also managed to get my FT-4 to chastise me with the ERROR message. I will ask the main CHIRP developer, Dan Smith, if there is a way for the radio-specific driver to reject a config change and tell the user why. if there is, there is a set of reasonable edit checks I can implement.

What was the value of the DUPLEX field the produced an error when the TX Freq field was missing?

Updated by Daniel Clemmensen over 1 year ago

Rick Sanders: your offset field is apparently encoded in increments of 50,000 Hz. It is supposed to be in increments of 25,000 Hz. I know that the current code computes the radio code by dividing by 25,000 Hz, and computes the code to report to CHIRP for display by multiplying the code by 25,000 Hz. I also know that very early on I had some code that used 50,000 Hz instead, but I do not believe that I ever uploaded that code to the CHIRP repository.

If you have the python code for ft4.py, you can check this.

What do you get when you change a value in CHIRP, then upload to the radio, then download to the Yaesu software?

Updated by radi _ over 1 year ago

Daniel, thanks for a nice work. I want to confirm it also works with FT-4XE (E stands for an European version so I think it would be fine to rename radio in CHIRP just to FT-4X).
It reads and writes changed file OK. Is it possible that you can change the TX/RX frequency range checking routine to include "unlocked" radios with expanded frequency range? This unlocking is simply made by entering some digits combination, as described here: https://simonthewizard.com/2018/07/10/new-yaesu-ft-4x-unlock/

By the way, similar procedure to wideband is also available for FT-65. So the question of frequency edit probably also applies here.

Updated by Daniel Clemmensen over 1 year ago

Hi, Radi, and thanks for the info.
I have not yet really worked on the FT-4XE. My code currently has the restrictions for the US model. Note that you cannot set a step of 6.25, because it is restricted on the US version.

The way CHIRP is structured, I think it's best for me to code a new radio class for each variant set of restrictions. A new class is implemented as a very small added chunk of code in the bottom of the module that subclasses the generic parent class, and I already have two of them: FT-4XR and FT-65R, so adding new classes "should" be straightforward. I was hoping that the Yaesu version string would allow me to autodetect the radio type. What string did you get when you ran my little v.py program on your FT-4XE?, Also, please look at the field in memory that I arbitrarily called "radiotype" with no justification whatsoever. You can see it in the "browser" tab at root->radiotype->notknown[16] .My FT-4 XR shows hex 34,31,32,33,FF,FF..... and as we all know those first four bytes are ASCII 4123, whatever that means.

I think the "unlocked" radio is effectively the "Asian" version. I will ask Dan Smith how we should handle it and the FT-4XE.

Updated by radi _ over 1 year ago

Daniel: while speaking of "unlocked" frequency range, I meant not the frequency tune step, but just a value for "Frequency" field in CHIRP.
Quick example: let's try to enter e.g. marine distress channel frequency /or any other in this range/ - it says it's out of supported range.
As in the attached screenshot. So I guess there is a some kind of frequency range check routine in effect.

Updated by radi _ over 1 year ago

I'm also aware that in case of FT-4X without this modification, it should not be permitted to enter frequency outside the standard TX/RX range for this model.
So perhaps in case of "unlocked" radio, there should be some checkbox in settings, like "check this to allow edit extended frequency range on frequency unlocked
radio" then entering "wideband" frequencies will be permitted.

Updated by radi _ over 1 year ago

Daniel: radiotype/notknown shows probably the same data, it starts with the same Hex values like yours.

Updated by Daniel Clemmensen over 1 year ago

  • Due date set to 03/14/2019
  • Assignee set to Daniel Clemmensen
  • % Done changed from 0 to 90
  • Estimated time set to 1.00

Well, it took more than 3 months, but FT-65 support is now going into the daily build. I will close this bug once it is in the build, so I ask that if you find bugs (they have to be there!) you start new issues or add to the appropriate open issue. We just had a BIG bug reported: see #6601. This is the same problem that Johan reported here and that I thought I had reproduced and fixed, but no.

Updated by Dan Smith over 1 year ago

Dan, do you want to mark either of these radios as Experimental? That will let you throw up a warning to the user (of your own wording) when they first go to clone. If nothing else, just encouraging people to scrutinize the behavior and potentially direct them to be more likely to file bugs for things they see. It's your call, but it seems like it might be a reasonable idea given that bug that was just reported pretty early in the lifecycle of this. We can remove it in a couple months or whatever you want once we have more confidence.

Updated by Daniel Clemmensen over 1 year ago

They are both already marked as experimental. They throw a message on both download and upload. The message is thrown by their shared parent class. I put it there before we released the FT4. I suspect we will get more activity now, because the FT-65 appears to be more widely used than the FT-4.

One minor problem: that "experimental" message comes before the "continue" message (with my instructions) on the download, so the instructions make sense. It comes AFTER the "continue?" on the upload, and the instructions dopn't quite make sense.

I'm guessing that this driver may have more bugs than a typical new driver, because the radios are quite complicated and because the main tester (me) is a new Ham who barely understands how it's supposed to work when it's working correctly.

Updated by Dan Smith over 1 year ago

Ah, you're right, sorry. I had been looking at/around the recent changes to the subclasses and wasn't thinking :)

Updated by Daniel Clemmensen over 1 year ago

  • Status changed from New to Closed
  • % Done changed from 90 to 100

It's now in the daily build, so closing this bug. Please report any issues in new bugs as appropriate.

Also available in: Atom PDF

prevent spam