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)
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
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
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
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
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
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
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
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
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
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...
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.
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
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.
"an Error occurred setting the rig to pathname:/dev/ttyS0"
Has anyone seen this before by chance?
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
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Thanks for the help I will get on it as soon as I get home.
G ki4lui
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
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
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
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.
Have you any luck getting it to work?
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
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
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
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 >>
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 >>
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
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.
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).
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 :-)
Can you please read Peters response form yesterday (its below)
He suggests -r option and so does man page
thanks
Ki4lui