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

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

On Saturday 27 Mar 2010, Nate Bargmann wrote:
> * On 2010 27 Mar 12:20 -0500, Chris Bryant wrote:
> > Take this perhaps as another step of debugging rather than any kind of
> > fix
> >
> > On the basis that the last few bytes in the status return are undefined,
> > they can't be used for anything.
> >
> > So I downloaded the source of 1.2.10 (which I don't pretend to understand
> > to any degree as my software skills are 20+ years old and I never did do
> > any C). I looked around a bit to find were the get status command was
> > issued in ft747.c, observed the parameter for the no. of characrers
> > expected and edited the file ft747.h to change
> >
> > #define FT747_STATUS_UPDATE_DATA_LENGTH      345
> >
> > to
> >
> > #define FT747_STATUS_UPDATE_DATA_LENGTH      344
> >
> > in an attempt to fool hamlib. Then recompiled and ran ldconfig.
> >
> > rigctl now runs without a timeout error message and F, M, T commands
> > work. Clearly I should expect a buffer overflow somewhere as I suspect
> > the rig really is sending 345 characters and I don't know where the
> > buffer space is defined/allocated.
> 
> Interesting sleuth work, Chris.  Do you have a copy of the 747 manual?
> What does it say?  Note that I've found errors in the manuals!
> 
> If, in fact, the rig is putting 345 bytes on the wire then you should
> see a slow corruption of returned data.  Actually, not so slow as
> everything will be off by one on the next read.  As for the buffer, it
> is defined at line 136 of ft747.c and is used by the read_block
> function called at line 763.  In my experience, if the read_block
> function is called with a smaller count than what the rig actually puts
> on the wire, the remainder will just "sit on the wire" until the next
> status command is sent.
> 
> If your tests reveal no data corruption and the data reads are
> consistent, then we can patch ft747.h in SVN to correct this bug.
> 
> 73, de Nate >>
> 

Yes, I have the user manual which is the only data I've ever found on the 747 
CAT. The service manual just covers hardware. The user manual clearly specifies 
inter-byte spacing of 50 - 200 mSec and I wonder if a decimal point got lost 
somewhere and they meant to say 5 - 20. It also clearly specifies 345 bytes of 
status data are returned in response to the 00 00 00 00 10 command, so that 
could be wrong as well. But has no-one else spotted this before? It's 
immediately obvious if you try rigctl.

I built my 232-TTL converter with a monitor port and if I set it to watch the 
data returned by the 747, and connect it to a separate linux pc running 
cutecom as recommended by K9AO, then I repeatably see 344 (0157h) bytes 
returned in response to the  get-status command. Also, I don't see any sign of 
data corruption due to a byte left on the wire/in a buffer somewhere.

Now I have a test setup confirmed, I will send details to another UK ham who 
has a 747 (and pointed me at MixW in the first place). He is not a linux 
person, so I could send him a live CD of Ubuntu with instructions on 
installing hamlib + utilities from the debian repository and see if he gets 
the timeout at 344 characters. 

After sending my previous posts, I thought "what the heck" and fired up 
gpredict to see if it would talk to my butchered version of hamlib. As it 
happened, AO-7 was in view at the time so the doppler calculations etc were 
entirely valid. gpredict seemed to be able to talk to hamlib ok, but I saw 
occasional glitches where rigctld was reporting a timeout (0 bytes) and the 
747 threw a complete wobbly - the frequency readout blanked, a relay clicked 
inside and the S meter read S9+20. The only way to exit this condition was to 
move the tuning dial - it even persisted through a power-cycle which had me in 
a bit of a panic. I put this down to an unintended consequence of my ill-
informed mod to hamlib - am I right, or is this something to talk to oz9aec 
about?

I've just seen tthe post from N1VQW - great minds think alike! As per my 
previous post, the first byte is ok; it's not possible to make the last byte 
change as it's reserved and undefined. 

Now I've swapped PCs and if I drive the 747 from MixW and watch the returned 
status data with cutecom, again I'm pretty sure I see 344 (0157h) bytes 
returned, though this is harder to catch as MixW polls at about 2 second 
intervals, and I have to stop the capture at the right place.

So it all looks pretty conclusive that my 747 sends 344 bytes not 345. Again I 
hestitate to state this is definitive behaviour as surely someone else would 
have seen it. I'll try and check with the other 747 user...

Chris g3wie