<div dir="ltr">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.<div><br></div><div>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.<div><div><br></div><div>All versions of Chirp run the same codebase, in Python. You can see the code for the FT-60 here:</div></div></div><div><a href="http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft60.py">http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/drivers/ft60.py</a><br></div><div><br></div><div>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.</div><div><br></div><div>Tom</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 27, 2016 at 4:16 PM, <span dir="ltr"><<a href="mailto:bob@n4rfc.com" target="_blank">bob@n4rfc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>Yes, the information below is on Chirp's behavior. </p>
<p>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. </p>
<p>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. </p>
<p>Is the PC version written in Python? I noticed I had to load the runtime for the Mac version.</p>
<p>Regards,</p>
<p>Bob - N4RFC</p><div><div class="h5">
<p> </p>
<p>On 2016-04-27 21:11, Tom Hayward wrote:</p>
<blockquote type="cite" style="padding-left:5px;border-left:#1010ff 2px solid;margin-left:5px">
<pre>On Wed, Apr 27, 2016 at 12:04 PM, <<a href="mailto:bob@n4rfc.com" target="_blank">bob@n4rfc.com</a>> wrote:</pre>
<blockquote type="cite" style="padding-left:5px;border-left:#1010ff 2px solid;margin-left:5px">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</blockquote>
<pre>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
</pre>
</blockquote>
<p> </p>
<div> </div>
</div></div></div>
</blockquote></div><br></div>