OpenWebRx and KiwiSDR added to Max/MSP control program

The Max remote receiver project described in an earlier post: https://reactivemusic.net/?p=20965 now includes support for OpenWebRx and KiwiSDR sites.

When using OpenWebRx, you need to select a “profile” that supports the receive frequency range, before you can operate within that frequency.  Its an unusual system that uses an offset frequency within the selected profile, instead of a global “actual frequency” like the other platforms.

The KiwiSDR sites, in general, have very good quality reception and audio.

The next step in this project will be to consolidate a directory of sites that are useful for remote reception in the ham bands for various parts of the world.

files

See above linked post

Using hamlib to poll frequency data with Max/MSP

This Max patch connects to a radio transceiver and reads the frequency data using hamlib. Hamlib provides a common API for amateur radio devices. https://hamlib.github.io/. The hamllib server runs in the background using TCP/IP. This patch uses Jeremy Bernstein’s shell object. https://github.com/jeremybernstein/shell and the Sadam Library of externals, installed with the Max package manager.

Files

hamlibtcptest1.maxpat : select radio, starts rigcltd dameon, poll frequency via tcp/ip

launch-rigctld.sh : shell script to run rigctld

Libraries

Max: Jeremy Bernstein’s shell external, and the sadam library from Max package manager.

hamlib can be installed using homebrew

Notes

There is some latency when using the Elecraft K4. Need to look into the internal CAT settings.

Also, look into communication latency of TCP/IP and associated libraries.

I’m exploring a version of this that uses node.js instead of the shell external and tcp/ip library in Max. Initial problem is that the rigctld daemon stays active after Max is closed and needs to get killed manually.

Detect amplifier keying line (PTT) with Arduino

Use an Arduino to detect transmit/receive state.

Using an Arduino Uno to detect the transmit state of a radio. The amplifier keying line (PTT) is grounded on transmit. The Arduino sees it as a switch being pulled low. The keying line is connected to digital input 2 (D2) and ground. The digital input uses the builtin pullup resistor. The sketch is the Arduino digital | input pullup example. Max polls the serial data from the Arduino and displays the state of the keying line.

Websdr as a remote receiver with Max/MSP and Elecraft K4

Remote receiver project using Websdr as a remote alternative to a local receiver.

Demonstration of a Max/MSP program that connects an amateur radio transceiver to Websdr – transmitting locally from Maine (USA) while receiving remotely using a radio in the Netherlands. The Max program reads the frequency from a Elecraft K4 transceiver, to control the Websdr sites. It also loads the remote receivers, controls audio routing, mode, filter, and waterfall display settings. An iPad, running touchOSC, acts a a control panel. Up to 4 remote receivers operate at the same time. Websdr is a remarkable system, developed by PA3FWM at http://websdr.org/. It lets you control remote receivers worldwide, from your Web browser.

Components:

  • Max/MSP
  • Websdr
  • TouchOSC
  • Elecraft K4 transceiver with antenna system
  • Skookumlogger (logging software)

Max Patches:

websdrjweb7.maxpat : main control program. Contains [jweb] objects for launching websdr instances. Also code for injecting javascript to control parameters like frequency, filter, and volume. This patch acts as an intermediary between TouchOSC, WebSDR, and allows external MIDI control as well as getting frequency input from CAT controlled radios like the Elecraft K4.

websdrCATaudio.maxpat : handles serial port interaction for the K4. Also reads audio stream from either the K4 receiver (via USB) or the websdr receiver (via Blackhole.)  I created an aggregate audio device called K4sdr to allow Max to read both devices at the same time. Audio switching and levels are handled using a Korg nanoControl2. For example to switch between the audio streams or listen to both.

Optional: arduino-ptt-detect2.maxpat : reads serial data from an Arduino, connected to the amplifier keying line, to determine whether the radio is in transmit mode, so we can switch back to the local audio stream to eliminate latency of hearing your signal via websdr. See subsequent post about this setup…

TouchOSC

websdrCW3.touchOSC : controls all 4 websdr channels, ie,., volume, mute, filter, CW offset, filtershift, – Also handles window management, loading js code, zoom in/out websdr and selecting channel waterfall views or Max code views.

CW Offset

websdr doesn’t have a control for CW pitch offset. To sync the frequency of the K4, the websdr is run in LSB mode with a frequency offset equal to the CW pitch setting in the transceiver. eg., 450 Hz. This works for most of the websdr sites, but unfortunately some of the sdr’s are off-frequency. You can usually compensate by adjusting the CWfreqOffset for that channel (in Max or TouchOSC).

