I'm using an Orion II. On onee of my systems, which uses the newest version of Klikit-Linux, based on Ubuntu 8.04.2, I tried Xlog 1.9 (installed using Synaptic from the Debian/sid repository). When I choose "Enable hamlib" in Xlog's Preferences the transceiver's frequency is immediately picked up, but very quickly (probably at the first poll) I get "There was an error communicating with your rig, hamlib has stopped."
Running rigctl -r /dev/ttyS1 -m 1608 and entering "f" gives the correct frequency, "m" the correct mode and passband.
I'm not really sure how to determine that, Martin, but Synaptic shows libhamlib-utils 1.2.8-1 is installed. Apologies for being so ignorant, but I don't even know if that actually IS "hamlib"!
Maybe I need to download and install hamlib...tar.gz from sourceforge, but I tried that on a different hard disk with a different system a few days ago, and on ./configure got a "/lib/cpp sanity test failed" error. I don't have that one figured out yet either; I looked for cpp (libcpp, etc) and C++ files, and there are a number of them installed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK... I believe hamlib 1.2.8 was successfully compiled. Running Xlog 1.9, first "Enable hamlib" reads the frequency correctly but then gives the error described at the start of this thread.
Here is some rigctl output. (In the first section, I changed freq and passband to make sure the changes were tracked, and they were.) I have to run rigctl as ROOT, while I run Xlog as USER... could that be a problem?
The initial "retry" error is normal. The Orion does not respond correctly until after the first command, and Hamlib retries until it succeeds. I don't think that will affect xlog. (The message is only a warning.)
Xlog is probably seeing the "unsupported level". If this is the same as my prior experience (I also use xlog), it is because Xlog is trying to read the "calibrated" S meter reading (in dB relative to S9) -- and the Orion Hamlib backend did not properly provide that info.
This has been fixed in the current CVS source, and should be incorporated in the upcoming 1.2.9 release.
73
Martin AA6E
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, Martin... I just DL'd and compiled the CVS version, and Xlog 1.9 is now working with hamlib! No polling problems, ctrl-k inserts freq into the QSO pane, etc. Thanks again!
Now... to get up the courage to replace the smoothly functioning Xlog 1.6.2 that's on my main hard disk...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using an Orion II. On onee of my systems, which uses the newest version of Klikit-Linux, based on Ubuntu 8.04.2, I tried Xlog 1.9 (installed using Synaptic from the Debian/sid repository). When I choose "Enable hamlib" in Xlog's Preferences the transceiver's frequency is immediately picked up, but very quickly (probably at the first poll) I get "There was an error communicating with your rig, hamlib has stopped."
Running rigctl -r /dev/ttyS1 -m 1608 and entering "f" gives the correct frequency, "m" the correct mode and passband.
This is hamlib.out:
rig:rig_init called
rig:rig_open called
TX 3 bytes
0000 3f 56 0d ?V.
RX 15 characters
0000 56 65 72 73 69 6f 6e 20 32 2e 30 33 39 64 2dTX 3 bytes
0000 3f 53 0d ?S.
RX 4 characters
0000 35 36 36 0d 566.
** retry after delay (io=12, retry=0) **
RX 12 characters
0000 40 53 52 4d 30 36 39 53 30 33 32 0d @SRM069S032.
TX 3 bytes
0000 3f 53 0d ?S.
RX 12 characters
0000 40 53 52 4d 30 36 39 53 30 33 32 0d @SRM069S032.
tt565_get_level: unsupported level 1073741824
rig:rig_close called
rig:rig_cleanup called
Anything obvious here, or is more information needed?
Yes, this is a known issue with earlier Hamlib versions. Current CVS (and probably the latest release version) have improved quite a lot.
What version are you using now?
73
Martin AA6E
I'm not really sure how to determine that, Martin, but Synaptic shows libhamlib-utils 1.2.8-1 is installed. Apologies for being so ignorant, but I don't even know if that actually IS "hamlib"!
Maybe I need to download and install hamlib...tar.gz from sourceforge, but I tried that on a different hard disk with a different system a few days ago, and on ./configure got a "/lib/cpp sanity test failed" error. I don't have that one figured out yet either; I looked for cpp (libcpp, etc) and C++ files, and there are a number of them installed.
OK... I believe hamlib 1.2.8 was successfully compiled. Running Xlog 1.9, first "Enable hamlib" reads the frequency correctly but then gives the error described at the start of this thread.
Here is some rigctl output. (In the first section, I changed freq and passband to make sure the changes were tracked, and they were.) I have to run rigctl as ROOT, while I run Xlog as USER... could that be a problem?
*********************************************************
root@AMD2400:/home/john# rigctl -r /dev/ttyS1 -m 1608
Rig command: f
** retry after delay (io=2, retry=0) **
Frequency: 7024830
Rig command: m
Mode: CWR
Passband: 360
Rig command: f
Frequency: 7028940
Rig command: m
Mode: CWR
Passband: 490
Rig command:
********************************************************
root@AMD2400:/home/john# rigctl -vvvvv /dev/ttyS1 -m 1608
rigctl, Hamlib version 1.2.8
Report bugs to <hamlib-developer@lists.sourceforge.net>
rig:rig_init called
rig: loading backend tentec
tentec: _init called
rig_register (1601)
rig_register (1607)
rig_register (1608)
rig_register (1602)
rig_register (1603)
rig_register (1604)
rig_register (1605)
rig:rig_open called
TX 3 bytes
0000 3f 56 0d ?V.
read_string: timedout without reading a character
tt565_get_info: ack NG, len=-5
Opened rig model 1608, 'TT-565 Orion'
Backend version: 0.3, Status: Beta
Command '' not found!
rig:rig_close called
rig:rig_cleanup called
root@AMD2400:/home/john#
**********************************************************
The initial "retry" error is normal. The Orion does not respond correctly until after the first command, and Hamlib retries until it succeeds. I don't think that will affect xlog. (The message is only a warning.)
Xlog is probably seeing the "unsupported level". If this is the same as my prior experience (I also use xlog), it is because Xlog is trying to read the "calibrated" S meter reading (in dB relative to S9) -- and the Orion Hamlib backend did not properly provide that info.
This has been fixed in the current CVS source, and should be incorporated in the upcoming 1.2.9 release.
73
Martin AA6E
Thanks, Martin... I just DL'd and compiled the CVS version, and Xlog 1.9 is now working with hamlib! No polling problems, ctrl-k inserts freq into the QSO pane, etc. Thanks again!
Now... to get up the courage to replace the smoothly functioning Xlog 1.6.2 that's on my main hard disk...