Thread: [Hamlib-developer] FT747GX timeout problem - (disgusting) workaround
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Chris B. <ry...@cr...> - 2010-03-27 17:17:56
|
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. hth Chris g3wie |
|
From: Nate B. <n0...@n0...> - 2010-03-27 18:45:44
|
* 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 >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html |
|
From: Nate B. <n0...@n0...> - 2010-03-27 20:31:08
|
* On 2010 27 Mar 14:28 -0500, Mark Pilant wrote: > I managed to locate a copy of the manual online: > > <http://hamradio.lakki.iki.fi/new/Documents/Manuals/Yaesu/base&portable/Yaesu%20FT-747GX%20users%20manual.pdf> Thanks for that. Added to my collection. > Starting on page 26 at the CAT commands. On page 27, Reading Transceiver > Status, it does indeed say 345 bytes should be transferred. Note also that in column 1 at the bottom of page 26 it mentions "767" as the model as well. Oops! > Since Chris seems to be seeing only 344, this suggests a couple of things: > 1) The manual is incorrect :-) My first guess. > 2) For some reason, the last byte is not being sent (pretty unlikely) > 3) The first byte is being missed I think Chris has shown he's getting the first byte by his message of yesterday. > 4) ?? > > Probably the easiest way to figure out whether 2 or 3 is the case, it should > be possible to take the data Chris has returned and see how it matches up > with the manual. This should make it real obvious if the first or last byte > is missing. Also, the backend code parses the data per the manual so an offset error will show rather quickly. > As for the length being incorrect, I expect this would take getting samples > from several rigs to see what is being returned. It may also be possible to > use another program to see what information they receive and whether the > amount is 344 or 345 bytes. There is a 747 locally, I'm not sure if he has an interface for it. I can ask at work on Monday as we share the same office. :-) > Just some thoughts (from a quasi-lurker :-) Always welcome to read the thoughts of anyone who wishes to chime in. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html |
|
From: Mark P. <n1...@ar...> - 2010-03-27 21:44:54
|
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
|
|
From: Mark P. <n1...@ar...> - 2010-03-27 19:25:15
|
I managed to locate a copy of the manual online:
<http://hamradio.lakki.iki.fi/new/Documents/Manuals/Yaesu/base&portable/Yaesu%20FT-747GX%20users%20manual.pdf>
Starting on page 26 at the CAT commands. On page 27, Reading Transceiver
Status, it does indeed say 345 bytes should be transferred.
Since Chris seems to be seeing only 344, this suggests a couple of things:
1) The manual is incorrect :-)
2) For some reason, the last byte is not being sent (pretty unlikely)
3) The first byte is being missed
4) ??
Probably the easiest way to figure out whether 2 or 3 is the case, it should
be possible to take the data Chris has returned and see how it matches up
with the manual. This should make it real obvious if the first or last byte
is missing.
As for the length being incorrect, I expect this would take getting samples
from several rigs to see what is being returned. It may also be possible to
use another program to see what information they receive and whether the
amount is 344 or 345 bytes.
Just some thoughts (from a quasi-lurker :-)
73
- Mark N1VQW
|
|
From: Chris B. <ry...@cr...> - 2010-03-27 21:05:50
|
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 |
|
From: Nate B. <n0...@n0...> - 2010-03-28 00:12:53
|
* On 2010 27 Mar 16:08 -0500, Chris Bryant wrote: > > 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. There's the rub, is anyone actually using the 747 these days with Hamlib? As our code doesn't "phone home" or anything of the like, it's impossible to tell whether anyone actually uses it. Also, even though the 747 code is some of the oldest in Hamlib, if it doesn't get used, it doesn't get tested. The difference between MixW and Hamlib may well be the difference in why MixW works and Hamlib didn't. Of course we can't examine the MixW code, but it's possible that it is not as strict looking for the byte count on the wire as Hamlib. That's just conjecture on my part. The worst case is what do we do if we find that some rigs report 344 bytes and others 345? And, no, your work-around is not disgusting! It's a valid fix to your problem. Now we need to test other 747s to see what's going on. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html |
|
From: Nate B. <n0...@n0...> - 2010-03-28 00:17:09
|
BTW, Chris, Stephane just added two patches that affect the 747. Check out SVN or grab the daily snapshot from: http://n0nb.users.sourceforge.net around 1030z tomorrow. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html |
|
From: Stephane F. <f8...@fr...> - 2010-03-28 10:37:23
|
Nate Bargmann skribis: > BTW, Chris, Stephane just added two patches that affect the 747. Check > out SVN or grab the daily snapshot from: > > http://n0nb.users.sourceforge.net > > around 1030z tomorrow. You understand why I did that before going to bed yesterday ;-) > The difference between MixW and Hamlib may well be the difference in > why MixW works and Hamlib didn't. Of course we can't examine the MixW > code, but it's possible that it is not as strict looking for the byte > count on the wire as Hamlib. That's just conjecture on my part. I can't remember Chris whether you said what was the snooped block length when using MixW. 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? As a bonus, there's also support for split operation in the svn commit. > The worst case is what do we do if we find that some rigs report 344 > bytes and others 345? 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? 73 -- Stephane - F8CFE |
|
From: Chris B. <ry...@cr...> - 2010-03-28 17:15:22
|
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
|
|
From: Chris B. <ry...@cr...> - 2010-03-28 17:25:49
|
Strange After my previous build failure, I cleared everything out, downloaded the gz file and tried again. This time I get ...... config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands configure: WARNING: unrecognized options: --enable-ltdl-convenience and then it exits (cleanly) chris g3wie |
|
From: Nate B. <n0...@n0...> - 2010-03-28 19:03:45
|
* On 2010 28 Mar 12:26 -0500, Chris Bryant wrote: > Strange > > After my previous build failure, I cleared everything out, downloaded the gz > file and tried again. This time I get > > ...... > config.status: creating config.h > config.status: executing depfiles commands > config.status: executing libtool commands > configure: WARNING: unrecognized options: --enable-ltdl-convenience > > and then it exits (cleanly) Did it build correctly? 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html |
|
From: Chris B. <ry...@cr...> - 2010-03-28 21:41:29
|
On Sunday 28 Mar 2010, you wrote: > Chris Bryant skribis: > [...] > > > ../libltdl/libltdlc.la ../lib/libmisc.la -lm -ldl > > libtool: link: cannot find the library `../libltdl/libltdlc.la' or > > unhandled argument `../libltdl/libltdlc.la' > > Looks like there's a problem with the embedded libltdl. > To workaround that, if by any chance you're running a debian/ubuntu > system, can you install libltdl-dev ? On the command line, this is > something like "sudo apt-get install libltdl-dev" > Then, you will have to run the hamlib configure script again, and make. > Ok Stephane, that fixed it, thanks. I'm using debian unstable here, to be sure to get the latest libraries as I've found problems with amateur radio s/w using late versions of libraries in the past. Now that Ubuntu is mainstream, and developers tend to use it as a default test platform, I will switch to that because debian unstable is like it says, not stable.... I ran up rigctl -m 105 -r /dev/ttyS0 and it seemed quite happy with no timeout on the read of 344 chars, then a timeout on the potential extra char as expected. I did a little bit of testing, and it seems ok. I'll do some more detailed testing tomorrow. Here's the -vvvvv output fyi. VFO A is on 7045 LSB and VFO B is on 14076 AM ft747:ft747_init called rig:rig_open called ft747:rig_open: write_delay = 5 msec ft747:rig_open: post_write_delay = 5 msec ft747: read pacing = 0 TX 5 bytes 0000 00 00 00 00 0e ..... TX 5 bytes 0000 00 00 00 00 10 ..... RX 344 bytes 0000 00 00 07 04 50 00 13 00 00 07 04 50 00 50 00 08 ....P......P.P.. 0010 00 14 07 60 00 42 00 17 50 10 00 10 00 00 00 10 ...`.B..P....... 0020 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 ................ 0030 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 ................ 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: vfo status = 0 ft747: VFO = A Opened rig model 105, 'FT-747GX' Backend version: 0.4, Status: Alpha Chris g3wie |
|
From: Stephane F. <f8...@fr...> - 2010-03-29 18:03:49
|
Chris Bryant skribis: > On Sunday 28 Mar 2010, you wrote: > > Looks like there's a problem with the embedded libltdl. > > To workaround that, if by any chance you're running a debian/ubuntu > > system, can you install libltdl-dev ? On the command line, this is > > something like "sudo apt-get install libltdl-dev" > > Then, you will have to run the hamlib configure script again, and make. > > 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. > to get the latest libraries as I've found problems with amateur radio s/w > using late versions of libraries in the past. Now that Ubuntu is mainstream, > and developers tend to use it as a default test platform, I will switch to > that because debian unstable is like it says, not stable.... Indeed, but unstable versions needs courageous beta-testers for the good of everybody. It's very true for Hamlib also. > I ran up rigctl -m 105 -r /dev/ttyS0 and it seemed quite happy with no timeout > on the read of 344 chars, then a timeout on the potential extra char as > expected. I did a little bit of testing, and it seems ok. I'll do some more > detailed testing tomorrow. Here's the -vvvvv output fyi. VFO A is on 7045 LSB > and VFO B is on 14076 AM 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 Attn hamlib devs: I've added a generic function rig_check_cache_timeout() in the frontend (src/misc.c), inspired by the ft817 code. This should make the caching of status easy to handle in various backends. Maybe the ft817, ft857, and the ft897 could be converted to save for some code size. Look at yeasu/ft747.c or tentec/paragon.c (newly fleshed out!) for an example. Is there any rig that should get status caching? ft757gx, ft767gx ? There's also a function rig_force_cache_timeout() in the frontend that can be used in any backend_set_* function that could modify the current status. This may allow longer cache duration (c.f. comment in yaesu/ft817.h about FT817_CACHE_TIMEOUT). > ft747:rig_open: write_delay = 5 msec > ft747:rig_open: post_write_delay = 5 msec > ft747: read pacing = 0 > TX 5 bytes > 0000 00 00 00 00 0e ..... > TX 5 bytes > 0000 00 00 00 00 10 ..... > RX 344 bytes > 0000 00 00 07 04 50 00 13 00 00 07 04 50 00 50 00 08 ....P......P.P.. > 0010 00 14 07 60 00 42 00 17 50 10 00 10 00 00 00 10 ...`.B..P....... > 0020 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 ................ > 0030 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 ................ > 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 ........ -- Stephane - F8CFE |
|
From: <rem...@gm...> - 2010-03-29 21:17:47
|
Stephane Fillod wrote: > Chris Bryant skribis: >> On Sunday 28 Mar 2010, you wrote: >> Now that Ubuntu is mainstream, and developers tend to use it as a default test platform, I will switch to >> that because debian unstable is like it says, not stable.... I use Mandriva for ten years, and also never had any stability nor installation problem, therefore it might be worth considering. An quick poll here about the best Linux dtsribution of the Decade: http://www.junauza.com/2010/02/best-linux-distributions-of-decade-2000.html |
|
From: Chris B. <ry...@cr...> - 2010-03-29 21:17:29
|
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
|
|
From: Stelios B. <sb...@en...> - 2010-03-30 04:24:39
|
> On Mon, 29 Mar 2010 22:17:18 +0100, Chris Bryant <ry...@cr...> said: >> On Monday 29 Mar 2010, Stephane Fillod wrote: [snip] >> 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. I have used Debian/unstable for more than 10 years and always been pretty happy with it. There's the occasional breakage but nothing that I couldn't fix with minimal effort. In my experience, it's mainly the distribution as a whole (i.e. as a collection of packages and dependency relations) that is unstable, and not the individual programs. It helps if you're willing to keep abreast with the development of various packages; in fact, using unstable is not a bad way to encourage yourself to do so :-) As for dealing with broken packages, tools like apt-listchanges and apt-listbugs can help you spot potential problems and keep a package on hold while it is broken. You can choose to dodge a bad package revision or help fix the bug(s), depending on your time and interest. You can usually downgrade a package if you notice the problem soon enough, and historical versions of packages are also kept at snapshot.debian.net. If you find unstable too volatile, you might consider using testing instead. Problems like "kde4 is broken" should happen much more rarely there, and testing is never far behind unstable unless the version in unstable is broken. -- 73, Stelios, M0GLD. |
|
From: Chris B. <ry...@cr...> - 2010-03-30 10:36:37
|
On Tuesday 30 Mar 2010, Stelios Bounanos wrote: > I use Mandriva for ten years, and also never had any stability nor > installation problem, therefore it might be worth considering. On Tuesday 30 Mar 2010, Remi Chateneau wrote: > I have used Debian/unstable for more than 10 years and always been > pretty happy with it. There's the occasional breakage but nothing that > I couldn't fix with minimal effort. In my experience, it's mainly the > distribution as a whole (i.e. as a collection of packages and dependency > relations) that is unstable, and not the individual programs. It helps > if you're willing to keep abreast with the development of various > packages; in fact, using unstable is not a bad way to encourage yourself > to do so :-) > Thanks both for your recommendations - I'll think about all this when I come to do the rebuilds. I have three machines to do... Chris g3wie |
|
From: Kamal M. <ka...@wh...> - 2010-04-04 16:36:18
|
Stephane Fillod wrote: > Looks like there's a problem with the embedded libltdl. > [...] can you install libltdl-dev ? Chris Bryant skribis: > Ok Stephane, that fixed it, thanks. I'm using debian unstable here, to be sure Stephane Fillod wrote: > 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. Chris Bryant wrote: > Btw I didn't have that probelm building 1.2.10 from source (d/l from the > sourceforge d/l page) Sorry I'm arriving late to the party here folks... I suspect that this libltdl problem is related to the change I made on 2010-03-01 (r2841) which affected the way hamlib selects which libltdl to use: http://sourceforge.net/mailarchive/message.php?msg_name=1267470158.7216.21.camel%40fourier At that time, the group discussed (but decided against) the idea of removing the bundled libltdl from hamlib altogether, which would force users to want to build hamlib from source to use their distro's native libltdl (or build that too if their distro doesn't provide it). FWIW, it sounds like Chris' problem may have been avoided if we had taken that step. The group may want to consider the idea of dropping the bundled libltdl again. I'm not sure how many hamlib users even "need" it anymore (I think libltdl is probably supplied by most distros), but we do have evidence that its presence causes some problems: CVE-2009-3736, and now Chris' problem. Is the benefit of bundling libltdl worth the burden that it imposes on hamlib? 73 de KA6MAL -Kamal |
|
From: Stephane F. <f8...@fr...> - 2010-04-04 21:06:36
|
Kamal Mostafa skribis: > Stephane Fillod wrote: > > Looks like there's a problem with the embedded libltdl. > > [...] can you install libltdl-dev ? > > Chris Bryant skribis: > > Ok Stephane, that fixed it, thanks. I'm using debian unstable here, to be sure > > Stephane Fillod wrote: > > 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. > > Chris Bryant wrote: > > Btw I didn't have that probelm building 1.2.10 from source (d/l from the > > sourceforge d/l page) > > > Sorry I'm arriving late to the party here folks... > > I suspect that this libltdl problem is related to the change I made on > 2010-03-01 (r2841) which affected the way hamlib selects which libltdl > to use: > http://sourceforge.net/mailarchive/message.php?msg_name=1267470158.7216.21.camel%40fourier Kamal, I still think you did the right thing with the libltdl update. However, I don't understand why the order was changed in Makefile.am in the definition of SUBDIRS: -SUBDIRS = macros include lib libltdl src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ +SUBDIRS = macros include lib src $(subdirs) @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ According to me, 'src' should be built after $(subdirs), since src depends on libltdl, when selected. Do you agree? SUBDIRS = macros include lib $(subdirs) src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ > At that time, the group discussed (but decided against) the idea of > removing the bundled libltdl from hamlib altogether, which would force > users to want to build hamlib from source to use their distro's native > libltdl (or build that too if their distro doesn't provide it). FWIW, > it sounds like Chris' problem may have been avoided if we had taken that > step. Actually, I'm not sure what was Chris' problem. Probably, it's more like me guessing it's because of libltdl-dev, while in fact the configure script was too slow finding the python dev setup. The "find /usr ..." is not that smart in macros/python.m4, and probably has to be reworked, maybe with a more up to date script. > The group may want to consider the idea of dropping the bundled libltdl > again. I'm not sure how many hamlib users even "need" it anymore (I > think libltdl is probably supplied by most distros), but we do have > evidence that its presence causes some problems: CVE-2009-3736, and now > Chris' problem. Is the benefit of bundling libltdl worth the burden > that it imposes on hamlib? Yes, it is worth it because some non-Linux distos are frugal, or carry broken library. For example, the cross-compilation for win32 under Linux does need the bundled libtldl. 73 -- Stephane - F8CFE |
|
From: Nate B. <n0...@n0...> - 2010-04-05 00:37:37
|
For what it's worth, I committed a small change to autogen.sh back on March 11 at Rev 2854 where I added '-e' to line 84's echo command. Without it the string wasn't being parsed correctly and the 1.5.x version from a new Debian Lenny install was being regarded as newer than the bundled version! It hadn't been caught before as I had backports enabled on the old laptop I built the daily snapshots with and it had 2.2.6b installed. I don't know if Chris ran afoul of that or not. As for Python slowing the build, I've not seen it as I disable the Perl and Python bindings on my local builds. Is there any benefit to having them built by default? Would it be "better" to disable them by default so that people "who know what they are doing" could enable them if needed? 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://n0nb.us/index.html |
|
From: Thomas B. <tb...@fo...> - 2010-04-05 07:06:21
|
Hi All, some words to the python problem from me. On Sun, Apr 04, 2010 at 07:37:25PM -0500, Nate Bargmann wrote: > As for Python slowing the build, I've not seen it as I disable the Perl > and Python bindings on my local builds. On some machines the search for the path to the python library takes very long (1..3 minutes). That comes from the very old python.m4 macro we use at the moment. If the python lib libpython.so... can not be found in the old standard locations it tries to find it via some 'find' commands. That can take a long time if you have a lot of files in /usr. The funny point is that we do not need that library it looks for at all. Maybe we should adapt to the newer ax_python.m4 macro from the autoconf archive. But we would have to adapt configure.ac accordingly. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- |
|
From: Kamal M. <ka...@wh...> - 2010-04-08 01:00:35
|
On Sun, 2010-04-04 at 23:06 +0200, Stephane Fillod wrote: > > Kamal, I still think you did the right thing with the libltdl update. > However, I don't understand why the order was changed in Makefile.am > in the definition of SUBDIRS: > > -SUBDIRS = macros include lib libltdl src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ > +SUBDIRS = macros include lib src $(subdirs) @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ > > According to me, 'src' should be built after $(subdirs), since src > depends on libltdl, when selected. Do you agree? Yes, I do agree. I suppose that I failed to consider the build order, and I didn't notice the problem, since my build selected the system's libltdl anyway. > SUBDIRS = macros include lib $(subdirs) src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ > Stephane, will you apply that change? 73 de KA6MAL -Kamal |
|
From: Stephane F. <f8...@fr...> - 2010-04-08 20:26:16
|
Wed, Apr 07, 2010, Kamal Mostafa skribis: > On Sun, 2010-04-04 at 23:06 +0200, Stephane Fillod wrote: [..] > > SUBDIRS = macros include lib $(subdirs) src @BACKEND_LIST@ @ROT_BACKEND_LIST@ \ > > Stephane, will you apply that change? Yes, applied. Thanks. 73 -- Stephane - F8CFE |
|
From: Stephane F. <f8...@fr...> - 2010-04-08 20:54:56
|
On Sun, Apr 04, 2010, Nate Bargmann wrote: [..] > As for Python slowing the build, I've not seen it as I disable the Perl > and Python bindings on my local builds. Is there any benefit to having > them built by default? Would it be "better" to disable them by default > so that people "who know what they are doing" could enable them if > needed? I agree with you, they should be disabled by default. Mon, Apr 05, 2010, Thomas Beierlein skribis: > On some machines the search for the path to the python library takes very long > (1..3 minutes). That comes from the very old python.m4 macro we use at the > moment. If the python lib libpython.so... can not be found in the old standard > locations it tries to find it via some 'find' commands. That can take a long > time if you have a lot of files in /usr. > > The funny point is that we do not need that library it looks for at all. But we do need PYTHON_CPPFLAGS. Some systems may need the library, and/or its dependencies, but we can leave that. > Maybe we should adapt to the newer ax_python.m4 macro from the autoconf > archive. But we would have to adapt configure.ac accordingly. Good idea. Anyway, we'll have to adapt configure.ac in order to follow Nate's suggestion. 73 -- Stephane - F8CFE |
