Faulty SNR reports

[helioshk]

Hi, A number of erroneous SNR reports popped up on wsprnet, all of them reporting version rtlsdr-wspr. The users report much too high SNR, up to +60 dB. Let me know if you need examples.

[IZ7BOJ]

Hi, I’m checking my received spots and I confirm they’re too high compared to the results obtained with old version of rtlsdr_wsprd I hope Guenael can have a look into the code Alfredo IZ7BOJ

Il giorno mer 22 dic 2021 alle 18:26 helioshk @.***> ha scritto:

Hi, A number of errornous SNR reports popped up on wsprnet, all of them reporting version rtlsdr-wspr. The users report much too high SNR, up to +60 dB. Let me know if you need examples.

— Reply to this email directly, view it on GitHub https://github.com/Guenael/rtlsdr-wsprd/issues/110, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJCWU3XD2R6EKHN3YZUE6ULUSIC5ZANCNFSM5KTA47PQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Guenael]

Hum... I will check the code, but wsprd is supposed to calculate the SNR, and your input signal should have no impact. @helioshk Could you give some details on your conf? (command line used, version etc. A copy paste of the app init. should do the job.)

[helioshk]

I'm not running rtlsdr-wsprd, I only noticed the anomalous spots. Perhaps @IZ7BOJ can provide the config but numerous users seem to be affected.

[Guenael]

@helioshk the version of rtlsdr-wsprd is included in each post (code), do you know if it's possible to filter on this specific version field?

I take a look here and here but I didn't found the right option. How did you get the clue about rtlsdr-wsprd ?

Thanks!

[helioshk]

@Guenael On this site it is possible to search for spots submitted by specific versions: http://wspr.rocks/ in the "advanced search" menu. The query is and version = 'rtlsdr-wsp' (only the first 10 characters of the version ID are stored)

[Guenael]

@helioshk Nice, TIL!! :+1: And I will update my version field, to fit something smaller.

[Guenael]

I upgraded to a more recent version of wsprd, it could have fixed this issue at the same time. But I will add another function to load the regular .c2 files and made some comparison/benchmark. I also updated the version field of my app: rtlsdr-050 for now.

[Rilapy]

I tried 0.5.0 and I am still seeing the elevated snr. At the moment I am using pihole to block wsprnet.org to stop the reporting. I have already uploaded too many of these spots.

rtl-sdr + gqrx + wsjt-x 211223 1044 -26 1.39 10.1401623 VK6KOZ OF77 23 0 0.20 1 1 0 0 31 25 -24

rtl-sdr + rtlsdr-wsprd Spot : 2021-12-23 10:50:00 35.18 -0.83 10.140153 0 VK6KOZ OF77 23

I then used rtl-sdr + gqrx + wsjt-x to record a cycle and decoded it with wsprd and rtlsdr-wsprd.

wsprd 211223_1102.c2 1102 -25 0.7 10.140163 0 VK6KOZ OF77 23

./rtlsdr_wsprd -r 211223_1102.c2 Reading IQ file: 211223_1102.c2 Number of samples: 45000 SNR DT Freq Dr Call Loc Pwr Spot : -24.85 -0.23 0.001463 0 VK6KOZ OF77 23

It decodes samples provided by wsjt-x fine. I am only seeing the snr problem with data rtlsdr-wsprd collects itself.

[Guenael]

@Rilapy Just to be sure that I understand. With rtlsdr-wsprd:

• Reported SNR are higher
• But when decoded from a .c2 sample, console reports are fine. Is it correct?

[Guenael]

I opened this branch, to try to fix this issue: https://github.com/Guenael/rtlsdr-wsprd/tree/snr-fix

[Rilapy]

That is correct.

[Guenael]

This is a tricky one... WSPRnet format didn't change, the string is formatted adequately, I tested a fake spot and it works. When decoded from a file, it looks good. I will need some help! Can someone:

• Record an .iq sample, zip it and post-it here
• For this spot, past the output message from the console
• And copy the exact line reported on WSPRnet
• (Please use the latest version)

Thanks!

[Rilapy]

6m wspr into a dummy load. Power low enough I can not see it on my power meter. Rtlsdr + rpi 3B+ as the receiver.

commit 0e9c8d25d30f08dbd2e8d218572a751d21a38fcf Spot : 2021-12-24 01:34:01 -2.06 -0.89 50.294480 -4 VK4XJB QG52 37

commit 72f528cd60f47fe259751641043072bd16db4782 Spot : 2021-12-24 01:25:59 30.19 -0.87 50.294481 -4 VK4XJB QG52 37

72f528cd60f47fe259751641043072bd16db4782 is the 1st bad snr for me.

Latest commit was 1a3f36b51331a243795fd86f1a3e039a95f262a0 0.5.2 when I started the following

console Spot : 2021-12-24 03:10:05 51.15 -0.91 50.294479 -4 VK4XJB QG52 37