Setting the offset also requires shifting the filter so it is centered over the actual signal.

Files

This is currently a work in progress, not available on Github. Local files are in max teaching examples folder.

11 Km feedback delay

Using 40 meter SSB, Max/MSP, and Websdr to build a feedback delay from Maine to the Netherlands.

A Max patch plays an audio file into the transmitter in Maine. Then, using a websdr receiver in the Netherlands, the received signal is amplified and mixed back into the audio to be retransmitted. Effectively creating a feedback delay line.

Here is an example of what it sounds like on 40 meters.

http://www.pr0jex.com/longdelayline.mp3

This is the Max patch

The audio from Websdr is routed to the input of Max by creating a multi-output device (In Audio Midi Setup) combining “Blackhole 2ch” and external headphone output (for monitoring). The audio output of Max is assigned to the transmitter SSB input.

Patch not yet available. Local version is in max teaching examples.

Building SoapySDR and CubicSDR with Linux

How to build SoapySDR and CubicSDR from source in Ubuntu 20.04

After unsuccessful attempts to compile SoapySDR and CubicSDR on Mac OS and Windows, I was able to get it running in Ubuntu 20.04.  The whole process took about 2 hours but could be done in less time if you know what you are doing.

It wasn’t really necessary to install CubicSDR to test SoapySDR. But CubicSDR is the only SoapySDR app that consistently works when it comes to devices, I/Q, files and TCP frequency control.

After completing this install I was also able to compile and run the SoapySDR example code here:  https://github.com/pothosware/SoapySDR/wiki/Cpp_API_Example

Build

There are excellent instructions at the CubicSDR wiki on github: https://github.com/cjcliffe/CubicSDR/wiki/Build-Linux

I also added the rtlsdr driver and the airspyhf driver. Instructions for rtlsdr are on the wiki. Instructions for airspyhf are below. You can add these drivers/libraries at any time, after SoapySDR is installed.

There were several missing libraries – described here.

hamlib

Hamlib is an option in CubicSDR. It was included because we’re using it to send frequency data to the devices via rigctld. You’ll need to install hamlib before you try to compile CubicSDR

Instructions and source code here: https://github.com/Hamlib/Hamlib

Instructions are somewhat vague. Here’s what I did.

Install libtool:

sudo apt install libtool

Clone the repository, build, and install:

git clone https://github.com/Hamlib/Hamlib.git
cd Hamlib
./bootstrap
./configure
make
sudo make install

airspyhf

airspyhf library code from Airspy. Instructions here: https://github.com/airspy/airspyhf

This is what I did, if I can remember correctly. You may need to install libusb, but if you have done all the stuff above you probably already have it.

git clone https://github.com/airspy/airspyhf
cd airspyhf
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON<
make
sudo make install
sudo ldconfig

SoapyAirspyHF

Now you can add the Soapy AirspyHF drivers. Instructions here:  https://github.com/pothosware/SoapyAirspyHF/wiki

git clone https://github.com/pothosware/SoapyAirspyHF.git
cd SoapyAirspyHF
mkdir build
cd build
cmake ..
make
sudo make install

 

Python3 tcp client for Max

Using OSC from [udpsend]

I needed a better way to send radio frequency data from Max to a rigcltd daemon (via tcp). This is the method of tuning SDR devices hosted by CubicSDR.

From the max8radio folder run:

py3rigctl2.py

The input is OSC frequency data, on port 8001, in the form: /F 7001000

(This would be for 7.001 MHz)

An OSC server in the python program listens for these messages and then reformats and sends them to a running rigctld daemon running in the background on port 4532

rigctld -m 1 4532 &

The frequency message going to rigctld would be in the format: F+ 7001000

 

Max8radio project

New version of software define radio for Max/MSP  (in progress)

github repository: https://github.com/tkzic/max8radio

Notes

goals and strategy

The new approach will be to remove most of the device handling code from Max. Instead providing device interfaces from existing device libraries, like soapy-sdr, hamlib, gnu-radio, etc., The Max portion of the project will read IQ files, perform DSP, and other magic.

The first platform will be Max8 in Mac OS Catalina

projects

Max + CubicSDR + hamlib

See working prototype below. This setup uses CubicSDR as a device driver to send IQ data into Max’s input audio stream. CubicSDR supports many devices via soapySDR. It supports networked rig control via Hamlib.

