Several Unsupported command received INF log entries

Bugs
1

Brief summary of problem (put in title as well):

There are several “Unsupported command received” INF log entries for legitimate CI-V commands I am sending to the radio. The commands appear to exist in the Rig files. When this happens the spectrum display freezes.

Radio Model: IC-9700, IC-705, IC-905
Connectivity (USB/Ethernet/Wifi/Other): LAN/WiFI
Operating System: Pi OS on Pi 5
wfview version (press “About”): 2.04 March 10 build using fullbuild script
Checked the wfview manual (Y/N): Y
Checked the wfview FAQ (Y/N): Y
Tried to google it (Y/N/NA): Y

What I did: Sending a range of CI-V commands to the radio from a program over the virtual serial port.

Expected behavior: Should not get these messages, spectrum should not freeze

Observed behavior: Spectrum freezes, lots of log entries for each commands sent.
These are replies from the radio for legitimate commands and they exist in the Rig File. I put a few examples below.

INF rig: Unsupported command received from rig "2700000101" Check rig file

These are 0x27 Spectrum waveform data output commands and they stop when I turn off the spectrum view on the radio. Rig file has:
Commands\109\Type=Scope Wave Data
Commands\109\String=\x27\x00

INF rig: Unsupported command received from rig "2500005095" Check rig file

The 0x25 is selected/unselected VFO reply. Get this for both the 705 and 9700. Rig file has these entries:
Commands\105\Type=Selected Freq
Commands\105\String=\x25\x00

I also spotted this error in the log after I sent the command to the radio:
WRN rig: **** Function “Read TX Freq” Not Found, rig file may be out of date?
Rig file has:
Commands\101\Type=Read TX Freq
Commands\101\String=\x1c\x03

…
2025-03-12 17:47:18.955 INF rig: “Have new rig ID: 0xa2”
2025-03-12 17:47:18.958 INF rig: “Loading Rig: IC-9700 from /usr/local/share/wfview/rigs/IC-9700.rig”
2025-03-12 17:47:18.960 WRN rig: **** Function “Read TX Freq” Not Found, rig file may be out of date?
2025-03-12 17:47:18.961 INF serial: Got rigcaps for: “IC-9700”
…

Also get this error - Not sure it has anything to do with any of this:
WRN qt.qpa.wayland: Wayland does not support QWindow::requestActivate(

2

This is an issue with Wayland (the new window manager that has replaced X11 in many distros). It appears to be benign, but is generated by the Qt platform that wfview uses (once they fix it, the warning should disappear)

Although the command is added to the rig file for various rigs, wfview doesn’t currently do anything with it (hence the warning to remind us to implement it!)

The 25/26/27 command warnings are something else entirely, without knowing exactly what commands you sent and what sender address you used, it is difficult to say what is happening here though as those commands are definitely supported.

Most likely, we should adapt wfview to ignore commands that are sent to a recipient other than 0xE1 (the sender address that wfview uses).

If you can share the commands that you sent (or your script) we can try to replicate this issue.

3

I am using controller address 0xE0. The radio addresses are defaults for each of the 3 radios, A2, A4 and AC.

I never issue a 0x27 command and I do not see them sent to me either. I suspect it is “crosstalk” in the CI-V bridging functionality. These messages start a soon as I start to communicate. When this happens the spectrum in GUI freezes. Everything else still works.

I can skinny down all sent commands until I find where the unsupported commands stop.

4

The code is at

https://github.com/K7MDL2/CI-V_Serial_Band_Decoder

Clone the repo, chmod the install script and run it. It downloads the dependencies and sets up a systemd service in the user context. use can use ‘stop_Decoder’ and start_Decoder to stop it and run it manually. The config and log files are in ~/$USER.

5

I found it. I removed all sent commands and listen only to the port. No unsupported commands, can RX stuff sent by the radio OK.

I then added one sent command, 0x19,0x00, TRX ID.
That starts the unsupported messages. They continue long after I have stopped my program. I see in the log below it sees address 0x0 and loads a new rig file. That is probably not good.

2025-03-13 03:03:13.381 INF system: receiveMode "Received new mode for Main: 2 (AM) filter:1 data:0"
2025-03-13 03:03:13.382 INF serial: pty detected remote CI-V: "0xe0"
2025-03-13 03:03:33.651 INF system: receiveMode "Received new mode for Main: f (WFM) filter:1 data:0"
2025-03-13 03:04:07.391 INF rig: "Have new rig ID: 0x0"
2025-03-13 03:04:07.392 INF rig: "Loading Rig: DEFAULT from /usr/local/share/wfview/rigs/DEFAULT-ICOM.rig"
2025-03-13 03:04:07.393 INF rig: Unsupported command received from rig "164401" Check rig file

I am auto detecting the radio CI-V address by sending a message out before I know the CI-V address. I am using a radio address of 0x0 (which I understand is a broadcast address). I then receive the first replies and then load up the frequency tables according to the radio model.

I replaced the startup address with 0xA2 and all is good, spectrum stays running. I use 0x0 for the radio address to start with to trigger all my detection logic.

I am thinking that ignoring controller addresses other than your 0xE1 might be one answer. Or, if 0x0 is a valid to-radio direction broadcast address then you would want to ignore it.

Mike K7MDL

6

The current master branch should now have a fix for this issue. It simply ignores TRX ID once the rig model has been detected. It will still pass any response to the pty though.

7

Thanks! Will check it out.

Got the IC-9700 Sub RX logic worked out finally in my serial band decoder that connects to wfView to make it an ethernet decoder.

Configurable to operate the band decoder outputs for cross-band split (Sub in RX, Main for TX) or Main band only (MAIN for TX and RX). Just finishing putting the same logic into my USB band decoder.

Running today’s build, working well with one observation. Many times after running normally with my app then I want to disconnect to switch to another radio for testing, if I press disconnect button it will crash. The radio LAN connection is of course still open then. Sometimes when I restart wfView after this, it crashes immediately before I can hit the disconnect button. Usually the 3or 4th try I can hit disconnect and all works again. I saw there is a debug switch, I have not tried it yet. I have to return the borrowed IC-9700 likely tomorrow night so I am rushing to get support for it done by then.

I have shifted my normal operation to use the --platform vnc. Using half the CPU. I have not figured out how to make -platform offscreen work.

– Mike K7MDL