Connectivity issues.

29 posts / 0 new
Last post
ki4lui
Connectivity issues.

First let me say thanks for the great product. I have the latest stable release (0.8.2) installed.
I am not sure if my connectivity issue is cqrlog or hamlibs.

I fired up the rig then fired up the computer.
Confirm cable connected.

When I start cqrlog
[george@klocalhost cqrlog]$ ./cqrlog
Starting CQRLOG ...

Rig is not OK

Rig is not OK

The user is in the uucp group which the device is writable for that group.

[george@localhost cqrlog]$ ldd ./cqrlog
linux-gate.so.1 => (0x0012a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00d21000)
libdl.so.2 => /lib/libdl.so.2 (0x00d1b000)
librt.so.1 => /lib/librt.so.1 (0x00df0000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x0690d000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x055e9000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x05d87000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x059ed000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x0595e000)
libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x0578e000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x056ee000)
libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x003de000)
libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00319000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x05dd0000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x05e1b000)
libhamlib.so.2 => /usr/lib/libhamlib.so.2 (0x00678000)
libc.so.6 => /lib/libc.so.6 (0x003e3000)
/lib/ld-linux.so.2 (0x00322000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00d4f000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00d54000)
libm.so.6 => /lib/libm.so.6 (0x00cf2000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x058e3000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x058ee000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x0026a000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00d5c000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x002c3000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00dfb000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x05e11000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x002e1000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x002d5000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x002ce000)
libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x00340000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x05da0000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00d6e000)
libz.so.1 => /usr/lib/libz.so.1 (0x00d3a000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x0029b000)
libexpat.so.0 => /lib/libexpat.so.0 (0x00247000)
[george@localhost cqrlog]$

[george@localhost ~]$ rigctl -vvvvv -r /dev/ttyS0 -m 123

rigctl, Hamlib version 1.2.9

Report bugs to

rig:rig_init called

rig: loading backend yaesu

yaesu: initrigs2_yaesu called

rig_register (121)

rig_register (127)

rig_register (110)

rig_register (105)

rig_register (106)

rig_register (107)

rig_register (109)

rig_register (120)

rig_register (101)

rig_register (122)

rig_register (123)

rig_register (111)

rig_register (115)

rig_register (113)

rig_register (114)

rig_register (128)

rig_register (116)

rig_register (103)

rig_register (124)

rig_register (104)

rig_register (125)

rig_register (129)

rig_register (130)

rig_register (117)

rig_register (119)

rig_register (118)

rig_register (126)

ft897:ft897_init called

rig:rig_open called

ft897:ft897_open called

Opened rig model 123, 'FT-897'

Backend version: 0.3.2, Status: Beta

Rig command:

I am pretty Linux savvy from the Sys Admin standpoint but not very when it comes to interfacing I/O.
Thanks a lot for any help or direction and my apologies if this is supposed to be directed else where.

Good site and a great product as far as I see.

I hope I can contribute my skills to this site.

thanks
G (ki4lui)

ki4lui
Woops I wanted to add that i

Woops I wanted to add that i have a yaesu 897 and the rate is confirmed to be set at 38400 and the tuner is set to CAT.

Also I noticed when I instrument the "tx control" window I see:
Starting CQRLOG ...

Rig is not OK

Rig is not OK

aaaa

aaaa

aaaa

aaaa

aaaa

aaaa

The "aaaa" occurs when I click a band

Thanks again

ki4lui
I set it to debug

