CAT support to enable pan adapter functionality

[ghost]

Hi CJ!

I would like to suggest support for CAT control so we can use this excellent SDR program as pan adapter for our HAM radio transceivers. I think it's not needed to build everything from scratch. You can have a look at RigCAT or HAMLib as platforms to integrate with.

Thanks,

Ton EA3HOE.

[cjcliffe]

Greetings @Toontje -- and thanks for the information!

I'd like to investigate adding support for control and input/output via network/block device so this seems like a logical extension that could be included as a module or app compiled against rigcat/hamlib as suggested.

Cheers,
-CJ

[cjcliffe]

Going to attempt to implement this in pothosware/SoapyAudio#3 in the future.

[ghost]

Nice!! Thanks!

[ghost]

Hey Charles! Any update on this one? I think more people want this although they don't know it yet. ;-) This is -the- function that can make CubicSDR the HDSDR for Mac and Linux.

[cjcliffe]

@Toontje I've been wanting to try this one for awhile for VLF; I'll make a start on SoapyAudio and let you know when there's something to test.

[ghost]

Like!

[cjcliffe]

Getting there..

cjmacbook:build ccliffe$ SoapySDRUtil --find
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Found device 0
  default_input = True
  default_output = False
  device_id = 1
  driver = audio
  label = Apple Inc.: Built-in Microphone

Found device 1
  default_input = False
  default_output = False
  device_id = 2
  driver = audio
  label = Apple Inc.: Built-in Input

Found device 2
  default_input = False
  default_output = False
  device_id = 4
  driver = audio
  label = ma++ ingalls for Cycling '74: Soundflower (2ch)

Found device 3
  default_input = False
  default_output = False
  device_id = 5
  driver = audio
  label = ma++ ingalls for Cycling '74: Soundflower (16ch)

cjmacbook:build ccliffe$ SoapySDRUtil --probe="driver=audio,device_id=1"
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device driver=audio,device_id=1

----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=Audio
  hardware=Audio
  device_id=1
  origin=https://github.com/pothosware/SoapyAudio

----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
  Channels: 1 Rx, 0 Tx
  Timestamps: NO

----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
  Full-duplex: YES
  Supports AGC: YES
  Stream formats: CS8, CS16, CF32
  Native format: CS16 [full-scale=65536]
  Antennas: RX
  Full gain range: [0, 100] dB
    AUDIO gain range: [0, 100] dB
  Full freq range:  MHz
    RF freq range:  MHz
  Sample rates: [0.008, 0.096] MHz

[cjcliffe]

@Toontje SoapyAudio now compiles for OSX, and initial compile appears to be working (minus sample rate changes) note you can't use the same device for CoreAudio without a crash; will have to add a check/workaround for that. Currently adjusting CubicSDR to bypass the channelizer when bandwidth is <=500KHz.

[ghost]

It's still early here, but how does SoapyAudio work towards CAT control? It looks like this is the Audio-Input use case which is also a nice-to-have, BTW.

[cjcliffe]

The base case I'm going for is a radio that contains RS-232 CAT control and I/Q 'stereo' output for connection to sound card; it's something I can at least simulate here on a Raspberry Pi / Arduino as well :)

For non sound card use (i.e. the SDR is wired in as a panadapter) I can create a case where it spawns a null SoapyAudio device and operates the CAT control in relation to the active SDR device.

[cjcliffe]

@Toontje CAT frequency control support has now been committed to SoapyAudio.

CubicSDR has also been updated to support a SoapySDR device controlling it's frequency externally (through SoapyAudio at the moment).

You can enable it with the cmake setup of:

build $ cmake ../ -DUSE_HAMLIB=1

Rig selection / baud / port can be configured at device setup time or runtime.

Try it with a mic or line input for now; if you're able to drag the frequency and control the radio and vice-versa with the basic audio driver it's working and when I finish the next step you should be able to choose the rig for any SDR device (as long as SoapyAudio is installed) since all the commands work with a stand-in dummy audio device that has no streaming.

[ghost]

On compiling i get:

CMake Warning:
  Manually-specified variables were not used by the project:

    USE_HAMLIB

I do get my audio devices in CubicSDR:

I select the Kenwood audio device (USB Audio Codec) and get the audio on the waterfall:

Sample Rate menu looks ok:

Not sure what to do next. I don't see any reference to a transceiver nor does frequency change when i change frequency on Cubic nor on the transceiver.

Also you have the SSB frequency entry doubling issue again which i reported in #238.

