Re: [Hamlib-developer] FT747GX timeout problem - solved?

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

On Monday 29 Mar 2010, Stephane Fillod wrote:
>
> > Ok Stephane, that fixed it, thanks. I'm using debian unstable here, to be
> > sure
> 
> Thanks for confirming the libltdl-dev issue. On a side note, that means we
>  have to fix that problem before thinking of releasing hamlib 1.2.11.
Btw I didn't have that probelm building 1.2.10 from source (d/l from the 
sourceforge d/l page)

> 
> Indeed, but unstable versions needs courageous beta-testers for the good
> of everybody. It's very true for Hamlib also.
Think I'm running out of courage at the distribution level. I run kde4.3.4 and  
bits of it crash regularly, plus some important applications (kmail) ported up 
from 3.5.x have lost functionality..... Happy to help out in some small way  
with hamlib - much closer to what I'm trying to achieve.

> 
> 
> If you're into some more testing today, download the monday snapshot,
> it has been improved with:
> - cached update data
> - passband width in get_mode
> - added set_mem/get_mem
> - various fixes and cleanup
> 

I gave it a try, Stephane. First I got the permission denied error again. This 
time, while I was checking what the permissions really are on the stated 
directory, the ./configure script started running again (after about 30 seconds 
- I didn't wait that long last time)!

....
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                                      

[paused here for 30 seconds]

configure: WARNING: cannot find Python include path
checking whether to build python binding and demo... 
.......

Anyway the directory was accessible only by root, so I gave everyone read 
access and tried again with a clean un-gzipped. It all built with no error. 
Guess that must have been (another) funny in my system .....

Some tests:

1) on starting, rigctl runs ok and manages timeout on the 345th char ok
2) m reports passband correctly when in CW and AM & changed from std to narrow 
(only supported in these 2 modes)
3) set/get memory works ok

4) Is there a problem with reading the VFO? I set the dial to 14061.25 and 
send f. The reported frequency is 140761.000000Hz which comes from bytes 1 ..5  
in the status block below (ignoring the 25 Hz which the 747 can't display as 
it onhly has one digit after the decimal point). Running grig gives a dial 
frequency 140.761 kHz.

Rig command: f
ft747:ft747_get_freq called
rig_check_cache_timeout: cache timed out (81317 ms)
TX 5 bytes
0000     00 00 00 00 10 .....
RX 344 bytes
0000     08 00 14 07 61 25 25 00 00 07 00 40 00 04 00 08        ....a%%....@..
0010     00 14 07 61 25 04 00 01 04 10 00 10 00 00 00 10        ...a%.........
0020     00 10 00 07 00 10 00 04 00 10 00 07 00 20 25 04        ............. 
0030     00 10 00 07 00 30 25 04 00 10 00 10 00 00 00 10        .....0%.......
0040     00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10        ..............
0050     00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10        ..............
0060     00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10        ..............
0070     00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10        ..............
0080     00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10        ..............
0090     00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10        ..............
00a0     00 10 00 10 00 00 00 30 00 10 00 10 00 00 00 10        .......0......
00b0     00 10 00 10 00 00 00 10 00 00 00 00 00 00 00 00        ..............
00c0     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
00d0     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
00e0     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
00f0     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
0100     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
0110     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
0120     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
0130     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
0140     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00        ..............
0150     00 00 00 00 00 00 00 00                                ........

read_block: timedout after 0 chars
ft747:  freq = 140761.000000 Hz  for VFO = 536870912
Frequency: 140761


5) I ran rigctld then gpredict. This time, I see no sign of the instability 
and lockup/display blanking of the 747 that caused my heart some trouble last 
time. I set gpredict up to track AO-51's S-band downlink where the doppler got 
to ~22Hz per second (not quite 25 like I wanted) to force lots of frequency 
changes on the 747 as it is being polled. Again I do not see any lockups in my 
40 minutes of running. The frequencies shown are all correct, but I suspect 
that gpredict shows the frequencies it calculates, not what it reads from the 
radio

This is looking good :-)   thanks for your work

Chris g3wie