I set it to debug (http://www.cqrlog.com/?q=node/67)

I was ASSuming poll rate 38400 was baud rate.
Debug showed 9600 for baud rate for cqrlog and radio was at 38400.

I seem to be connected however I am still unable to control the radio. That's a different hairball
Sorry to waste bits.

../cqrlog

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:9600

Databits:8

StopBits:1

Handshake:

Parity:None

DTR:OFF

RTS:OFF

Poll:38400

Reloading rig configuration

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

aaaa

aaaa

aaaa

aaaa

aaaa

aaaa

aaaa

aaaa

This is an invalid mode:WFM

Removing Rig control thread from memory

ok1rr
ok1rr's picture
Poll rate

Hi George,

Apparently your poll rate is set incorrectly. A value of 38400 is impossible, you are mixing up the communication speed with the poll rate! The poll rate is good to set to a value between 50 and 500. Higher number means slower hauly display, a lower number may cause a higher CPU load. AFAIK the optimal value for most radios is 250 or 300, the very safe value is 500.

Another thing which seems suspicious is the handshake. You need really set this to NONE, a blank does not mean NONE, the backend can get confused.

I can't tell you very much because not keen of Yaesu, however the hamlib is a wonderful piece of software. On my Slackware I had never a trouble with any version above 1.2.8 and the T-T Orion (the older versions have a buggy backend causing disconnect if tuned to 7015.9 and some other freq, this bug was fixed in 1.2.8). On Ubuntu the repository version 1.2.9 didn't work at all but my own build of 1.2.10cvs from sources works like a champ. Therefore I recommend to try the cvs version, they are pretty stable.

I hope this helps. Let us know how it works!

73 Martin, OK1RR

ki4lui
Connected but no real control..

Hi Martin,
Sorry for the delay the new baby is keeping me very, VERY busy.

I saw that there is a new version so I downloaded and made the suggested changes.

I seem to be connected but no real control of the radio is obtained.

I can see the frequency that is on the radio on cqrlog. However, I can't change bands, or frequencies ( i Don;t even see a way to change frequency in cqrlog.) in cqrlog and have them reflected on the radio or vice versa. Does that make sense?

I thought I was running the latest hamlibs but guess not. i don;t see source for 1.2.10

[george@localhost cqrlog]$ rigctl --version

rigctl, Hamlib version 1.2.9

The 897 is in BETA so maybe that could be part of the issue. I have been asking hams on the different nets if they use it I have had a few bites but using different radios.

Thanks for any help you or anyone else can provide.

Below is my start up in debug mode maybe I am missing something.
I played with various poll rates and still the same results.

George

[george@localhost cqrlog]$ ./cqrlog

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:

Parity:None

DTR:OFF

RTS:OFF

Poll:500

Reloading rig configuration

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

This is an invalid mode:USB

Removing Rig control thread from memory

[george@worldgeorge cqrlog]$ ./cqrlog

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:

Parity:None

DTR:OFF

RTS:OFF

Poll:500

Reloading rig configuration

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

This is an invalid mode:FM

Removing Rig control thread from memory

ki4lui
Poll Rate to 50

Ok I set poll rate to 50.

The result is now I can see the band and frequencies changed in cqrlog (TRX control) when I make the changes from the radio.

However no changes are made when I try to control from TRX control.

I get:
"This is an invalid mode:USB

Removing Rig control thread from memory"

OR any mode for that matter.

When I try to "refresh" I get a stack trace.

TApplication.HandleException Access violation

Stack trace:

$081272DD

$080C8CF2

$0824D0F1

$0824D750

$0806A1B9

$082B091B

$08348F43

$05821169

$05813E98

$05824DAB

$058262E7

$058264A9

$05C8E984

$05B82D08

$05B842D2

$05B7BEA5

$05B76060

And I am required to restart cqrlog.

Getting closer I think.

Looking at top CPU holds up pretty well with poll rate at 50 and memory is fine.

So far.

Thanks
George

ok2cqr
ok2cqr's picture
Re: Poll Rate to 50

Hi George,

poll rate 50 is too fast. Please set poll rate to 300 or more.

"This is an invalid mode:USB"

Please go to Preferences window, choose Modes tab and set bandwidth to 0 for all modes. It should help.

You can change freq directly from cqrlog by typing freq i kHz to Call field e.g. if you type 14020 and hit enter, TRX change freq to 14020kHz. Or you can use ALT+F shortkey.

73 Petr, OK2CQR

ki4lui
AHAAA!!

PERFECT!!!
thanks a lot.

I a have an extra computer, I am always trying to get my elmer (ak3rx) which is my dad switched to linux. I think I found a way.

Thanks for the help.

G

ki4lui
error 250

Left the machine on ofr a few days and turned the radio off and on.
Now I get an error 250.

I have power cycled both radio and computer.

Turned on radio first then computer and vise versa.

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:

Parity:None

DTR:OFF

RTS:OFF

Poll:50

rig_open: error =

rig_open: error = 250

Reloading rig configuration

rig_open: error =

rig_open: error = 250

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

Everything is connected physically

ok1rr
ok1rr's picture
Re: error 250

George,

allow me, please, to ask if you have any idea how the polling system works.

It is a false premise that you able to speed up the logger response to frequency changes. Unless you have an apparently wrong settings, you can't do too much.

Anyway, the poll rate determines how many times per second is your radio queried for frequency, mode, filter bandwidth etc. The main unit is a millisecond, ie. poll rate of 100 means that the radio is queried 10 times per second. The communication is bidirectional. A poll rate of 50 is apparently too low. A quite unknown parameter is what your radio can process, how good performer is the processor inside your radio!

You probably know the saga of the old Kenwood TS-140 which was unable to key CW speeds above 25-30 wpm, thanks to its poor processor (a Zilog Z-80). Reckon that everything in your radio is controlled by the processor and the communication with the computer is not a task of highest priority! There is a widely spread idea that the radio <-> computer communication is the limiting factor. Isn't! The limiting factor is the processor itself and the (possibly buggy) firmware.

To ensure properly timed response, almost everything must be buffered. It is also possible that a buffer overflow can cause some quirky actions in your radio. There is no simple answer because every radio has its own, different philosophy. This will result in built-in limits/defaults which we should introduce (probably) into CQRLOG. A good thing would be limited range of poll rate settings, say 150 - 1000. A lower value than 150 will result in poll rate 150, a larger value than 1000 will produce a poll rate of 1000.

For now, set your poll rate to 250 (ie. your radio will be queried 4times per second). Hopefully you don't need to reset your radio completely...

ki4lui
error 250

I believe I understand how polling works.

I was trying different polls rates to if that was my issue. It is apparent that no matter what I put for poll rate I still get a rig 250 error. I checked hamlib with no luck.

I have tried 250, 500, 750, and 1000 as poll rates and the error still comes up.

The last thing I did was put everything in the "modes" preferences as "0"

I reset the radio and reconfigured for cat communications and baud rate and still the same error.

I would agree and understand that yes the processor in the radio is doing something quirky. Also the control modules for the 897 is inBeta.
Maybe I need to find some other 897 users.

I will do some more messing around and see what I come up with.

ki4lui
Handshake issue

Something is wrong with the handshake I think. I reinstalled cqrlog. I am noticing that handshake is blank even though I change it in the preferences and in the cqrlog.cfg I know it to be NONE However it doesn't seem to show that in debug mode.
When I switch it to "ON/OFF" debug shows it to be in "None". When I set to "Hardware" debug shows it to be "on/off". Can anyone confirm this. I know it sounds crazy. No I have not lost my mind.
I have tried the 3 following cases three times each independently.

When set Handshake to : "None"
[george@localhost cqrlog]$ ./cqrlog

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:

Parity:None

DTR:OFF

RTS:OFF

Poll:300

rig_open: error =

rig_open: error = 250

Reloading rig configuration

rig_open: error =

rig_open: error = 250

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

WHEN I SET TO "on/off"
[george@worldgeorge cqrlog]$ ./cqrlog

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:None

Parity:None

DTR:OFF

RTS:OFF

Poll:300

rig_open: error =

rig_open: error = 250

Reloading rig configuration

rig_open: error =

rig_open: error = 250

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

Reloading rig configuration

rig_open: error =

rig_open: error = 250

OnCloseQuery - NewQSO

Closing Details window

Closing BandMap window

Closing DXCluster window

Closing TRXControl window

Closing GrayLine window

Closing dDXCC

Closing dData

Saving config file

WHEN SET TO "Hardware"
[george@worldgeorge cqrlog]$ ./cqrlog

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:XONXOFF

Parity:None

DTR:OFF

RTS:OFF

Poll:300

rig_open: error =

rig_open: error = 250

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

Reloading rig configuration

rig_open: error =

rig_open: error = 250

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

ki4lui
Installed latest snapshot

I installed snapshot CVS and now my error changes to
"an Error occurred setting the rig to pathname:/dev/ttyS0"

Time to head to bed.
Heres more debug output

Starting CQRLOG ...

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

RootDirectory = /home/george/cqrlog/

ExternalFileAccess = Restrict /home/george/cqrlog/log_data

SELECT * FROM version

SELECT * FROM cqrlog_main ORDER BY qsodate,time_on

In inicializerig

Model:123

Port:/dev/ttyS0

Baudrate:38400

Databits:8

StopBits:1

Handshake:

Parity:None

DTR:OFF

RTS:OFF

Poll:300

An error has occured setting the rig pathname:/dev/ttyS0

Reloading rig configuration

An error has occured setting the rig pathname:/dev/ttyS0

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

SELECT * FROM profiles WHERE nr = 0

LATEST HAM LIB
rigctl -V

rigctl, Hamlib version 1.2.10svn

Copyright (C) 2000-2009 Stephane Fillod

Copyright (C) 2000-2003 Frank Singleton

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ki4lui
"an Error occurred setting

"an Error occurred setting the rig to pathname:/dev/ttyS0"

Has anyone seen this before by chance?

ok2cqr
ok2cqr's picture
Re: "an Error occurred setting

Hi George,

you can try rpc.rigd.

More here: http://linux.die.net/man/8/rpc.rigd

In CQRLOG se rig ID to 1901, port to localhost.

73 Petr, OK2CQR

ki4lui
Thanks

Thanks for the help I will get on it as soon as I get home.
G ki4lui

ki4lui
Connectivity through rigctl only.

Running rigctl

Getting connectivity through rigctl:
ft897:ft897_init called
rig:rig_open called
ft897:ft897_open called
Opened rig model 123, 'FT-897'
Backend version: 0.3.3, Status: Beta

Rig command: f
ft897: cache invalid
TX 5 bytes
0000 00 00 00 00 03 .....
RX 5 bytes
0000 00 71 40 83 00 .q@..
Frequency: 7140830

rigd:
[root@local cqrlog]# /usr/local/sbin/rpc.rigd -m 1901 -r localhost -s 38400
localhost: RPC: Program not registered
rig_open: error = Invalid configuration

Still getting a rig path name error
Running cqrlog
[george@local cqrlog]$ ./cqrlog
Starting CQRLOG ...
An error has occured setting the rig pathname:/dev/ttyS0
An error has occured setting the rig pathname:/dev/ttyS0

ok2cqr
ok2cqr's picture
Re: Connectivity through rigctl only.

Hi George,

please run CQRLOG, go to File -> Preferences -> choose TRX control tab. In section for radio one, put localhost to device, into rig model put 1901, poll rate set to 500. Click to OK and close CQRLOG.

Open console and write this command:

/usr/local/sbin/rpc.rigd -m 123 -r /dev/ttyS0 -s 38400

and hit enter.

Now run CQRLOG and rigcontrol should work.

73 Petr, OK2CQR

N0NB
Hmmm, I can't convince CQRLog

Hmmm, I can't convince CQRLog to use the rpc.rigd daemon. Fldigi is using it just fine but CQRLog 0.8.4 seems to be a no-go at the moment.

I've set the device to 'localhost' and put '1901' in the rig model field (I'm using an FT-920, model 114 through rpc.rigd) and poll rate at 500, closed and restarted CQRLog (several times actually) but CQRLog refuses to see rpc.rigd. Here is the output from the terminal on a restart:

