Re: [Hamlib-developer] FT747GX timeout problem - (disgusting) workaround

[Chris B. <ry...@cr...>]

Thanks for the lightning response Stephane!

On Sunday 28 Mar 2010, Stephane Fillod wrote:
> 
> I can't remember Chris whether you said what was the snooped block length
> when using MixW.

I can't find a way of counting the bytes on the wire. The storage scope doesn't 
have enough resolution/memory. Btw with MixW  the 747 is quite stable being 
polled at ~2 second intervals, unlike my brief try with gpredict and rigctld


> 
> On top of Mark's suggestions for unexpected protocol, it can also be
> due to a non-standard firmware. It can be the systematic pacing command
> right before the status report which confuses the rig.
> That's why I moved the pacing command into ft747_open() in my patch
> yesterday, which is then done once for all.
> In that patch, the write_delay has been changed from 50 ms to 5 ms.
> Is it the most appropriate value?

5mS works fine for me

I've sent some info off to the other 747 owner I know, so he can try it out. I 
think he said his has not CAT icon on teh display, so there are different 
versions of the 747 out there.

> 
> This is what I did in ft747_get_update_data(): read_block() of 344 bytes
> with normal timeout, then read_block() of 1 additional byte with a 100 ms
> timeout and doesn't make whole transaction to fail if that byte is missing
> 
> Now, giving it more thought, I'm worried by the 790 ms latency. What
> about reading only the first 23 bytes (rest is memory content), hence
> shortening latency, but before sending the Update opcode, doing
> a serial flush? The serial flush should take care of dropping the unread
> mem status from a previous request. What do you think about it?

This would be neat as it'd reduce the delay in getting a single frequency. 
However one would have to take care not to ask the 747 to do anything while 
it's sending the remainder of the block as my expereince is that it will most 
likely ignore the command.


I've just tried to build the 28March SVN that I got from Nate's auto link. It 
fails in the ./configure as shown...

Checking for a Python interpreter with version >= 1.5... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.5/site-packages
checking for python extension module directory... 
${exec_prefix}/lib/python2.5/site-packages
checking for Python include path... find: `/usr/include/python/': No such file 
or directory
find: `/usr/lib/mozilla/extensions': Permission denied

then it hung and I had to ^c to get out. Am I doing something wrong? 1.2.10 
from sourceforge built ok.

Chris g3wie