TRX control ICOM IC-7100

12 posts / 0 new
Last post
JP3REM
TRX control ICOM IC-7100

I have not been able to get TRX control to work with my Icom IC-7100.

I'm using CQRLOG 2.3.0 in Debian 9 (Stretch). I have no issues using WSJT-X or Fldigi or Flrig and they can see and control my radio. My attempts to get TRX control in CQRLOG have not been successful though. I have read through most of the threads in this site and tried various suggestion, but have not had any luck.

In this thread https://www.cqrlog.com/node/2188 (TRX Control and Icom CIV) I saw the hint to try to use the civaddress argument. The radio uses 88h, so I tried combinations of:
--civaddr=88h
--civaddr=0x88
--civaddr=136

I can access the radio via
rigctl -m 370 -r /dev/ttyUSB0 -vvvv
or
rigctl -m 370 -r /dev/ttyUSB0 -vvvv -c 136
and issue a few commands. I can change modes and frequencies that way. Not sure why the CQRLOG won't work...

oh1kh
TRX control ICOM IC-7100

HI !

If rigctl works just try to add "d" so it becomes "rigctld". After starting that take another console and try telnet.
telnet localhost 4532

It should work similar way as the "rigctl"

If so far OK let both consoles run and start cqrlog. Change preferences/TRXcontrol to use rig model: "2 Hamlib NET rigctl ", poll rate 1000 and port 4532
Set host to localhost or 127.0.0.1
Clear Device to be empty.

( It may be that starting cqrlog while preferences/TRXcontrol/Device has same port as with rigctld console it causes port conflict and everything stops working. So after cqrlog Device is cleared stop all consoles and cqrlog and start all consoles and cqrlog from beginning.)

Return from preferences and open TRXControl. You should see rig frequency. Change to telnet window and give f You should get same frequency.
If telnet still works, but cqrlog does not show frequency stop cqrlog. Open 3rd console and start cqrlog with:
cqrlog debug=1
Watch the debug texts at the start phase. Is there any errors shown when rigctld starts?

If you started "rigctld" with "-vvvv" at the 1st console watch also that console while cqrlog starts and when it is running. Are there any errors shown? You can use 5 vs "-vvvvv" to see all debug info from rigctld.

Look also this:
http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...

--
Saku
OH1KH

JP3REM
Hi Saku,

Hi Saku,

Playing with rigctl I noticed I made a mistake in my initial post. Only this one:
rigctl -m 370 -r /dev/ttyUSB0 -vvvv -c 136
would allow me to reach Rig command: where I could enter commands like 'f' or 'm' to interact with the radio. If I didn't enter the -c or --civaddr=id in the command it would hang after the
Opened rig model 370, 'IC-7100'
Backend version: 0.7, Status: Untested