Advantages of this system: It works now. It runs in Windows. It runs over the a local network. The software is managed and distributed by somebody else.

Disadvantages: Its not an elegant solution – ie., not self contained within Max. It requires installation and setup of CubicSDr. The software is managed and distributed by somebody else – so it could stop working at any time.

rx_tools + hamlib

rx_tools is an update of some of the rtl tools, like rtl_fm. It includes soapySDR device support. If hamlib is added to rx_tools, then you could do the same networked frequency control, and IQ streaming as CubicSDR – using rigctld. Without the overhead of running CubicSDR. The downside it that it’s yet another program to maintain and distribute.

Next step: look at source code for rx_tools and estimate scope of hamlib intergration.

openwebrx and websdr API

openwebrx  https://www.openwebrx.de/

Websdr  http://websdr.org/

These sites provide access to SDR devices connected to web servers. Although they don’t stream IQ data, it would be interesting to build a Max front end to the APIS.

background information

See previous posts:

External programs required

  • hamlib (macports)
  • cubicSDR (see link above)
  • netcat (nc) (built into Mac OS terminal)

notes on rigctld commands

Best results using one letter commands with single quotes:

echo 'F 7023000' | nc -w 1 localhost 4532

Prepend ‘+’ for more feedback, like this:

% echo '+F 7023000' | nc -w 1 localhost 4532
set_freq: 7023000
RPRT 0

Latest prototypes

Links to latest working projects (from newest to oldest)

 

First Max test project

This is an update of the test done with CubicSDR and RTLSDR as described here: https://reactivemusic.net/?p=19802

CubicSDR is great but eventually the goal is to pare down the interface between the SDR device and Max. Something like a command line IQ filter would be ideal:  https://github.com/xmikos/simplesoapy

Hardware and system setup

This test uses an Airspy Discovery HF+, but any device supported in CubicSDR should work – that’s the point of this exercise.

Using BlackHole from Existential Audio https://existential.audio/blackhole/

as an alternative to Soundflower to route the IQ (audio stream) data from CubicSDR to Max. You could also use a cable to connect output of one audio device to input of another, etc.,

Signal path:

Antenna -> Airspy -> CubicSDR -> rigctld -> Max

CubicSDR settings

  • Plug in Airspy device before launching CubicSDR, so it will be discovered on the setup screen
  • On the main display, click just to the right of the mode buttons to bring up a drop down menu of audio devices
  • select I/Q mode
  • select the audio device, or “BlackHole 2ch”, that you will use to route audio to Max
  • click on any of the frequency digits, press space, and enter in the same frequency as the Center Frequency (e.g., 7000000)
  • click the ‘V’ to the left of the frequency digits, to select ‘delta lock mode’. This causes the frequency and center frequency to sync.
  • Be careful not to click anywhere in the waterfall window – or this will mess up the sync
  • Under Rig Control menu:
    • Select “Hamlib NET rigctl” as the model
    • Enter localhost:4532 as the control port
    • Select 57600 as the serial rate
    • Make sure that “follow rig” and “floating center” are checked
    • After you get the rigctld daemon started, come back here and ‘Check’ ‘enable rig’. If it doesn’t stay checked, then there is a problem with the connection.
  • Under the Audio sample rate menu, select the correct sample rate for your audio device (e.g. 96k)

Notes: It seems there is some kind of AGC hardwired into CubicSDR.  https://github.com/cjcliffe/CubicSDR/issues/826

TCP and rigctld settings

  • Open a terminal window
  • type: rigctld -m 1 4532 &
  • This starts the server running in the background using the HAMLIB test dummy rig
  • to set frequency to 7.010 MHz, type:

    echo ‘F 7010000’ | nc -w 1 localhost 4532

  • This should change the center frequency and frequency in CubicSDR

Max settings

For this test, you can use any of the MaxSDR tutorials available  at https://github.com/tkzic/max8radio

We’ll be using maxsdr7a.maxpat

ignore the max-console messages about missing externals.

The key is to choose the default audio input device and set it to be the same as what is coming out of CubicSDR.  ie., “BlackHole 2ch”

  • Set the audio input device to match CubicSDR, as described above. Also match the sample rate (e.g., 96k)
  • Set the audio output device to your internal soundcard/speakers
  • Start audio and recall preset 1 or some normal settings for SSB
  • It should be receiving I/Q data now from Cubic SDR
  • Note: may need to flip the I/Q input due to anomaly in CubicSDR.
  • Now load another Max patch to do the frequency control: rigctld1.maxpat

