Re: gr-soapy mishandles hackrf on flowgraph exit

[Jeff Long]

This could be something we need to change in the in-tree gr-soapy. You can
post an issue to https://github.com/gnuradio/gnuradio/issues and we'll take
a closer look to make sure we're using the SoapySDR AP correctly.

On Sat, Apr 16, 2022 at 10:29 PM Cinaed Simson 
wrote:

>
>
> On 4/16/22 14:53, Gavin Jacobs wrote:
>
> I had previously thought that there was an issue with the save/restore of
> the geometry of the QT window, but I determined that it was a problem when
> using the gr-soapy block with a hackrf, so I have started a new thread.
>
> If I make a flowgraph using the "Soapy hackrf source" (i.e. gr-soapy block
> with a hackrf yml), it works fine when receiving the streaming data, but
> crashes the top block on exit. When I stop the flowgraph, I get the
> following message on the console area:
> >>> Done (return code -11)
> I now know that means a segmentation fault, and thanks to Vasil, I tried
> to debug it. The offending code is in a callback and references some memory
> that is no longer around, probably because all the blocks are shutting down
> and calling their respective destructors. So, I then disabled the gr-soapy
> source, and used the gr-osmosdr source (soapy=0,driver=hackrf). This worked
> as expected, including a normal message:
> >>> Done
> So, I compared the way the gr-osmosdr used soapyHackrf with the way
> gr-soapy does it, and I found that:
> gr-osmosdr calls deactivateStream() on stop(), and closeStream() on
> ~destructor()
> gr-soapy never calls deactivateStream(), calls closeStream() on stop(),
> and does nothing in ~destructor()
>
> My assessment is that gr-soapy should follow the pattern previously used
> in gr-osmosdr. The call to deactivateStream() stops the streaming and
> cancels the callback, so the problem would be fixed. A workaround is to use
> the gr-osmosdr/soapy/hackrf block, but it is marked as deprecated, so that
> won't do for long term.
>
> Is there anyone with a hackrf that can verify the problem? and then, how
> to register a bug report?
>
> Jake
>
>
> Try posting an issue
>
>https://github.com/pothosware/SoapyHackRF
>
> -- Cinaed
>
>

Re: gr-soapy mishandles hackrf on flowgraph exit

[Jeff Long]

PR https://github.com/gnuradio/gnuradio/pull/5772 adds a call to
deactivateStream() right before closeStream(). We'll need to do a little
testing with various Soapy modules to make sure that they all handle this
correctly. The SoapyRTLSDR module calls deactivateStream() itself from
closeStream() - need to make sure that doesn't cause any problems. But the
majority of the modules expect us to call deactivateStream().

Thanks for tracking this down.

On Sun, Apr 17, 2022 at 7:02 AM Jeff Long  wrote:

> This could be something we need to change in the in-tree gr-soapy. You can
> post an issue to https://github.com/gnuradio/gnuradio/issues and we'll
> take a closer look to make sure we're using the SoapySDR AP correctly.
>
> On Sat, Apr 16, 2022 at 10:29 PM Cinaed Simson 
> wrote:
>
>>
>>
>> On 4/16/22 14:53, Gavin Jacobs wrote:
>>
>> I had previously thought that there was an issue with the save/restore of
>> the geometry of the QT window, but I determined that it was a problem when
>> using the gr-soapy block with a hackrf, so I have started a new thread.
>>
>> If I make a flowgraph using the "Soapy hackrf source" (i.e. gr-soapy
>> block with a hackrf yml), it works fine when receiving the streaming data,
>> but crashes the top block on exit. When I stop the flowgraph, I get the
>> following message on the console area:
>> >>> Done (return code -11)
>> I now know that means a segmentation fault, and thanks to Vasil, I tried
>> to debug it. The offending code is in a callback and references some memory
>> that is no longer around, probably because all the blocks are shutting down
>> and calling their respective destructors. So, I then disabled the gr-soapy
>> source, and used the gr-osmosdr source (soapy=0,driver=hackrf). This worked
>> as expected, including a normal message:
>> >>> Done
>> So, I compared the way the gr-osmosdr used soapyHackrf with the way
>> gr-soapy does it, and I found that:
>> gr-osmosdr calls deactivateStream() on stop(), and closeStream() on
>> ~destructor()
>> gr-soapy never calls deactivateStream(), calls closeStream() on stop(),
>> and does nothing in ~destructor()
>>
>> My assessment is that gr-soapy should follow the pattern previously used
>> in gr-osmosdr. The call to deactivateStream() stops the streaming and
>> cancels the callback, so the problem would be fixed. A workaround is to use
>> the gr-osmosdr/soapy/hackrf block, but it is marked as deprecated, so that
>> won't do for long term.
>>
>> Is there anyone with a hackrf that can verify the problem? and then, how
>> to register a bug report?
>>
>> Jake
>>
>>
>> Try posting an issue
>>
>>https://github.com/pothosware/SoapyHackRF
>>
>> -- Cinaed
>>
>>

