CHIRP

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

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.

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?)".

I can loan a radio and programming cable.

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!

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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

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.

#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.

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

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.

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.

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.

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.

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.

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.

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).

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, , Raaall, and END. The radio responds to a command by first repeating it back, then adding any data, then sending the ASCII (0x06) byte. The response to PROGRAM is PROGRAMQX. This is the first command/reaponse of the session. The is a single byte with value 0x02, and the response from my radio is
024946542d333552000056313030000006
Which as you see starts with the and ends with the . In ASCII, this is
IFT-35R<0><0>V100<0><0>
whatever that is supposed to mean.

The response to END is END. This is the last command of the session. After the 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 . 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 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?

The byte prior to the 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.

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!

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.

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.

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!

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.

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.

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.

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

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

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.

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.

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?

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

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.

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.

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.

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

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

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.

Version=IH-420V100

this is the version string as well forgot in first post

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...)

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.

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'

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

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.

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.

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

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

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

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.

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

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?

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?

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.

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.

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.

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

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.

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.

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