[chirp_users] Can't Write to Yaesu FT-06

[Tom Hayward]

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/ft60.py

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 at 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 at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20160427/c343cbeb/attachment.html