Possible QMX+ source

[kalehmann]

Feature proposal

This feature request proposes to provide a new source for SDR++, that sets a QMX+ transceiver automatically in IQ mode, syncs the frequency with the device via CAT commands and mutes audio during transmit.

Background

I own a QMX+ QRP radio which is an SDR device and has support for IQ output via USB audio. Since the device has no spectrum display, I want to use SDR++ (which is great software btw, thanks so much) as a panadapter.

This is already possible with the SDR++ audio source:

For this to work, the QMX+ has to be only set to IQ mode, which can be done via the CAT-command w Q91 or the serial interface.

Next I can also start a rigctld instance and use the rigctl_client module of SDR++ to to sync the frequency of with the device via

 rigctld
     --model=2057 \
     --rig-file=/dev/serial/by-id/usb-QRP_Labs_QMX_Transceiver-if00 \
     --serial-speed=115200 \
     --listen-addr=127.0.0.1 \
     --port=4532

Now the problem with that is, that the IQ data from the QMX+ is shifted by 12 kHz. Unfortunately, the Offset mode setting seems to have no effect for the audio source of SDR++.
I therefore wrote a small Python script, that acts as a proxy to rigctld and automatically adapts the frequency with

freq_change = re.compile(rb"^F \d+\.\d+\n$")
while (request := client_socket.recv(1024)):
    if freq_change.match(request) is not None:
        freq = float(request[2:-1])
        freq += 12_000
        request = f"F {freq:.6f}\n".encode()
    
    # Next line passes request to rigctld
    proxy_resp = rigctld.proxy(request)    
    client_socket.send(proxy_resp)

Now I only have to make sure, that the VFO in SDR++ is always positioned on three quarters of the spectrum and I change frequency in SDR++ by dragging the band left and right.

Finally when I key up the QMX+, the IQ data pauses as it is, which causes a weird screeching sound from SDR++, so I mute my laptop every time before I hit PTT and unmute afterwards.

While that setup works for me, it is really hacky. A real QMX+ source in SDR++, that works out of the box would be so much appreciated. I expect it to be technically not that challenging as the audio source already works, hamlib could be used to sync the frequency with the QMX+ (including the 12 kHz offset) and read the PTT state from the QMX+ to mute the audio output during transmit. However I am fully aware, that the developer of SDR++

1. most likely does not own that device
2. does not welcome pull requests with code changes

Now my question is, would there be any practical way to realize this?

[AlexandreRouma]

Just use the rigctl client module to send the tuning commands

[kalehmann]

I am sorry that I did not describe that clear enough - I already use the rigctl_client module to send the commands. However if I would do that without my little Python proxy, that rewrites all the F ... (change frequency) commands, the frequency in SDR++ would be offset from the frequency of the device by 12 kHz.

To clarify this, I just connected SDR++ to rigctld directly and tuned to the 80 meter FT8 frequency of 3.573 MHz in SDR+:

As you see in the screenshot, the FT8 signals are clearly at 3.585 MHz (12 kHz above the expected frequency) in SDR++.

Setting the Offset mode for the Audio source to Manual and entering the 12 kHz as offset has unfortunately no effect on that. Second, I still have the issue with the weird audio screeching during transmit.

[kalehmann]

However, I would also greatly approve further tips on how I could do this more smoothly without adapting SDR++ at all.

[AlexandreRouma]

Setting the Offset mode for the Audio source to Manual and entering the 12 kHz as offset has unfortunately no effect on that.

That's a bug, I'm gonna fix it.

[kalehmann]

That's a bug, I'm gonna fix it.

Thanks, that would be great.

I'd like to go one step further on that. Another problem which I unfortunately did not describe that good, is that it would be really helpful to have the VFO in SDR++ always on the frequency that the radio is tuned to.

If the offset of 12 kHz is correctly applied, the frequency display in SDR++ matches the frequency of the signal, however the radio is not tuned to the center of the waterfall, but 12 kHz above the center (the QMX+ does that, to not have the DC spike overlap the signal).

That can be seen clearly in the screenshot above. There SDR++ is again synced with the radio via rigctld and the proxy that applies the 12 kHz offset to the change-frequency-commands. Here the radio is tuned to the 80 meters FT8 frequency of 3.573 MHz and SDR++ correctly displays that frequency for the signal.

Now, if I would click in SDR++ on some of the CW-signal on the left of the screen, the VFO would just move without any re-tuning. When I would then key up the radio, it would transmit still on the FT8 frequency. Therefore I always have to be careful, to move the band to change frequencies to always retune the radio.

I am aware of the key centerTuning in config.json - if that is set to true, clicking anywhere on the waterfall tunes to that frequency and moves the current VFO to the center. In the given case that is not suitable, as the VFO is now 12 kHz below the frequency, that the radio is tuned to.
Would it be possible to configure centerTuning with an offset in the UI?

That means when I click somewhere on the waterfall, the software tunes to that frequency minus the configured offset and moves the current VFO by the configured offset away from the center?

---

Reading the above again before sending, I realize my explanation is still quite confusing - I am sorry for that. Feel free to inquire further in case you do not get my intent.

[AlexandreRouma]

Center tuning is enabled with the button next to the frequency, refer to the manual.
And when the bug will be fixed there will be no 12KHz offset.

[kalehmann]

Center tuning is enabled with the button next to the frequency, refer to the manual.

Didn't know that yet, sorry for not reading the manual throughoutly.

And when the bug will be fixed there will be no 12KHz offset.

Well, I believe there still will be due to the radio being a superhet with a 12 kHz intermediate frequency. If I would tune to for example 3.6 MHz, the radio internally tunes to 3600 kHz - 12 kHz = 3588 KHz, so the center frequency in SDR++ will be just that.

However, if I hit PTT the radio still transmits on 3600 KHz. Therefore I have to make sure that - for this device - the VFO in SDR++ is always 12 kHz besides the center

[bubnikv]

I am working on a SDR++ fork specifically for QMX, both for remote use and local (direct USB) use. At the current state I have a very ugly prototype of UDP streaming from one Android phone to another one, not ready for prime time yet, but it brings me a lot of joy already. Currently receive only, the 12 kHz offset is accounted for inside the remote server.

https://github.com/bubnikv/SDRPlusPlus-iak
https://github.com/bubnikv/qmxserver-android

My goal is to have it working locally, however the catch on Android is that the Android stack identifies the QMX USB audio and steals it. There is a way to get it back partially by directly accessing the USB device with libusb, which I have proven working with the qmxserver-android. In addition, the Android stack has to be convinced to switch the audio routing back to the other audio devices.

73, Vojtech OK1IAK