FT-991A connection

18 posts / 0 new
Last post
HP1COO
FT-991A connection

Hi All,

I have been running CQRLOG connected to a YAESU FT-450D without any troubles, I can control the radio from CQRLOG, open FLDIGI and WSJT.

I upgraded my station and now have a YAESU FT-991A. I want to connect to the radio using only the USB port. When I tried to connect, I do not see the radio on the TRX control RIG list.

I am running CQRLOG V2.2.0 (001) dated 2017-12-30 and Hamlib 1.2.15.3. I understand there is a newer version of hamlib that includes the FT-991 on the list my guess is that I need to upgrade hamlib and then I'll be able to use the new radio under CQRLOG. Any ideas on how to upgrade it?

I'm running UBUNTU 16.04.

Thanks,

Alejandro

oh1kh
hamlib

try:

sudo apt-get install libhamlib2

as console command. For me it gives: libhamlib2 is already the newest version (3.1-7).
I think for you it installs newer version.
--
Saku
OH1KH

--
Saku
OH1KH

HP1COO
FT-991A connection

Hello Saku

I'll try to perform the update tonight. Let you know the results.

Thanks!

73 de HP1COO Alejandro

HP1COO
FT-991A connection

Hi,

This is the output of the command:

alejandro@alejandro-ham:~$ sudo apt-get install libhamlib2
[sudo] password for alejandro:
Reading package lists... Done
Building dependency tree      
Reading state information... Done
libhamlib2 is already the newest version (1.2.15.3-3.1build1).
libhamlib2 set to manually installed.
The following packages were automatically installed and are no longer required:
  libbonobo2-0 libbonobo2-common libgnome-2-0 libgnome2-common libgnomevfs2-0
  libgnomevfs2-common liborbit-2-0 linux-headers-4.4.0-31
  linux-headers-4.4.0-31-generic linux-image-4.4.0-31-generic
  linux-image-extra-4.4.0-31-generic snap-confine ubuntu-core-launcher
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 27 not upgraded.

Any ideas?

Thanks,

 

73 de HP1COO Alejandro

oh1kh
FT-991A connection

Hi !

It looks like you have version 3.1 installed.
in console give:
rigctld --version

You should get something like:
[saku@tpad ~]$ 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.

Version number is at first line.

If you have 3.1 it is the latest official.

If you have installed WSJT-X 1.8.0 it installs the latest (stabile) version, but it is named as rigctld-wsjtx.
In console try:
rigctl-wsjtx --version

[saku@tpad ~]$ rigctl-wsjtx --version
rigctl, Hamlib 3.2~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 you get text like that then you can change cqrlog prferences/trx control/path to rigctld to point this file.
Just add -wsjtx at the end of existing text.

Then try does it work.

--
Saku
OH1KH

--
Saku
OH1KH

oh1kh
FT-991A connection

Just tested from console:

[saku@tpad ~]$ rigctld-wsjtx -l| grep 991
135 Yaesu FT-991 0.23.4 Beta

[saku@tpad ~]$ rigctld -l| grep 991
135 Yaesu FT-991 0.23.4 Beta

Both seems to know FT-991 (-m 135) is'nt that working?

--
Saku
OH1KH

--
Saku
OH1KH

HP1COO
FT-991A connection

Hi Saku,

You are right, the 991A is connected and sending frequency information to CQRLOG Now. I need to keep reading to tweak the communication parameters, the frequency on the QSO Windows does not update as fast as before (comparing with a serial connection to FT-450D).

Thanks!

73 de HP1COO Alejandro

oh1kh
FT-991A connection

Fine!

I guess it updates faster than you can keep full qso :) !
I have poll value 1000 (ms = 1sec) in my settings with serial speed of 19600 to IC706. That is fast enough.
I have run also with 2500 (2,5sec) and it is good enough, too. My qsos usually lasts longer than 2,5sec so the right frequency is there at the time of pressing "Save qso".

--
Saku
OH1KH

--
Saku
OH1KH

HB9GKC
Not Working

I installed by scratch (sourceforge...) the hamlib 3.2
It appears to work:

rigctld -l| grep 991

returns

135 Yaesu FT-991 0.23.5 Stable

also manual command from terminal is returning good response:

MacBook ~ $ /usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -s 38400 -v
Opened rig model 135, 'FT-991'

Rig command: f
Frequency: 7105500

Rig command:

Also The program FLDigi is working with the parameters set as in the picture attached (top left).

NO way to get the frequency on CQRLOG (settings top right)

Any help??

File: 

HB9GKC
terminal output

MacBook ~ $ cqrlog

**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=1 PARAMETER ****

180414 21:45:29 [Note] /usr/sbin/mysqld (mysqld 10.0.34-MariaDB-0ubuntu0.16.04.1) starting as process 8578 ...

Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctl
RigCtldArgs:-m 135 -r /dev/ttyUSB0 -t 4532 -s 38400
RunRigCtld: TRUE
RigDevice: /dev/ttyUSB0
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 300
RigSendCWR: FALSE
RigId: 135

Starting RigCtld ...
/usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -t 4532 -s 38400