[cjcliffe]

@Toontje you're compiling SoapyAudio with those parameters right? CubicSDR doesn't support hamlib directly yet it comes through SoapyAudio module. You'll see the rig selection on the property list on the right of the device.

SoapyAudio should show when configuring:

-- Checking for module 'hamlib'
--   Found hamlib, version 1.2.12

I've pushed a quick fix for the frequency-doubling as well (it was only supposed to do it for bandwidth).

If all works you'll see something similar to this:

And in the menu:

[ghost]

Ok, my mistake. I didn't have hamlib installed. Installed the latest version (3.0) from source. Now i get the correct menu entries. Issue (probably hamlib related):

When i select these settings, check the port, CubicSDR gives me a spinning beachball.

UPDATE:
However, when i select the serial port from the menu all seems to be working fine. Happy camper!!

[cjcliffe]

@Toontje not tested here with the source version of hamlib unfortunately; I'm using the latest version from macports which I assume is stable. I'm able to at least use it with the Dummy rig driver and had it talking to my Arduino (though reporting errors since I just made a quick dummy response set) through one of the TS-4xx series protocols.

Perhaps try uninstalling source version (sudo make uninstall?) and do sudo port install hamlib or brew install hamlib depending on which you might have available. I'll have to see what's new in 3.0 before I can be confident it'll work there.

[ghost]

See my update. All is working when i select the correct serial port from the menu.
1.2.12 is the latest on macports, but doesn't support my TS-590. 1.2.15 does. Then, when i looked at the hamlib.org homepage, i found out that the latest version is 1.3 which has been renamed to 3.0.

So i think that, apart from the spinning ball, all is working fine. Now implement the same code for the real SDR devices instead of the audio devices. ;) Great work so far, man!!

[cjcliffe]

Excellent; now I can use SoapyAudio as a 'dummy' driver for now since the RigThread activates once the settings criteria are met and doesn't require an audio stream.

I think the eventual idea is to allow you to have audio-out from computer connected to your rig and be able to use CubicSDR to transmit (including triggering TX and tuning output freq. appropriately) instead of just act solely as a panadapter. In that case the 'dummy' SoapyAudio rig device becomes the TX output while the SDRPlay, etc. is your RX.

If it's too much to try and shoehorn in there then we'll take a look at limiting the SoapyAudio hamlib usage to relevant setups and integrate remaining hamlib features directly.

[ghost]

I don't know how other radios do this, but the Kenwoods have a virtual serial port driver and a audio codec that ports the audio from the rig to the PC using the USB port. The same USB port that you CAN use (you can also use the RS232 serial port on the rig) to control the radio.
I think there are various scenarios here. Sending and receiving audio over the standard PC audio-in and audio-out ports which can be used for the Softrocks and the likes, the special audio codecs like the ones Kenwood is using and then the specific SDR ones like the BladeRF type of devices.
For me personally, i listen to the transceiver when i use the CAT, mostly using the RTL adapter. When i use the SDRplay i use the audio from CubicSDR. The Kenwood codec i only use when i want to decode stuff. It's good to have a device that ports audio without any losses from the radio direct into any software program like FLDigi or even Krypto500.
One thing i noticed is that when using the audio devices is that when i change the frequency using either CubicSDR or the radio the waterfall doesn't move with it (see https://www.dropbox.com/s/a4g4jstkk5y7r6x/CAT1.mov?dl=0). So if i wanted to use the Kenwood codec to listen to the rig using CubicSDR's audio i cannot.

[cjcliffe]

@Toontje yeah I see the issue with that; I think we're going to hit a bunch of problems trying to fit all the scenarios into SoapyAudio as I'd need to hack around that -- I'm going to bring the RigThread over to a new branch of CubicSDR and start plugging it in there and add the special hamlib case for SoapyAudio handling instead of repurposing it as a dummy. We'll leave SoapyAudio with the option to use hamlib on it's own for SoftRock and I/Q hybrid radio types and it made a reasonable initial test; that will leave CubicSDR free to have it's own global CAT control configuration (plus rotator controls and relevant utility functions, etc.)

[cjcliffe]

Added a 'rig_control' branch to CubicSDR for native hamlib support; no controls yet but hope to have something working shortly if you want to get hamlib configured for it.

[cjcliffe]

@Toontje a basic hamlib configuration and frequency control implementation is now built-in to CubicSDR in the 'rig_control' branch.

You can set-up the rig via the menu options (probably a dialog eventually) and enable/disable it as needed.

