Cubicsdr: Net RigCTL control for Fldigi / WSJT-X / etc.

[frspin]

Recent upgrade from Github show a "Rig Control" Menu.

As can I see, it is for control a rig from CubicSDR, used as panadapter or receiver only when using also a transmitter able to be controlled by Hamlib.

How instead control CubicSDR from another program (as Fldigi or WSJT-X) with Hamlib?
Is CubicSDR implementing a Hamlib protocol (Net RigCTL)?

Regards
Franco Spinelli
IW2DHW

[cjcliffe]

@frspin USE_HAMLIB wasn't supposed to be on by default yet but I'm glad it compiled ok :)

It's for both controlling a rig and allowing a rig to control CubicSDR; right now it will control frequency and allow frequency changes from the rig (or HamLib RPC, etc) to control it. Port can either be a local file (such as serial or USB) or for some rig protocols it's an IP address.

If you use the SDR-IF mode setting it will allow you to lock the current SDR to a desired rig IF and still enable frequency tuning between CubicSDR and the rig. This effectively lets you connect an SDR to the IF lines of your rig and set the SDR-IF to the rig's IF frequency but maintain the actual frequency sync with the rig.

The SDR-IF, Baud and Port will be saved and loaded with each individual rig type used; this will probably be expanded in to rig configurations in the future.

I'm not sure if other programs can control it; but if they send or accept frequency updates and are compatible with one of the hamlib protocols it should sync up when connected.

[frspin]

Il 12/01/2016 01:40, Charles J. Cliffe ha scritto:

@frspin https://github.com/frspin USE_HAMLIB wasn't supposed to be on
by default yet but I'm glad it compiled ok :)

I was updating from GIT before you commit a change for USE_HAMLIB=NO as
default. But it compile and menu is correct. I don't know if it is also
working...

It's for both controlling a rig and allowing a rig to control CubicSDR;
right now it will control frequency and allow frequency changes from the
rig (or HamLib RPC, etc) to control it. Port can either be a local file
(such as serial or USB) or for some rig protocols it's an IP address.

If you use the SDR-IF mode setting it will allow you to lock the current
SDR to a desired rig IF and still enable frequency tuning between
CubicSDR and the rig. This effectively lets you connect an SDR to the IF
lines of your rig and set the SDR-IF to the rig's IF frequency but
maintain the actual frequency sync with the rig.

This is for using CubicSDR as IF panadapter.

The SDR-IF, Baud and Port will be saved and loaded with each individual
rig type used; this will probably be expanded in to rig configurations
in the future.

I'm not sure if other programs can control it; but if they send or
accept frequency updates and are compatible with one of the hamlib
protocols it should sync up when connected.

Fldigi and WSJT-X use Hamlib for controlling a receiver. So how is
supposed to work CubicSDR for this?
Which rig type need I define in CubicSDR and in Fldigi or WSJT-X? Can I
use a network type (hamlib type 2 NET rigctl or any other network
controlled)? How can I define port number for this network connection?

Regards

Franco Spinelli
IW2DHW

[frspin]

Looking in the code I have find nothing simulating a rig. All Hamlib calls are for controlling a rig.
I am missing something?

Regards
Franco Spinelli
IW2DHW

[jdeitch]

@frspin Yes. If you change the VFO on the rig and you automatically update the display in CubicSDR by polling the rig to match your changes does it not look like the rig is "controlling" CubicSDR? Change modes and Cubic follows.
A panadapter should follow what the rig does and the rig should follow what the panadapter does.

Jim
JG1KGS

[frspin]

Il 15/01/2016 23:26, jdeitch ha scritto:

@frspin https://github.com/frspin Yes. If you change the VFO on the
rig and you automatically update the display in CubicSDR by polling the
rig to match your changes does it not look like the rig is "controlling"
CubicSDR? Change modes and Cubic follows.
A panadapter should follow what the rig does and the rig should follow
what the panadapter does.

Yes, this is correct for a panadapter.

My question was about controlling CubicSDR from another program, like
Fldigi or WSJT-X
In this case the "rig" is CubicSDR and the program using Hamlib for
controlling rig is Fldigi or WSJT-X

So CubicSDR need to simulate a rig as done for other programs (HDSDR or
SDR_Console in Windows, Quisk or GQRX in Linux).

Emulating a type 2 rig (Net Rigctl) is the preferred choice as you can
then use your LAN for running CubicSDR and Fldigi/WSJT-X on different
machine.

Regards
Franco Spinelli
IW2DHW

[sean808080]

I don't see the rig control menu in the MacOS builds. Am I missing it? I have a new SDRPlay that I am trying to get setup as a pan adapter for my 857D. Thanks for the many updates to CubicSDR!

[cjcliffe]

@sean808080 still having issues bundling hamlib; will try for next build -- but building from source and enabling USE_HAMLIB will make it work locally.

[sean808080]

Tried building locally but wx was giving me the sads last night:

./include/wx/any.h:611:5: warning: expression with side effects will be evaluated despite being used as an operand to 'typeid'
[-Wpotentially-evaluated-expression]
WX_DECLARE_ANY_VALUE_TYPE(wxAnyValueTypeImplVariantData)

Just kept looping and showing this error. I can wait and thanks again for all your efforts. Really looking forward to getting to use cubicSDR for the pan adapter display

[cjcliffe]

@sean808080 it's not looping actually; it shows that warning for each file built..

Adding make -j4 where '4' means use 4 cores might help speed up builds.

Additionally adding:

-DUSE_HAMLIB=1

to the CubicSDR build line like so:

cmake_build$ cmake ../ -DwxWidgets_CONFIG_EXECUTABLE=/Users/<YOUR_USERNAME>/wxWidgets/wxWidgets-staticlib/bin/wx-config -DCMAKE_BUILD_TYPE=Release -DBUNDLE_APP=1 -DCPACK_BINARY_DRAGNDROP=1 -DUSE_HAMLIB=1