$ cqrlog/cqrlog
Starting CQRLOG ...
An error has occured setting the serial speed:4800
An error has occured setting the serial speed:4800

The configuration dialog prevents blanking the serial speed.

I also tried '127.0.0.1' instead of 'localhost' with no results.

ki4lui
Any luck NONB

Have you any luck getting it to work?

ok2cqr
ok2cqr's picture
Re: Any luck NONB

Hi,

I've asked Dan OK1HRA, he uses rpg.rigd every day with hamlib version 1.2.6.2 and it works. Newer version doesn't work with CQRLOG. I must find out why.

73 Petr, OK2CQR

ki4lui
Hrrrm don't people use hamlib

Hrrrm don't people use hamlib nightly 2.6.10 all the time?

I guess I am not understanding the difference of rigctl and rigd.

I will see if I can find the older version and test.

ki4lui

N0NB
No. Some use whatever

No. Some use whatever version their distribution provides. Since we ask that distributions not distribute the nightly builds, they wait for our stable releases. Others don't see a need to update as their rig has probably not seen any changes for a long time and if it works, why change? As one of the Hamlib developers I do try to keep current but since I've had the same rigs for several years, I don't gain much from doing so except making sure it all still works with my hardware. However, that may change as I may tackle memory functions this fall in some of the Yaesu backends.