edit: note that -DUSE_HAMLIB=1 cmdline or checkbox in CMake-GUI needs to be enabled for CubicSDR as well; mine came in cached as off (though I defaulted it to ON in the CMake config).

Let me know how it goes 👍

[ghost]

TM-MBP:build Ton$ cmake ../ -DwxWidgets_CONFIG_EXECUTABLE=/Users/Ton/wxWidgets/wxWidgets-staticlib/bin/wx-config -DCMAKE_BUILD_TYPE=Release -DBUNDLE_APP=1 -DCPACK_BINARY_DRAGNDROP=1 -DENABLE_DIGITAL_LAB=1 -DENABLE_LIQUID_EXPERIMENTAL=1 -DUSE_HAMLIB=1
-- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.28") 
-- Checking for module 'hamlib'
--   Found hamlib, version 3.0
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_PREFIXES
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_SUFFIXES
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_PREFIXES
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_SUFFIXES
hamlib_INCLUDE_DIR=/usr/local/include
hamlib_LIBRARY=hamlib_LIBRARY-NOTFOUND
CMake Error at cmake/Modules/LibFindMacros.cmake:74 (message):
  Required library hamlib NOT FOUND.

  Install the library (dev version) and try again.  If the library is already
  installed, use ccmake to set the missing variables manually.
Call Stack (most recent call first):
  cmake/Modules/Findhamlib.cmake:42 (libfind_process)
  CMakeLists.txt:42 (find_package)


-- Configuring incomplete, errors occurred!

Any ideas?

[cjcliffe]

@Toontje strange, that's the same 'Findhamlib' script from SoapyAudio -- I got that error here because /opt/local/ wasn't part of my path when using the CMake GUI but I was able to copy + paste (after clicking 'advanced' and searching 'ham' to see them) the hamlib cmake vars from SoapyAudio to CubicSDR.

If you can do that to test for now I'll be able to resolve the cmake issue this evening.

[ghost]

Hahaha. I have no clue what you are talking about. ;-) I don't use the CMake GUI. My hamlib is in /usr/local instead of in /opt/local. I prefer manual build tools to be separated from MacPorts builds.

[cjcliffe]

@Toontje LOL, this should provide some context:

I use command line cmake for pretty much everything except CubicSDR which I do in CMake GUI for tinkering with options and rebuilding live in XCode :)

For command line that should translate to you as adding:

cmake [.. the usual stuff ..] -DUSE_HAMLIB=1 -Dhamlib_INCLUDE_DIR=/usr/local/include -Dhamlib_LIBRARY=/usr/local/lib/libhamlib.dylib -Dhamlib_STATIC_LIBRARY=/usr/local/lib/libhamlib.a

Just for now until I can rewrite the Findhamlib.cmake to work better.

[cjcliffe]

@Toontje git pull CubicSDR and you shouldn't need any more hamlib magic; fixed a dependency order and added a better starting point for Findhamlib.cmake

[ghost]

Working as expected. Continuing testing. If I do see a couple of things, I will open separate issues for them.

[ghost]

Check https://www.dropbox.com/s/i4906w7pwb9ovz7/rigcontrol.mov?dl=0
I start using the SDRPlay with Kenwood TS-590S rig control. All works fine until CubicSDR starts to get re-buffering issues. This makes CubicSDR to behave really sluggish.
At some point (04:15) i switch to the RTL adapter to see if this makes a difference. The "Unknown command or rig busy" issue you see if because the settings file selects the IF frequency of the Kenwood (73.095MHz) which the Kenwood doesn't support. That's why i asked for per-device settings and frequency offset in the settings file.
What else? Nothing else. Yeah, propagation is crap today, but i suspect you will not be able to fix that.

[cjcliffe]

@Toontje looks like it's fighting the screen recorder for CPU or something and the buffers are piling up; CubicSDR should get a solid 30-60fps during normal use.

What are you using for screen recording? I usually just open Quicktime player and hit the "New Screen Recording" -- it's the most efficient on here and I still have to knock it down to about 1024x768 to get a screen recording without it causing issues with CubicSDR UI (on 2010 macbook).

I feel like there's a more intelligent rig-specific feature or state I can add to CubicSDR to handle the need to keep shifting the offset or automate it with editable/switchable rig configs -- Now that we have the Rig Control menu we might as well implement the convenience there (assuming it is just a rig related issue).

Not quite sure I understand the IF rig frequency issue; I'll find a copy of the manual and see what it says.

