Error during frequency scan using 1.7.5-beta7

[hb9hfn]

Hello!

I'm using Auto-RX 1.7.5-beta7 and got following error every 5-10 minutes. Tested on an Intel Debian 12 iNUC and on a Raspi 5. SDR is an Airspy mini, latest version of everything:

2024-09-28 13:34:38,814 INFO:Scanner (SpyServer localhost:5555) - Running frequency scan.
2024-09-28 13:35:08,817 CRITICAL:Scanner (SpyServer localhost:5555) - ss_power call failed with return code 124.
2024-09-28 13:35:08,817 CRITICAL:Scanner (SpyServer localhost:5555) - Other Error: center_freq: 403000000 fft_res: 100
bins for res: 100000 fft bins: 32768 resolution: 305.175781Hz
SS_client_if(localhost, 5555)
SS_client_if: Trying to connect
SS_client_if: Connected

---

Device Info:
Type: 1
Serial: 877896803
MaximumSampleRate: 6000000
MaximumBandwidth: 4800000
DecimationStageCount: 11
GainStageCount: 0
MaximumGainIndex: 0
MinimumFrequency: 24000000
MaximumFrequency: 1800000000
Resolution: 12
MinimumIQDecimation: 0
ForcedIQFormat: 0

---

Client sync:
Control: No
gain: 14
dev_ctr: 403000000
ch_ctr: 403000000
iq_ctr: 403000000
fft_ctr: 403000000
min_iq_ctr: 400600000
max_iq_ctr: 405400000
min_fft_ctr: 403000000
max_fft_ctr: 403000000
SS_client_if: Ready
Desired decimation stage: 0 (6000000 / 1 = 6000000) resample ratio: 1
ss_client: setting center_freq to 403000000
SS_client_if: The server does not allow you to change the gains.
SS_client_if: Starting Streaming
SS_client_if: Error in ThreadLoop: parse_message Server is running an unsupported protocol version.

2024-09-28 13:35:08,817 WARNING:Scanner (SpyServer localhost:5555) - SDR produced no output... resetting and retrying.
2024-09-28 13:35:18,818 INFO:Scanner (SpyServer localhost:5555) - Running frequency scan.

Sometimes:
SS_client_if: Starting Streaming
timeout: the monitored command dumped core
Segmentation fault

Any help appreciated,
Cedric

[darksidelemm]

It's possible that there's been a spyserver update which has changed the protocol versions. @miweber67's spyserver_client is looking for a specific major/minor protocol version.

I downloaded the latest ARM64 spyserver from the airspy website, and the spyserver software build has not changed from when I last looked (late July) - v2.0.1920

What version do you see when starting up the spyserver binary manually?

[darksidelemm]

If you're feeling a bit enterprising, could I get you to clone my fork of spyserver_client (where I've just added a line to print out the server protocol version) and try connecting to your spyserver?

git clone https://github.com/darksidelemm/spyserver_client
cd spyserver_client
make
cp ss_client ss_iq
cp ss_client ss_power

Then, assuming your spyserver instance is running on the same host as this:

./ss_iq -f 401500000 -s 48000 -r localhost -q 5555 - > /dev/null
./ss_power -f 403000000 -i 20 -1 -o -r localhost -q 5555 test.csv

If there is a protocol issue, this should print out the same error as you had before

[hb9hfn]

This is strange. I was using the docker version (both versions "testing" and "latest" checked and giving the same errors) and installed the latest version of spyserver a few days ago. Most of the time there are error messages without the one with the unsupported protocol text. Spyserver version is: "SPY Server v2.0.1920"

[hb9hfn]

Other error messages:

SS_client_if: Starting Streaming
ss_power: pthread_mutex_lock.c:167: ___pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
timeout: the monitored command dumped core
Aborted

SS_client_if: Starting Streaming
timeout: the monitored command dumped core
Segmentation fault

SS_client_if: Starting Streaming
Received 0 samples in 3.32991476e-07 sec (0 samp/sec)
SS_client_if: Stopping Streaming
timeout: the monitored command dumped core
Segmentation fault

[darksidelemm]

OK, so 2.0.1920 is the same version I've been testing with... Unfortunately I don't know what's going on here. The spyserver client is @miweber67's code, and I don't think they really want to support it anymore (and I don't blame them).

[darksidelemm]

I think trying to see what incorrect version the client think it's getting would still be valuable here. It's possible this is some kind of data corruption issue, and not a version problem at all.