So when I tried rigctld as suggested, with or without the CIV address, it never reaches the Rig command. However, if I connect telnet and issue commands there, they seem to work. (i.e., I can't issue rig commands in the terminal via telnet where rigctld is running)

After trying your suggestions it looks like I have a problem with rigctld not starting properly
from cqrlog --debug=1

Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctl
RigCtldArgs:-m 2 -r -t 4532
RunRigCtld: TRUE
RigDevice:
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 1000
RigSendCWR: FALSE
RigId: 2

Starting RigCtld ...
/usr/bin/rigctl -m 2 -r -t 4532
rig_open: error = Invalid configuration
rigctld failed to start!
1
2
3
4
5
6

I think I need to get that fixed before trying the suggestion in the linked PDF.

JP3REM
correction

* (i.e., I can't issue rig commands in the terminal via telnet where rigctld is running)

I can issue rig commands via telnet to rigctld. They return in the telnet terminal. I cannot issue commands via rigctld

oh1kh
Hi!

Hi!
OK!
So you need the -c parameter for rigctld. Have you changed Icom's default CI-V address ? Then you need to add the -c parameter to access the rig.
Otherwise, if not changed, selecting a rig model number should use default CI-V address to that rig model.

But never mind, if you need to enter it and it makes it work so be it.

You should not be able to give commands at that command window where you started rigctld. For telnet you need to open second command terminal window and enter "telnet localhost 4532"- command there.
If you did give "-vvvvv" as one parameter in rigctld command line window you should see something like in my attached screen copy at left side command console. The right side command console runs telnet. Every time you issue command on right side you see more debug text at left side.

So if your telnet window works cqrlog should also work with rig model -m 2 when rigctld is running at command console.

Here is my cqrlog debug that works here:

Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 2 -r -t 4532
RunRigCtld: FALSE
RigDevice:
RigCtldPort:4532
RigCtldHost:127.0.0.1
RigPoll: 1500
RigSendCWR: FALSE
RigId: 2

rigctld started!
Connected to 127.0.0.1:4532

Only difference is that I do not use localhost I use 127.0.0.1 instead. That should be same, but you can try also with numbers.

Check once again "preferences/TRXcontrol/Path to rigctld binary". Seems that "d" is missing there. you have "rigctl" and you should have "rigctld"
I think that is the error.

When you have fixed that you can even try once again to put your rig model and Device (serial port name) to cqrlog settings and put -c 136 to "extra command line arguments"

If that makes it work (without any console windows open) you can use it. But then if you use fldigi or wsjt-x or qsstv you have to use rig model -m 2 and localhost 4532 setting (look the pdf) for those other programs then cqrlog.
Then you have always start cqrlog first and other programs after that. Other programs do not work without cqrlog.
This way there are no conflicts with rig serial port usage as cqrlog alone uses it and gives rig information to other programs. (See PDF diagram picture)

But if you do all settings as PDF says you can run any program alone (without cqrlog) or all at same time.

I hope that I did not confuse you with all different possibilities.

--
Saku
OH1KH

oh1kh
Hi!

Hi!

Ooops!
Forgot to add the screen copy. It is here.

And I also remind that if your rig has:

"CI-V Tranceive" setting it should be OFF.
If you use USB port without "Link to [REMOTE]" then you should set "CI-V Echo back" to ON

Those are Ic 7300 settings but I assume your rig has nearly similar settings.

File: 

--
Saku
OH1KH

JP3REM
Hi Saku,

Hi Saku,

I had great hopes that fixing the path to rigctld would have fixed things, but I am getting the same results.

> Have you changed Icom's default CI-V address ?
No. The default CIV Address for the IC-7100 is 88h I believe. In the radio I have:

  • CI-V Baud Rate - Auto
  • CI-V Address - 88h
  • CI-V Transceive - OFF
  • CI-V Output (for ANT) - OFF

> If you use USB port without "Link to [REMOTE]" then you should set "CI-V Echo back" to ON
The IC-7100 doesn't appear to have this setting. Just those 4 options above in the CI-V menu. I looked in other menus but didn't come across anything similar.

Thanks for the confirmation on the rigctld behavior, and the screenshot. Mine is operating similar to what you show in the rigctld terminal along with the separate telnet window. It works the same whether I indicate the CI-V address or not in the terminal.
These all work in the terminal along with telnet:
rigctld -m 370 -r /dev/ttyUSB0 -t 4532 -s 19200 -vvvvv
rigctld -m 370 -r /dev/ttyUSB0 -t 4532 -s 19200 -c 0x88 -vvvvv
rigctld -m 370 -r /dev/ttyUSB0 -t 4532 -s 19200 -c 136 -vvvvv

My cqrlog --debug=1 shows this:

Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 2 -r -t 4532 -c 136
RunRigCtld: TRUE
RigDevice:
RigCtldPort:4532
RigCtldHost:127.0.0.1
RigPoll: 1000
RigSendCWR: FALSE
RigId: 2

Starting RigCtld ...
/usr/bin/rigctld -m 2 -r -t 4532 -c 136
rig_open: error = Invalid configuration
rigctld failed to start!
1
2
3
4
5
6
1
2
3
4
5
6
So rigctld still doesn't appear to be starting from CQRLOG.

oh1kh
ic7100

Hi!

So lets forget the command terminals and focus only to cqrlog settings first.

Set your cqrlog preferences/TRXControl as in attached picture. Double check that everything is ok.

Do not start any command terminals, just restart cqrlog when you have done these settings.
Even better if you restart whole PC after you have done new settings and then start first rig and then cqrlog

If your command terminal testing worked, this should also work.

When it works (I strongly believe it does) you have to decide how you are going to work with cqrlog and wsjt-x, fldigi, qsstv or any other program that likes to use CI-V.

Option 1)
Always start cqrlog with these settings that now works. After that any of those other programs. Other programs work as long as cqrlog is running.

Option 2)
Do as in PDF making script that starts rigctld at the PC start. Then you must change cqrlog/preferences/rig to model "2 Hamlib NEt rigctl"
Then you can start any program alone, or all together, without cqrlog or with cqrlog.

In any case, both Option1 or Option2, other program (fldigi,wsjt-x,qsstv ..etc..) settings needs always to be done as in PDF pictures.

Only cqrlog's rig model changes depending how rigctld is is started. Via script or from cqrlog.

File: 

--
Saku
OH1KH

oh1kh
ic7100

Aaah..!

Always forget something:

If you use Option2 and change cqrlog/preferences/rig to model "2 Hamlib NEt rigctl" you have also uncheck "Run rigctld when program starts"

Option1 needs true rig model 370, true Device (/dev/ttyUSB0), and CHECK "Run rigctld when program starts"

I hope I remembered to write all now.

--
Saku
OH1KH

JP3REM
SOLVED

Thanks Saku for the clear explanations and assistance! That works!

I tried out Option #1 first to make sure things were working with WSJT-X and Fldigi. Flawless!

Then I went through the PDF, created the script, got cron working, and everything in Option #2 just works! I spent several weeks trying to do this before asking. I had just about given up, but your instructions really fixed things. Thank you!!!

JP3REM
linked PDF is gone

Saku,

Might you have another copy of that PDF somewhere? The linked copy in this message is no longer available.

oh1kh
linked PDF is gone

--
Saku
OH1KH