[chirp_users] Can't Write to Yaesu FT-06
I have the same problem with writing to a Yaesu FT-60 handheld. I can download from the FT-60, but when I write I get a "Failed to communicate with radio: Radio is not responding" error.
I have checked the issues page and see there was a issue with writing to the FT-60 that was deemed closed after reloading drivers for the Prolific Chipset. My USB/RS-323 interface is a FTDI. The interface is a homebrew RS-232 to TTL level shifter that works, with a different cable, just fine to read and write to my FT-8900R.
I suspect there is some timing differences between the two radios.
The computer is a Winders 7 - 64 bit 3gHz I3 Processor with 8 gB ram. I am running the latest download of Chrip (4/19/16).
Is there any logging going on in Chrip that I can enable and look at?
Regards,
Bob - N4RFC
On Tue, Apr 26, 2016 at 10:37 AM, bob@n4rfc.com wrote:
I have the same problem with writing to a Yaesu FT-60 handheld. I can download from the FT-60, but when I write I get a "Failed to communicate with radio: Radio is not responding" error.
I have checked the issues page and see there was a issue with writing to the FT-60 that was deemed closed after reloading drivers for the Prolific Chipset. My USB/RS-323 interface is a FTDI. The interface is a homebrew RS-232 to TTL level shifter that works, with a different cable, just fine to read and write to my FT-8900R.
I suspect there is some timing differences between the two radios.
The computer is a Winders 7 - 64 bit 3gHz I3 Processor with 8 gB ram. I am running the latest download of Chrip (4/19/16).
Is there any logging going on in Chrip that I can enable and look at?
There is a log. Details here: http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues#Getting-...
But I suspect it won't tell you much more than you already know.
If you were me, I might try watching the signals on a digital oscilloscope / logic analyzer to see if the radio truly is not responding. You could then proceed with the timing hypothesis.
One thing you might check with your homebrew cable is that loopback is working. Chirp expects the serial tx/rx lines on Yaesu cables to be tied together, so you should see everything you type into a serial console echoed back. Chirp knows this and will read as many bytes as it writes to clear the buffer before looking for a response from the radio. If your cable isn't echoing, it will clear the response from the buffer without looking for it!
Tom KD7LXL
Tom,
Thanks for the input. I will check the log to see if their is anything interesting in there.
The interface definitely loops back, hardwired at the cable going to the radio. (Schematic Attached) I opened PUTTY (terminal) and it loops back just fine.
I was thinking there could be something different on this radio vs the FT-8900 that is causing one of the signals from the interface to be pulled down (or up) and I will check that too.
However, I loaded a copy of the FTB60 program from G4HFQ, imported a CSV file from the 8900 and the FTB60 program wrote the FT-60 first try. So, I think the levels are probably good between the radio and the interface. I will look at them on the O-Scope just to make sure.
I have achieved my goal, to have the FT-8900R and the FT-60 with the same channel setup, but I am $15 lighter than I was this morning when I started this project!
Thanks,
Bob N4RFC
On 2016-04-26 19:06, Tom Hayward wrote:
On Tue, Apr 26, 2016 at 10:37 AM, bob@n4rfc.com wrote:
I have the same problem with writing to a Yaesu FT-60 handheld. I can download from the FT-60, but when I write I get a "Failed to communicate with radio: Radio is not responding" error. I have checked the issues page and see there was a issue with writing to the FT-60 that was deemed closed after reloading drivers for the Prolific Chipset. My USB/RS-323 interface is a FTDI. The interface is a homebrew RS-232 to TTL level shifter that works, with a different cable, just fine to read and write to my FT-8900R. I suspect there is some timing differences between the two radios. The computer is a Winders 7 - 64 bit 3gHz I3 Processor with 8 gB ram. I am running the latest download of Chrip (4/19/16). Is there any logging going on in Chrip that I can enable and look at?
There is a log. Details here: http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues#Getting-... [1]
But I suspect it won't tell you much more than you already know.
If you were me, I might try watching the signals on a digital oscilloscope / logic analyzer to see if the radio truly is not responding. You could then proceed with the timing hypothesis.
One thing you might check with your homebrew cable is that loopback is working. Chirp expects the serial tx/rx lines on Yaesu cables to be tied together, so you should see everything you type into a serial console echoed back. Chirp knows this and will read as many bytes as it writes to clear the buffer before looking for a response from the radio. If your cable isn't echoing, it will clear the response from the buffer without looking for it!
Tom KD7LXL _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users [2] This message was sent to Bob N4RFC at bob@n4rfc.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
Links: ------ [1] http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues#Getting-... [2] http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Tue, Apr 26, 2016 at 1:20 PM, bob@n4rfc.com wrote:
However, I loaded a copy of the FTB60 program from G4HFQ, imported a CSV file from the 8900 and the FTB60 program wrote the FT-60 first try. So, I think the levels are probably good between the radio and the interface. I will look at them on the O-Scope just to make sure.
That is pretty definitive, and I don't know that the o-scope will tell you anything more at this point. It might be interesting to compare a serial data capture from Chirp and FTB60 to see if there is a significant difference that could explain the problem with Chirp. I don't know how to help you with the serial capture -- I have only used portmon on 32-bit Windows. I hear it's incompatible with 64-bit varieties.
Tom KD7LXL
Here is what I found....probably not helpful, but data points at any rate.
Connected to the FT-60, on download I see RTS/CTS (connected together) go high, that is important as it powers my interface. Then a good stream of data as it is downloaded.
On upload, I see RTS/CTS go high, then one short data burst, maybe a couple of characters, then the error pops up and data stops and RTS/CTS goes low.
I did one other thing, I loaded the program on my Macbook Air. I got the same results, I can read the FT-60 but not write it. I can read and write the FT-8900 on the Macbook same as on the PC.
It could be the Chirp software, or it could be hardware. But, as far as the hardware, it doesn't make sense that the FTB60 will work ok.
Suggestions anyone?
Bob -N4RFC
On 2016-04-26 21:24, Tom Hayward wrote:
On Tue, Apr 26, 2016 at 1:20 PM, bob@n4rfc.com wrote:
However, I loaded a copy of the FTB60 program from G4HFQ, imported a CSV file from the 8900 and the FTB60 program wrote the FT-60 first try. So, I think the levels are probably good between the radio and the interface. I will look at them on the O-Scope just to make sure.
That is pretty definitive, and I don't know that the o-scope will tell you anything more at this point. It might be interesting to compare a serial data capture from Chirp and FTB60 to see if there is a significant difference that could explain the problem with Chirp. I don't know how to help you with the serial capture -- I have only used portmon on 32-bit Windows. I hear it's incompatible with 64-bit varieties.
Tom KD7LXL
On Wed, Apr 27, 2016 at 12:04 PM, bob@n4rfc.com wrote:
Here is what I found....probably not helpful, but data points at any rate.
Connected to the FT-60, on download I see RTS/CTS (connected together) go high, that is important as it powers my interface. Then a good stream of data as it is downloaded.
On upload, I see RTS/CTS go high, then one short data burst, maybe a couple of characters, then the error pops up and data stops and RTS/CTS goes low.
I did one other thing, I loaded the program on my Macbook Air. I got the same results, I can read the FT-60 but not write it. I can read and write the FT-8900 on the Macbook same as on the PC.
It could be the Chirp software, or it could be hardware. But, as far as the hardware, it doesn't make sense that the FTB60 will work ok.
Suggestions anyone?
Bob -N4RFC
I'm guessing this is the behavior you observed from Chirp. What could be really helpful in identifying the problem is to also observe the behavior of FTB60 and report any differences to Chirp. Since your outcomes are different with each software, they must be doing something different. If the difference is identified, we could tweak Chirp to work more like FTB60.
Tom
Yes, the information below is on Chirp's behavior.
I guess what I would be looking for is the timing between the first characters sent by the PC to the radio and look for a reply coming back from the radio. I thinking I can monitor and trigger the scope on the TX data line from the RS-232 port and watch for gaps when there is RX data and NO TX Data. Since it is an upload, the PC is going to being most of the talking.....can you give me an idea of how often the radio "acks" back to the PC? Is the data in blocks, or is it just one big long string of bytes? From looking this morning it is a "blink and you missed it" sort of thing. I don't have a logic analyzer. I think I have a com port monitor on my XP notebook.....wonder what that would do? I know I haven't found anything that works on this Winders 7 64 bit machine.
I would assume that the PC sends a start block and expects a return from the radio in a timely fashion some sort of ACK to say send more data. With the processor in the radio being pretty busy, I expect there is some time between blocks for housekeeping.
Is the PC version written in Python? I noticed I had to load the runtime for the Mac version.
Regards,
Bob - N4RFC
On 2016-04-27 21:11, Tom Hayward wrote:
On Wed, Apr 27, 2016 at 12:04 PM, bob@n4rfc.com wrote:
Here is what I found....probably not helpful, but data points at any rate. Connected to the FT-60, on download I see RTS/CTS (connected together) go high, that is important as it powers my interface. Then a good stream of data as it is downloaded. On upload, I see RTS/CTS go high, then one short data burst, maybe a couple of characters, then the error pops up and data stops and RTS/CTS goes low. I did one other thing, I loaded the program on my Macbook Air. I got the same results, I can read the FT-60 but not write it. I can read and write the FT-8900 on the Macbook same as on the PC. It could be the Chirp software, or it could be hardware. But, as far as the hardware, it doesn't make sense that the FTB60 will work ok. Suggestions anyone? Bob -N4RFC
I'm guessing this is the behavior you observed from Chirp. What could be really helpful in identifying the problem is to also observe the behavior of FTB60 and report any differences to Chirp. Since your outcomes are different with each software, they must be doing something different. If the difference is identified, we could tweak Chirp to work more like FTB60.
Tom
I don't recall the exact exchange with the Yaesu. I think it's basically one big dump with ACK bytes every 64 bytes. In any case, the issue you see with Chirp happens almost instantly (right?), so you can bet the difference between Chirp and FTB60 will be in the first few bytes exchanged. You may or may not be able to see this difference on the 'scope.
Since you've already confirmed the low-level signaling works with your cable (by successfully using FTB60), the 'scope is no longer necessary. I would use portmon to capture the serial data from the computer. This will show hex bytes for data in and out of the serial port as well as the time it occurred. I think this utility only runs in 32-bit Windows, so you may or may not have the ability to run it.
All versions of Chirp run the same codebase, in Python. You can see the code for the FT-60 here: http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft6...
If you've ever done any programming, I think you'll find Python is pretty easy to read regardless of your familiarity of the language.
Tom
On Wed, Apr 27, 2016 at 4:16 PM, bob@n4rfc.com wrote:
Yes, the information below is on Chirp's behavior.
I guess what I would be looking for is the timing between the first characters sent by the PC to the radio and look for a reply coming back from the radio. I thinking I can monitor and trigger the scope on the TX data line from the RS-232 port and watch for gaps when there is RX data and NO TX Data. Since it is an upload, the PC is going to being most of the talking.....can you give me an idea of how often the radio "acks" back to the PC? Is the data in blocks, or is it just one big long string of bytes? From looking this morning it is a "blink and you missed it" sort of thing. I don't have a logic analyzer. I think I have a com port monitor on my XP notebook.....wonder what that would do? I know I haven't found anything that works on this Winders 7 64 bit machine.
I would assume that the PC sends a start block and expects a return from the radio in a timely fashion some sort of ACK to say send more data. With the processor in the radio being pretty busy, I expect there is some time between blocks for housekeeping.
Is the PC version written in Python? I noticed I had to load the runtime for the Mac version.
Regards,
Bob - N4RFC
On 2016-04-27 21:11, Tom Hayward wrote:
On Wed, Apr 27, 2016 at 12:04 PM, bob@n4rfc.com wrote:
Here is what I found....probably not helpful, but data points at any rate. Connected to the FT-60, on download I see RTS/CTS (connected together) go high, that is important as it powers my interface. Then a good stream of data as it is downloaded. On upload, I see RTS/CTS go high, then one short data burst, maybe a couple of characters, then the error pops up and data stops and RTS/CTS goes low. I did one other thing, I loaded the program on my Macbook Air. I got the same results, I can read the FT-60 but not write it. I can read and write the FT-8900 on the Macbook same as on the PC. It could be the Chirp software, or it could be hardware. But, as far as the hardware, it doesn't make sense that the FTB60 will work ok. Suggestions anyone? Bob -N4RFC
I'm guessing this is the behavior you observed from Chirp. What could be really helpful in identifying the problem is to also observe the behavior of FTB60 and report any differences to Chirp. Since your outcomes are different with each software, they must be doing something different. If the difference is identified, we could tweak Chirp to work more like FTB60.
Tom
participants (2)
-
bob＠n4rfc.com -
Tom Hayward