This patch sends frequency data to the rigctld daemon via the [shell] object. You can change the frequency using the number box.

That’s about it for now.

Generic SDR realtime IQ converter

With CubicSDR, HAMLIB, and Max

update: 1/25/2021 – Using this general setup with Airspy, CubicSDR, rigctld, and netcat (nc) to send IQ data into the basicSDR3.maxpat patch


CubicSDR uses the SoapySDR library as generic tool for extracting realtime IQ data streams from common SDR devices. It also provides TCP external frequency control using HAMLIB.

http://cubicsdr.com/

Although its not the main purpose of CubicSDR, the IQ streaming capability will connect SDR devices to Max, Pd, and other DSP platforms, to build experimental radios. All without building external objects or hardware device drivers.  The convenience of using CubicSDR for this purpose far outweighs the overhead.

A prototype with Max and rtl_sdr

How to use CubicSDR as a front-end for SDR experiments in Max.

The signal path for this test is:

  1. antenna
  2. NooElec HAM IT UP upconverter
  3. rtl-sdr dongle
  4. CubicSDR
  5. Soundflower (or a “loop-backed” external audio device)
  6. Max

Running in the other direction, the frequency control path is:

  1. netcat running in Mac OS X terminal (or a Max patch that sends TCP)
  2. rigctld (hamlib TCP server)
  3. CubicSDR
  4. rtl-sdr dongle

There’s a lot of stuff going on here, so the choice to use hardware audio routing instead of Soundflower and netcat instead of TCP in Max, is an effort toward simplicity.

CubicSDR settings:

  • Plug in the rtl-sdr before launching CubicSDR, so it will be discovered on the setup screen
  • On the main display, click just to the right of the mode buttons to bring up a drop down menu of audio devices
  • select I/Q mode
  • select the audio device, or Soundflower, that you will use to route audio to Max
  • If using an upconverter, set the ‘frequency offset’ in the settings menu (e.g. -125000000)
  • click on any of the frequency digits, press space, and enter in the same frequency as the Center Frequency (e.g., 7000000)
  • click the ‘V’ to the left of the frequency digits, to select ‘delta lock mode’. This causes the frequency and center frequency to sync.
  • Be careful not to click anywhere in the waterfall window – or this will mess up the sync
  • Under Rig Control menu:
    • Select “Hamlib NET rigctl” as the model
    • Enter localhost:4532 as the control port
    • Select 57600 as the serial rate
    • Make sure that “follow rig” and “floating center” are checked
    • ‘Check’ ‘enable rig’. If it doesn’t stay checked, then there is a problem with the connection.
  • Under the Audio sample rate menu, select the correct sample rate for your audio device (e.g. 96k)

TCP and rigctld settings

  • Open a terminal window
  • type: rigctld -m 1 4532 &
  • This starts the server running in the background using the HAMLIB test dummy rig
  • to set frequency to 7.010 MHz, type:

    echo ‘F 7010000’ | nc -w 1 localhost 4532

  • This should change the center frequency and frequency in CubicSDR

Max settings

For this test, you can use any of the MaxSDR tutorials available at https://github.com/tkzic/maxradio but I chose to use the main program, currently maxsdr7a.maxpat. The key is to choose the default audio input device and set it to be the same as what is coming out of CubicSDR.  I used a stereo patch cord to connect the line output of my Apollo Twin interface to the input jacks – but you can also use Soundflower.

  • Set the audio input device to match CubicSDR, as described above. Also match the sample rate (e.g., 96k)
  • Set the audio output device to your internal soundcard/speakers
  • You may need to toggle the flip IQ button
  • Start audio and recall preset 1 or some normal settings for SSB
  • It should be receiving I/Q data now from Cubic SDR

Links:

Installing Hamlib: https://reactivemusic.net/?p=19402

Installing CubicSDR: https://github.com/cjcliffe/CubicSDR/releases

Supported SDR devices: https://reactivemusic.net/?p=19746

Notes:

I had some success using the Max TCP external described at the Installing Hamlib link above, but temporarily abandoned it due to some latency and dropouts.

Local version of this patch is: tcpClient-small2.maxpat

Next steps:

  • hardware (i.e., MIDI controller) control of frequency – and refinement of Max TCP patch. Can likely re-use the patch from the remote radio project.
  • Convert to PD : TCP/IP code is builtin
  • Consider forking CubicSDR and adding direct MIDI/OSC control of UI.