HTH,

73, de Nate >>

N0NB
That is odd as rpc.rigd had

That is odd as rpc.rigd had been very stable. Looking at the SVN commit log rpc.rigd hasn't received but one minor update, and that was a status message, within the past five years which should cover all the way to before the 1.2.6.2 version.

If you find a bug in rpc.rigd, let me know.

73, de Nate >>

ki4lui
aye ya aye

Ok I made the changes in cqr log:
confirmed:
device = local host
rig id = 1901
poll rate = 500
baud = 38200
stop bits = 1
data bits = 8
handshake = none
parity = none

I closed cqrlog

ran the following:
[george@local cqrlog]$ /usr/local/sbin/rpc.rigd -m 123 -r /dev/ttyS0 -s 38400

executed cqrlog again and this was the result:
[george@worldgeorge cqrlog]$ ./cqrlog

Starting CQRLOG ...

An error has occured setting the serial speed:38400

An error has occured setting the serial speed:38400

I check the cqrlog tx control window and frequency is 0.00000

NOW if I just run rigctl form the command line it seems as if I do in fact have connectivity.

Sorry to bother you with such newbie stuff.

As you can see rigctl can retrieve the frequency (see below)
rigctl -vvvvv -r /dev/ttyS0 -m 123

rigctl, Hamlib version 1.2.10svn