Rig command: rigctld started!
Connected to localhost:4532
Sending: fmv

Sending: fmv

Sending: fmv

Sending: fmv

Sending: fmv

and so on.... but no numbers in the frequency.

I have also tried another log-software (xlog) and is working.

HB9GKC
v command does not work

I have tested individually on the terminal the commands: f m v
it looks like vfo is not working. Could it be the reason it is not working?

Here the terminal output:

Rig command: f
Frequency: 7031000

Rig command: v
get_vfo: error = Feature not available

Rig command: m
Mode: CW
Passband: 2400

oh1kh
v command does not work

Hi!

Do not worry about the VFO defunct. There you see that with my IC706 the problem is same,
but it works as long as frequency and mode are ok.

(v command below gives RPRT -11 [not supported] )

saku@hamtpad ~]$ telnet localhost 4532
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
f
7080000
fmv
7081000
USB
2400
RPRT -11

--
Saku
OH1KH

oh1kh
v command does not work

Hi!

I have written about this subject here for some times. You find them using search.

First you say this works:
/usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -s 38400 -v

So In cqrlog you should use same parameters. TRXcontrol/radio one parameters: 38400 , default, default, default, default, default, default should give you that.

You can check this by setting those. Stop cqrlog. To make sure no rigctld is running at that point give from console:
ps ax | grep rig
If there is no rigctld-line start cqrlog. If there is rigctrld-line give:
killall rigctld
So many times that you get "no processes". Then start cqrlog again.

Give again
ps ax | grep rig
and now you should see similar line than yours:
/usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -s 38400 -v

Then you are sure TRXcontrol settings are ok.

When you are working with cqrlog AND fldigi OR wsjtx, OR any other program that uses rig CAT. You should NOT set up your yeasu with similar parameters in those program's setups!!

Instead all other programs should use "net rigctld" as rig and localhost:4532 as the port.
I that way you do not have conflicts with CAT serial port as only ONE rigctld is accessing your rig via serial interface and it is sharing the information to all programs.

All programs can the run at the same time !
You can even telnet localhost 4532 and control your rig there while programs are running.

File: 

--
Saku
OH1KH

HB9GKC
I did what you said, no

I did what you said, no process were pending...

After running cqrlog , with ps ax ... I can see:

9858 pts/5 S+ 0:00 /usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -t 4532 -s 38400 --set-conf=serial_parity=None

But in the cqrlog terminal (running) I only see:

Sending: fmv
Sending: fmv
Sending: fmv
.........
Sending: fmv

thousand times... every pull-out (2000 ms)

and nothing else
Is like connected but not getting anything; Nothing changes on the frequency number on the CQRlogger....
Looks like stock on the same frequency....

HB9GKC
rigctld

I noticed that only rigctl works (in terminal) with manual command...

I used (in terminal ) rigctld with same parameters and it does not work.

When I run CQRLOG the terminal says:

RigCtldPath:/usr/bin/rigctl
RigCtldArgs:-m 135 -r /dev/ttyUSB0 -t 4532 -s 38400 --set-conf=serial_parity=None
RunRigCtld: TRUE
RigDevice: /dev/ttyUSB0
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 3000
RigSendCWR: FALSE
RigId: 135

Starting RigCtld ...
/usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -t 4532 -s 38400 --set-conf=serial_parity=None

Rig command: rigctld started!
Connected to localhost:4532
Sending: fmv

Sending: fmv

Sending: fmv

Sending: fmv

Where it says:

Rig command: rigctld started!

is it using Rigctld??

oh1kh
rigctld

/usr/bin/rigctl -m 135 -r /dev/ttyUSB0 -t 4532 -s 38400 --set-conf=serial_parity=None

This is not ok.
It shoud be:
/usr/bin/rigctld -m 135 -r /dev/ttyUSB0 -t 4532 -s 38400 --set-conf=serial_parity=None

D stands for daemon. Rigctl is a foreground program and is not right for cqrlog.

Cqrlog debug messages say rigctld as hard coded, but if your setup string is wrong (=rigctl) it will not work.

Check the path/filename in preferences/TRXControl.
See what I have my picture from this morning from previous message.

--
Saku
OH1KH

HB9GKC
OK it works

FINE !! it works !!

Although, initially I had RIGCTLD but didn't work, so I used rigctld-wsjt etc etc and i found out that the only working was rigctl from terminal.. . That was why I started the thread...

Thanks a lot !!

LM

oh1kh
OK it works

Fine !

The difference of d and without d is so small that I messed it at first message. I should have noticed it already then. But as my picture is from working setup it was ok if checked from that.

It is very important that other programs do not start another rigctld program(s) as they may work a while, but sooner or later they have problems.
Only way is to run one rigctld either started by cqrlog, or started as system service at operating system startup (when cqrlog also need rig model 2 "Net rigctld" and uncheck "start rigctld at program start").

Linuxes are usually not so critical as windozes that say immediately that you are going to access already used serial device. They may let several instances access to same serial device and it is users role to check that it does not cause conflicts.

--
Saku
OH1KH