[GSoC 2022 Cover Letter] GNU Radio goes Browser: Web Assembly (WASM) port

[史 皓航]

Hi!  My name is Yao. I am a fresh student from China, majoring in Computer 
Science. I want to reach out to this sub-program: “porting SIMD-heavy code (eg. 
volk, fftw3, etc) to use the Wasm-supported set of intrinsics”.  Following is 
my background and my solution to achieve this program.

Background:  I am familiar with modern C++ and I have used AVX512 to accelerate 
the convolution algorithm(Winograd) in a competition. Besides, currently, I am 
working to improve a wasm runtime(called WasmEdge 
  previous SSVM)  performance in LFX 
mentorship LFX Workspace: Improving the performance of running miniruby · Issue 
#1292.


Solution: Since not all simd instructions are 
supported well in Wasm, If the 
emscripten is done well, we can port it with an extra compile flag. On the 
other side,  I think we should reimplement related code with official wasm-simd 
header if the original function is not supported and really necessary (like 
many portable functions in volk ).


Additionally, I found the GSoCIdeas (section) 
page
 has a typo in the sentence:

  [ porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted 
set of intrinsics. ]

I believe the Wasm-suppprted should be Wasm-supported.


That’s my thought, thank you for reading this!

Re: Trouble With gr-osmosdr Install

[Cinaed Simson]

Try

  apt install gr-osmosdr

I'm assuming you installed gnuradio using apt and you're running an 
updated version of the original raspbian shipped with the device.


And since the install guide indicated it should be installed in 
/usr/local/lib and it's not working it may not be a problem - but in the 
end you should only have one install of gr-osmosdr.


You should be able to locate the one you install from source by typing

  find /usr/local/lib -name osmosdr -type d

-- Cinaed

On 4/13/22 20:28, Ambroise Curutchague wrote:

Hello,

I will preface this by saying I am a linux novice. I have been trying 
to set up GNURadio to use with a HackRF. To do this, I have installed 
gr-osmosdr following instructions from the install guide 
(https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR). I have 
GNURadio Companion version 3.7.13.4. I am on a Raspberry Pi 4 running 
the most recent Raspbian.


My problem is that I cannot get the osmocom source and sink blocks to 
show up in GRC, and I cannot find the osmocom_source and osmocom_sink 
.XML files anywhere either.  I tried copying the hackrf_source and 
hackrf_sink .XML files directly to the folder in my GRC block path, 
but when starting GRC it would throw an error message that the .XML 
files were unrecognized. Not sure what else to do. Would greatly 
appreciate your help.


Best,
Ambroise - KN6NOR

Problems with OOT C++ fft

[George Edwards]

Dear Gnuradio Community,

I am writing an OOT signal processing algorithm in C++ that requires both
fft and ifft. I use the Gnuradio C++ library to get the fft and ifft
functions. To confirm understanding of setting up these functions, I wrote
C++ OOT blocks for both fft and ifft blocks. I ran a complex sinusoid into
the fft block and fed its output to the ifft block to reverse the process.
In the GRC flowgraph, the time and frequency plots seem correct (the output
of the ifft shows the sinusoidal frequency it recovers is right on mark).

For further validation, I decided to compare Gnuradio C++ fft computation
to that of Matlab. I created a Python QA file to Debug the fft block and
examine the fft  computation. For the experiment, I fed 8 complex data
samples into the fft block to see how its fft computation compares to that
of Matlab. The OOT fft computation was not correct! Here is a snippet of my
C++ OOT code written to test the fft computation (below "in and out" points
to the addresses of Gnuradio input/out data variables).

memcpy(d_fft.get_inputbuf(), in, sizerof(gr_complex)*d_fft_size);
d_fft.execute();
memcpy(out, d_fft.get_output(), sizerof(gr_complex)*d_fft_size);
gr_complex c_data[8];
for(int i = 0; i < 8; i++) {
  c_data[i] = out[i];
}
As can be seen in my code, I wrote the fft output into the array variable
c_data. c_data has 1+1j in c_data[0] and all the other elements of the
array have values 0+0j. The values are all wrong (not the same as Matlab).
So I am at a loss!

I appreciate any suggestions?

Thank you!
George