Rig is an FT1000-MP and using a USB to Serial therefore the device is /dev/ttyUSB0. The serial parameters are correct. The port default is 4532. The program is not communicating with the radio. What am I missing here? No idea how to check the Ubuntu 16.04 port the radio is actually connected to in Settings.
CQRLOG was downloaded from Petr's PPA.
New to Linux how do I check the port and if the drivers are working for the usb/serial?
73
john
Check your port with this script:
#!/bin/bash
for sysdevpath in $(find /sys/bus/usb/devices/usb*/ -name dev); do
(
syspath="${sysdevpath%/dev}"
devname="$(udevadm info -q name -p $syspath)"
[[ "$devname" == "bus/"* ]] && continue
eval "$(udevadm info -q property --export -p $syspath)"
[[ -z "$ID_SERIAL" ]] && continue
echo "/dev/$devname - $ID_SERIAL"
)
done
Thanks ok1rr.
The device USB0 is listed properly but still no work.
You suggest what else I may check?
73
john
dev/sdb - USB_Mass_Storage_Device_816820130806-0:0
/dev/ttyUSB0 - Prolific_Technology_Inc._USB-Serial_Controller_D
/dev/input/event2 - Logitech_USB_Receiver
/dev/input/mouse0 - Logitech_USB_Receiver
/dev/input/event3 - Logitech_USB_Receiver
Hi John,
your USB0 seems OK although the Prolific chip is not as reliable as it should be. A replacement with FTDI chip is recommended. I made very good experience with cheap chinese CH340 which has a built-in kernel support in the same way, as FTDI and Prolific has. Check if rigctld runs properly - it must be listed if you dump the running processes with ps aux command
martin 7862 0.4 0.1 369204 33288 ? Sl 17:58 0:00 lxterminal
martin 7865 0.0 0.0 31060 5172 pts/0 Ss 17:58 0:00 bash
martin 7877 9.9 0.3 671552 106884 ? Sl 17:58 0:01 cqrlog
martin 7880 2.2 0.4 1511808 147048 ? Sl 17:58 0:00 /usr/sbin/mysqld --defaults-file=/home/martin/.config/cqrlog/database/mysql.cnf --datadir=/home/martin/.conf
martin 7913 0.0 0.0 104580 4708 ? Sl 17:59 0:00 /usr/bin/rigctld -m 229 -r /dev/ttyS4 -t 4532
martin 7920 0.0 0.0 47996 3560 pts/0 R+ 17:59 0:00 ps aux
(look onto process 7913)
Do you have checked the option 'Run rigctld when program starts' in Preferences -> TRX Control?
73,
Martin, OK1RR
File:
Martin,
Ordered a FTDI chip cable. Be here Wednesday and yes the "run rigctld on startup" is checked.
Ran the ps aux command and rigctld is NOT running.
john
John,
you hit the nail. The NOT running rigctld is the culprit. Check your hamlib installation
73 Martin
Not able to find why rigctld is not running and checking everything in the parameters I removed cqrlog with
to delete the configuration file.
I then and now have an error window stating "Access Violation. Press OK to ignore and risk data corruption. Press Cancel to kill the program."
73 john
Disregard my previous reply. Not sure what happened but some aspects of it are not there.
Uninstalling and reinstalling hamlib to no avail I removed cqrlog using sudo apt-get purge cqrlog and then did a complete
install using sudo apt-get install cqrlog. I now have have a window stating
Access violation. Press OK to ignore and risk data corruption. Press Cancel to kill the program.
73 john
Uninstalled and reinstalled. CQRLOG is now running dxcluster, qso window, but still no rigctrld.
what does ps aux?
Check /usr/bin/ if rigctld is present. Try to run it. If does not work, try in /usr/bin/
ldd rigctld
to check missing parts. I suggest to place the result here.
Remember to check the option 'Run rigctld when program starts' in Preferences->TRX control.
ps aux shows no rigctld. rigctld is present in /usr/bin/ but I don't know how to run it and I don't understand what you mean by trying in /usr/bin/
ldd rigctld to check for missing parts.
The option Run righctld when program starts in Preferences>TRX control is checked.
73 john
john@JohnsComputer:~$ ldd /usr/bin/rigctld
linux-vdso.so.1 => (0x00007ffe1ed7d000)
libhamlib.so.2 => /usr/lib/libhamlib.so.2 (0x00007fac0d3ea000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fac0d1ca000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fac0cdfa000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007fac0cbea000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fac0c8da000)
libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007fac0c6ca000)
/lib64/ld-linux-x86-64.so.2 (0x00007fac0d60a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fac0c4c2000)
????
73 john
John,
ps aux shows all running processes.
We need to test that rigctld is there and is able to run.
In terminal, write /usr/bin/rigctld
rigctld is a daemon (a process running in the background) and shows no terminal output if is run in so simple way.
To verify that rigctld can be run you need another terminal instance (ie. you will have TWO terminals running simultaneously). Open the terminal again and run ps aux. rigctld must be there as the attached image shows.
This will verify if your rigctld is functional.
In the next step we will investigate why rigctld does not start up if you start CQRlog and the appropriate option in Preferences is checked.
73 Martin
File:
I do not know how to run a second Terminal while the first is open. Sorry for my inexperience in basic Linux.
Ok Martin. Opened a second terminal and ran ps aux and rigctld is NOT there.
73 john
What happens if you try to start up rigctld by typing
/usr/bin/rigctldinto terminal?
BTW are you member of
dialoutgroup?
Typing that command into the terminal the cursor blinks and nothing more.
I am not a member of the dialout group. Never heard of it.
John,
you MUST be a member of dialout group to have access to ports!
Try
sudo usermod -a -G dialout $USER
Assumed that your user name is john, just type
sudo usermod -a -G dialout $john
You should log out and log in back or restart your machine. Verify that you belong to the group using
getent group dialout
your name must be listed.
73 Martin
What option do I put at the prompt Martin?
73 john
john@JohnsComputer:~$ sudo usermod -a -G dialout $john
[sudo] password for john:
Usage: usermod [options] LOGIN
Options:
-c, --comment COMMENT new value of the GECOS field
-d, --home HOME_DIR new home directory for the user account
-e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
-f, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-g, --gid GROUP force use GROUP as new primary group
-G, --groups GROUPS new list of supplementary GROUPS
-a, --append append the user to the supplemental GROUPS
mentioned by the -G option without removing
him/her from other groups
-h, --help display this help message and exit
-l, --login NEW_LOGIN new value of the login name
-L, --lock lock the user account
-m, --move-home move contents of the home directory to the
new location (use only with -d)
-o, --non-unique allow using duplicate (non-unique) UID
-p, --password PASSWORD use encrypted password for the new password
-R, --root CHROOT_DIR directory to chroot into
-s, --shell SHELL new login shell for the user account
-u, --uid UID new UID for the user account
-U, --unlock unlock the user account
-v, --add-subuids FIRST-LAST add range of subordinate uids
-V, --del-subuids FIRST-LAST remove range of subordinate uids
-w, --add-subgids FIRST-LAST add range of subordinate gids
-W, --del-subgids FIRST-LAST remove range of subordinate gids
-Z, --selinux-user SEUSER new SELinux user mapping for the user account
john@JohnsComputer:~$
john@JohnsComputer:~$ getent group dialout
dialout:x:20:
john@JohnsComputer:~$
Screenshot of Preferences
File:
John,
your preferences looking OK, you are also member of dialout - OK.
Start up CQRlog from terminal. I would recommend to use Midnight Commander (mc) which can save you a lot of typing. So, I would navigate to /usr/bin/cqrlog and ENTER. Now CQRlog runs from there.
Open the terminal again (new instance) and type ps aux. Check if rigctld runs, provide possibly a screenshot of this terminal instance.
73 Martin
Midnight Commander command /usr/bin/cqrlog resulted immediately with this Martin. Did not go further with opening the
terminal again.
john@JohnsComputer:~$ /usr/bin/cqrlog
Cqrlog Ver:2.3.0 (001) Date:2018-06-17
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=1 PARAMETER ****
180927 6:37:29 [Note] /usr/sbin/mysqld (mysqld 10.0.36-MariaDB-0ubuntu0.16.04.1) starting as process 3146 ...
rig_open: error = IO error
73
john
Using the ps aux command in another terminal resulted in this. There is no rigctld file.
ohn 3298 0.0 0.2 61628 7652 pts/0 Ss+ 06:41 0:00 mc
john 3300 0.0 0.1 22640 5304 pts/18 Ss 06:41 0:00 bash -rcfile .b
john 3312 2.0 3.1 859740 102680 pts/18 Sl+ 06:42 0:01 /usr/bin/cqrlog
john 3322 0.4 2.4 670936 79632 pts/18 Sl+ 06:42 0:00 /usr/sbin/mysql
john 3383 0.5 0.1 22636 5300 pts/19 Ss 06:43 0:00 bash
john 3394 0.0 0.1 37364 3384 pts/19 R+ 06:43 0:00 ps aux
john@JohnsComputer:~$
Hi!
There are 3 Yeasus:
[saku@hamtpad ~]$ rigctl -l | grep FT-1000
103 Yaesu FT-1000D 0.0.6 Alpha
104 Yaesu MARK-V FT-1000MP 0.0.5 Alpha
124 Yaesu FT-1000MP 0.1.1 Beta
125 Yaesu MARK-V Field FT-1000MP 0.0.5 Alpha
Be sure to select right rig type.
Open console, give command:
whereis rigctld
whereis rigctl
You should get something like:
[saku@hamtpad ~]$ whereis rigctld
rigctld: /usr/bin/rigctld /usr/local/bin/rigctld /usr/share/man/man1/rigctld.1.gz
[saku@hamtpad ~]$ whereis rigctl
rigctl: /usr/bin/rigctl /usr/local/bin/rigctl /usr/share/man/man1/rigctl.1.gz
[saku@hamtpad ~]$
Open your rig and then give command (check the rig model and port to be right):
rigctl -m 124 -P /dev/ttyUSB0 -vvvvv
if it does not start check previous command what is the complete path for rigctl and use that instead.
It should start rigctl in terminal mode (not daemon as it has command rigctld). "vvvvv"s make it very verbose telling what happens.
It looks like that:
[saku@hamtpad ~]$ /usr/bin/rigctl -m 373 -r /dev/icom7300 -vvvvv
rigctl, Hamlib 3.2
Report bugs to
rig_init called
icom: _init called
rig_register called
rig_register: rig_register (355)
rig_register called
rig_register: rig_register (309)
rig_register called
rig_register: rig_register (310)
rig_register called
rig_register: rig_register (311)
rig_register called
rig_register: rig_register (313)
rig_register called
rig_register: rig_register (314)
rig_register called
rig_register: rig_register (315)
rig_register called
rig_register: rig_register (319)
rig_register called
rig_register: rig_register (320)
rig_register called
rig_register: rig_register (321)
rig_register called
rig_register: rig_register (322)
rig_register called
rig_register: rig_register (367)
rig_register called
rig_register: rig_register (323)
rig_register called
rig_register: rig_register (346)
rig_register called
rig_register: rig_register (324)
rig_register called
rig_register: rig_register (328)
rig_register called
rig_register: rig_register (330)
rig_register called
rig_register: rig_register (326)
rig_register called
rig_register: rig_register (327)
rig_register called
rig_register: rig_register (347)
rig_register called
rig_register: rig_register (357)
rig_register called
rig_register: rig_register (363)
rig_register called
rig_register: rig_register (329)
rig_register called
rig_register: rig_register (362)
rig_register called
rig_register: rig_register (345)
rig_register called
rig_register: rig_register (356)
rig_register called
rig_register: rig_register (375)
rig_register called
rig_register: rig_register (360)
rig_register called
rig_register: rig_register (370)
rig_register called
rig_register: rig_register (361)
rig_register called
rig_register: rig_register (373)
rig_register called
rig_register: rig_register (378)
rig_register called
rig_register: rig_register (331)
rig_register called
rig_register: rig_register (312)
rig_register called
rig_register: rig_register (316)
rig_register called
rig_register: rig_register (332)
rig_register called
rig_register: rig_register (334)
rig_register called
rig_register: rig_register (344)
rig_register called
rig_register: rig_register (368)
rig_register called
rig_register: rig_register (335)
rig_register called
rig_register: rig_register (369)
rig_register called
rig_register: rig_register (377)
rig_register called
rig_register: rig_register (336)
rig_register called
rig_register: rig_register (358)
rig_register called
rig_register: rig_register (337)
rig_register called
rig_register: rig_register (338)
rig_register called
rig_register: rig_register (339)
rig_register called
rig_register: rig_register (340)
rig_register called
rig_register: rig_register (341)
rig_register called
rig_register: rig_register (342)
rig_register called
rig_register: rig_register (343)
rig_register called
rig_register: rig_register (366)
rig_register called
rig_register: rig_register (303)
rig_register called
rig_register: rig_register (304)
rig_register called
rig_register: rig_register (306)
rig_register called
rig_register: rig_register (307)
rig_register called
rig_register: rig_register (302)
rig_register called
rig_register: rig_register (352)
rig_register called
rig_register: rig_register (353)
rig_register called
rig_register: rig_register (351)
rig_register called
rig_register: rig_register (364)
rig_register called
rig_register: rig_register (365)
rig_register called
rig_register: rig_register (354)
rig_register called
rig_register: rig_register (371)
rig_register called
rig_register: rig_register (372)
rig_register called
rig_register: rig_register (374)
rig_register called
rig_register: rig_register (376)
icom_init called
icom_init: civ_version=1
rig_open called
port_open called
serial_open called
serial_setup called
rig_get_vfo called
Opened rig model 373, 'IC-7300'
rig_strstatus called
Backend version: 0.8.3, Status: Stable
Rig command:
When you get prompt "Rig command:" (if you get it. Otherwise you get reason why it does not start)
Then give letter f and enter.
You should get current rig frquency.
giving q enter stops the rigctl and you get command prompt back.
Rig command: f
rig_get_freq called
icom_get_freq called
serial_flush called
write_block called
write_block(): TX 6 bytes
0000 fe fe 94 e0 03 fd ......
read_string called
read_string(): RX 6 characters
0000 fe fe 94 e0 03 fd ......
read_string called
read_string(): RX 11 characters
0000 fe fe e0 94 03 00 40 07 14 00 fd ......@....
from_bcd called
Frequency: 14074000
Rig command: q
rig_close called
port_close called
ser_close called
rig_cleanup called
icom_cleanup called
[saku@hamtpad ~]$
When rigctl does what you want you may try rigctld with same parameters (from console adding just one parameter more: -t 4352)
If it starts ok you can try cqrlog with same settings (without extra parameter -vvvvv)
--
Saku
OH1KH
Here you go Saku:
john@JohnsComputer:~$ rigctl -m 124 -P /dev/ttyUSB0 -vvvvv
rigctl, Hamlib 1.2.15.3
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 (131)
rig_register (116)
rig_register (103)
rig_register (124)
rig_register (104)
rig_register (125)
rig_register (129)
rig_register (132)
rig_register (130)
rig_register (117)
rig_register (119)
rig_register (118)
rig_register (126)
rig_register (133)
ft1000mp: ft1000mp_init called
rig:rig_open called
serial_open: Unable to open /dev/ttyS0 - Permission denied
rig_open: error = IO error
john@JohnsComputer:~$
Any suggestions? New USB to Serial FTDI. Works on Windows 7 with another logging program to verify.
John,
your setup seems promising. The main problem is to find the right radio type and the port. From previous dumps it seems to be USB0 but with the proper radio type can't help (never had any Yaesu). Try radio type 103, 104, 124 or 125. Set the poll rate to 500, this is an very acceptable value. The port comm parameters are usually:
serial_rate = 4800
serial_data_bits = 8
serial_stop_bits = 2
serial_parity = NONE
serial_handshake = NONE
serial_open: Unable to open /dev/ttyS0 - Permission denied
rig_open: error = IO error
That is the key!
You are not in dialup group, or that group does not have rights to access /dev/ttyUSB0.
In console try:
cat /etc/group | grep john
Should see like this:
[saku@hamtpad ~]$ cat /etc/group | grep saku
dialout:x:18:saku,test,test2,svxlink
lock:x:54:saku
saku:x:1001:
Then give:
ls -l /dev/ttyUSB0
Should see:
[saku@hamtpad ~]$ ls -l /dev/ttyUSB0
crw-rw----. 1 root dialout 188, 0 27. 9. 19:28 /dev/ttyUSB0
[saku@hamtpad ~]$
If your username is in line with dialout, and on second try you get "root,dialout" it should work.
Assume there is problem in one.
--
Saku
OH1KH
john@JohnsComputer:~$ cat /etc/group | grep john
adm:x:4:syslog,john
cdrom:x:24:john
sudo:x:27:john
dip:x:30:john
plugdev:x:46:john
lpadmin:x:113:john
john:x:1000:
sambashare:x:128:john
john@JohnsComputer:~$
What option do I put at the prompt Martin?
73 john
john@JohnsComputer:~$ sudo usermod -a -G dialout $john
[sudo] password for john:
John, you had typing error above. Right line is without $
sudo usermod -a -G dialout john
--
Saku
OH1KH
john@JohnsComputer:~$
When I open the Terminal this is the prompt.
john
NO no..
Look again. you had $john, not john (without $). I do not mean first (prompt) $
--
Saku
OH1KH
NO no..
Look again. you had $john, not john (without $). I do not mean first (prompt) $
I mean you typed:
sudo usermod -a -G dialout $john (see message #30)
you should type:
sudo usermod -a -G dialout john (leave the $ away from beginning of username)
As you see in message #29 you are not in dialup group.
Give again right typed line:
sudo usermod -a -G dialout john
Then check again with :
cat /etc/group | grep john
--
Saku
OH1KH
Thank you Martin and Saku. This has been and will continue to be a great learning experience for me. At times it was frustrating but thanks to the both of you much knowledge has been gained not only about this fine program but Linux in general.
As I turn the vfo dial cqrlog's qso frequency window now tracks but have an issue clicking on a spot in the dx cluster window. The call is entered but the mode and frequency takes anywhere from 2-5 minutes for the to change and many times an inaccurate call and frequency results. Polling is set to 500.
73 john
Hi John.
Nice to hear your progress with linux and cqrlog.
May I suggest that you continue with your problem as follows:
From preferences/TRXControl
- drop the pollrate. 500ms might be to fast if your rig uses 4800baud as Martin suspected. Try with 1000 or 1500 (1-1,5sec) it is still fast enough.
If that does not help you have to dig out why rig does not move. Long time, as you said 2-5min (!!!), looks like communication error between rig and rigctld that would explain wrong frequency (but not wrong callsign).
To find the reason drop the poll rate (just for testing period) to 5000. Then uncheck "Run rigctld at program start" .
Open console and give command:
ps ax | grep rig
Copy the text from line having "rigctld" starting from point /usr/bin/rigctld till the end.
[saku@hamtpad ~]$ ps ax| grep rig
1796 ? S 0:00 /usr/bin/rigctld -m 373 -r /dev/icom7300 -t 4532
2761 pts/0 S+ 0:00 grep --color=auto rig
[saku@hamtpad ~]$
In my case copied text would be:
/usr/bin/rigctld -m 373 -r /dev/icom7300 -t 4532
Paste it to text editor for later use.
Close cqrlog.
Give again:
ps ax | grep rig
To be sure that rigctld is closed. If it still running you see it like before.
If there is no line like that, it is not running any more. Good.
In that case it is still running try command:
killall rigctld
And check that rigctld died using the first command again.
If killall does not work you can pick the number at the beginning of that "rigctld" line. It is a process ID number.
By using that give:
kill -9 XXXX (where XXXX is the number)
Again check that rigctld now is gone.
When it finally is gone, give the same command and parameters (copy/paste from your text editor) but add one parameter more at the end.
That is again "-vvvvv".
In my case text would then be:
/usr/bin/rigctld -m 373 -r /dev/icom7300 -t 4532 -vvvvv
Now rigctld should run in your console window. Start cqrlog now. As you unchecked "run rigctld at program start" cqrlog will not start another rigctld, but uses this one running in you console.
When cqrlog is up you will see from console what happens when it polls rig on every 5000 (5sec). At that point double click DXcluster line to make your TX move to DX's frequency.
Look what happens at console window. Any errors seen then???
You can scroll console lines, and also kill rigctld with Ctrl+C to stop polling fill up then console window.
If you kill rigctld like that you can restart it using "arrow up" key that brings you the last typed command and pressing enter after that.
How ever cqrlog does not work after that until you use NewQSO/File/Refresh TRX/ROT control.
When you have finished with testing remember to return poll rate and "Run rigctld at program start" from Preferences/TRXcontrol.
We will make you a linux nerd very soon...
--
Saku
OH1KH
Saku
I dropped the poll rate to 1500 and that corrected the issue. All is working well now.
Next week I am going to read and reread back over this entire series of replies and redo the commands to learn from this. This is great insight into the inner workings of Linux and cqrlog.
Again Thank you Saku and Martin.
73 John
Hi Saku,
Now I have a similar problem to John. I had everything working with a fresh install on Linux Mint 18.3. I had the radio and PC talking and I could read the radio frequency in CQRLog. Then I tried installing fldigi using Package Manager. I was able to install the program but could not get it to talk to the radio, no matter what I tried.
Radio Yaseu FT-1000D (rig 103)
I quit out of fldigi and decided to run CQRLog and get on the air to make a few contacts. To my sadness, now CQRLog won't read the radio frequency anymore. I use a generic serial/parallel port card plugged into a pci slot on the motherboard. From there, that serial cable plugs into my Yaseu (MFJ) radio interface. It has worked perfectly for years. No issues running it under Windows-7 with N1MM Logger either. Running ps aux - it looks like proper operation of ttyS4.
Running the command: ps aux
Returns the following:
bob 6650 14.0 1.3 646776 107356 ? Sl 12:11 0:01 cqrlog
bob 6654 3.5 1.8 1379992 148728 ? Sl 12:11 0:00 /usr/sbin/mysqld --defaults-file=/home/bob/.config/cqr
bob 6687 0.0 0.0 17164 2588 ? S 12:11 0:00 /usr/bin/rigctld -m 103 -r /dev/ttyS4 -t 4532 -s 4800
I tried all the things you mentioned above and nothing worked. I am a member of the dialout group.
Runing the command:
bob@Bob-Linux-PC ~ $ getent group dialout
Returns the following:
dialout:x:20:bob
Running the command:
bob@Bob-Linux-PC ~ $ whereis rigctld
rigctld: /usr/bin/rigctld /usr/local/bin/rigctld /usr/share/man/man8/rigctld.8.gz
bob@Bob-Linux-PC ~ $ whereis rigctl
rigctl: /usr/bin/rigctl /usr/local/bin/rigctl /usr/share/man/man1/rigctl.1.gz
Running the command:
bob@Bob-Linux-PC ~ $ rigctl -m 103 -P /dev/ttyS4 -vvvvv
Returns the following:
rig_init called
yaesu: initrigs3_yaesu called
rig_register called
rig_register: rig_register (121)
... plus many more lines of similar "rig_register" lines
At the end of that command return, the last line indicates to following:
rig_open: error = Communication timed out.
That must be where the problem is located - but how to correct it... I have no idea.
Can you help point me in the right direction?
Also, on a separate note: I can't get hamlib to work either.
Thanks, Bob, WG9L
Hi Bob!
To be sure nothing uses serial port you are defined for cqrlog you can use google with search words:
linux show programs using serial ports
Look what you get, one that looks good to test is: http://semtamtam.blogspot.com/2013/05/linux-who-is-using-my-serial-port....
When you are sure no other program is running using serial port in question you should get cqrlog working with exisiting settings that did work before.
Then you could check Hamlib version. If you have installed wsjt-x you actually have 2 versions.
[saku@tpad ~]$ 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.
[saku@tpad ~]$ rigctl-wsjtx --version
rigctl(d), Hamlib 3.3~git
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.
If there is difference in version use higest. Should be over 3. In case of using rigctl-wsjtx/rigctld-wsjtx you have to change the filename of "path to rigctld" in cqrlog preferences.
Then you could read this: http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...
You need, and should use, only one instance of rigctld.
It is bit hard to pinpoint your problem "as remote". But if n1mm logger works with windows side using same hardware we can assume that there is no problem at hardware side.
Try these first and tell what you did find out.
--
Saku
OH1KH
Still not working.
I tried your suggestions above and still have the same issue. Here are a few extra details.
I tried to download, compile and install WSJT-X 2.0 from K1JT's web page. Since I use Linux Mint and there is no install package available yet for version 2.0 (AMD64), this is my only option. I got most of the way compiling and installing while adding any missing library and developer files along the way, until I got one that Synaptic Package Manager could not find or install. At that point, I just quit my attempt to install WSJT-X 2.0.
I know they will work on my machine (both CQRLog 2.3.0(001) and WSJT-X 2.0), because I had them running under Mint 19.1 - but I also had issues with Evolution email not running correctly on Mint version 19.1 (could not receive any messages, but could send without any problem at all), that I downgraded my OS and did a fresh, new install of Mint version 18.3. The other programs seem to behave correctly now running Mint 18.3, but CQRLog can't communicate with the radio, but did work just fine with Mint 19.1.
I tried the following:
Who is using my serial port?
Typing in the following: sudo lsof /dev/ttyS4
Returns the following: lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rigctld 4990 bob 3u CHR 4,68 0t0 92 /dev/ttyS4
Typing in the following: ps -f -p 4990
Returns the following: UID PID PPID C STIME TTY TIME CMD
bob 4990 3845 0 16:02 ? 00:00:00 /usr/bin/rigctld -m 103 -r /dev/ttyS4 -t 4532 -s 4800
Typing in the following: pwdx 4990
Returns the following: 4990: /usr/bin
In CQRLog, my settings on the TRX Control tab of the Preferences menu are as follows:
Path to rigctrld binary: /usr/bin/rigctld
Radio One: Description: FT-1000D
Host: localhost
Rig model: 103 Yaesu FT-1000D
Device: /dev/ttyS4
Poll rate: 1000
Port number: 4532
Run rigctrls when program starts: (checked - yes)
Radio one serial parameters all default, except for Serial speed: 4800 (Yaesu speed)
Typing in the following: rigctl --version
Returns the following: rigctl(d), 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.
Typing in the following: rigctl-wsjtx --version
Returns the following: rigctl-wsjtx: command not found
Typing in the following: grig -m 103 -r /dev/ttyS4 -s 4800 -d 3
Returns the following: Lots of messages and a graphical window pops up showing a generic radio interface with the window title heading:
GRIG: Yaesu FT-1000D
The ONLY thing that appears to work is the S-Meter. Is changes appropriately as I tune in loud or quiet stations on the actual radio. No frequency display and no other function appear to work. Then I quit GRIG.
Is there something wrong with my path to rigctrld?
I did notice one new thing I didn't see previously- not related to GRIG testing.
While in CQRLog, if I go to the File menu and hit the option:
Refresh TRX/ROT Control
The CAT light blinks three times on the radio, but still won't read the radio frequency. I can repeat this over and over with the same results.
I'm getting VERY frustrated. I have blown a TON of time playing around to get it working. Any more ideas?
TNX
Bob, WG9L
One more thing...
Typing in the following: ps ax | grep rig
Returns the following:
5323 ? S 0:00 /usr/bin/rigctld -m 103 -r /dev/ttyS4 -t 4532 -s 4800
5404 pts/0 S+ 0:00 grep --color=auto rig
The first numbers on each line are different now, because I quit out of CQRLog and started a new session and that changed the PID numbers?
Bob
Dubug start report
Typing in a terminal window the following:
cqrlog --debug=1
Returns the following (partial info. of my Settings):
Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 103 -r /dev/ttyS4 -t 4532 -s 4800
RunRigCtld: TRUE
RigDevice: /dev/ttyS4
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 1000
RigSendCWR: FALSE
RigId: 103
Starting RigCtld ...
/usr/bin/rigctld -m 103 -r /dev/ttyS4 -t 4532 -s 4800
rigctld started!
Connected to localhost:4532
Bob
Hi Bob!
Try to set cqrlog preferences/TRXControl:
poll rate to 3000
Then set extra command line arguments
--set-conf=timeout=2000
You can also give this in command line:
rigctld -L
And see what you get.
First 3 items might be worth of try. We start with timeout.
Check also this thread https://www.cqrlog.com/node/2191
--
Saku
OH1KH
Saku,
No matter what I tried, I just could not make this work properly. I finally wiped out my Linux Mint 18.3 partition and swap space, reformatted the partition and reinstalled Mint 19.1 - After a few minutes of setup and configuration with CQRLog, I had everything working once again.
The reason I went back to Mint 18.3 was because I just could not get Evolution or Thunderbird to receive ANY email - but I could always send no problem. That turned out to be a NSS Network Security file that needed to be installed on Mint 19.1 - because my local internet provider, COMCAST had a compatibility issue with something in LM 19.1 and when Mint 19.1 was released, this updated file was not originally included. It took quite a bit of searching to figure this one out.
Now that I'm back on Mint 19.1 - I've got CQRLog and WSJT-X working properly. They are talking to each other and the radio as well. Evolution works now and even my old HP laser printer got the latest driver installed and I can print also - I'm happy.
Now I've got to figure out how to get fldigi up and running AND talking to the radio.
Thanks again for all your help and assistance - I appreciate it very much.
TNX and 73,
Bob, WG9L
Hi Bob!
I recommend you to read this (if I did not that before) http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...
Some words there of fldigi, too.
Then you could peek my videos. Sorry about quality and poor language Specially look the part of fldigi/xmlrpc. https://www.youtube.com/channel/UC3yPCVYmfeBzDSwTosOe2fQ
All you have to find by yourself is how to make audio settings properly for fldigi. Everything else should be found from those links.
--
Saku
OH1KH
Hi,
I'd like to warm up this thread since many FT-1000MP users have problems with the classic YAESU FT-1000MP CAT control.
The problem is: There are 2 different RS232 cables available on the market, one has crossed RXD/TXD and the other one has not. Both have female/female connectors which makes it almost impossible to find out if you have the right one. It looks like both are the same, but in fact they're not!
Most cables on the market are ok for almost all ham radio transceivers, but not for the FT-1000MP. It doesn't matter if you use a USB-to-serial converter since the problem is a "wrong" cable.
DL6ZB
Hi!
Quite a lot has changed in Hamlib since this thread was started. It has lot of new rigs and features now. Unfortunately if Hamlib is loaded as a dependency package of Cqrlog it usually is very old version.
Same can be said from Cqrlog. Package versions are too old.
That 's why it is most recommended to learn to compile both from source. It may feel too difficult at start, but there are very good explanations found from documentations and by Googling.
How ever that does not help for cable problem as it is a hardware one.
I do not know FT1000, but if it really has "old good" RS232 connectors it is easy to check the connection with multimeter.
I assume there are 9 pin Canon connectors. Standard ground pin for those is pin 5.
It can be checked with ohm or diode testing. Pin 5 should show 0 ohms to rig ground, or diode tester should show 0V and audible sound.
After ground pin has been found we can put negative lead of multimeter to it (as well as to rig ground, if they showed to be in connection).
Measuring voltage from pins 2 and 3 should show different values. In RS232 standard the TX pin should have negative voltage against ground. WIth "modern" connectors this may be just 0V.
The RX pin should show different value, something more positive than 0V.
If the connector meets the RS232 standard it is very easy to separate TX and RX pins by voltage measurement.
Same measurement should be done at computer side, or at the RS232 end of USB converter cable.
When both sides have been measured and TX and RX pins order found they should be connected so that computer TX meets Rig RX and computer RX meets Rig TX pins.
WIth two suitable Canon connectors a cross cable can be made by connection pin 5 to pin 5 of other connector and then connector 1-pin2 to connector 2-pin3 and same with connector1-pin3 to connector2-pin3. If it shows that Rig TX pin is against Compiter TX pin and same with RX pins, this cross cable can be used to get TX and RX in order.
What comes to handshake pins it seems that FT1000 does not have them connected (by manual). So it should not be needed t connect them, just 3 wire connection between computer and rig.
--
Saku
OH1KH