spot on wsprnet.org 2021-12-24 03:10 VK4XJB 50.294479 +51 0 QG52xh 5 VK4XJB/PI QG52xh 0 0 2

rtlsdr-wspr decoding the .iq file Spot : 28.33 -0.95 50.294479 -4 VK4XJB QG52 37 snr_2021-12-24_03-10-05.iq.zip

For comparison is here is a .c2 from gqrx + wsjt which is close to what I get with an old rtlsdr-wsprd

wsprd ../211224_0230.c2 0230 -5 0.7 50.294544 -3 VK4XJB QG52 37

./rtlsdr_wsprd -f 6m -c vk4xjb -l qg52xh -r ../211224_0230.c2 Reading IQ file: ../211224_0230.c2 Number of samples: 44977 SNR DT Freq Dr Call Loc Pwr Spot : -4.97 -0.31 50.294544 -4 VK4XJB QG52 37 211224_0230.c2.zip

Not the same cycle but this is an example of a wsjt-x spot from the wsprnet site. On the same hw wsjt-x is reporting -5 while rtlsdr-wsprd is reporting about +50 or higher. 2021-12-24 03:24 VK4XJB 50.294547 -5 -4 QG52xh 5 VK4XJB/PI QG52xh 0 0 2

[Guenael]

@Rilapy Many thanks for this investigations and your time! :heart_decoration:

I misunderstood how the SNR was calculated, but today I learned! We need to conduct one more test, but I think I understand the problem.

I plaid guilty on this one! :) I updated the FIR coefs, with one specific side effect. The calculated noise floor of the total BW changed, because I removed the unused part of the spectrum (the search algo is limited to +/- 110Hz by default) with this new FIR.

It could explain this issue. I hope you will able to get back an accurate SNR. And if it's not the FIR, well, I could take a break! :) #[If it's working, don't fix it!]

I created this branch : https://github.com/Guenael/rtlsdr-wsprd/tree/fir-bw-issue And I will merge in main, because main is broken anyway :) #bug #critical

You can also remove the FIR for testing:

diff --git a/rtlsdr_wsprd.c b/rtlsdr_wsprd.c
index 351d878..5c08da9 100644
--- a/rtlsdr_wsprd.c
+++ b/rtlsdr_wsprd.c
@@ -214,21 +214,23 @@ static void rtlsdr_callback(unsigned char *samples, uint32_t samples_count, void
         Qt2z = Qt2y;
         Qt2y = Qy1;

-        /* FIR compensation filter */
-        float Isum = 0.0,
-              Qsum = 0.0;
-        for (uint32_t j = 0; j < FIR_TAPS; j++) {
-            Isum += firI[j] * zCoef[j];
-            Qsum += firQ[j] * zCoef[j];
-            if (j < FIR_TAPS-1) {
-                firI[j] = firI[j + 1];
-                firQ[j] = firQ[j + 1];
-            }
-        }
-        firI[FIR_TAPS-1] = (float)Iy2;
-        firQ[FIR_TAPS-1] = (float)Qy2;
-        Isum += firI[FIR_TAPS-1] * zCoef[FIR_TAPS];
-        Qsum += firQ[FIR_TAPS-1] * zCoef[FIR_TAPS];
+        float Isum = (float)Iy2;
+        float Qsum = (float)Qy2;

         /* Save the result in the buffer */
         uint32_t idx = rx_state.bufferIndex;

[Rilapy]

Results copy/pasted from the wsprnet site. The 7:34 time stamp is wsjt-x and 7:26 time stamp is rtlsdr-wsprd with the above FIR removal patch. +4 is a lot closer than the +51 I was getting earlier.

2021-12-24 07:34 VK4XJB 50.294544 -6 -2 QG52xh 5 VK4XJB/PI QG52xh 0 0 2 2021-12-24 07:26 VK4XJB 50.294481 +4 0 QG52xh 5 VK4XJB/PI QG52xh 0 0 2

[Guenael]

Nice, but the FIR filter was here to compensate the CIC (significant db loss at higher frequencies). It didn't give good results with the legacy filter?

[Rilapy]

Bingo.

2021-12-24 07:54 VK4XJB 50.294483 -4 0 QG52xh 5 VK4XJB/PI QG52xh 0 0 2

I did not think to update. I applied that FIR patch in the comment to the code I already had. Did a git pull and tried again. That is copy/past from wsprnet. That looks good.

[Guenael]

Not sure to understand with these two options. Could you confirm? Did the latest git pull origin main solve the issue? (in other words, did the legacy filter allows you to get this good report?)

[Rilapy]

Had tried that patch that removed FIR because that was the 1st thing I saw and it was close. Did not think to update till later.

git log says I am now on commit 5a25fad1bdc3391f5e269188368e3cd926813d0d (HEAD -> main, origin/main, origin/HEAD)

The good signals have been since I changed to this commit.

[Guenael]

@Rilapy OK, thank you for this confirmation! And another time, thanks for your testing.