Report bugs to

rig:rig_init called

rig: loading backend yaesu

yaesu: initrigs2_yaesu called

rig_register (121)

rig_register (127)

rig_register (110)

rig_register (105)

rig_register (106)

rig_register (107)

rig_register (109)

rig_register (120)

rig_register (101)

rig_register (122)

rig_register (123)

rig_register (111)

rig_register (115)

rig_register (113)

rig_register (114)

rig_register (128)

rig_register (116)

rig_register (103)

rig_register (124)

rig_register (104)

rig_register (125)

rig_register (129)

rig_register (130)

rig_register (117)

rig_register (119)

rig_register (118)

rig_register (126)

ft897:ft897_init called

rig:rig_open called

ft897:ft897_open called

Opened rig model 123, 'FT-897'

Backend version: 0.3.3, Status: Beta

Rig command: f

ft897: cache invalid

TX 5 bytes

0000 00 00 00 00 03 .....

RX 5 bytes

0000 14 42 00 06 01 .B...

Frequency: 144200060

N0NB
I'm seeing the same problem

I'm seeing the same problem with CQRLog and rpc.rigd as you are. Fldigi is working fine with rpc.rigd so for the moment the problem would appear to be wtih CQRLog.

N0NB
Does your user have

Does your user have permission to use the /dev/ttyS0 device? On my system my user must be in the group "dialout" as follows:

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 2009-02-17 12:45 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 2009-09-07 06:18 /dev/ttyUSB1

Typing the `groups' command at the prompt will show you the groups you're a member of.

Also, I see you've specified an incorrect parameter for the rpc.rigd '-r' option, it should be the serial IO device, i.e. '/dev/ttyS0', /dev/ttyUSB0', etc.

Please let me know if the rpc.rigd manual page (`man rpc.rigd') is unclear as I'll updated it if needed.

Please see the examples at the bottom of the manual page. You may need to specify 2 stop bits as I show. Just replace rig model 114 with 123.

Note: If you see an error such as:

Cannot register service: RPC: Unable to receive; errno = Connection refused

Then you likely need to be sure the portmapper is installed and running (on Debian based systems this is the 'portmap' package).

ki4lui
Yes perms are all rwx for now

Yes perms are all rwx for now also user george is in uucp group and has always been.

"-r" was my fault because I have been running many rigctl and rigd commands.

[george@local cqrlog]$ ls -l /dev/ttyS0

crwxrwxrwx 1 root uucp 4, 64 Sep 7 01:52 /dev/ttyS0

Man page is understandable yes. I will try the top bit =2 and reread the man page as I have several times :-)

ki4lui
Can you please read Peters

Can you please read Peters response form yesterday (its below)

He suggests -r option and so does man page
thanks
Ki4lui