<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Yes, the information below is on Chirp's behavior.&nbsp;</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.&nbsp;&nbsp; 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.&nbsp; 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?&nbsp; 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.&nbsp; I don't have a logic analyzer.&nbsp; I think I have a com port monitor on my XP notebook.....wonder what that would do?&nbsp; I know I haven't found anything that works on this Winders 7 64 bit machine.&nbsp; </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.&nbsp; With the processor in the radio being pretty busy, I expect there is some time between blocks for housekeeping.&nbsp;</p>
<p>Is the PC version written in Python?&nbsp; I noticed I had to load the runtime for the Mac version.</p>
<p>Regards,</p>
<p>Bob - N4RFC</p>
<p>&nbsp;</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"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>On Wed, Apr 27, 2016 at 12:04 PM,  &lt;<a href="mailto:bob@n4rfc.com">bob@n4rfc.com</a>&gt; 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>&nbsp;</p>
<div>&nbsp;</div>
</body></html>