CHIRP

Here is the Python traceback...

Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/chirp-next_20230104-py3.11.egg/chirp/wxui/clone.py", line 60, in run
self._fn()
File "/usr/local/lib/python3.11/site-packages/chirp-next_20230104-py3.11.egg/chirp/drivers/ft60.py", line 418, in sync_out
raise errors.RadioError("Failed to communicate with radio: %s" % e)
chirp.errors.RadioError: Failed to communicate with radio: Radio did not respond
WARNING: Stopping clone thread

Just to be clear: you tried next and legacy and both behave the same right? That's good news for the next effort :)

So I haven't laid hands on an FT-60 in years, but when I did, it was extremely temperamental with respect to the cloning cable. I don't remember the details, but there was definitely some stuff related to not being able to upload without putting pressure on the connector. Like, I would have to hold pressure on the connector to one side or the other while initiating the clone in order for it to go. It was extremely frustrating, especially since yaesus require you to initiate the clone from the radio, making it at least a two-handed task.

Has this ever worked for you?

Yes, both next and legacy exhibit the same behavior.

I have not ever done anything physically with the connector. I have, however, been able to successfully upload to the radio using FT-60 Commander. Commander was a bit fussy with it too, though. I seem to recall that it had a menu option that was something like “Alternate Upload Config” that was needed to make it upload to the radio correctly.

I originally had a Prolific cable, and I got a FTDI cable specifically based on recommendations from the chirp community. Maybe I need to try yet another one.

Ah, interesting. Is your FT60 MARS modded?

FWIW, I don't think you need another adapter - FTDI should be the gold standard. It's the connector on the FT60 that was the problem for me and I've heard a number of people having the same experience I did.

It is not modded.

I’ll fiddle with the connector to see if that does anything.

I wasn't able to get it to work with any physical fiddling with the connector. I feel like FT-60 Commander would have issues too if some kind of physical connectivity issue was an issue. I was able to look in Commander, and the menu setting I had to enable was "Use Alternate Write Mode". I have looked all over online, and I can not find what that setting actually does. What I DID find in my searching was a lot of forum posts about people with the exact same issue with chirp and the FT-60...reads fine, won't write. Unfortunately, Commander appears to be abandonware, and I can not find the source code anywhere to see what this magical Alternate Write Mode does.

I keep thinking this is some kind of flow control problem...or perhaps something with the DSR or DTR signals that are preventing writing.

I went ahead and ordered a BlueMax49ers cable. We'll see if it makes any difference.

Okay, maybe there's something we're missing, perhaps a newer firmware version of the FT60 that requires the alternate mode or something. Yesterday I tried grabbing a trace of the first block it sends and it's identical regardless of that flag, so it must be something it does after that. Without an FT60 locally I can't get it to go further. Someone with serial tracing ability and an ft60 should be able to discern what the difference is and then we could apply a fix.

I also played around with this little tool: https://github.com/sergev/yaesutool

I had to make some edits to get it to build right, but once I did, it did the same thing as chirp...it gets no ACK from the radio when trying to write. Read is fine.

Obviously, I have the radio. What is needed to constitute a "serial tracing ability"? I do a fair bit of Python coding myself (although not at your level), and I'd love to help figure out what is going on with this. All I have been able to determine so far is that nothing comes back from the radio after sending those initial 8 bytes. The ack variable in _upload is an empty byte string after the read(1).

Also, where did you get the info on how exactly to program the FT-60? i.e. What the radio expects to see when it's in clone mode. I have Googled 10 different things, and I can't find anything.

Can you confirm that FT-60 commander works with the "alternate" method and does not work otherwise? If so, I can maybe work on an emulator to fool it into talking to me to try to figure out what the difference is. I think you said you recalled that, but I just want to confirm before I go down that rabbit hole.

Confirmed it does not work without Alternate Write Mode enabled. It fails with "No response from radio".

Interestingly, I just noticed that the instructions are slightly different when Alternate mode is enabled. When it is enabled, the instructions say to first command the radio to TX in clone mode, which leads to an Error...THEN press the Moni button to put the radio into RX mode. That seems odd to me, but I confirmed that when Alternate mode is NOT enabled, the instructions just have you put the radio directly into RX without having it first try to TX. Even taking the step of putting the radio in TX first, then RX does not make writing work in Commander, so the Alternate write mode is doing something differently in the software.

I tried this with chirp (going to TX, then RX), but it didn't work.

I also did a byte dump (od -b in Linux) on the image files from chirp and from Commander. The first 8 bytes are identical.

I applied the patch, but I still get no response from the radio. ack is still empty.

Okay, bummer.

So I built the simulator last night and can fool FT60 Commander into uploading to it. The bytes written to the radio do not differ in any way with normal/alt. Trying to suss out some timing differences, it seems like maybe there is some difference in the inter-char timing, but it's hard to say for sure. The write-char-read-echo was an attempt to slow it down a little bit. We could try a little slower if you want.

Just put a time.sleep(0.005) after pipe.write() in that _send() function and maybe try some different values up to maybe 0.020.

The way the timing looks, it almost seems like it writes the first byte of any string, then waits a tiny bit, and then sends all the rest. So something like:

pipe.write(data[:1])
time.sleep(0.005)
pipe.write(data[1:])

The way I'm doing my capture it's hard to see precise timing though.

Unfortunately yaesu radios are incredibly fragile and temperamental like this, and I've all but sworn off spending time (and certainly money) on them. As you can see from the code, we're just sending it eight bytes and expecting one. There's really not too many ways to mess that up :)

Not having any luck. I tried your suggestion, using varying lengths of sleep(). I also tried setting serial.inter_byte_timeout to some varying lengths from about 0.005s to 0.02s, and none of it made any difference.

My BlueMax49ers cable is supposed to be here today. I'm not optimistic that it'll have any effect, but we'll see.

Well...that'll teach me to be pessimistic.

The BlueMax49ers cable works. I'm not sure where my serial cable came from that I was using. I've had the FT-60 for a long time. The entire chain consists of the USB-Serial (DB9) adapter, a DB9 to 3.5mm 3-conductor plug and then a 3.5mm 3-pin to 4-pin adapter. Why Commander could work with that mess and not Chirp is a mystery, but I am thrilled to finally be able to use Chirp 100%!

As far as I'm concerned, this issue can be closed as a cable problem.

LOL…I almost didn’t believe it myself. Every time I thought, “Maybe it’s X” I would come back to Commander and think “If it was X, Commander wouldn’t work either.” I would love to know what that Alternate Write Mode is actually doing, but it appears that we may never know.

IMO, the safe answer for any FT-60 owner is get either a BlueMax or an RT Systems cable.

Thanks for all of your effort on this!