Re: How to compute FFT and IFFT in C++ OOT?

[George Edwards]

Hi Ron,

Thank you very much!

I am sure I will have questions later on how to use FFT with windows
(Harris Blackman, Kaiser, Hamming, etc.) but that is another story and I
will do a new posting on that when I reach that point.

Thank you very much!

Happy Holiday Season!

George

On Thu, Dec 23, 2021 at 6:18 PM Ron Economos  wrote:

> You have to copy your samples into get_inbuf() first. That's where FFTW
> expects the data. *dst is just a convenience variable to allow for less
> typing. Instead of:
>
> memcpy(ofdm_fft.get_inbuf(), in, sizeof(gr_complex) * ofdm_fft_size);
>
> You can use:
>
> memcpy(dst, in, sizeof(gr_complex) * ofdm_fft_size);
>
> Ron
> On 12/23/21 10:42 AM, George Edwards wrote:
>
> Hi Ron,
>
> Sorry for bothering some more!
> In Debugging it appears that dst is not pointing to the input data (
> input_items[0]), which we pointed to with pointer variable in at the
> start of the work(...) method
>  (const gr_complex *in = (const gr_complex *) input_items[0];
>
> Here is a snippet of my Debugging code and the values I see in ge_in =
> dst[i] while single stepping through the code are all zeros.
>
> gr_complex * dst;// copy from your code:
> dst = ofdm_fft.get_inbuf();   //copy from your code
>  //** my debug code starts **
> gr_complex  ge_in;
> for(int i = 0; i < 8; i++)  // I am inputting 8 samples
>  {
>ge_in = dst[i];// extracting the values in dst
> shows zero's
>   }
> // **my debug code ends *
>
> It appears that setting dst = ofdm_fft.get_inbuf() is not pointing to the
> actual input samples values.
>
> I did not see anywhere in your code where there is an explicit binding
> between in and get_inbuf().
>
> I will appreciate it if you can help me here!
> Thank you!
> George
>
> On Wed, Dec 15, 2021 at 12:32 AM Ron Economos  wrote:
>
>> FFT support is built in to GNU Radio with FFTW. Here's how it's done.
>> First, define it in your foo_impl.h file. The options are fft_complex_fwd,
>> fft_complex_rev, fft_real_fwd and fft_real_rev.
>>
>> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L25
>>
>> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L41
>>
>> Then initialize it in your foo_impl.cc constructor.
>>
>> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L47
>>
>> Then execute it.
>>
>>
>> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L175-L179
>>
>> You'll need to add the component in the top level CMakeLists.txt.
>>
>> https://github.com/drmpeg/gr-paint/blob/master/CMakeLists.txt#L78
>>
>> And link with it in lib/CMakeLists.txt
>>
>> https://github.com/drmpeg/gr-paint/blob/master/lib/CMakeLists.txt#L25
>>
>> If you need a window, you can look at the block implementation file for
>> details.
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-fft/lib/fft_v_fftw.cc
>>
>> Ron
>> On 12/14/21 7:53 PM, George Edwards wrote:
>>
>>  Dear GNURadio Community:
>>
>> I am writing a C++ OOT block where the signal processing requires
>> the computation of both fft and ifft. Is there any Gnuradio C++ functions
>> for the fft and ifft? If not, is there any way to wrap in Python's
>> libraries with these methods into C++ OOT?
>>
>> Thank you!
>>
>> Regards,
>> George
>>
>>

Re: How to compute FFT and IFFT in C++ OOT?

[Ron Economos]

You have to copy your samples into get_inbuf() first. That's where FFTW 
expects the data. *dst is just a convenience variable to allow for less 
typing. Instead of:


memcpy(ofdm_fft.get_inbuf(), in, sizeof(gr_complex) * ofdm_fft_size);

You can use:

memcpy(dst, in, sizeof(gr_complex) * ofdm_fft_size);

Ron

On 12/23/21 10:42 AM, George Edwards wrote:

Hi Ron,

Sorry for bothering some more!
In Debugging it appears that dst is not pointing to the input data 
(input_items[0]), which we pointed to with pointer variable inat the 
start of the work(...)method

 (constgr_complex*in = (constgr_complex*) input_items[0];

Here is a snippet of my Debugging code and the values I see in ge_in = 
dst[i] while single stepping through the code are all zeros.

gr_complex * dst;                // copy from your code:
dst = ofdm_fft.get_inbuf();   //copy from your code
 //** my debug code starts **
gr_complex  ge_in;
for(int i = 0; i < 8; i++)          // I am inputting 8 samples
     {
           ge_in = dst[i];            // extracting the values in dst 
shows zero's

      }
// **my debug code ends *

It appears that setting dst = ofdm_fft.get_inbuf() is not pointing to 
the actual input samples values.


I did not see anywhere in your code where there is an explicit binding 
between in and get_inbuf().


I will appreciate it if you can help me here!
Thank you!
George

On Wed, Dec 15, 2021 at 12:32 AM Ron Economos > wrote:


FFT support is built in to GNU Radio with FFTW. Here's how it's
done. First, define it in your foo_impl.h file. The options are
fft_complex_fwd, fft_complex_rev, fft_real_fwd and fft_real_rev.

https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L25


https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L41


Then initialize it in your foo_impl.cc constructor.

https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L47


Then execute it.


https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L175-L179



You'll need to add the component in the top level CMakeLists.txt.

https://github.com/drmpeg/gr-paint/blob/master/CMakeLists.txt#L78


And link with it in lib/CMakeLists.txt

https://github.com/drmpeg/gr-paint/blob/master/lib/CMakeLists.txt#L25


If you need a window, you can look at the block implementation
file for details.

https://github.com/gnuradio/gnuradio/blob/master/gr-fft/lib/fft_v_fftw.cc


Ron

On 12/14/21 7:53 PM, George Edwards wrote:

 Dear GNURadio Community:

I am writing a C++ OOT block where the signal processing requires
the computation of both fft and ifft. Is there any Gnuradio C++
functions for the fft and ifft? If not, is there any way to wrap
in Python's libraries with these methods into C++ OOT?

Thank you!

Regards,
George

Re: How to compute FFT and IFFT in C++ OOT?

[George Edwards]

Hi Ron,

Sorry for bothering some more!
In Debugging it appears that dst is not pointing to the input data (
input_items[0]), which we pointed to with pointer variable in at the start
of the work(...) method
 (const gr_complex *in = (const gr_complex *) input_items[0];

Here is a snippet of my Debugging code and the values I see in ge_in =
dst[i] while single stepping through the code are all zeros.

gr_complex * dst;// copy from your code:
dst = ofdm_fft.get_inbuf();   //copy from your code
 //** my debug code starts **
gr_complex  ge_in;
for(int i = 0; i < 8; i++)  // I am inputting 8 samples
 {
   ge_in = dst[i];// extracting the values in dst shows
zero's
  }
// **my debug code ends *

It appears that setting dst = ofdm_fft.get_inbuf() is not pointing to the
actual input samples values.

I did not see anywhere in your code where there is an explicit binding
between in and get_inbuf().

I will appreciate it if you can help me here!
Thank you!
George

On Wed, Dec 15, 2021 at 12:32 AM Ron Economos  wrote:

> FFT support is built in to GNU Radio with FFTW. Here's how it's done.
> First, define it in your foo_impl.h file. The options are fft_complex_fwd,
> fft_complex_rev, fft_real_fwd and fft_real_rev.
>
> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L25
>
> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L41
>
> Then initialize it in your foo_impl.cc constructor.
>
> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L47
>
> Then execute it.
>
>
> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L175-L179
>
> You'll need to add the component in the top level CMakeLists.txt.
>
> https://github.com/drmpeg/gr-paint/blob/master/CMakeLists.txt#L78
>
> And link with it in lib/CMakeLists.txt
>
> https://github.com/drmpeg/gr-paint/blob/master/lib/CMakeLists.txt#L25
>
> If you need a window, you can look at the block implementation file for
> details.
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-fft/lib/fft_v_fftw.cc
>
> Ron
> On 12/14/21 7:53 PM, George Edwards wrote:
>
>  Dear GNURadio Community:
>
> I am writing a C++ OOT block where the signal processing requires
> the computation of both fft and ifft. Is there any Gnuradio C++ functions
> for the fft and ifft? If not, is there any way to wrap in Python's
> libraries with these methods into C++ OOT?
>
> Thank you!
>
> Regards,
> George
>
>

Re: How to compute FFT and IFFT in C++ OOT?

[George Edwards]

Thanks Ron! I really appreciate your help!
George

On Wed, Dec 22, 2021, 9:52 PM Ron Economos  wrote:

> Comments in-line.
>
> Ron
> On 12/22/21 1:30 PM, George Edwards wrote:
>
> Hi Ron,
>
> Today, I tried to create an OOT block to compute FFT based on your good
> instructions. However, I must be doing something wrong because when I build
> my grc flowgraph to test (I run a complex sinusoid into a throttle which
> connects to a stream-to-vector, then to my fft block which takes in a
> vector and outputs a vector, then connects to a vector-to-stream which
> outputs to a file sink to collect data for me to view) it outputs zeros.
>
> The FFT of a sine wave is almost all zeroes. Only the center bin will have
> a value. Check your output carefully.
>
>
> I tried to Debug using a small data size of 8 samples in a QA file
> because I can easily compute the fft of 8 samples to know what to expect if
> the block is working properly. This way, I can single step through the code
> to Debug. When I ran the Debugger, it fails to get inside the
> my_fft_cc.impl.cc code and gave the error message:
> itemsize mismatch: vector_source0:0 using 8, my_fft_cc0:0 using 64
> However, I explicitly set the vector length inside my_fft_cc.impl.cc with
> a #define vlength 8, unless the fft function forces things to a minimum
> of 64 samples
> I will appreciate any suggestions you can offer here.
>
> The sizes being reported are in bytes. So you're connecting a complex
> vector_source of vector size 1 (8 bytes) to your FFT block of vector size 8
> (64 bytes).
>
>
> Regards,
> George
>
> On Thu, Dec 16, 2021 at 8:14 PM Ron Economos  wrote:
>
>> Comments in-line.
>>
>> Ron
>> On 12/16/21 12:47 PM, George Edwards wrote:
>>
>> Hi Ron,
>>
>> Thanks again for sending the links and annotating the lines of interest.
>> I have looked through links and have some questions:
>> Q1. The lib/CMakeList.txt file I can identify easily, but I am not sure
>> which is the top level CMakeList.txt file. There are CMakeList.txt files
>> in directories "apps" and "grc" in my project directory and I am not
>> sure which is considered the top level. I do not know if you can help me
>> here (thing is, in my project the contents of these CMakefileList.txt files
>> are small and do not mimic that in the link you sent, so I have no clue).
>>
>> Let's say you have an OOT in your home directory.
>>
>> ~/gr-something
>>
>> The top level CMakeLists.txt is in ~/gr-something.
>>
>>
>> Q2. I am reading in a fixed size vector of floats to compute the fft and
>> output a vector of fft values (complex) the same size as the block of
>> input, so I assumed the OOT block should be a "sync" block, right?
>>
>> Yes. If you want to use vectors on your input and output pins, change the
>> signature to (where vlength is your vector size):
>>
>> gr::io_signature::make(1, 1, sizeof(input_type) * vlength),
>> gr::io_signature::make(1, 1, sizeof(output_type) * vlength)),
>>
>> Then in the block .yml file, use the vlen tag.
>>
>> inputs:
>> -   domain: stream
>> dtype: complex
>> vlen: ${vlength}
>>
>> outputs:
>> -   domain: stream
>> dtype: complex
>> vlen: ${vlength}
>>
>> Note that when you use vectors, noutput_items will be the number of
>> vectors, not the number of items in each vector.
>>
>>
>> Q3. Assuming the input vector comes in on the variable "in" and the
>> output vector is on the variable "out" how do I taylor the expression in
>> the link which I copied below to compute the fft and pass it to the output
>> (plus, is volk_32fc_s32fc_multiply_32fc(...) a function in the fft
>> computation module?):
>> [image: df0555eb-9839-457b-ac3d-0a4c9d17c662.png]
>>
>> I was using an IFFT in that example, and it's almost always required to
>> normalize the output. So that's what the volk_32fc_s32fc_multiply_32fc()
>> was for. Here's the code for just a simple in to out IFFT. Also, the
>> variable names don't have to be "ofdm_fft". You can use something more
>> descriptive.
>>
>> gr_complex* dst;
>> dst = ofdm_fft.get_inbuf();
>> memcpy([ofdm_fft_size / 2], [0], sizeof(gr_complex) *
>> ofdm_fft_size / 2);
>> memcpy([0], [ofdm_fft_size / 2], sizeof(gr_complex) *
>> ofdm_fft_size / 2);
>>
>> ofdm_fft.execute();
>>
>> memcpy([0], ofdm_fft.get_outbuf(), sizeof(gr_complex) *
>> ofdm_fft_size);
>>
>> Note that for a forward FFT, you have to do the shift *after* the FFT.
>> Also, the example is complex in and complex out.
>>
>> Thank you very much!
>> George
>>
>>
>> On Wed, Dec 15, 2021 at 12:32 AM Ron Economos  wrote:
>>
>>> FFT support is built in to GNU Radio with FFTW. Here's how it's done.
>>> First, define it in your foo_impl.h file. The options are fft_complex_fwd,
>>> fft_complex_rev, fft_real_fwd and fft_real_rev.
>>>
>>> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L25
>>>
>>> https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L41
>>>
>>> Then initialize it in your foo_impl.cc constructor.
>>>

Re: fosphor sink block error

[Paul Atreides]

Gwendoline:
I think you may have conflicting versions of GNURadio and/or Fosphor. I have 
had this error before as well. 

I use fosphor on a daily basis on both GNURadio 3.8 and 3.9 and I can confirm 
that it does work on several different nvidia GPU’s as Sylvain said. I have had 
some issues relating to the drivers for the GPU, but they were usually not 
related to GNURadio. I also have a machine without a GPU and am running Fosphor 
using the Intel CPU implementation of OpenCL found here:
https://osmocom.org/projects/sdr/wiki/Fosphor#Intel-CPU-OpenCL

You should start by uninstalling all previous versions of GNURadio and Fosphor 
before continuing. You’ll need to make sure that all libraries have been 
removed from your system before trying anything else. 

Then, follow the build procedure for GNURadio 3.9 as 3.7 is EOL. 

For Ubuntu 20 you’ll also need to make sure your computer is actually using the 
NVIDIA driver as it sometimes defaults to the nouveau driver even if NVIDIA is 
installed. 



> On Dec 23, 2021, at 08:37, Gwendoline Hochet Derevianckine via GNU Radio, the 
> Free & Open-Source Toolkit for Software Radio  
> wrote:
> 
> Hi,
> 
> 
> 
> I install the package but before testing it I see a new problem.
> 
> Gnuradio is in version 3.9.4.0.
> 
> 
> 
> The fosphor sink block is in error so I can't run the flowgraph.
> 
> No matter what Window type I put, I have this error in block parameters:
> 
> 
> 
> Param - Window Type(wintype):
> Value "firdes.WIN_BLACKMAN_hARRIS" cannot be evaluated:
> type object 'gnuradio.filter.filter_python.firdes' has no attribute 
> 'WIN_BLACKMAN_hARRIS'
> 
> Param - Window Type(wintype):
> Expression None is invalid for type 'int'.
> 
> Is it because of how I install gr-fosphor ?
> 
> Regards,
> Gwendoline
> 
> De : Sylvain Munaut <246...@gmail.com>
> Envoyé : jeudi 23 décembre 2021 12:13:53
> À : Gwendoline Hochet Derevianckine
> Cc : discuss-gnuradio@gnu.org
> Objet : Re: fosphor sink block error
>  
> Warning - External Email
> 
> 
> Hi,
> 
> 
> If you're using Ubuntu, you can try the intel-opencl-icd package which
> is the binary package for https://github.com/intel/compute-runtime
> which is the OpenCL driver for Intel GPUs.
> However, I'm not sure anyone has ever run fosphor with it ... not sure
> if it supports the features required, I only tried on AMD and NVidia
> GPUs as I don't have any Intel GPU supporting that driver.
> 
> Cheers,
> 
>   Sylvain
> 
> To view our privacy policy, including the types of personal information we 
> collect, process and share, and the rights and options you have in this 
> respect, see www.semtech.com/legal.

Re: Late packets when using set_time_next_pps and set_start_time with Function Probe

[Marcus D. Leech]

On 2021-12-23 00:30, Manav Kohli wrote:

Hello,

Hope everyone is doing well. I am encountering an issue regarding late 
packet arrivals when using Function Probe blocks to 
call set_start_time and set_time_next_pps.


I have a flowgraph with a USRP Source and Sink and I am applying the 
following two function calls to each (so four function probes in 
total). The function probes have their rate set to 1e-9 (so they 
should only ever run once).


set_time_next_pps(uhd.time_spec_t(0.0))
set_start_time(uhd.time_spec_t(2.0))

The USRP Sink is fed by a file source and the USRP Source feeds a QT 
Frequency Sink. There is nothing else going on and the Sink and Source 
are on the same subdev. If I run the flowgraph, the following will 
invariably occur: a cascade of ... printed to stdout and the 
following warning: "gr::log :WARN: usrp_source0 - USRP Source Block 
caught rx error code: 2"


Disabling the Function Probes with 
set_start_time(uhd.time_spec_t(2.0)) or removing the time_spec_t 
function parameter in the set_start_time function call let the 
flowgraph run fine.


I've tried to look up exactly what is going on behind these two 
function calls but I have been unable to make any headway. I saw a 
previous thread here 
 which 
doesn't seem to have a resolution.


GNU Radio & USRP environment:
Ubuntu 20.04
UHD 4.0.0.0
GNU Radio 3.8
USRP 2974

I think this may have something to do with the USRP and PC clocks 
drifting apart, but this happens as soon as the Tx and Rx should turn 
on, i.e. two seconds after running the flowgraph, so I am not sure. 
Any help would be greatly appreciated, and thank you for your time 
in reading through this post.


Take care
Manav

My suspicion is that your approach is "all wrong".  What is it you're 
trying to actually do?


The gr-uhd module already does this when you select "unknown_pps" or 
"next_pps" in the "SYNC" option in the source/sink blocks.    Your 
approach is going to cause multiple
  resets of the system clock on the radio, at unpredictable times, 
likely leading to the results you're seeing.

RE: fosphor sink block error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi,


I install the package but before testing it I see a new problem.

Gnuradio is in version 3.9.4.0.


The fosphor sink block is in error so I can't run the flowgraph.

No matter what Window type I put, I have this error in block parameters:


Param - Window Type(wintype):
Value "firdes.WIN_BLACKMAN_hARRIS" cannot be evaluated:
type object 'gnuradio.filter.filter_python.firdes' has no attribute 
'WIN_BLACKMAN_hARRIS'

Param - Window Type(wintype):
Expression None is invalid for type 'int'.

Is it because of how I install gr-fosphor ?

Regards,
Gwendoline



De : Sylvain Munaut <246...@gmail.com>
Envoyé : jeudi 23 décembre 2021 12:13:53
À : Gwendoline Hochet Derevianckine
Cc : discuss-gnuradio@gnu.org
Objet : Re: fosphor sink block error

Warning - External Email


Hi,


If you're using Ubuntu, you can try the intel-opencl-icd package which
is the binary package for https://github.com/intel/compute-runtime
which is the OpenCL driver for Intel GPUs.
However, I'm not sure anyone has ever run fosphor with it ... not sure
if it supports the features required, I only tried on AMD and NVidia
GPUs as I don't have any Intel GPU supporting that driver.

Cheers,

  Sylvain

To view our privacy policy, including the types of personal information we 
collect, process and share, and the rights and options you have in this 
respect, see www.semtech.com/legal.

Re: [CFP] Free Software Radio DevRoom 2022

[Andrej Rode]

Hi all, 

Gentle reminder to submit proposals for presentations about e.g. your own 
projects, FOSS projects updates or other fun hacks you want to talk about. Our 
CfP is still open until (and including) December 26th. Do not hesitate to 
contact any of the Devroom managers if you have questions.  
Presentation slots are not fixed to 30 minutes, if you have some idea for a 
lightning talk we can also fit you in, as well as if you have some longer 
presentation to give. 

If you have creative ideas for a non-presentation format we are eager to hear 
about it.

Cheers,
Andrej

(For the Free Software Radio Devroom Managers)


> On 6. Dec 2021, at 02:04, Andrej Rode  wrote:
> 
> Dear friends and fans of software-defined radio and free/open-source radio 
> topics in general,
> 
> FOSDEM 2022 (the free and open-source developer's meeting usually in 
> Brussels, Europe but **repeatedly virtual**) will again feature a track on 
> Software Defined Radio and any other radio-related topics in the **Free 
> Software Radio** devroom. Therefore, we invite developers and users from the 
> free software radio community to join us for this track and present your 
> work, ideas and/or demos.
> 
> Given the current circumstances and the virtual nature of this event in 2022, 
> we are asking the presenters to pre-record the talks, which will then be 
> gathered by us and streamed during the event. Presenters are also asked to be 
> present online during their timeslot for live Q 
> 
> Software Radio is an important tool for educators, tinkerers and industry to 
> implement signal processing and communication algorithms in software while 
> still allowing for easy access to real signals. This allow anyone to access 
> the EM spectrum out of curiosity, for research or for profit. At FOSDEM we 
> want to foster collaboration and exchange of ideas between different projects 
> in the field of SDR. We hope to network all these projects, and improve 
> collaboration, bring new ideas forward and get more people involved.
> 
> The track's website resides at the link below. The final schedule will be 
> available through Pentabarf and the official FOSDEM website. Notice that the 
> reference time will be Brussels local time (CET).
> 
> https://fosdem.org/2022/schedule/track/free_software_radio/
> 
> Additional Information will be also available at: 
> https://wiki.gnuradio.org/index.php/FOSDEM_2022
> 
> ** Submit your presentations
> To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM22 and 
> follow the instructions (you need an account, but can use your account from 
> last year if you have one. Please do NOT create a new account if you already 
> have one). You need to create an 'Event'; make sure it's in the Free Software 
> Radio track! Your submission should have the following information:
> 
> * Your contact Email
> * A descriptive title and subtitle of your talk
> * A short abstract
> * Links related to the project
> * [Optional] A longer description of the content of your talk. 
> 
> Lengths aren't fixed, but give a realistic estimate, and please don't exceed 
> 30 minutes unless you have something special planned (in that case, contact 
> one of us). We will typically go for 30-minute slots -- shorter talks, unless 
> they're really short, usually tend to screw up the schedule too much. Please 
> take into account some live Q at the end of your presentation, going for 25 
> minutes presentation plus 5 minutes for Q will provide a more lively 
> conference experience for everyone.
> 
> You aren't limited to slide presentations, of course. Be creative. However, 
> FOSDEM is an free software conference, therefore we ask you to stay clear of 
> marketing presentations and present something relevant to free/open software. 
> We like nitty-gritty technical stuff.
> 
> Topics discussed in this devroom include (but are not limited to):
> * SDR Frameworks + Tools
> * Cellular/telecoms software
> * Free/Open SDR hardware
> * Wireless security
> * Random fun wireless hacks
> * SDR in education
> * Satellite/spacecraft communication
> * Ham radio related topics
> 
> 
> ** Important Dates
> * Submission deadline: 26 December 2021
> * Announcement of selected talks: 31 December 2021
> * (preliminary) Pre-recorded presentation submission deadline: 23 January 2022
> * Conference dates 5 & 6 February 2022 online
> * Free software radio devroom date: Sunday 6 February 2022 online
> 
> In the last years we were always full to the brim with presentations, so if 
> you want to present, please make sure to submit your abstracts soon!
> 
> (It might be possible to get our allotted time extended to Saturday - given 
> enough volunteers and high quality presentations to cover two days, but 
> that's only an option as last resort)
> 
> ** Following steps for accepted talks
> When your talk is accepted, you will be contacted by a deputy who will help 
> you with the pre-recording of your talk. Together you will make sure that the 
> 

Re: fosphor sink block error

[Sylvain Munaut]

Hi,


If you're using Ubuntu, you can try the intel-opencl-icd package which
is the binary package for https://github.com/intel/compute-runtime
which is the OpenCL driver for Intel GPUs.
However, I'm not sure anyone has ever run fosphor with it ... not sure
if it supports the features required, I only tried on AMD and NVidia
GPUs as I don't have any Intel GPU supporting that driver.

Cheers,

  Sylvain

RE: fosphor sink block error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Sylvain,


I realize that I'm not sure of how I install the gr-fosphor package. I download 
the .deb (gr-fosphor_3.8~2.2d4fe78-1build3_amd64.deb) and I install it. I did 
that because I don't really understand what to do by reading the wiki fosphor.


So I'm back in Gnuradio 3.9 


> What GPU do you have in your machine ?

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 
(Whiskey Lake) [8086:3ea0] (prog-if 00 [VGA controller])
Kernel driver in use: i915
Kernel modules: i915

> Also, list the files in `/etc/OpenCL/vendors/` which gives the
installed drivers.

I don't have such a repository ... I guess the problem comes from here.

Thanks for helping 
Gwendoline



De : Sylvain Munaut <246...@gmail.com>
Envoyé : jeudi 23 décembre 2021 11:29:58
À : Gwendoline Hochet Derevianckine
Cc : discuss-gnuradio@gnu.org
Objet : Re: fosphor sink block error

Warning - External Email


Hi Gwendoline,


> I tried various versions of Gnuradio but fosphor sink block doesn't work 
> under 3.8 or 3.9.

Definitely go for 3.9
I only maintain it for the latest version of gnuradio ( so it might be
3.10 only soon ... ).


> [!] CL Error (-1001, 
> /build/gr-fosphor-1DVbtt/gr-fosphor-3.8~2.2d4fe78/lib/fosphor/cl.c:299): 
> Unable to fetch platform IDs
> [!] No suitable OpenCL device found
> gr::log :ERROR: qt_sink_c0 - Failed to initialize fosphor

So that's a sign that it found no valid OpenCL device.
Most distribution don't install proper OpenCL drivers by default.

The OpenCL stack is composed of two elements :
 - The "Dispatcher" : which is just a shim to dispatch OpenCL requests
to multiple "platforms" (i..e vendors basically) in case you have
several OpenCL devices in your system.
 - The actual driver that talks to the hardware.

Obviously you have the dispatcher installed (called "ICD Loader"), but
there was no driver (caled "ICD") found (or if there was drivers,
those drivers reported no valid/available devices).

What GPU do you have in your machine ?
Also, list the files in `/etc/OpenCL/vendors/` which gives the
installed drivers.

Cheers,

   Sylvain

To view our privacy policy, including the types of personal information we 
collect, process and share, and the rights and options you have in this 
respect, see www.semtech.com/legal.

Re: fosphor sink block error

[Sylvain Munaut]

Hi Gwendoline,


> I tried various versions of Gnuradio but fosphor sink block doesn't work 
> under 3.8 or 3.9.

Definitely go for 3.9
I only maintain it for the latest version of gnuradio ( so it might be
3.10 only soon ... ).


> [!] CL Error (-1001, 
> /build/gr-fosphor-1DVbtt/gr-fosphor-3.8~2.2d4fe78/lib/fosphor/cl.c:299): 
> Unable to fetch platform IDs
> [!] No suitable OpenCL device found
> gr::log :ERROR: qt_sink_c0 - Failed to initialize fosphor

So that's a sign that it found no valid OpenCL device.
Most distribution don't install proper OpenCL drivers by default.

The OpenCL stack is composed of two elements :
 - The "Dispatcher" : which is just a shim to dispatch OpenCL requests
to multiple "platforms" (i..e vendors basically) in case you have
several OpenCL devices in your system.
 - The actual driver that talks to the hardware.

Obviously you have the dispatcher installed (called "ICD Loader"), but
there was no driver (caled "ICD") found (or if there was drivers,
those drivers reported no valid/available devices).

What GPU do you have in your machine ?
Also, list the files in `/etc/OpenCL/vendors/` which gives the
installed drivers.

Cheers,

   Sylvain