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

[Mark P. <n1...@ar...>]

Hi Nate.

 > Note also that in column 1 at the bottom of page 26 it mentions "767"
 > as the model as well.  Oops!

Curious.  I just found and downloaded the FT-767 manual:

     <http://www.foxtango.kc9foz.com/Eighties/FT-767GX.pdf>

and it doesn't have anything remotely like the 3xx bytes Chris is seeing.
(Chris, please feel free to call me Mark :-)  It can have 5, 8, 26 or 86
bytes.  Just to be different :-P

Chris, if you sent the rig bytes it didn't know how to handle, it might
very well cause the rig to get into a strange state.  Given the FT-847
is from the late 1980's early 1990's time frame, I would not expect the
code in the rig to be completely bullet-proof.  In other words, there was
the unwritten expectation the programmer wouldn't do anything other than
what was set out in the manual.  (As any software engineer will tell you,
this is a bad assumption.  Been there, done that :-)

I expect what I'd attempt to do is:
    1)   Start off with the original software (345 instead of 344 buffer
         for FT747_STATUS_UPDATE_DATA_LENGTH)
    2)   Modify the ft747_get_update_data() function to fill the return
         buffer (p->update_data) with a known pattern prior to the call
         to read_block() to get the data.
    3)   Then look at p->update_data to see what it contained.  This will
         most likely give you an idea as to how much data is being sent
         back.

The other possibility which just occurred to me is there could be a
difference in timing with the data stream sent by the rig.  If it only
sent 344 bytes, and then for some strange reason "waited" before sending
the 345th byte I could see all manner of strange things happening.

Just more random neurons firing :-P

73

- Mark  N1VQW