hi,
I would need some advice. I am back to amateur radio, using my old K2 Elecraft, and I installed CQRLog. I am trying to connect my RS232 K2 to my computer, (linux mint) using an RS232/USB adapter.
Thanks to the previous post from w3khd , rigctld is now apparently working. But the rig control is still not there, Could you give me some ideas on how to continue to investigate .... Thanks. 73 de Pierre
Below what I have
pf@pf-W240EU-W250EUQ-W270EUQ ~ $ cqrlog
Cqrlog Ver:2.3.0 (001) Date:2018-06-17
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=1 PARAMETER ****
Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 221 -r /dev/ttyUSB0 -t 4532 -s 4800 --set-conf=data_bits=8,stop_bits=2,serial_parity=None,serial_handshake=None,dtr_state=OFF,rts_state=OFF
RunRigCtld: TRUE
RigDevice: /dev/ttyUSB0
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 1000
RigSendCWR: FALSE
RigId: 221
Starting RigCtld ...
/usr/bin/rigctld -m 221 -r /dev/ttyUSB0 -t 4532 -s 4800 --set-conf=data_bits=8,stop_bits=2,serial_parity=None,serial_handshake=None,dtr_state=OFF,rts_state=OFF
rigctld started!
Connected to localhost:4532
Warning: For better performance, background image should be the same size as the output image
Warning: Can't find /home/pf/.config/cqrlog/xplanet/marker in
xplanet/markers
/home/pf/.xplanet/markers
/usr/share/xplanet/markers
Warning: Can't load marker file /home/pf/.config/cqrlog/xplanet/marker
Sending: fmv
rig_open: error = Communication timed out
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
./......
Looks good.
Are you sure the rig port is /dev/ttyUSB0 ?
While having rig on and connected, no need to run cqrlog, open console and give:
ls -l /dev/ttyUSB*
You should see something like:
[saku@hamtpad ~]$ ls -l /dev/ttyUSB*
crw-rw----. 1 root dialout 188, 0 7.10. 15:27 /dev/ttyUSB0
crw-rw----. 1 root dialout 188, 1 7.10. 16:01 /dev/ttyUSB1
[saku@hamtpad ~]$
Pull the rig cable off (at PC's side) and give same command. Did ttyUSB0 disappear? If so, put it back and again give same command. You can use "arrow up" on keyboard to get last command without typing, it needs just enter then.
If the port really was right was there a text "dialout" after root?
Give next:
groups your_username
You should see something like:
[saku@hamtpad ~]$ groups saku
saku : saku dialout lock
[saku@hamtpad ~]$
Is the "dialout" there. If not give:
sudo adduser dialout your_username
After that it should work.
If all that is ok but no connection, you could try from console:
/usr/bin/rigctl -m 221 -r /dev/ttyUSB0 -vvvvv
NOTE that is rigctl (without d at the end)!
You should get long list and finally "Rig command:"
giving
f (enter)
should show frequency in Hz
If it does not work you see some error texts. What?
If it works giving
q (enter) stops program.
If that worked you could try TRXControl settings so that you put all selectors to "Default". Then it is the same situation as in console test.
Check also that your hamlib is latest version (at least 3.xx).
[saku@hamtpad ~]$ rigctl --version
rigctl, Hamlib 3.1
Copyright (C) 2000-2012 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.
[saku@hamtpad ~]$
--
Saku
OH1KH
I also have an Elecraft K2 and appreciate this thread!
I was going through the steps outlined and "dialout" was a group that my userid was NOT associated with. When I attempted the command suggested:
sudo adduser dialout your_username.. this did not work. The correct command to add your_username is:
sudo addgroup your_username dialoutThen repeat the command:
groups your_usernameto verify that the dialout group has been added.
Bob KC2JAV
Hi Bob!
In my Fedora 28 there is no command addgroup, but adduser exist. Seems to be distribution related command.
Anyway main thing is to get user in dialout group.
Did you manage to get your K2 working?
With Pierre's K2 we end up thinking the fault is in K2, not in settings or cabels.
--
Saku
OH1KH
Hi Saku! I have not got it working yet - still trying to resolve installation of cqrlog on my Linux Mint 19 system (command differences between Fedora and Debian-based distros noted) - but I noticed this thread and wanted to keep tabs on the outcome. I will re-post when I get things working!
Bob KC2JAV
Hello Saku,
Many thanks for your help and advice. Unfortunately, my system is still not working.
a) Hamlib is version 3.3
b)Port is ttyUSB0
c)I am member of dialout
d)running rigctl for my K2 (rig 221) finish with rig_open: error = Communication timed out
See file below. 73 de Pierre
pf@pf-W240EU-W250EUQ-W270EUQ ~ $ rigctl --version
rigctl, Hamlib 3.3
Copyright (C) 2000-2012 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.
pf@pf-W240EU-W250EUQ-W270EUQ ~ $ groups
pf adm proxy dialout cdrom sudo dip plugdev lpadmin sambashare
pf@pf-W240EU-W250EUQ-W270EUQ ~ $ /usr/bin/rigctl -m 221 -r /dev/ttyUSB0 -vvvvv
rigctl, Hamlib 3.3
Report bugs to
rig_init called
initrigs3_kenwood called
rig_register called
rig_register: rig_register (213)
rig_register called
rig_register: rig_register (201)
rig_register called
rig_register: rig_register (225)
rig_register called
rig_register: rig_register (203)
rig_register called
rig_register: rig_register (204)
rig_register called
rig_register: rig_register (216)
rig_register called
rig_register: rig_register (224)
rig_register called
rig_register: rig_register (205)
rig_register called
rig_register: rig_register (207)
rig_register called
rig_register: rig_register (209)
rig_register called
rig_register: rig_register (210)
rig_register called
rig_register: rig_register (222)
rig_register called
rig_register: rig_register (214)
rig_register called
rig_register: rig_register (230)
rig_register called
rig_register: rig_register (221)
rig_register called
rig_register: rig_register (229)
rig_register called
rig_register: rig_register (238)
rig_register called
rig_register: rig_register (202)
rig_register called
rig_register: rig_register (211)
rig_register called
rig_register: rig_register (206)
rig_register called
rig_register: rig_register (208)
rig_register called
rig_register: rig_register (215)
rig_register called
rig_register: rig_register (226)
rig_register called
rig_register: rig_register (217)
rig_register called
rig_register: rig_register (233)
rig_register called
rig_register: rig_register (220)
rig_register called
rig_register: rig_register (223)
rig_register called
rig_register: rig_register (227)
rig_register called
rig_register: rig_register (234)
rig_register called
rig_register: rig_register (231)
rig_register called
rig_register: rig_register (239)
rig_register called
rig_register: rig_register (237)
rig_register called
rig_register: rig_register (228)
rig_register called
rig_register: rig_register (219)
rig_register called
rig_register: rig_register (232)
rig_register called
rig_register: rig_register (236)
rig_register called
rig_register: rig_register (240)
kenwood_init called
kenwood_init: if_len = 37
rig_open called
port_open called
serial_open called
serial_setup called
k2_open called
elecraft_open called, rig version=20120615
elecraft_open: rig_model=221,238
verify_kenwood_id called
kenwood_get_id called
kenwood_transaction called
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2076 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2026 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2063 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2047 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2069 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2060 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2028 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2058 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.1452 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2067 seconds after 0 chars
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): Timed out 2.2039 seconds after 0 chars
verify_kenwood_id: cannot get identification
rig_open: error = Communication timed out
HI!
Yep!
It seems that rigctld can not talk with rig. And that leads to situation that cqrlog can not get anything from rigctld.
I googled a littel bit and found this:
http://www.elecraft.com/manual/KIO2%20Pgmrs%20Ref%20rev%20E.pdf
Seems that communication format is same as with many Kenwoods. I have played a bit with TS50.
We have to look more what happens between rig and PC.
But before that, do you have an other program that works with K2? What I mean is that your connection cable and serial ports (at rig end and at pc end) are working and not broken that could be tested with that another program.
What kind of connection (cable) you have? Home made / bought from dealer ?
Try open console and give:
minicom -s
Minicom is a terminal program that is handy when testing serial ports. Originally made for operating with old phone line modems. If you do not have it you could install it:
sudo apt-get minicom
If minicom starts (with parameter -s) it goes right to setup. Choose serial port settings and set port to /dev/ttyUSB0
and speed to 4800 8N2 (8bits no parity 2 stop bits) that is default for Kenwoods.
Now you should be able to "talk" to K2
typing:
if;
should give lot of data (see link above, page 7)
Note that ; is "enter" for kenwoods You should end command with ; no enter/return is needed.
If you can not get anything pull the plug from rig and connect RXdata and TXdata together from rig end connector of your connection cable. When they are connected every character you type in minicom should return to your screen. And when you open connection this does not happen any more.
That verifies your PC's serial port and the connection cable. If there is no echo back you have faulty PC port, connection cable or the port device name is wrong and it is something else than ttyUSB0.
If characters echo back when RXdata and TXdata pins are together yo need to check that you have right speed and settings (4800,8N2) in minicom and also in rig (if they can be changed from rig setup).
If they are right you have to suspect rigs serial port. Is it broken?
That needs another setup (another ham) where you can test your rig to his PC and his rig to your PC.
How ever problem is now between rig and PC, not in cqrlog itself. It must be cleared out first,
File:
--
Saku
OH1KH
Hello Saku,
Your proposed logic of testing is very helpful, many thanks. I was travelling last days, so I was able to restart my tests only now.
My set-up is the following:
a) PC, with USB port cable.
b) serial USB / DB9 adapter. I have 2 cables, one FDTI and one with Prolific chip.
c)home made DB9 male/female cable, made, according to the elecraft instructions, specific for the Elecraft K2 use.
d) Rig K2 Elecraft.
I downloaded minicom, ran sudo minicom -s , set the serial parameters as per the elecraft sheet (4800 8N2 ), saved this configuration and than ran minicom.
My 2 usb/serial cables are echoing the typed characters when the TX/RX loop back is installed.
With my home made K2 communication cable, I also have the echo, when the loop back is installed at the end of these cables.
I do not have any answer from the K2, which has its port activated in the K2 set up menu.
So, with your help and guidance, it is now clear that the problem is with my K2. So I will later continue my investigations, first digging with the K2 software aspects, and then with the RS232 hard interface. I suspect a faulty interface....will see.
Since I am back to amateur radio after a long interruption, I need to rebuild some functioning capabilities, hard, but also intellectual.
Your advices were really helpful in this matter. Many thanks.
I will post my findings, if any.
73 de Pierre
HI Pierre!
Nice to hear that you succeeded with serial wire loopback tests. That proves your PC and cable are ok.
Sad to hear that problem is in rig.
I wish there is a parameter in setup that is forgotten to change. I do not know K2, so there is not much help to give about that.
One thing I must say:
REMEMBER GROUNDINGS !!!
Your PC, specially if it is a tower model, with its own power supply MUST be grounded to same ground as your rig.
BEFORE you pull or push any cable between them.
Laptops are not so critical as their power supply is isolated between mains and low voltage what comes to PC's case ground.
Tower PC powers have often (nearly 100%) switching power supply qrm filter at the mains line. That filter has 2 capacitors from Live(brown) to case Gnd(yellow/green) and from Neutral (blue) to case Gnd(yellow/green).
If case Gnd (yellow/green) is not connected at all (no Gnd at mains socket) , or has different potential than rig the potential difference between rig and PC may be 110VAC at worst case in 220V mains system.
Because these filter capacitors are very small (few nF) the floating case voltage is not dangerous between rig and PC when they have no connection you can feel it, but it has enough current and voltage to destroy serial port components. Either at PC end or rig end.
So remember grounding, at least have a wire between PC case and rig case that is under screws so that it is always present.
--
Saku
OH1KH
Hello Saku,
I am back again
I would again need your advice. I am still trying read the rig frequency in the qso window of cqrlog.
New computer, so I re-installed CQRlog.
Another serial port on my rig Elecraft K2.
The battle with the membership of dialout, changing permissions for the access of ttyUSB, etc...
Your forum and reading the history is helpful !
Here is where I am
a) rigctl is working.
When running rigctl in a terminal , rigctl is reading the different parameters of my rig, and with the command, I can display the frequency, mode, etc. No doubts, the job is done.
b) In CQRLOG, the frequency of my rig is not displayed in the qso window.
When I load cqrlog , (with the rigctl box checked, to make sureit is starting) ,I think that rigctl is starting (I have some noise in my rig when I start rigctl in the terminal, I have the same noise when I start cqrlog). The command ps aux is showing rigctl.
BUT the frequency of my rig is NOT displayed in the qso window.
So....Where to look now ? Any idea.
regards, Pierre F5MOG
Hello
CQRlog, no reading in TRX control, while rigctld is running and connected to the radio
When I start CQRlog, with the rigctld box checked, rigctld is starting. BUT I have NO FREQUENCY DISPLAY in the qso window.
Below is the line I obtain, when I run ps aux
/usr/bin/rigctld -m 221 -r /dev/ttyUSB0 -t 4532 -s 4800 --set-conf=data_bits=8,stop_bits=2,serial_parity=None,serial_handshake=None
I then unckecked the box Run rigctld when program starts.
I started manually rigctld in a terminal, copying the line obtained with ps aux. Then I started CQRlog.
Now the frequency of my rig is displayed in the QSO window.
Weird....
Any explanations. Any trick to solve this issue ?
Regards
Hi Pierre,
I had the same inconvenience and I solved it definitely.
If you have several programs that manage, at the same time, the same serial or USB port, this will eventually create problems like the failure of connected to the radio, due of writing overlay on the same device.
When you start CQRLOG with the "Run rigctld when program starts" active flag , rigctld is started a second time and this creates one overlapping.
For this you have to kill the rigctld process and re-execute rigctld start manually, in order to connect the radio correctly.
To solve this problem, I followed Saku's advice using the rigctl communication via TCP.
Below the link where to download the info on how to configure:
setting_rigctld_for_all_programs.pdf
73
Giuseppe IK0DWJ
--
Giuseppe
IKØDWJ
Thanks Giuseppe.
I do not think I am in a situation where rigctld is to be used by multiple programs.
The problem is apparently linked wirth a sequence.
If rigctld is started by CQRlog, I have no display of frequency.
if I start CQRLog and, then I start separately rigctld, I have no frequency display.
If I start rigctld, first, and then I start CQR log, the frequency / modes are displayed.
Regards, Pierre F5MOG
Hi Pierre,
if the third condition works, I do not see the problem anymore. For your system is the correct starting sequence. Unfortunately, the control commands are not always consistent, hamlib has the task of translating them into the appropriate commands but not everything is always perfect. Fortunately, in your case the solution is simple, just create a link that runs first rigctld and then cqrlog and everything will be fine.
In any case, to take full advantage of rigctld, the next step is to follow what was said in my previous answer. This configuration could also solve your case, in my opinion you should try.
73
Giuseppe IK0DWJ
--
Giuseppe
IKØDWJ
Hi Giuseppe,
Your comments were helpful. And since you had same inconvenience I have, and solved it, It gave me some motivation to start it.
With all the tests and trials I did, I came to the conclusion that rigctld NEEDS to run BEFORE CQRLOG is started.
Therefore I did 2 things
1)make sure rigctld is (almost )continuously running. I used the method recommended by Saku. If rigctld is not running, it will start automatically within one minute.
http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...
2) automatically start rigctld when I start the computer. I added the ¨rigctld_start.sh¨ described by Saku in the Linux Mint list of programs which are starting automatically.
This method is working.
However, if I refresh the TRX/ROT control from the CQRLOG file menu, I am loosing the freq/mode display, and I have to restart cqrlog, making sure that rigctld is running before. A minor constraint, since the refresh TRX/ROT is not often used, once set with the correct parameters.
Connecting my rig to CQRLOG was not userfriendly. It took me some time to set it up, but at least it is giving me the result I wanted.
Thanks you, thanks to the forum, which was of great help.
Regards, Pierre
Hi Pierre.
When you loose freq display and you have started rigctld separately before cqrlog you can also try to switch to rig2 at TRXcontrol window and then back to rig1.
rig2 does not need to be configured.
Switch of rigs will kill and restart rigctld connection of cqrlog.
You can use it also if rigctld dies and you start it again form command line. After that just switch rigs and cqrlog can catch the started rigctld again.
--
Saku
OH1KH
Hi!
I was reading again the whole thread.
OK. Now you start rigctld separately before cqrlog. And then it works. If you refres TRXcontrol it stops.
I think you have wrong settings in cqrlog/preferences/TRXcontrol
Did you read my document from page that sows TRXcontrol settings page?
Look at my current settings (image).
That is just for you. All you need to change is rig name if you like, but it is just cosmetic.
Just copy this to your TRXControl. Do NOT state rig model other than 2! No serial port value is needed!
Then test the refresh TRXcontrol.
I just tested. First frequency goes to 0.000 and after a while right display comes back.
The time is depended on poll rate.
File:
--
Saku
OH1KH
Hi Saku,
When I go to radio 2 on the TRX control screen, and I switch to radio 2, you are right, this is killing rigctld.
But when rigctld is back, the frequency display is not anymore refreshed.
Which brings back my comment. With what I have (linux Mint 19 + K2 & cable serial/USB), to get the frequency display, I need to have rigctld running BEFORE CQRLOG is started.
Regards, Pierre F5MOG
Hi!
What I mean is that if your rigctld (that has started before cqrlog) for some reason dies you can start it again (via console) and AFTER that just switch rig1->rig2->rig1. There is no need to close cqrlog. Switching rigs will refresh cqrlog connection to newly started rigctld.
Here is the script I'm currently using. I have 2 rigs IC7300 and IC706.
This script is called from crontab every minute:
It accepts parameters "start" stop" and "restart"
[saku@hamtpad ~]$ crontab -l
#
* * * * * /home/saku/rigctld_start.sh start > /dev/null 2>&1
[saku@hamtpad ~]$ cat rigctld_start.sh
#!/bin/bash
#
/usr/bin/date >> /tmp/start.log
case "$1" in
start)
#
# Nothing to do if it is already running.
#
a=$(/usr/bin/pidof rigctld)
if [ "$a" != "" ]; then
echo "Already running." >> /tmp/start.log
else
/usr/bin/date >> /tmp/start.log
/usr/bin/rigctld -m 309 -r /dev/rig -t 14532 -p /dev/rig -P RTS -s 19200 --set-conf=serial_handshake=None,dtr_state=Unset,rts_state=Unset &
/usr/bin/rigctld -m 373 -r /dev/icom7300 -t 4532 -s 19200 &
echo "Started." >> /tmp/start.log
fi
;;
stop)
killall rigctld
killall rigctld
echo "Killed." >> /tmp/start.log
;;
restart)
echo "Restarting." >> /tmp/start.log
killall rigctld
killall rigctld
echo "Killed." >> /tmp/start.log
#
# Nothing to do if it is already running.
#
a=$(/usr/bin/pidof rigctld)
if [ "$a" != "" ]; then
echo "Already running." >> /tmp/start.log
else
/usr/bin/date >> /tmp/start.log
/usr/bin/rigctld -m 309 -r /dev/rig -t 14532 -p /dev/rig -P RTS -s 19200 --set-conf=serial_handshake=None,dtr_state=Unset,rts_state=Unset &
/usr/bin/rigctld -m 373 -r /dev/icom7300 -t 4532 -s 19200 &
echo "Started." >> /tmp/start.log
echo "Restarted." >> /tmp/start.log
fi
;;
esac
echo "-----------------------" >> /tmp/start.log
It produces log like that (that disappears from /tmp in every PC restart):
[saku@hamtpad ~]$ cat /tmp/start.log
ma 4.2.2019 15.46.24 +0200
-----------------------
ma 4.2.2019 15.47.01 +0200
ma 4.2.2019 15.47.01 +0200
Started.
-----------------------
ma 4.2.2019 15.48.01 +0200
Already running.
-----------------------
ma 4.2.2019 15.49.01 +0200
Already running.
-----------------------
ma 4.2.2019 15.50.02 +0200
Already running.
-----------------------
ma 4.2.2019 15.50.05 +0200
Restarting.
Killed.
ma 4.2.2019 15.50.05 +0200
Started.
Restarted.
-----------------------
ma 4.2.2019 15.51.01 +0200
Already running.
-----------------------
ma 4.2.2019 15.52.01 +0200
Already running.
-----------------------
ma 4.2.2019 15.53.01 +0200
Already running.
-----------------------
ma 4.2.2019 15.54.01 +0200
Already running.
--
Saku
OH1KH