Doubtful I can commit an update to fix propagation in this reality :)

[ghost]

No, CubicSDR also runs out of buffers when i am not recording. And yes, i record the same way you do, with QuickTime. This is an Early 2011 MacBook Pro with 4 core i7 at 2GHz and 16Gb of memory.

About the offset issue, what i have here is two SDR's connected to the TS-590.
The SDRPlay is tapped directly from the RX path close to the antenna input. So what i hear there is exactly the same as what i hear on the antenna. This makes that i can tune the SDRPlay to any frequency the SDRPlay supports. Ideally this frequency would be synced with the frequency CubicSDR shows on the waterfall. This is ideal because i can see what is happening on the band and tune, either with CubicSDR or the rig itself to the frequency i want to work. Also, the multiple modulators make it possible for me to listen to multiple split frequencies and hear where the DX station is listening. This is a great use case for CubicSDR. This all works and i am extremely happy with it.

The second SDR is an RTL adapter. This one is tapped from the first IF in the rig. That IF has a frequency of 73.095 MHz and any signal that passes the RX path in the rig obviously passes through this IF. If you look what HDSDR is doing, it allows you to use it as a panadapter (see https://sites.google.com/site/g4zfqradio/hdsdr-use-with-rtl-dongle and then https://sites.google.com/site/g4zfqradio/hdsdr-if-pano). I can write out what is explained on these pages, but that would be overdoing it. You can go through them, they are very good.

Now that i am writing this i start to think that for my situation the RTL adapter doesn't even make sense anymore. CubicSDR + SDRPlay does what i want. But i think many people are using the second setup as well so it might (or might not) be worth looking into it.

Although you say you cannot change propagation i think you do. Something has changed since yesterday and i didn't do anything from my side. ;-)

[cjcliffe]

@Toontje Ok, I think I mostly understand the use cases now; I can add a "Rig SDR-IF" option to the Rig menu and figure some way to store it in relation to the current Rig+SDR device. What this would do is lock the frequency of the SDR device to a user-supplied IF frequency and then all center frequency changes would only be sent to the Rig. Switching devices would automatically use previously defined IF; setting the IF to 0 or disabling the Rig would return to normal operation.

Can you produce a more detailed log of the buffer failures when you get a chance? That's a fairly new thing I added for finding leaks -- couldn't quite read it all from the video log and there might be other relevant information in there worth looking at.

[ghost]

I am trying all i can to get the buffering messages back. I switched recording on, increased the sample rate to load up the CPU, used different modulations and set the waterfall to the highest and i cannot reproduce the buffering messages. I will record my settings when they come back.
As for the IF use case. As you have seen in my blog article, i now have removed the RTL-SDR and the IF connection from the radio, so i will not be able to test this anymore.

[cjcliffe]

@Toontje shouldn't need a rig to test it -- glad the SDRPlay + rig control is working well enough that you don't need it :)

I can just set it to hamlib dummy here with my RTL-SDR and set the IF to a local FM station or something to test -- I have the locking implemented here already, just need to update the menu.

[ghost]

Honestly, thinking about it, the IF use case IMHO should not be much more than syncing the frequencies in the CubicSDR interface to the VFO of the rig while listening to a fixed configurable IF frequency. Should not be difficult to implement. but that's my simplistic view on programming. ;-)

[cjcliffe]

@Toontje Yup I'll have it in tonight and it is actually relatively simple -- just had to disconnect the stuff that was listening for frequency changes first which I finished last night. Working out the details of saving the IF per-device per-rig at the moment.

[cjcliffe]

@Toontje Per-Rig + Per-SDR IF frequency is now implemented in rig_control, it'll activate and de-activate with the Rig Control and save/load from the config.

Going to mark CAT control closed for now, any additional rig features or implementations you're interested in just open a new issue or head over to the pull request at #244 if it's still open.

Cheers!

[ghost]

I will test asap. Thanks again!!

On Sat, Jan 9, 2016 at 6:14 AM, Charles J. Cliffe [email protected]
wrote:

@Toontje https://github.com/Toontje Per-Rig + Per-SDR IF frequency is
now implemented in rig_control, it'll activate and de-activate with the Rig
Control and save/load from the config.

Going to mark CAT control closed for now, any additional rig features or
implementations you're interested in just open a new issue or head over to
the pull request at #244 #244
if it's still open.

Cheers!

—
Reply to this email directly or view it on GitHub
#70 (comment).