will enable HAMLIB with Rig Control and SDR-IF support.

[cjcliffe]

@frspin I still haven't had any luck getting hamlib to work as a host to other apps; I think I'll have to add specific support for it.

[sean808080]

Thanks for the tip that it wasn't looping. I got the wxwidgets to build. Installed hamlib (after restoring my fubar'd ruby install) Now I"m stuck at building CubicSDR.

-- Found hamlib library at: /usr/local/lib/libhamlib.dylib
-- Found hamlib static library at: /usr/local/lib/libhamlib.a
-- Found hamlib static modules:
-- Found hamlib include directory at: /usr/local/include
64 bit compiler detected
CMake Error at cmake/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find wxWidgets (missing: wxWidgets_FOUND)
Call Stack (most recent call first):
cmake/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindwxWidgets.cmake:869 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:136 (find_package)

I'm able to build the sample wxwidgets successfully. I tried looking at the logs but they're not making much sense to me.

[frspin]

2016-02-05 4:35 GMT+01:00 Charles J. Cliffe [email protected]:

@frspin https://github.com/frspin I still haven't had any luck getting
hamlib to work as a host to other apps; I think I'll have to add specific
support for it.

Have you seen this document?

http://james.ahlstrom.name/hamlib.html

Setting hamlib as a host to other apps require an answer to initial
question from hamlib, with rig capabilities.

Regard
Franco Spinelli
IW2DHW

[sean808080]

Using the GUI for CMAKE I was able to figure my way around the path issues. Nifty for people like me that need to see things.

Building CubicSDR now with hamlib support. Just saw some errors about libltdl.7.dylib but there is a binary that runs and crashes sometimes. Hmmmmm

[sean808080]

All settings seem to work except when I select the rig model yaesu 857 it crashes every time.

https://gist.github.com/sean808080/9ec747d59e10a0569955

[cjcliffe]

@sean808080 this looks like a pretty simple fix; I think it's just a buffer-overrun on a string value in the RigThread -- I'll do some review and let you know when a fix is committed.

[cjcliffe]

@sean808080 I think it's possible the info string for the device was null and I didn't handle it; I've committed a patch that checks for that -- let me know if that helps your situation. If not I'll add some useful log info to the RigThread.

[sean808080]

No more crashes observed. Thanks!

[cjcliffe]

@frspin I finally got FLDigi and CubicSDR connected via hamlib here :)

The key steps were:

Launch rigctld from the command line (-vvvv just means very very very verbose, can turn if off once it works, -m 1 is dummy rig, use rigctld -l to list model numbers to connect actual rig):

rigctld -m 1 -vvvv -T 127.0.0.1 -t 4532

From FLDigi:

From CubicSDR Rig menu:
Model:

Control Port:

This is all locally but I assume that exchanging 127.0.0.1 with remote address should work the same.

Additionally I've committed a fix that was causing a crash in RigThread on startup sometimes.

[frspin]

Il 15/02/2016 18:24, Charles J. Cliffe ha scritto:

@frspin https://github.com/frspin I finally got FLDigi and CubicSDR
connected via hamlib here :)

The key steps were:

Launch rigctld from the command line (-vvvv just means very very very
verbose, can turn if off once it works):

|rigctld -m 1 -vvvv -T 127.0.0.1 -t 4532 |

From FLDigi:
image
https://cloud.githubusercontent.com/assets/247927/13055599/332d511e-d3de-11e5-88d9-53569fb9374a.png

From CubicSDR Rig menu:
Model:
image
https://cloud.githubusercontent.com/assets/247927/13055653/8ca0875c-d3de-11e5-8201-188b94f45343.png

Control Port:
image
https://cloud.githubusercontent.com/assets/247927/13055615/517f3088-d3de-11e5-9ccb-05cb728de4cd.png

This is all locally but I assume that exchanging 127.0.0.1 with remote
address should work the same.

Additionally I've committed a fix that was causing a crash in RigThread
on startup sometimes.

This is working but there are some problems:

1) rigctld is needed starting before CubicSDR and before Fldigi
2) Fldigi show center freq of CubicSDR and CubicSDR use frequency from
Fldigi as center freq
3) changing mode in Fldigi or CubicSDR don't change mode in the other
program
4) Enable Rig in Rig Control menu need to be enabled at each startup of Cubic

If you can integrate a Rigctl server in CubicSDR we can avoid starting
rigctld, as done in Quisk (see my previous message).

Regards

Franco Spinelli
IW2DHW

[frspin]

Some test and some problems:

Now Rig Control menu' have:

• Enable RIg
• Control Rig
• Follow rig
  Enable RIg don't stay checked between sessions and is the only option for CubicSDR to connect with rigctld daemon.

For test this, do this steps:

• start a fresh rigctld daemon
• start CubicSDR
• in another terminal start rigctl -m 2 -r 127.0.0.1:4532
• type "f" and get 145000000 (default for rigctld)
• pull down Rig menu, click on Enable rig (now rig is enabled but menu item is not checked)
• type "f" and get Center Frequency value in CubicSDR

Using rigctl you can also test other problems as in my previous message.
m and M command have no effect on CubicSDR
f and F command use Center Frequency and not Frequency, as correct.

Regards
Franco Spinelli
IW2DHW

[cjcliffe]

@frspin thanks for your help with testing -- I don't have a rig here to work with and it's good to know what's happening in the field too :) rigctld has helped quite a bit so far with emulation and I think we'll have sever integrated eventually.

I'm going to be working on cleaning up hamlib support for bundling with the 0.2.0 release and will message you when I have more to test.