Caught signal 11

[F4HTB]

Hello Dear OM,

I try to make a multi RTL-SDR wspr decoder. Your soft is very helpfull but i have a new bug. I have made it with last raspbian version at this time.

When come the time to decode, i get only "Caught signal 11" message and software stop...

Can you help me?

[F4HTB]

I have try to get the error:

I have add -g in makefile to get debug mode. dgb (gdb) file rtlsdr_wsprd (gdb) run -f 7.038600M -c F4HTB -l JN38TG -a 0 -u 125M -g 3 -p 40 -i 0

Starting program: /home/pi/rtlsdr-wsprd/rtlsdr_wsprd -f 7.038600M -c F4HTB -l JN38TG -a 0 -u 125M -g 3 -p 40 -i 0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0x7624f440 (LWP 2005)] Found 1 device(s): [New Thread 0x7624f440 (LWP 2006)] [Thread 0x7624f440 (LWP 2005) exited] 0: Realtek, RTL2838UHIDIR, SN: 00000001 [New Thread 0x7624f440 (LWP 2007)] [Thread 0x7624f440 (LWP 2006) exited]

Using device 0: Generic RTL2832U OEM [New Thread 0x7624f440 (LWP 2008)] [Thread 0x7624f440 (LWP 2007) exited] Found Rafael Micro R820T tuner [R82XX] PLL not locked!

Starting rtlsdr-wsprd (2017-12-23, 14:23z) -- Version 0.2 Callsign : F4HTB Locator : JN38TG Dial freq. : 7038599 Hz Real freq. : 132038599 Hz PPM factor : 40 Gain : 3 dB Wait for time sync (start in 59 sec)

[New Thread 0x75a4f440 (LWP 2009)] [New Thread 0x7524f440 (LWP 2010)]

Thread 7 "rtlsdr_wsprd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7524f440 (LWP 2010)] subtract_signal2 (id=0xa9ec, id@entry=0x2d46c , qd=0x75030668, qd@entry=0x5938c , np=np@entry=43500, f0=f0@entry=67.282814, shift0=185452, shift0@entry=400, drift0=drift0@entry=1, channel_symbols=channel_symbols@entry=0x0) at wsprd.c:332 332 cs=(float)channel_symbols[i]; (gdb)

I hope that can help you.

73 F4HTB

[F4HTB]

Ok i have search a litle bit. I seem that in wsprd.c it use get_wspr_channel_symbols(call_loc_pow, hashtab, channel_symbols) in line 774 So wsprsim_utils.c send something in symbols var that is a pointer to channel_symbols but when we comme back to wsprd.c in line 775, and we try to use channel_symbols, channel_symbols look like empty.

[F4HTB]

Ok I am not a profesionnal coder but i found that: Durring my test, when i add code for print of channel_symbols like this:

                if( get_wspr_channel_symbols(call_loc_pow, hashtab, channel_symbols) ) {
                    for ( i = 0; i < (NSYM -1); ++i )
                    {
                            printf("%c", channel_symbols[i]);
                    }
                    subtract_signal2(idat, qdat, npoints, freq1, shift1, drift1, channel_symbols);

Nothing is printing by printf but the but the bug dont appear and all working fine...

[Guenael]

Hello, nothing new here. "Caught signal 11" is related to the availability of the data through the USB port. Basically, there is two cases :

• the processing power is too low to deal with the decoding & receiving new samples
• writing data on the memory device (for further deep search) took to much time.

To fix this, disable the deep search. Make a try using -S an/or -Q options. Good luck and Merry Christmas!

[F4HTB]

Hello Guenael, Thank you for your reply. Disabling the deep search would drop the weapons ... I would like to develop a network of WSPR all-band receivers. As I have seen in many other projects, the cheaper it is, the better. I already have a model at home with a RPI3 + 12 rtl sdr that I will certainly synchronize on a TCXO.

I'm looking for a light project like yours, because by doing tests directly recording audio and then decoding it works but it's less frendly ...

Your project impressed me for that. Hence my question, do you think continue to develloper to correct these problems?

73 Dear OM , Happie Xmass To!

[Guenael]

Le problème ne vient pas du code de cette application, mais d'une modification qui a été faite au cours de la maintenance/évolution de Rasberian. Ce changement n'est pas critiquable auprès de la team de Rasberian, c'est juste un choix, qui privilégie certains types d'accès plutôt que d'autres.

Le problème n'existe en général pas sur un PC classique et n'était pas la sur les vielles version de Rasberian, aussi je ne compte pas modifier le code. Le crash apparait lorsque la hastable est mise à jour via une écriture disque/flash, aussi, la solution proposée est de désactiver cette option de recherche avancée pour ne plus utiliser les hashtable (recherche de signaux ayant déjà été relevés, par rapport à une soustraction du signal recomposé du callsign recherché). Le workarrond existe, et la différence entre recherche normale et deepsearch n'est pas énorme.

Autre point, je ne suis pas sur qu'un seul RPI3 puisse dealer avec autant de RTL, mais bon, a toi de voir.

Bon courage pour ton projet.

[kpbenz]

Maybe a bit too late, but this fix, currently in review, solves the issue: https://github.com/Guenael/rtlsdr-wsprd/pull/22/commits