Re: Deprecated volk_* functions?

[Ron Economos]

  
  
Ralf,
Here's an example in one of my OOT projects.
https://github.com/drmpeg/gr-atsc3/blob/master/lib/paprtr_cc_impl.cc#L488-L492
Here's the pull request that changed things.
https://github.com/gnuradio/volk/pull/695
Ron

On 11/4/24 11:42, Ralf Gorholt wrote:

Dear all,
  
  
  in one of my blocks I use VOLK functions for which the compiler
  prints a
  
  "deprecated" warning message (volk_32fc_s32fc_x2_rotator_32fc and
  
  volk_32fc_s32fc_multiply_32fc).
  
  
  How do I need to change my code to get rid of them? In the volk
  
  documentation I haven't seen anything but maybe I've overlooked
  it. I am
  
  currently using VOLK version 3.1.2
  
  
  Thank you for your help!
  
  
  Ralf
  
  

  

Re: Regarding the use of file sink module

[Marcus Müller]

Hi Yuhe,

On 01.11.24 02:29, 徐雨荷 wrote:

The txt file cannot fully display the data


It's not a text file. Please read

https://wiki.gnuradio.org/index.php?title=File_Sink#What_is_the_file_format_of_a_file_sink?_How_can_I_read_files_produced_by_a_file_sink?

Best regards,
Marcus

Re: "forecast" function error in Embedded Python basic_block

[Achilleas Anastasopoulos]

I guess I answered my own question:

The forecast function definition has changed in gnuradio 3.10 and it is now
defined in such a way that the second argument is only the number of input
ports.
So a correct forecast looks like this.

def forecast(self, noutput_items, ninputs):
ninput_items_required = [0] * ninputs
for i in range(ninputs):
ninput_items_required[i] = noutput_items * self.sps
return ninput_items_required

Achilleas

On Fri, Nov 1, 2024 at 1:36 PM Achilleas Anastasopoulos 
wrote:

> Hi everyone,
>
> I am running a simple flowgraph where I use an embedded python block.
>
> I have rewritten a forecast function.
>
> When I run the code I get:
> 
> Executing: /usr/bin/python3 -u top_block.py
>
> thread_body_wrapper :error: ERROR thread[thread-per-block[15]:  sampler and diff decoder(7)>]: TypeError: 'int' object does not support
> item assignment
>
> At:
>   /n/higgins/z/anastas/GNURADIO_LAB/Final Draft Lab
> 8/top_block_epy_block_0.py(39): forecast
>   /usr/lib/python3/dist-packages/gnuradio/gr/gateway.py(149):
> handle_forecast
> ===
>
> It thinks that the second argument in forecast is an "int" instead of a
> list to be populated
> by the function.
>
> What am I missing? (I am using gnuradio 3.10.1.1 (Python 3.10.12))
> Also, where can i find the exact Python bindings for each of these
> functions?
>
> thanks
> Achilleas
>
> Here is the relevant code:
> =
> class blk(gr.basic_block):  # other base classes are basic_block,
> decim_block, interp_block
> """Embedded Python Block example"""
>
> def __init__(self, datalength=10, sps = 8):
> """arguments to this function show up as parameters in GRC"""
> gr.basic_block.__init__(
> self,
> name='MF sampler and diff decoder',
> in_sig=[np.int8, np.complex64],
> out_sig=[np.int8]
> )
> self.datalength = datalength
> self.sps = sps
> self.set_output_multiple(self.datalength)
> self.state=1
>
> def forecast(self, noutput_items, ninput_items_required):
> ninput_items_required[0] = noutput_items*self.sps
> ninput_items_required[1] = noutput_items*self.sps
>
>

Re: Signal data is not true

[Chris Kuethe]

one thing I always do to test new RF equipment is to try receive a
commercial fm broadcast station. I don't even need to demodulate the audio,
but it had better be visible on a waterfall. then I see if weaker signals
(eg. a car remote) is also visible. those help rule out a few gross
failures.

did someone give you an RP-SMA connector instead of SMA? are your gain
settings correct? is your transmitter actually working? did someone add
some extra attenuation?

On Fri, Nov 1, 2024, 03:34 PACSys R&D  wrote:

> Hi
> I am having a rather major issue with my signal detector system. It
> includes a HackRF One, a raspberry pi 4 and a bunch of other components
> connected to the Pi for extra data. It was working perfectly fine until
> recently (1 month ago) I noticed that the signal values are sort of
> "sticking" even though I move the source around and the values should be
> changing accordingly. The strengths also drop significantly in a short
> physical range now. I tested everything, down to the SD card on the Pi.
> Eventually I thought it could be the HackRF because it was overheating.
> Got a new one, and the problem persists. I am also using a Low Noise Amp
> and tried to see what my results were without it, the problem persisted
> as well but I am not sure if I can rule it out as a problem (I bought a
> new one but it is stuck in shipment). I also replaced the antenna and the
> antenna cable. I wanted to find out if anyone has experienced this before
> or what you think the problem could be?
> Thank you.
> Kind regards
>

Re: Installation of GNURadio v3.8 on Ubuntu 22.04 using PyBombs

[Marcus Müller]

Hi Kunal,

nice to have you around! But: please, don't take screenshots of text – a copy & pasting of 
the actual error text to an email would have allowed us to actually search the things you see.
(also, even if you need to take a screenshot: Use the built-in functionality of your 
operating system to take screenshots. Reading a slanted camera picture is an unnecessary 
hassle!)


Now, I'm afraid that GNU Radio 3.8 isn't really something we can support you much with at 
this point. In this case, as you can see, it looks like the Boost you're using is newer 
than what that old GNU Radio can deal with.


So, the question here is

Why GNU Radio 3.8?

Maybe we can find a way forward based on that :)

Best regards,
Marcus

On 25.10.24 17:10, KunalPrabhakar Sangurmath wrote:

Hi,

I'm trying to install GNURadio v3.8 on Ubuntu 22.04(jammy) using PyBombs but I am getting 
an error. I would appreciate your help with this.

Steps followed:
sudo apt-get install python3-pip
sudo pip3 install pybombs
pybombs auto-config
pybombs recipes add-defaults
pybombs prefix init ~/prefix-3.8 -R gnuradio38.


Regards,
Kunal.

Re: Recovering symbols from burst transmissions with unknown sample rate

[Adrian Musceac]

On Saturday, 19 October 2024 17:22:13 EEST Marcus Müller wrote:
> Hi Adrian,

Hi Marcus, 
Thank you for the suggestions, I had to think a bit and also translate to what 
I already have here - there are two small differences:

1. I use the quadrature demod block instead of the PLL freq detect, but the 
outcome should be the same basically
2. I use a raised cosine filter for the known correlation sequence, since a 
matched RRC filter is applied right after the quadrature demod. So the block 
sequence is: Quad demod -> matching RRC filter -> correlate the sync sequence.
I believe this is needed to have a sync block operate on symbols with ISI 
removed.

So if I understood your design correctly, I need to count the distance between 
two correlation peaks in samples, and apply this difference between actual 
number of samples and ideal number of samples as the second input to the 
fractional resampler in a feed forward loop, and this will enable me to sample 
at the symbol peak later as the peak correlation tag would be aligned to the 
symbol peak and the input sample rate will match the ideal sample rate right?

So if I understood this system correctly, then the earliest aligned symbol 
sampling can happen on the third burst, since the first two are necessary to 
determine the samples per symbol mismatch? I'm going to give this a try.

Then my questions following from this:
- can rotating the samples achieve the same symbol alignment as the fractional 
resampler?
- I wonder if the correlator filter can give me enough information to achieve 
this in a single burst. I took a brief look at the code of the correlation 
estimator block, and it appears to me that the "time_est" tag gives the offset 
between the correlation peak and the optimum actual symbol peak. So I wonder 
if this information is enough to adjust the peak symbol sampling in one go (so 
even a single burst could be decoded correctly (in a single sync block as 
opposed to a loop).

Thanks,
Adrian

> 
> interesting system! And with the "1 out of 6 frames only" sync opportunity,
> the rather generous 24/132 symbols midamble does seem more reasonable.
> 
> Thinking about that, I think one way you can approach this is:
> 
> - Instead of the corr_est block, you go ahead and build a simple correlation
> detector yourself:
>- AGC
>- Input signal gets put through PLL Freq Det; that gives us the
> RRC-shaped 4-ASK (->A) - (offline, before) use the same RRC to filter [54
> zeros, midamble, 54 zeros] to get a prototype burst; reverse the order (and
> complex conjugate, but this is real, so nevermind), call the result
> "coeffs"
>- Filter input signal with a filter whose taps are these "coeffs"
>- complex to mag² (-> B)
>- requires your own sync_block with 2 inputs, one of them being (A), the
> other (B): - set output multiple to 132/2
>  - copy (all - 132/2) input from (A) to output
>  - look for value above threshold on B (correlation peaks!) starting at
> input sample 132/2
>  - if peak present, add tag to output at position of peak - 132/2
>  - consume (all - 132/2) input items (inherently from both inputs)
> 
> Couple observations:
> 
> - If you start by interpolating (say, by a factor of f=4), then you need to
> multiply 132 by f in all considerations above, but you might no longer need
> a symbol sync at all. With an FFT FIR filter, things should still be plenty
> fast enough - You could use the peak positions in a block that keeps track
> whether they are multiples of the TDMA slot length, you can track the
> amount by which they deviate from the "correct" count, and use that
> (ideally, smoothed a bit, maybe go PID on that) to adjust a Fractional
> Resampler block that you put up front of things, to match your receive
> chain's sample rate to the transmitter's sample rate
> - You could also include the complex phase of the peak in the tag; divide
>(phase difference) / (tag distance) to get a fine carrier frequency error
> estimate
> On 18.10.24 21:07, Adrian Musceac wrote:
> > On Friday, 18 October 2024 21:07:55 EEST Marcus Müller wrote:
> >> Hi Adrian,
> >> if you don't know the sample rate, then how can you get a detection by
> >> correlating with the midamble? Is the midamble structured to be tolerant
> >> against sample frequency offset (SFO)? In that case, therein probably
> >> lies
> >> an approach to getting your decoding to work.
> > 
> > Hi Marcus,
> > I meant unknown sample rate in the sense that the number of received
> > samples per symbol can be different in small amounts to the ideal samples
> > per symbol value, not in the sense that the sample rate is not coarsely
> > known.
> > 
> > The difference between ideal and actual rate is small enough that a
> > correlation peak can easily be extracted from the correlation estimator
> > populated with a set of filtered symbols from the right sequence (there
> > are 4 such sequences, only two are relevant to me).
> > 
> >> But we'd really need to know more

Re: Error on trying to install an OOT

[Elmore Family]

Thanks Marcus,

That did it. Don't know what I would do without you!

Jim

-Original Message- 
From: Marcus Müller

Sent: Friday, October 18, 2024 2:03 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Error on trying to install an OOT

Hi!
Sounds like you're in the right place :)

Question: this looks a bit like half a build made with an older version; you 
need to clean
the build/ directory, run `cmake` and `make` again before you can `sudo make 
install`.


Best,
Marcus

On 18.10.24 02:45, Elmore Family wrote:

I’m not sure this is where I should be asking this question but here goes.
To anyone that is wondering I just upgraded to Bookworm on my Pi and 
installed GNURadio 3.10.5.1. ( This was the subject of much discussion 
recently)
I am attempting to install an OOT module from my existing project because 
it does not show in the flowgraph. I assume that I need to perform ‘sudo 
make install’ to load it into the new GNURadio. Perhaps this is not a 
correct assumption.
However, when I perform the command I get an error which is spelled out in 
the error log below.

What do I need to do here?
Jim
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the 
following output:

Change Dir: /home/pi/gr-freq/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/gmake cmTC_15004/fast && /usr/bin/gmake  -f 
CMakeFiles/ cmTC_15004.dir/build.make CMakeFiles/cmTC_15004.dir/build

gmake[1]: Entering directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_15004.dir/src.c.o
/usr/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD -std=gnu11 -o 
CMakeFiles/cmTC_15004.dir/src.c.o - c 
/home/pi/gr-freq/build/CMakeFiles/CMakeTmp/src.c

Linking C executable cmTC_15004
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/cmTC_15004.dir/link.txt --verbose=1
/usr/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD 
CMakeFiles/cmTC_15004.dir/src.c.o -o cmTC_15004

/usr/bin/ld: CMakeFiles/cmTC_15004.dir/src.c.o: in function `main':
src.c:(.text+0x40): undefined reference to `pthread_create'
/usr/bin/ld: src.c:(.text+0x4c): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x58): undefined reference to `pthread_cancel'
/usr/bin/ld: src.c:(.text+0x68): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_15004.dir/build.make:106: cmTC_15004] Error 
1

gmake[1]: Leaving directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_15004/fast] Error 2
Source file was:
#include 
void* test_func(void* data)
{
   return data;
}
int main(void)
{
   pthread_t thread;
   pthread_create(&thread, NULL, test_func, NULL);
   pthread_detach(thread);
   pthread_cancel(thread);
   pthread_join(thread, NULL);
   pthread_atfork(NULL, NULL, NULL);
   pthread_exit(NULL);
   return 0;
}
Determining if the function pthread_create exists in the pthreads failed 
with the following output:

Change Dir: /home/pi/gr-freq/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/gmake cmTC_75010/fast && /usr/bin/gmake  -f 
CMakeFiles/ cmTC_75010.dir/build.make CMakeFiles/cmTC_75010.dir/build

gmake[1]: Entering directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_75010.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -std=gnu11 -o 
CMakeFiles/ cmTC_75010.dir/CheckFunctionExists.c.o -c 
/usr/share/cmake-3.18/Modules/CheckFunctionExists.c

Linking C executable cmTC_75010
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/cmTC_75010.dir/link.txt --verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create 
CMakeFiles/cmTC_75010.dir/ CheckFunctionExists.c.o -o 
mTC_75010  -lpthreads

/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_75010.dir/build.make:106: cmTC_75010] Error 
1

gmake[1]: Leaving directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_75010/fast] Error 2

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig- 
email&utm_content=emailclient> Virus-free.www.avg.com 
<http://www.avg.com/email-signature? 
utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>




--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: Recovering symbols from burst transmissions with unknown sample rate

[Marcus Müller]

Hi Adrian,

interesting system! And with the "1 out of 6 frames only" sync opportunity, the rather 
generous 24/132 symbols midamble does seem more reasonable.


Thinking about that, I think one way you can approach this is:

- Instead of the corr_est block, you go ahead and build a simple correlation detector 
yourself:

  - AGC
  - Input signal gets put through PLL Freq Det; that gives us the RRC-shaped 4-ASK 
(->A)
  - (offline, before) use the same RRC to filter [54 zeros, midamble, 54 zeros] 
to get a
prototype burst; reverse the order (and complex conjugate, but this is 
real, so
nevermind), call the result "coeffs"
  - Filter input signal with a filter whose taps are these "coeffs"
  - complex to mag² (-> B)
  - requires your own sync_block with 2 inputs, one of them being (A), the 
other (B):
- set output multiple to 132/2
- copy (all - 132/2) input from (A) to output
- look for value above threshold on B (correlation peaks!) starting at 
input sample
  132/2
- if peak present, add tag to output at position of peak - 132/2
- consume (all - 132/2) input items (inherently from both inputs)

Couple observations:

- If you start by interpolating (say, by a factor of f=4), then you need to 
multiply 132
  by f in all considerations above, but you might no longer need a symbol sync 
at all.
  With an FFT FIR filter, things should still be plenty fast enough
- You could use the peak positions in a block that keeps track whether they are 
multiples
  of the TDMA slot length, you can track the amount by which they deviate from 
the
  "correct" count, and use that (ideally, smoothed a bit, maybe go PID on that) 
to adjust
  a Fractional Resampler block that you put up front of things, to match your 
receive
  chain's sample rate to the transmitter's sample rate
- You could also include the complex phase of the peak in the tag; divide
  (phase difference) / (tag distance) to get a fine carrier frequency error 
estimate


On 18.10.24 21:07, Adrian Musceac wrote:

On Friday, 18 October 2024 21:07:55 EEST Marcus Müller wrote:

Hi Adrian,
if you don't know the sample rate, then how can you get a detection by
correlating with the midamble? Is the midamble structured to be tolerant
against sample frequency offset (SFO)? In that case, therein probably lies
an approach to getting your decoding to work.


Hi Marcus,
I meant unknown sample rate in the sense that the number of received samples
per symbol can be different in small amounts to the ideal samples per symbol
value, not in the sense that the sample rate is not coarsely known.

The difference between ideal and actual rate is small enough that a correlation
peak can easily be extracted from the correlation estimator populated with a
set of filtered symbols from the right sequence (there are 4 such sequences,
only two are relevant to me).



But we'd really need to know more about the signal; I feel at least

- burst length compared to midamble length,
- pulse shaping if known,
- constellation type



The signal is 4-FSK with RRC pulse shaping applied, the burst length is 132
symbols, and the midamble length is 24 symbols. The sync sequences consist of
values from the set (-3,+3) where the constellation is defined as
  [-3, -1, 1, 3]. It is the standard air interface for DMR (digital mobile
radio), direct mode of operation (not BS mediated).



Furthermore, you say not all bursts have such a known midamble: but then,
how do you figure out such a burst started? Sounds like there's *also* some
kind of preamble.



Unfortunately not, the standard specifies that a synchronization opportunity is
provided every 6 voice frames, and also every data frame (the transmission
headers and terminators).
My hope is that by estimating a symbol timing offset during a synchronization
burst, this offset could be used for sampling the next 5 TDMA frames and not
deviate significantly in such a short time, but this is just a guess.

Thank you,
Adrian


Best,
Marcus

Re: Recovering symbols from burst transmissions with unknown sample rate

[Marcus Müller]

Hi Adrian,

interesting system! And with the "1 out of 6 frames only" sync opportunity, the rather 
generous 24/132 symbols midamble does seem more reasonable.


Thinking about that, I think one way you can approach this is:

- Instead of the corr_est block, you go ahead and build a simple correlation detector 
yourself:

  - AGC
  - Input signal gets put through PLL Freq Det; that gives us the RRC-shaped 4-ASK 
(->A)
  - (offline, before) use the same RRC to filter [54 zeros, midamble, 54 zeros] 
to get a
prototype burst; reverse the order (and complex conjugate, but this is 
real, so
nevermind), call the result "coeffs"
  - Filter input signal with a filter whose taps are these "coeffs"
  - complex to mag² (-> B)
  - requires your own sync_block with 2 inputs, one of them being (A), the 
other (B):
- set output multiple to 132/2
- copy (all - 132/2) input from (A) to output
- look for value above threshold on B (correlation peaks!) starting at 
input sample
  132/2
- if peak present, add tag to output at position of peak - 132/2
- consume (all - 132/2) input items (inherently from both inputs)

Couple observations:

- If you start by interpolating (say, by a factor of f=4), then you need to 
multiply 132
  by f in all considerations above, but you might no longer need a symbol sync 
at all.
  With an FFT FIR filter, things should still be plenty fast enough
- You could use the peak positions in a block that keeps track whether they are 
multiples
  of the TDMA slot length, you can track the amount by which they deviate from 
the
  "correct" count, and use that (ideally, smoothed a bit, maybe go PID on that) 
to adjust
  a Fractional Resampler block that you put up front of things, to match your 
receive
  chain's sample rate to the transmitter's sample rate
- You could also include the complex phase of the peak in the tag; divide
  (phase difference) / (tag distance) to get a fine carrier frequency error 
estimate


On 18.10.24 21:07, Adrian Musceac wrote:

On Friday, 18 October 2024 21:07:55 EEST Marcus Müller wrote:

Hi Adrian,
if you don't know the sample rate, then how can you get a detection by
correlating with the midamble? Is the midamble structured to be tolerant
against sample frequency offset (SFO)? In that case, therein probably lies
an approach to getting your decoding to work.


Hi Marcus,
I meant unknown sample rate in the sense that the number of received samples
per symbol can be different in small amounts to the ideal samples per symbol
value, not in the sense that the sample rate is not coarsely known.

The difference between ideal and actual rate is small enough that a correlation
peak can easily be extracted from the correlation estimator populated with a
set of filtered symbols from the right sequence (there are 4 such sequences,
only two are relevant to me).



But we'd really need to know more about the signal; I feel at least

- burst length compared to midamble length,
- pulse shaping if known,
- constellation type



The signal is 4-FSK with RRC pulse shaping applied, the burst length is 132
symbols, and the midamble length is 24 symbols. The sync sequences consist of
values from the set (-3,+3) where the constellation is defined as
  [-3, -1, 1, 3]. It is the standard air interface for DMR (digital mobile
radio), direct mode of operation (not BS mediated).



Furthermore, you say not all bursts have such a known midamble: but then,
how do you figure out such a burst started? Sounds like there's *also* some
kind of preamble.



Unfortunately not, the standard specifies that a synchronization opportunity is
provided every 6 voice frames, and also every data frame (the transmission
headers and terminators).
My hope is that by estimating a symbol timing offset during a synchronization
burst, this offset could be used for sampling the next 5 TDMA frames and not
deviate significantly in such a short time, but this is just a guess.

Thank you,
Adrian


Best,
Marcus

Re: Recovering symbols from burst transmissions with unknown sample rate

[Adrian Musceac]

On Friday, 18 October 2024 21:07:55 EEST Marcus Müller wrote:
> Hi Adrian,
> if you don't know the sample rate, then how can you get a detection by
> correlating with the midamble? Is the midamble structured to be tolerant
> against sample frequency offset (SFO)? In that case, therein probably lies
> an approach to getting your decoding to work.

Hi Marcus, 
I meant unknown sample rate in the sense that the number of received samples 
per symbol can be different in small amounts to the ideal samples per symbol 
value, not in the sense that the sample rate is not coarsely known.

The difference between ideal and actual rate is small enough that a correlation 
peak can easily be extracted from the correlation estimator populated with a 
set of filtered symbols from the right sequence (there are 4 such sequences, 
only two are relevant to me).

> 
> But we'd really need to know more about the signal; I feel at least
> 
> - burst length compared to midamble length,
> - pulse shaping if known,
> - constellation type
> 

The signal is 4-FSK with RRC pulse shaping applied, the burst length is 132 
symbols, and the midamble length is 24 symbols. The sync sequences consist of 
values from the set (-3,+3) where the constellation is defined as
 [-3, -1, 1, 3]. It is the standard air interface for DMR (digital mobile 
radio), direct mode of operation (not BS mediated).

> 
> Furthermore, you say not all bursts have such a known midamble: but then,
> how do you figure out such a burst started? Sounds like there's *also* some
> kind of preamble.
> 

Unfortunately not, the standard specifies that a synchronization opportunity is 
provided every 6 voice frames, and also every data frame (the transmission 
headers and terminators). 
My hope is that by estimating a symbol timing offset during a synchronization 
burst, this offset could be used for sampling the next 5 TDMA frames and not 
deviate significantly in such a short time, but this is just a guess. 

Thank you,
Adrian

> Best,
> Marcus
> 

Re: Recovering symbols from burst transmissions with unknown sample rate

[Marcus Müller]

Hi Adrian,
if you don't know the sample rate, then how can you get a detection by correlating with 
the midamble? Is the midamble structured to be tolerant against sample frequency offset 
(SFO)? In that case, therein probably lies an approach to getting your decoding to work.


But we'd really need to know more about the signal; I feel at least

- burst length compared to midamble length,
- pulse shaping if known,
- constellation type

would be necessary.

Furthermore, you say not all bursts have such a known midamble: but then, how do you 
figure out such a burst started? Sounds like there's *also* some kind of preamble.


Best,
Marcus

On 18.10.24 08:19, Adrian Musceac wrote:

Hello,

As the title says, I'd like to know if it would be possible to recover symbols
from a transmission containing regular bursts separated by noise (TDMA), using
just blocks present in GNU Radio (or some custom algorithm that can be
implemented as a block).

I've tried using the correlation estimator together with the symbol
synchronization block, but the problem I had was that the known
synchronization sequence is placed in the middle of the data burst (as in most
such real life transmissions). This meant that the "time_est" tag will not
jump start the symbol synchronizer in time to recover all symbols of the
burst.

What is even worse is that not all data bursts have an embedded
synchronization sequence, so there is no way to estimate the difference from
expected to actual sample rate until the next sync sequence is transmitted
(every 6 frames).

Is there a way to overcome this apparent limitation of the corr_est + symbol
sync combination?

Thank you,
Adrian

Re: Error on trying to install an OOT

[Marcus Müller]

Hi!
Sounds like you're in the right place :)

Question: this looks a bit like half a build made with an older version; you need to clean 
the build/ directory, run `cmake` and `make` again before you can `sudo make install`.


Best,
Marcus

On 18.10.24 02:45, Elmore Family wrote:

I’m not sure this is where I should be asking this question but here goes.
To anyone that is wondering I just upgraded to Bookworm on my Pi and installed GNURadio 
3.10.5.1. ( This was the subject of much discussion recently)
I am attempting to install an OOT module from my existing project because it does not show 
in the flowgraph. I assume that I need to perform ‘sudo make install’ to load it into the 
new GNURadio. Perhaps this is not a correct assumption.
However, when I perform the command I get an error which is spelled out in the error log 
below.

What do I need to do here?
Jim
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following 
output:
Change Dir: /home/pi/gr-freq/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/gmake cmTC_15004/fast && /usr/bin/gmake  -f CMakeFiles/ 
cmTC_15004.dir/build.make CMakeFiles/cmTC_15004.dir/build

gmake[1]: Entering directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_15004.dir/src.c.o
/usr/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD -std=gnu11 -o CMakeFiles/cmTC_15004.dir/src.c.o - 
c /home/pi/gr-freq/build/CMakeFiles/CMakeTmp/src.c

Linking C executable cmTC_15004
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_15004.dir/link.txt 
--verbose=1
/usr/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD CMakeFiles/cmTC_15004.dir/src.c.o -o 
cmTC_15004
/usr/bin/ld: CMakeFiles/cmTC_15004.dir/src.c.o: in function `main':
src.c:(.text+0x40): undefined reference to `pthread_create'
/usr/bin/ld: src.c:(.text+0x4c): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x58): undefined reference to `pthread_cancel'
/usr/bin/ld: src.c:(.text+0x68): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_15004.dir/build.make:106: cmTC_15004] Error 1
gmake[1]: Leaving directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_15004/fast] Error 2
Source file was:
#include 
void* test_func(void* data)
{
   return data;
}
int main(void)
{
   pthread_t thread;
   pthread_create(&thread, NULL, test_func, NULL);
   pthread_detach(thread);
   pthread_cancel(thread);
   pthread_join(thread, NULL);
   pthread_atfork(NULL, NULL, NULL);
   pthread_exit(NULL);
   return 0;
}
Determining if the function pthread_create exists in the pthreads failed with the 
following output:

Change Dir: /home/pi/gr-freq/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/gmake cmTC_75010/fast && /usr/bin/gmake  -f CMakeFiles/ 
cmTC_75010.dir/build.make CMakeFiles/cmTC_75010.dir/build

gmake[1]: Entering directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_75010.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -std=gnu11 -o CMakeFiles/ 
cmTC_75010.dir/CheckFunctionExists.c.o -c /usr/share/cmake-3.18/Modules/CheckFunctionExists.c

Linking C executable cmTC_75010
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_75010.dir/link.txt 
--verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTC_75010.dir/ 
CheckFunctionExists.c.o -o cmTC_75010  -lpthreads

/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_75010.dir/build.make:106: cmTC_75010] Error 1
gmake[1]: Leaving directory '/home/pi/gr-freq/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_75010/fast] Error 2

	Virus-free.www.avg.com 


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Error regarding communication connection between GNUradio and SDRplayRSPdx

[Franco VENTURI]

Yuhe,
I think gr-osmosdr was the old way to interface an SDR with GNU Radio.
 
With recent versions of GNU Radio you may want to use one of these two ways:
 
   - gr-soapy, which is an in-tree module and should be part of GNU Radio 
3.10.10
 
   - gr-sdrplay3, which is an out-of-tree module I wrote; it uses directly the 
SDRplay API to connect to your RSP (i.e. it does not require SoapySDR or the 
SoapySDRPlay3 module). You can find the OOT module 'gr-sdrplay3' here: 
https://github.com/fventuri/gr-sdrplay3
 
I'll be happy to help you if you have any questions.
 
Franco
 

> On 10/17/2024 9:36 PM EDT 徐雨荷  wrote:
>  
>  
> I’m not sure this is where I should be asking this question but here goes.
> 
>  
> I try to read the data of SDRplay on GNUradio, but it shows an error. It 
> thinks there is something wrong with the installation or configuration of my 
> USB device driver and communication is not possible.But SDRuno software can 
> be used to read data normally, what should I do now?
>  
> I hope I can get some help.Attached below is the error report from GNUradio.
>  
> Yuhe
>  
> gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.10.0
> built-in source types: file rtl rtl_tcp uhd miri hackrf bladerf airspy 
> airspyhf soapy redpitaya
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_108200; 
> UHD_4.6.0.0-release
> [WARNING] Unable to scan local: -19
>  
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_2717&PID_5023\7&27C58F36&0&2'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_3277&PID_0029\0001'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_2717&PID_5023&MI_01\8&F29D925&0&0001'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_05E3&PID_0610\6&72FCEC3&0&2'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_2717&PID_5023&MI_00\8&F29D925&0&'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_05E3&PID_0625\6&72FCEC3&0&4'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\ROOT_HUB30\5&292403F0&0&0'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_13D3&PID_3563\0'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_3277&PID_0029&MI_00\7&18314511&0&'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\ROOT_HUB30\5&14F916E1&0&0'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\ROOT_HUB30\5&33507A3D&0&0'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_1A40&PID_0101\7&27C58F36&0&1'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_13D3&PID_3563&MI_00\7&1D754FA2&0&'
> libusb: info [get_guid] no DeviceInterfaceGUID registered for 
> 'USB\VID_0951&PID_1666\80C5F274C4DA159098360041'
> [WARNING] Unable to scan ip: -19
>  
> [INFO] Using format CF32.
>  
> 

Re: Constellation Rect. Object parameters for 8psk 16-32-64-256APSK modulations.

[Daniel Estévez]

On 15/10/2024 20:30, mehtap özkan wrote:

Hi All,
I am having difficulty finding examples for demodulating 8psk 
16-32-64-256APSK modulated signals. Does anybody know what the settings 
of Constellation Rect. Object for these modulation schemes should be?


Thanks in advance.


Hello Mehtap,

Here is an example of how to set up a DVB-S2 32APSK constellation:

https://github.com/daniestevez/qo100-modem/blob/master/gr-qo100_modem/python/constants.py#L25

Best,
Daniel.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New install of GNU Radio executes old version

[Elmore Family]

Marcus,

In retrospect that is true.

I didn't take that path because for various reasons in the process I thought 
that 3.10 was not available to me in the repository and anyway at the time I 
tried an upgrade to bookworm it failed. I think it failed at the time 
because of some instability.


So now I have new problems (it never ends). I tried upgrading to bookworm. 
On reboot the Pi hangs. Oh well, what's new?


I am going on the Pi forum to see if I can resolve this issue.

Thanks, Chris, for spending all this time with me. I did learn a lot. 
Thanks, Marcus, for your comments. I wouldn't still be playing with GNU 
Radio if it hadn't been for this forum answering all my stupid questions.


Jim



-Original Message- 
From: Marcus Müller

Sent: Monday, October 14, 2024 2:52 AM
To: Elmore Family ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

so, taking a step back from your problem I'd say you invested far more time 
into staying
on Debian 11 (which is "oldstable" by now) than it would have cost you to 
upgrade to 12
("stable", bookworm). So, in all honesty, *not* doing any source code 
building yourself
and upgrading to Debian bookworm would have probably been the winning move 
here :)


Is that an option?

Best regards,
Marcus

On 12.10.24 03:07, Elmore Family wrote:

Marcus,

My OS is Debian 11, Bullseye. I upgraded to Bullseye in Jan. 2022.

I want to install GNU Radio 3.10+.

The reason why has a long explanation. I have an application in which I 
wish to have a text display window instead of the text appearing in the 
console output.
I posted this request last year when I began to think about this and 
Volker answered me suggesting I look in to gr-display.
I went to the github account of the publisher of gr-display and downloaded 
everything. One of the dependencies is version 3.10+ of GNU Radio.
I performed 'sudo apt-get install gnuradio' in an attempt to install 
3.10+. I was informed that I already had the latest version (3.9.4).
Thus, I arrived at the conclusion that the only way I could upgrade was to 
install from source which is what started me on this unfortunate path.


Jim

-Original Message- From: Marcus Müller
Sent: Friday, October 11, 2024 10:48 AM
To: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

sorry for jumping in so late, I've been travelling.

I'm super confused as to *why* you're going through all this. And, yes,
libuhd4.2.0 is *not* the name of library package.

I've tried skimming the thread, and quite honestly, it's a bit of a
collection of conflicting approaches, and it feels like that's setting
you up for a hard time.

Now, let's get this sorted as easily as possible: Just to verify,
because, again, conflicting things,

1. what version of GNU Radio do you want to install

1.1 importantly: and why?

2. on which version of which OS (`cat /etc/os-release` might be the most
authorative you can get)

My *suspicion* is that knowing the answer to 1.1 gives me the info I'd
need to give you a "tried and tested" way forward. Building GNU Radio on
a Raspberry Pi certainly is *not* a desirable detour, if it can *at all*
be avoided.

Best,
Marcus

On 2024-10-11 3:15 PM, Elmore Family wrote:

Chris,

Here's the latest in this never-ending saga:

pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends 
libuhd4.2.0 libuhd-dev

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package libuhd4.2.0
E: Couldn't find any package by glob 'libuhd4.2.0'
E: Couldn't find any package by regex 'libuhd4.2.0'

Jim

-Original Message- From: Chris Gorman
Sent: Wednesday, October 9, 2024 9:05 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired 

Re: New install of GNU Radio executes old version

[Marcus Müller]

Hi Jim,

so, taking a step back from your problem I'd say you invested far more time into staying 
on Debian 11 (which is "oldstable" by now) than it would have cost you to upgrade to 12 
("stable", bookworm). So, in all honesty, *not* doing any source code building yourself 
and upgrading to Debian bookworm would have probably been the winning move here :)


Is that an option?

Best regards,
Marcus

On 12.10.24 03:07, Elmore Family wrote:

Marcus,

My OS is Debian 11, Bullseye. I upgraded to Bullseye in Jan. 2022.

I want to install GNU Radio 3.10+.

The reason why has a long explanation. I have an application in which I wish to have a 
text display window instead of the text appearing in the console output.
I posted this request last year when I began to think about this and Volker answered me 
suggesting I look in to gr-display.
I went to the github account of the publisher of gr-display and downloaded everything. One 
of the dependencies is version 3.10+ of GNU Radio.
I performed 'sudo apt-get install gnuradio' in an attempt to install 3.10+. I was informed 
that I already had the latest version (3.9.4).
Thus, I arrived at the conclusion that the only way I could upgrade was to install from 
source which is what started me on this unfortunate path.


Jim

-Original Message- From: Marcus Müller
Sent: Friday, October 11, 2024 10:48 AM
To: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

sorry for jumping in so late, I've been travelling.

I'm super confused as to *why* you're going through all this. And, yes,
libuhd4.2.0 is *not* the name of library package.

I've tried skimming the thread, and quite honestly, it's a bit of a
collection of conflicting approaches, and it feels like that's setting
you up for a hard time.

Now, let's get this sorted as easily as possible: Just to verify,
because, again, conflicting things,

1. what version of GNU Radio do you want to install

1.1 importantly: and why?

2. on which version of which OS (`cat /etc/os-release` might be the most
authorative you can get)

My *suspicion* is that knowing the answer to 1.1 gives me the info I'd
need to give you a "tried and tested" way forward. Building GNU Radio on
a Raspberry Pi certainly is *not* a desirable detour, if it can *at all*
be avoided.

Best,
Marcus

On 2024-10-11 3:15 PM, Elmore Family wrote:

Chris,

Here's the latest in this never-ending saga:

pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends libuhd4.2.0 
libuhd-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package libuhd4.2.0
E: Couldn't find any package by glob 'libuhd4.2.0'
E: Couldn't find any package by regex 'libuhd4.2.0'

Jim

-Original Message- From: Chris Gorman
Sent: Wednesday, October 9, 2024 9:05 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired of builds and want to install your
backup instead, I understand this has been a frustrating experience.
However, I do hope you get the source build to work.

Best regards,

Chris

On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:


Chris,

Here is the latest.

It did seem to complete the install but with the same 2 errors as before:

gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error
> 1
> make[1]: *** [CMakeFiles/Makefile2:7870:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2

Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts
whose execution results in cannot import gnuradio.

Something must have been missed somewhere. I can't believe this can be this
difficult.

I have my backup of the system from before this began.

Jim


-Original Message-
From: Chris Gorman
Sent: Tuesday, October 8,

Re: Getting constellation size as a variable

[Jones, James (jtjones49)]

One can obtain the number of constellation points by using the syntax: 
constellation.arity()
Replace "constellation" with the ID of the constellation object. This will 
return 'M' representing the number of distinct symbols 2^n.

Get Outlook for Android

From: discuss-gnuradio-bounces+jtjones49=tntech@gnu.org 
 on behalf of Austen, 
Jeffrey 
Sent: Sunday, October 13, 2024 11:24:47 AM
To: discuss-gnuradio@gnu.org 
Subject: Getting constellation size as a variable

When using the Constellation Object block in Gnu Radio Companion how can
one obtain the size of the constellation, M, or the number of bits per
symbol? This value is needed so other blocks, e.g. Pack k Bits, can be
adjusted accordingly when the constellation size is changed.

A simple example would be "Random Source" producing a binary output,
followed by "Pack k Bits" to create symbols, then "Constellation
Encoder" to convert the symbols to complex-envelope symbol values.
Currently when the constellation size is changed it is necessary to also
change an additional variable, the number of bits per symbol (which is
needed by the Pack k Bits block). I'd like to be able to get this value
from the constellation object.

Re: New install of GNU Radio executes old version

[Elmore Family]

Marcus,

My OS is Debian 11, Bullseye. I upgraded to Bullseye in Jan. 2022.

I want to install GNU Radio 3.10+.

The reason why has a long explanation. I have an application in which I wish 
to have a text display window instead of the text appearing in the console 
output.
I posted this request last year when I began to think about this and Volker 
answered me suggesting I look in to gr-display.
I went to the github account of the publisher of gr-display and downloaded 
everything. One of the dependencies is version 3.10+ of GNU Radio.
I performed 'sudo apt-get install gnuradio' in an attempt to install 3.10+. 
I was informed that I already had the latest version (3.9.4).
Thus, I arrived at the conclusion that the only way I could upgrade was to 
install from source which is what started me on this unfortunate path.


Jim

-Original Message- 
From: Marcus Müller

Sent: Friday, October 11, 2024 10:48 AM
To: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

sorry for jumping in so late, I've been travelling.

I'm super confused as to *why* you're going through all this. And, yes,
libuhd4.2.0 is *not* the name of library package.

I've tried skimming the thread, and quite honestly, it's a bit of a
collection of conflicting approaches, and it feels like that's setting
you up for a hard time.

Now, let's get this sorted as easily as possible: Just to verify,
because, again, conflicting things,

1. what version of GNU Radio do you want to install

1.1 importantly: and why?

2. on which version of which OS (`cat /etc/os-release` might be the most
authorative you can get)

My *suspicion* is that knowing the answer to 1.1 gives me the info I'd
need to give you a "tried and tested" way forward. Building GNU Radio on
a Raspberry Pi certainly is *not* a desirable detour, if it can *at all*
be avoided.

Best,
Marcus

On 2024-10-11 3:15 PM, Elmore Family wrote:

Chris,

Here's the latest in this never-ending saga:

pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends 
libuhd4.2.0 libuhd-dev

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package libuhd4.2.0
E: Couldn't find any package by glob 'libuhd4.2.0'
E: Couldn't find any package by regex 'libuhd4.2.0'

Jim

-Original Message- From: Chris Gorman
Sent: Wednesday, October 9, 2024 9:05 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired of builds and want to install your
backup instead, I understand this has been a frustrating experience.
However, I do hope you get the source build to work.

Best regards,

Chris

On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:


Chris,

Here is the latest.

It did seem to complete the install but with the same 2 errors as before:

gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] 
Error

> 1
> make[1]: *** [CMakeFiles/Makefile2:7870:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2

Again the only gnuradio-companion file is the one in 
/gnuradio/grc/scripts

whose execution results in cannot import gnuradio.

Something must have been missed somewhere. I can't believe this can be 
this

difficult.

I have my backup of the system from before this began.

Jim


-Original Message-
From: Chris Gorman
Sent: Tuesday, October 8, 2024 8:43 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I'm guessing on this, but I have had experiences where I explicitly
disable a feature and it fixes a build failure.  So, rather than
letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
and disable them in the cmake call.  So I'd try ...

cd /home/pi/gnuradio
rm -rf build
mkdi

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

I did some google surfing to see what the problem was, given a missing
libuhd4.2.0.  The package available for bullseye is libuhd3.15.  The
package available for bookworm is libuhd4.3.0.  I have read one source
that said gnuradio > 3.8 will require libuhd > 4, so we won't be able
to install libuhd from apt and build gnuradio 3.10+.  (The source was
the cheat sheet I sent you.)  If I am wrong, hopefully someone on the
mailing list will correct me.  That said, it limits our options.

You could update to bookworm on your Pi.  This would allow you to use
the v3.10.5.1 gnuradio as Volker suggested.  I believe this requires a
64bit Pi.  I have never updated debian on a Pi, so I don't know the
obstacles, but from my memory it was fairly easy to do on an x86.
Alternatively, you could attempt a build of libuhd 4+ on your machine.
This will consume some time as well as it is a fairly large software
package.  The process is fairly easy (cmake, make, make install), but
you may run into build errors given the older software on the Pi and
newer software for the uhd.  If you're planning on trying to update
the UHD software, the link on how to do so is
https://wiki.gnuradio.org/index.php?title=Draft-AN-445#Building_and_installing_UHD_from_source_code
.

I wish I had better news for you given all the work you've already
done trying to get this up and running.

Best regards,

Chris








On Thu, Oct 10, 2024 at 6:15 PM Elmore Family  wrote:
>
> Chris,
>
> Here's the latest in this never-ending saga:
>
> pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends libuhd4.2.0
> libuhd-dev
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package libuhd4.2.0
> E: Couldn't find any package by glob 'libuhd4.2.0'
> E: Couldn't find any package by regex 'libuhd4.2.0'
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Wednesday, October 9, 2024 9:05 PM
> To: Elmore Family
> Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> I've found a cheat sheet on installing on the Pi.  It's available at
> https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
> originally read it I thought it said you'd need to build libuhd from
> scratch, but it appears upon closer inspection that there are packages
> for libuhd.  Yay!
>
> In short the author suggests,
>
> sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev
>
> to install UHD on the Pi.  If you have patience to try yet another
> build, try installing those packages and see if it fixes the build
> error.  (As you can see from the error it's happening with a Qt Rfnoc
> file.)  You'll have to ...
>
> cd /home/pi/gnuradio
> rm -rf build
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
> -DPYTHON_EXECUTABLE=/usr/bin/python3  ../
> make -j4
> sudo make install
>
> again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
> your error will go away.
>
> Don't feel bad if you are tired of builds and want to install your
> backup instead, I understand this has been a frustrating experience.
> However, I do hope you get the source build to work.
>
> Best regards,
>
> Chris
>
> On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:
> >
> > Chris,
> >
> > Here is the latest.
> >
> > It did seem to complete the install but with the same 2 errors as before:
> >
> > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o]
> > Error
> > > 1
> > > make[1]: *** [CMakeFiles/Makefile2:7870:
> > > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> > > make: *** [Makefile:160: all] Error 2
> >
> > Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts
> > whose execution results in cannot import gnuradio.
> >
> > Something must have been missed somewhere. I can't believe this can be
> > this
> > difficult.
> >
> > I have my backup of the system from before this began.
> >
> > Jim
> >
> >
> > -Original Message-
> > From: Chris Gorman
> > Sent: Tuesday, October 8, 2024 8:43 PM
> > To: Elmore Family
> > Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version
> >
> > Hi Jim,
> >
> > I'm guessing on this, but I have had experiences where I explicitly
> > disable a feature and it fixes a build failure.  So, rather than
> > letting cmake disable gr-uhd and uhd

Re: New install of GNU Radio executes old version

[Marcus Müller]

Hi Jim,

sorry for jumping in so late, I've been travelling.

I'm super confused as to *why* you're going through all this. And, yes, 
libuhd4.2.0 is *not* the name of library package.


I've tried skimming the thread, and quite honestly, it's a bit of a 
collection of conflicting approaches, and it feels like that's setting 
you up for a hard time.


Now, let's get this sorted as easily as possible: Just to verify, 
because, again, conflicting things,


1. what version of GNU Radio do you want to install

1.1 importantly: and why?

2. on which version of which OS (`cat /etc/os-release` might be the most 
authorative you can get)


My *suspicion* is that knowing the answer to 1.1 gives me the info I'd 
need to give you a "tried and tested" way forward. Building GNU Radio on 
a Raspberry Pi certainly is *not* a desirable detour, if it can *at all* 
be avoided.


Best,
Marcus

On 2024-10-11 3:15 PM, Elmore Family wrote:

Chris,

Here's the latest in this never-ending saga:

pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends 
libuhd4.2.0 libuhd-dev

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package libuhd4.2.0
E: Couldn't find any package by glob 'libuhd4.2.0'
E: Couldn't find any package by regex 'libuhd4.2.0'

Jim

-Original Message- From: Chris Gorman
Sent: Wednesday, October 9, 2024 9:05 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired of builds and want to install your
backup instead, I understand this has been a frustrating experience.
However, I do hope you get the source build to work.

Best regards,

Chris

On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:


Chris,

Here is the latest.

It did seem to complete the install but with the same 2 errors as 
before:


gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] 
Error

> 1
> make[1]: *** [CMakeFiles/Makefile2:7870:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2

Again the only gnuradio-companion file is the one in 
/gnuradio/grc/scripts

whose execution results in cannot import gnuradio.

Something must have been missed somewhere. I can't believe this can 
be this

difficult.

I have my backup of the system from before this began.

Jim


-Original Message-
From: Chris Gorman
Sent: Tuesday, October 8, 2024 8:43 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I'm guessing on this, but I have had experiences where I explicitly
disable a feature and it fixes a build failure.  So, rather than
letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
and disable them in the cmake call.  So I'd try ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
-DENABLE_UHD_RFNOC=OFF ../
make -j4
sudo make install

And wait for a while, especially on a Pi.  Hope this helps (and works).

Chris



Chris

On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:
>
> Chris,
>
> I have attached the build log. The following shows the install 
errors. I

> think it all began with the top line.
>
> Jim
>
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member > 
function

> ‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float,
> float,
> float, float)’:
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
> ‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean
> ‘GL_TEXTURE_3D’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 
GL_REPLACE);

>   |   ^~
>   |   GL_TEXTURE_3D

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris,

Here's the latest in this never-ending saga:

pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends libuhd4.2.0 
libuhd-dev

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package libuhd4.2.0
E: Couldn't find any package by glob 'libuhd4.2.0'
E: Couldn't find any package by regex 'libuhd4.2.0'

Jim

-Original Message- 
From: Chris Gorman

Sent: Wednesday, October 9, 2024 9:05 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired of builds and want to install your
backup instead, I understand this has been a frustrating experience.
However, I do hope you get the source build to work.

Best regards,

Chris

On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:


Chris,

Here is the latest.

It did seem to complete the install but with the same 2 errors as before:

gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] 
Error

> 1
> make[1]: *** [CMakeFiles/Makefile2:7870:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2

Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts
whose execution results in cannot import gnuradio.

Something must have been missed somewhere. I can't believe this can be 
this

difficult.

I have my backup of the system from before this began.

Jim


-Original Message-
From: Chris Gorman
Sent: Tuesday, October 8, 2024 8:43 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I'm guessing on this, but I have had experiences where I explicitly
disable a feature and it fixes a build failure.  So, rather than
letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
and disable them in the cmake call.  So I'd try ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
-DENABLE_UHD_RFNOC=OFF ../
make -j4
sudo make install

And wait for a while, especially on a Pi.  Hope this helps (and works).

Chris



Chris

On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:
>
> Chris,
>
> I have attached the build log. The following shows the install errors. I
> think it all began with the top line.
>
> Jim
>
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member 
> function

> ‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float,
> float,
> float, float)’:
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
> ‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean
> ‘GL_TEXTURE_3D’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   |   ^~
>   |   GL_TEXTURE_3D
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error:
> ‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean
> ‘GL_TEXTURE_MAX_LOD’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   |   ^~~
>   |   GL_TEXTURE_MAX_LOD
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error:
> ‘glTexEnvf’ was not declared in this scope
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   | ^
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error:
> ‘glBegin’ was not declared in this scope
>   167 | glBegin(GL_QUADS);
>   | ^~~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error:
> ‘glTexCoord2f’ was not declared in this scope
>   168 | glTexCoord2f(0.0f, 0.0f);
>   | ^~~~

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired of builds and want to install your
backup instead, I understand this has been a frustrating experience.
However, I do hope you get the source build to work.

Best regards,

Chris

On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:
>
> Chris,
>
> Here is the latest.
>
> It did seem to complete the install but with the same 2 errors as before:
>
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error
> > 1
> > make[1]: *** [CMakeFiles/Makefile2:7870:
> > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> > make: *** [Makefile:160: all] Error 2
>
> Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts
> whose execution results in cannot import gnuradio.
>
> Something must have been missed somewhere. I can't believe this can be this
> difficult.
>
> I have my backup of the system from before this began.
>
> Jim
>
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 8:43 PM
> To: Elmore Family
> Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> I'm guessing on this, but I have had experiences where I explicitly
> disable a feature and it fixes a build failure.  So, rather than
> letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
> and disable them in the cmake call.  So I'd try ...
>
> cd /home/pi/gnuradio
> rm -rf build
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
> -DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
> -DENABLE_UHD_RFNOC=OFF ../
> make -j4
> sudo make install
>
> And wait for a while, especially on a Pi.  Hope this helps (and works).
>
> Chris
>
>
>
> Chris
>
> On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:
> >
> > Chris,
> >
> > I have attached the build log. The following shows the install errors. I
> > think it all began with the top line.
> >
> > Jim
> >
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member function
> > ‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float,
> > float,
> > float, float)’:
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
> > ‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean
> > ‘GL_TEXTURE_3D’?
> >   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> >   |   ^~
> >   |   GL_TEXTURE_3D
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error:
> > ‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean
> > ‘GL_TEXTURE_MAX_LOD’?
> >   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> >   |   ^~~
> >   |   GL_TEXTURE_MAX_LOD
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error:
> > ‘glTexEnvf’ was not declared in this scope
> >   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> >   | ^
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error:
> > ‘glBegin’ was not declared in this scope
> >   167 | glBegin(GL_QUADS);
> >   | ^~~
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error:
> > ‘glTexCoord2f’ was not declared in this scope
> >   168 | glTexCoord2f(0.0f, 0.0f);
> >   | ^~~~
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:169:5: error:
> > ‘glVertex2f’ was not declared in this scope
> >   169 | glVertex2f(x0, y0);
> >   | ^~

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris,

Here is the latest.

It did seem to complete the install but with the same 2 errors as before:

gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error

1
make[1]: *** [CMakeFiles/Makefile2:7870:
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
make: *** [Makefile:160: all] Error 2


Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts 
whose execution results in cannot import gnuradio.


Something must have been missed somewhere. I can't believe this can be this 
difficult.


I have my backup of the system from before this began.

Jim


-Original Message- 
From: Chris Gorman

Sent: Tuesday, October 8, 2024 8:43 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

I'm guessing on this, but I have had experiences where I explicitly
disable a feature and it fixes a build failure.  So, rather than
letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
and disable them in the cmake call.  So I'd try ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
-DENABLE_UHD_RFNOC=OFF ../
make -j4
sudo make install

And wait for a while, especially on a Pi.  Hope this helps (and works).

Chris



Chris

On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:


Chris,

I have attached the build log. The following shows the install errors. I
think it all began with the top line.

Jim

/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member function
‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float, 
float,

float, float)’:
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean 
‘GL_TEXTURE_3D’?

  164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
  |   ^~
  |   GL_TEXTURE_3D
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error:
‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean
‘GL_TEXTURE_MAX_LOD’?
  164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
  |   ^~~
  |   GL_TEXTURE_MAX_LOD
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error:
‘glTexEnvf’ was not declared in this scope
  164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
  | ^
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error:
‘glBegin’ was not declared in this scope
  167 | glBegin(GL_QUADS);
  | ^~~
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error:
‘glTexCoord2f’ was not declared in this scope
  168 | glTexCoord2f(0.0f, 0.0f);
  | ^~~~
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:169:5: error:
‘glVertex2f’ was not declared in this scope
  169 | glVertex2f(x0, y0);
  | ^~
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:176:5: error: 
‘glEnd’

was not declared in this scope
  176 | glEnd();
  | ^
make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/build.make:1025:
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] 
Error

1
make[1]: *** [CMakeFiles/Makefile2:7870:
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
make: *** [Makefile:160: all] Error 2



-Original Message-
From: Chris Gorman
Sent: Tuesday, October 8, 2024 4:44 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

The --DPYTHON_EXECUATBLE=/usr with the extra switch is a typo on my
part, it should be -DPYTHON_EXECUTABLE=/usr .  Sorry.  You should get
an error from cmake with the second switch.

Can you send the error and log file and I'll have a look.

Hoping your nightmare ends soon. :)

Chris

On Tue, Oct 8, 2024 at 4:28 PM Elmore Family  wrote:
>
> Chris, et al,
>
> The install failed with 2 errors at qtgui.
>
> This is a nightmare.
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 8:08 AM
> To: Volker Schroer
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> Your call on what to do about this.  If it were me, I'd probably try
> what Volker is suggesting and use the prebuilt binary.  That said, if
> you want to try to get gnuradio built on your pi, I'll try to help.
> Unfortunately, I'm kind of confused about your results.  You should
> have more than just python-support and libad9361 if all the
> dependencies were installed.
>
> If you want to continue.  Run the following and attach the build.log
> fi

Re: New install of GNU Radio executes old version

[Elmore Family]

I am running Bullseye on the RPi. I believe that is the latest. Not sure of 
a date.


I'm not sure exactly what you are referring to about the package source 
list. All I can say is I followed the procedure InstallingGRFromSource on 
Raspberry Pi.


I have some new info for Chris that I will post shortly.

Jim

-Original Message- 
From: Volker Schroer

Sent: Wednesday, October 9, 2024 10:50 AM
To: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Are you sure that you updated your package source list ?
Seems to may that you have an older version.
Which version of the Raspberry Pi do you use ?
Your system should be ≥2021-10-30.

-- Volker

Chris, et al,

First, I tried an sudo apt-get install gnuradio  again. This time, of
course, there is no gnuradio installed since 3.9.4 was removed. It
installed 3.8.2 instead of 3.10.5 that I expected from Volker's link.

So I decided to send you the log file. I noticed something meanwhile
that I hadn't seen before. The cmake line from the original doc I used
for the instructions has " -DPYTHON_EXECUTABLE .." instead of " --
DPYTHON_EXECUTABLE ." that you used in one of your notes to me. Can
this make a difference?

I used the "--" in my cmake and the result was that the enabled
components are complete now except for gr-uhd and gr-uhd UHD 4.0 RFNoC.
Since I don't really use uhd I went ahead and started the install.

The install has been running for several hours now so I assume that it
will work.

Can the missing "-" have been the only problem or did something get
"fixed" by installing 3.8.2. BTW I immediately removed 3.8.2.

Jim

-Original Message- From: Chris Gorman
Sent: Tuesday, October 8, 2024 8:08 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:


https://wiki.gnuradio.org/index.php?title=InstallingGR
says:
For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
v3.10.5.1.

Why can't you use this?
> Chris,
>
> I did what you suggested.
>
> I then ran cmake as before. The result was the same except that the
> following were added to the gnuradio enabled components:
>
> python-support
> libad9361
>
> I'm considering giving up on this. I'm consuming a lot of your time and
> this is a personal project only. I really appreciate the effort you
have
> put into this.
>
> I wanted to upgrade in order to add a component to my project that
> requires 3.10.
>
> I wouldn't be upset if you want to pull the plug on this.
>
> Jim
>
> -Original Message- From: Chris Gorman
> Sent: Monday, October 7, 2024 9:22 AM
> To: Barry Jackson
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hello Jim,
>
> As Barry said you're missing lots of devel packages.  I assume based
> on your python version that you're using Raspbian Bullseye as your OS.
> If that's the case, there is a list of packages that you'll need to
> install to build gnuradio.  I would try the list of packages
> recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> .
>
> Basically,
>
> sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-
numpy > \
> python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-
pyqt5 > \
> liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> plugins \
> python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> python3-setuptools
>
> sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
>
> and
>
> sudo apt install libiio-dev libad9361-dev libspdlog-dev
> python3-packaging python3

Re: New install of GNU Radio executes old version

[Volker Schroer]

Are you sure that you updated your package source list ?
Seems to may that you have an older version.
Which version of the Raspberry Pi do you use ?
Your system should be ≥2021-10-30.

-- Volker

Chris, et al,

First, I tried an sudo apt-get install gnuradio  again. This time, of
course, there is no gnuradio installed since 3.9.4 was removed. It
installed 3.8.2 instead of 3.10.5 that I expected from Volker's link.

So I decided to send you the log file. I noticed something meanwhile
that I hadn't seen before. The cmake line from the original doc I used
for the instructions has " -DPYTHON_EXECUTABLE .." instead of " --
DPYTHON_EXECUTABLE ." that you used in one of your notes to me. Can
this make a difference?

I used the "--" in my cmake and the result was that the enabled
components are complete now except for gr-uhd and gr-uhd UHD 4.0 RFNoC.
Since I don't really use uhd I went ahead and started the install.

The install has been running for several hours now so I assume that it
will work.

Can the missing "-" have been the only problem or did something get
"fixed" by installing 3.8.2. BTW I immediately removed 3.8.2.

Jim

-Original Message- From: Chris Gorman
Sent: Tuesday, October 8, 2024 8:08 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:


https://wiki.gnuradio.org/index.php?title=InstallingGR
says:
For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
v3.10.5.1.

Why can't you use this?
> Chris,
>
> I did what you suggested.
>
> I then ran cmake as before. The result was the same except that the
> following were added to the gnuradio enabled components:
>
> python-support
> libad9361
>
> I'm considering giving up on this. I'm consuming a lot of your time and
> this is a personal project only. I really appreciate the effort you
have
> put into this.
>
> I wanted to upgrade in order to add a component to my project that
> requires 3.10.
>
> I wouldn't be upset if you want to pull the plug on this.
>
> Jim
>
> -Original Message- From: Chris Gorman
> Sent: Monday, October 7, 2024 9:22 AM
> To: Barry Jackson
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hello Jim,
>
> As Barry said you're missing lots of devel packages.  I assume based
> on your python version that you're using Raspbian Bullseye as your OS.
> If that's the case, there is a list of packages that you'll need to
> install to build gnuradio.  I would try the list of packages
> recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> .
>
> Basically,
>
> sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-
numpy > \
> python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-
pyqt5 > \
> liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> plugins \
> python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> python3-setuptools
>
> sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
>
> and
>
> sudo apt install libiio-dev libad9361-dev libspdlog-dev
> python3-packaging python3-jsonschema python3-qtpy
>
> Once you get those installed, you'll need to rebuild gnuradio.  You're
> looking for a list of gnuradio enabled components after running cmake
> similar to the one I sent you.
>
> Hope this helps.
>
> Chris
>
> On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson 
wrote:
>>
>> On 07/10/2024 01:11, Elmore Family wrote:
>> > Chris,
>> >
>> > Here is what I have after cmake:
>> >
>>

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

I'm guessing on this, but I have had experiences where I explicitly
disable a feature and it fixes a build failure.  So, rather than
letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
and disable them in the cmake call.  So I'd try ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
-DENABLE_UHD_RFNOC=OFF ../
make -j4
sudo make install

And wait for a while, especially on a Pi.  Hope this helps (and works).

Chris



Chris

On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:
>
> Chris,
>
> I have attached the build log. The following shows the install errors. I
> think it all began with the top line.
>
> Jim
>
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member function
> ‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float, float,
> float, float)’:
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
> ‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean ‘GL_TEXTURE_3D’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   |   ^~
>   |   GL_TEXTURE_3D
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error:
> ‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean
> ‘GL_TEXTURE_MAX_LOD’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   |   ^~~
>   |   GL_TEXTURE_MAX_LOD
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error:
> ‘glTexEnvf’ was not declared in this scope
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   | ^
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error:
> ‘glBegin’ was not declared in this scope
>   167 | glBegin(GL_QUADS);
>   | ^~~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error:
> ‘glTexCoord2f’ was not declared in this scope
>   168 | glTexCoord2f(0.0f, 0.0f);
>   | ^~~~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:169:5: error:
> ‘glVertex2f’ was not declared in this scope
>   169 | glVertex2f(x0, y0);
>   | ^~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:176:5: error: ‘glEnd’
> was not declared in this scope
>   176 | glEnd();
>   | ^
> make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/build.make:1025:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error
> 1
> make[1]: *** [CMakeFiles/Makefile2:7870:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2
>
>
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 4:44 PM
> To: Elmore Family
> Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> The --DPYTHON_EXECUATBLE=/usr with the extra switch is a typo on my
> part, it should be -DPYTHON_EXECUTABLE=/usr .  Sorry.  You should get
> an error from cmake with the second switch.
>
> Can you send the error and log file and I'll have a look.
>
> Hoping your nightmare ends soon. :)
>
> Chris
>
> On Tue, Oct 8, 2024 at 4:28 PM Elmore Family  wrote:
> >
> > Chris, et al,
> >
> > The install failed with 2 errors at qtgui.
> >
> > This is a nightmare.
> >
> > Jim
> >
> > -Original Message-
> > From: Chris Gorman
> > Sent: Tuesday, October 8, 2024 8:08 AM
> > To: Volker Schroer
> > Cc: discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version
> >
> > Hi Jim,
> >
> > Your call on what to do about this.  If it were me, I'd probably try
> > what Volker is suggesting and use the prebuilt binary.  That said, if
> > you want to try to get gnuradio built on your pi, I'll try to help.
> > Unfortunately, I'm kind of confused about your results.  You should
> > have more than just python-support and libad9361 if all the
> > dependencies were installed.
> >
> > If you want to continue.  Run the following and attach the build.log
> > file produced to your next email.  (It's the build command followed by
> > stdio and stderr redirection to a file.)
> >
> > cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
> > --DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1
> >
> > I'll take a look at the results and compare to w

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris,

I have attached the build log. The following shows the install errors. I 
think it all began with the top line.


Jim

/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member function 
‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float, float, 
float, float)’:
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error: 
‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean ‘GL_TEXTURE_3D’?

 164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
 |   ^~
 |   GL_TEXTURE_3D
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error: 
‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean 
‘GL_TEXTURE_MAX_LOD’?

 164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
 |   ^~~
 |   GL_TEXTURE_MAX_LOD
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error: 
‘glTexEnvf’ was not declared in this scope

 164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
 | ^
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error: 
‘glBegin’ was not declared in this scope

 167 | glBegin(GL_QUADS);
 | ^~~
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error: 
‘glTexCoord2f’ was not declared in this scope

 168 | glTexCoord2f(0.0f, 0.0f);
 | ^~~~
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:169:5: error: 
‘glVertex2f’ was not declared in this scope

 169 | glVertex2f(x0, y0);
 | ^~
/home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:176:5: error: ‘glEnd’ 
was not declared in this scope

 176 | glEnd();
 | ^
make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/build.make:1025: 
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error 
1
make[1]: *** [CMakeFiles/Makefile2:7870: 
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2

make: *** [Makefile:160: all] Error 2



-Original Message- 
From: Chris Gorman

Sent: Tuesday, October 8, 2024 4:44 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

The --DPYTHON_EXECUATBLE=/usr with the extra switch is a typo on my
part, it should be -DPYTHON_EXECUTABLE=/usr .  Sorry.  You should get
an error from cmake with the second switch.

Can you send the error and log file and I'll have a look.

Hoping your nightmare ends soon. :)

Chris

On Tue, Oct 8, 2024 at 4:28 PM Elmore Family  wrote:


Chris, et al,

The install failed with 2 errors at qtgui.

This is a nightmare.

Jim

-Original Message-
From: Chris Gorman
Sent: Tuesday, October 8, 2024 8:08 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:
>
> https://wiki.gnuradio.org/index.php?title=InstallingGR
> says:
> For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
> v3.10.5.1.
>
> Why can't you use this?
> > Chris,
> >
> > I did what you suggested.
> >
> > I then ran cmake as before. The result was the same except that the
> > following were added to the gnuradio enabled components:
> >
> > python-support
> > libad9361
> >
> > I'm considering giving up on this. I'm consuming a lot of your time 
> > and
> > this is a personal project only. I really appreciate the effort you 
> > have

> > put into this.
> >
> > I wanted to upgrade in order to add a component to my project that
> > requires 3.10.
> >
> > I wouldn't be upset if you want to pull the plug on this.
> >
> > Jim
> >
> > -Original Message- From: Chris Gorman
> > Sent: Monday, October 7, 2024 9:22 AM
> > To: Barry Jackson
> > Cc: discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

The --DPYTHON_EXECUATBLE=/usr with the extra switch is a typo on my
part, it should be -DPYTHON_EXECUTABLE=/usr .  Sorry.  You should get
an error from cmake with the second switch.

Can you send the error and log file and I'll have a look.

Hoping your nightmare ends soon. :)

Chris

On Tue, Oct 8, 2024 at 4:28 PM Elmore Family  wrote:
>
> Chris, et al,
>
> The install failed with 2 errors at qtgui.
>
> This is a nightmare.
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 8:08 AM
> To: Volker Schroer
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> Your call on what to do about this.  If it were me, I'd probably try
> what Volker is suggesting and use the prebuilt binary.  That said, if
> you want to try to get gnuradio built on your pi, I'll try to help.
> Unfortunately, I'm kind of confused about your results.  You should
> have more than just python-support and libad9361 if all the
> dependencies were installed.
>
> If you want to continue.  Run the following and attach the build.log
> file produced to your next email.  (It's the build command followed by
> stdio and stderr redirection to a file.)
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
> --DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1
>
> I'll take a look at the results and compare to what I'm getting on my
> x86 machine.
>
> All the best,
>
> Chris
>
> On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:
> >
> > https://wiki.gnuradio.org/index.php?title=InstallingGR
> > says:
> > For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
> > v3.10.5.1.
> >
> > Why can't you use this?
> > > Chris,
> > >
> > > I did what you suggested.
> > >
> > > I then ran cmake as before. The result was the same except that the
> > > following were added to the gnuradio enabled components:
> > >
> > > python-support
> > > libad9361
> > >
> > > I'm considering giving up on this. I'm consuming a lot of your time and
> > > this is a personal project only. I really appreciate the effort you have
> > > put into this.
> > >
> > > I wanted to upgrade in order to add a component to my project that
> > > requires 3.10.
> > >
> > > I wouldn't be upset if you want to pull the plug on this.
> > >
> > > Jim
> > >
> > > -Original Message- From: Chris Gorman
> > > Sent: Monday, October 7, 2024 9:22 AM
> > > To: Barry Jackson
> > > Cc: discuss-gnuradio@gnu.org
> > > Subject: Re: New install of GNU Radio executes old version
> > >
> > > Hello Jim,
> > >
> > > As Barry said you're missing lots of devel packages.  I assume based
> > > on your python version that you're using Raspbian Bullseye as your OS.
> > > If that's the case, there is a list of packages that you'll need to
> > > install to build gnuradio.  I would try the list of packages
> > > recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> > > .
> > >
> > > Basically,
> > >
> > > sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy
> > > \
> > > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> > > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5
> > > \
> > > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> > > plugins \
> > > python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> > > libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> > > python3-setuptools
> > >
> > > sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> > > libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
> > >
> > > and
> > >
> > > sudo apt install libiio-dev libad9361-dev libspdlog-dev
> > > python3-packaging python3-jsonschema python3-qtpy
> > >
> > > Once you get those installed, you'll need to rebuild gnuradio.  You're
> > > looking for a list of gnuradio enabled components after running cmake
> > > similar to the one I sent you.
> > >
> > > Hope this helps.
> > >
> > > Chris
> > >
> > > On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
> > >>
> > >

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris, et al,

The install failed with 2 errors at qtgui.

This is a nightmare.

Jim

-Original Message- 
From: Chris Gorman

Sent: Tuesday, October 8, 2024 8:08 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:


https://wiki.gnuradio.org/index.php?title=InstallingGR
says:
For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
v3.10.5.1.

Why can't you use this?
> Chris,
>
> I did what you suggested.
>
> I then ran cmake as before. The result was the same except that the
> following were added to the gnuradio enabled components:
>
> python-support
> libad9361
>
> I'm considering giving up on this. I'm consuming a lot of your time and
> this is a personal project only. I really appreciate the effort you have
> put into this.
>
> I wanted to upgrade in order to add a component to my project that
> requires 3.10.
>
> I wouldn't be upset if you want to pull the plug on this.
>
> Jim
>
> -Original Message----- From: Chris Gorman
> Sent: Monday, October 7, 2024 9:22 AM
> To: Barry Jackson
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hello Jim,
>
> As Barry said you're missing lots of devel packages.  I assume based
> on your python version that you're using Raspbian Bullseye as your OS.
> If that's the case, there is a list of packages that you'll need to
> install to build gnuradio.  I would try the list of packages
> recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> .
>
> Basically,
>
> sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy 
> \

> python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 
> \

> liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> plugins \
> python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> python3-setuptools
>
> sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
>
> and
>
> sudo apt install libiio-dev libad9361-dev libspdlog-dev
> python3-packaging python3-jsonschema python3-qtpy
>
> Once you get those installed, you'll need to rebuild gnuradio.  You're
> looking for a list of gnuradio enabled components after running cmake
> similar to the one I sent you.
>
> Hope this helps.
>
> Chris
>
> On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
>>
>> On 07/10/2024 01:11, Elmore Family wrote:
>> > Chris,
>> >
>> > Here is what I have after cmake:
>> >
>> > -- ##
>> > -- # Gnuradio enabled components
>> > -- ##
>> > --   * testing-support
>> > --   * post-install
>> > --   * doxygen
>> > --   * man-pages
>>
>> You are missing lots of -devel packages for all those disabled missing
>> components.
>>
>> As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
>> start at line 75:
>>
>> http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/
>> gnuradio.spec?revision=2102453&view=markup
>>
>>
>>
>>
>>
>>
>
>





--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris, et al,

First, I tried an sudo apt-get install gnuradio  again. This time, of 
course, there is no gnuradio installed since 3.9.4 was removed. It installed 
3.8.2 instead of 3.10.5 that I expected from Volker's link.


So I decided to send you the log file. I noticed something meanwhile that I 
hadn't seen before. The cmake line from the original doc I used for the 
instructions has " -DPYTHON_EXECUTABLE .." instead of 
" --DPYTHON_EXECUTABLE ." that you used in one of your notes to me. Can 
this make a difference?


I used the "--" in my cmake and the result was that the enabled components 
are complete now except for gr-uhd and gr-uhd UHD 4.0 RFNoC. Since I don't 
really use uhd I went ahead and started the install.


The install has been running for several hours now so I assume that it will 
work.


Can the missing "-" have been the only problem or did something get "fixed" 
by installing 3.8.2. BTW I immediately removed 3.8.2.


Jim

-Original Message- 
From: Chris Gorman

Sent: Tuesday, October 8, 2024 8:08 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:


https://wiki.gnuradio.org/index.php?title=InstallingGR
says:
For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
v3.10.5.1.

Why can't you use this?
> Chris,
>
> I did what you suggested.
>
> I then ran cmake as before. The result was the same except that the
> following were added to the gnuradio enabled components:
>
> python-support
> libad9361
>
> I'm considering giving up on this. I'm consuming a lot of your time and
> this is a personal project only. I really appreciate the effort you have
> put into this.
>
> I wanted to upgrade in order to add a component to my project that
> requires 3.10.
>
> I wouldn't be upset if you want to pull the plug on this.
>
> Jim
>
> -Original Message- From: Chris Gorman
> Sent: Monday, October 7, 2024 9:22 AM
> To: Barry Jackson
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hello Jim,
>
> As Barry said you're missing lots of devel packages.  I assume based
> on your python version that you're using Raspbian Bullseye as your OS.
> If that's the case, there is a list of packages that you'll need to
> install to build gnuradio.  I would try the list of packages
> recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> .
>
> Basically,
>
> sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy 
> \

> python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 
> \

> liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> plugins \
> python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> python3-setuptools
>
> sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
>
> and
>
> sudo apt install libiio-dev libad9361-dev libspdlog-dev
> python3-packaging python3-jsonschema python3-qtpy
>
> Once you get those installed, you'll need to rebuild gnuradio.  You're
> looking for a list of gnuradio enabled components after running cmake
> similar to the one I sent you.
>
> Hope this helps.
>
> Chris
>
> On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
>>
>> On 07/10/2024 01:11, Elmore Family wrote:
>> > Chris,
>> >
>> > Here is what I have after cmake:
>> >
>> > -- ##
>> > -- # Gnuradio enabled components
>> > -- ###

Re: New install of GNU Radio executes old version

[Ron Economos]

  
  
Just a guess, but probably need to clear the crud from the build
  directory.
cd gnuradio/build (or wherever you have the source)

sudo rm -rf *
*** Danger Will Robinson !!! *** Make absolutely sure you're in
  the correct directory before issuing that command.
Also, it's better to do three steps.
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
  --DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log
  2>&1


make -j4
sudo make install
That way, you don't have files with root ownership in the build
  directory.
Ron

On 10/8/24 05:08, Chris Gorman wrote:


  Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:

  

https://wiki.gnuradio.org/index.php?title=InstallingGR
says:
For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
v3.10.5.1.

Why can't you use this?


  Chris,

I did what you suggested.

I then ran cmake as before. The result was the same except that the
following were added to the gnuradio enabled components:

python-support
libad9361

I'm considering giving up on this. I'm consuming a lot of your time and
this is a personal project only. I really appreciate the effort you have
put into this.

I wanted to upgrade in order to add a component to my project that
requires 3.10.

I wouldn't be upset if you want to pull the plug on this.

Jim

-Original Message- From: Chris Gorman
Sent: Monday, October 7, 2024 9:22 AM
To: Barry Jackson
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hello Jim,

As Barry said you're missing lots of devel packages.  I assume based
on your python version that you're using Raspbian Bullseye as your OS.
If that's the case, there is a list of packages that you'll need to
install to build gnuradio.  I would try the list of packages
recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
.

Basically,

sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
plugins \
python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
python3-setuptools

sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph

and

sudo apt install libiio-dev libad9361-dev libspdlog-dev
python3-packaging python3-jsonschema python3-qtpy

Once you get those installed, you'll need to rebuild gnuradio.  You're
looking for a list of gnuradio enabled components after running cmake
similar to the one I sent you.

Hope this helps.

Chris

On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:

  

On 07/10/2024 01:11, Elmore Family wrote:


  Chris,

Here is what I have after cmake:

-- ##
-- # Gnuradio enabled components
-- ##
--   * testing-support
--   * post-install
--   * doxygen
--   * man-pages



You are missing lots of -devel packages for all those disabled missing
components.

As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
start at line 75:

http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/
gnuradio.spec?revision=2102453&view=markup







  
  






  
  


  

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:
>
> https://wiki.gnuradio.org/index.php?title=InstallingGR
> says:
> For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
> v3.10.5.1.
>
> Why can't you use this?
> > Chris,
> >
> > I did what you suggested.
> >
> > I then ran cmake as before. The result was the same except that the
> > following were added to the gnuradio enabled components:
> >
> > python-support
> > libad9361
> >
> > I'm considering giving up on this. I'm consuming a lot of your time and
> > this is a personal project only. I really appreciate the effort you have
> > put into this.
> >
> > I wanted to upgrade in order to add a component to my project that
> > requires 3.10.
> >
> > I wouldn't be upset if you want to pull the plug on this.
> >
> > Jim
> >
> > -Original Message- From: Chris Gorman
> > Sent: Monday, October 7, 2024 9:22 AM
> > To: Barry Jackson
> > Cc: discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version
> >
> > Hello Jim,
> >
> > As Barry said you're missing lots of devel packages.  I assume based
> > on your python version that you're using Raspbian Bullseye as your OS.
> > If that's the case, there is a list of packages that you'll need to
> > install to build gnuradio.  I would try the list of packages
> > recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> > .
> >
> > Basically,
> >
> > sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
> > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
> > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> > plugins \
> > python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> > libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> > python3-setuptools
> >
> > sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> > libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
> >
> > and
> >
> > sudo apt install libiio-dev libad9361-dev libspdlog-dev
> > python3-packaging python3-jsonschema python3-qtpy
> >
> > Once you get those installed, you'll need to rebuild gnuradio.  You're
> > looking for a list of gnuradio enabled components after running cmake
> > similar to the one I sent you.
> >
> > Hope this helps.
> >
> > Chris
> >
> > On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
> >>
> >> On 07/10/2024 01:11, Elmore Family wrote:
> >> > Chris,
> >> >
> >> > Here is what I have after cmake:
> >> >
> >> > -- ##
> >> > -- # Gnuradio enabled components
> >> > -- ##
> >> > --   * testing-support
> >> > --   * post-install
> >> > --   * doxygen
> >> > --   * man-pages
> >>
> >> You are missing lots of -devel packages for all those disabled missing
> >> components.
> >>
> >> As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
> >> start at line 75:
> >>
> >> http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/
> >> gnuradio.spec?revision=2102453&view=markup
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>

Re: New install of GNU Radio executes old version

[Volker Schroer]

https://wiki.gnuradio.org/index.php?title=InstallingGR
says:
For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
v3.10.5.1.

Why can't you use this?

Chris,

I did what you suggested.

I then ran cmake as before. The result was the same except that the
following were added to the gnuradio enabled components:

python-support
libad9361

I'm considering giving up on this. I'm consuming a lot of your time and
this is a personal project only. I really appreciate the effort you have
put into this.

I wanted to upgrade in order to add a component to my project that
requires 3.10.

I wouldn't be upset if you want to pull the plug on this.

Jim

-Original Message- From: Chris Gorman
Sent: Monday, October 7, 2024 9:22 AM
To: Barry Jackson
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hello Jim,

As Barry said you're missing lots of devel packages.  I assume based
on your python version that you're using Raspbian Bullseye as your OS.
If that's the case, there is a list of packages that you'll need to
install to build gnuradio.  I would try the list of packages
recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
.

Basically,

sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
plugins \
python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
python3-setuptools

sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph

and

sudo apt install libiio-dev libad9361-dev libspdlog-dev
python3-packaging python3-jsonschema python3-qtpy

Once you get those installed, you'll need to rebuild gnuradio.  You're
looking for a list of gnuradio enabled components after running cmake
similar to the one I sent you.

Hope this helps.

Chris

On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:


On 07/10/2024 01:11, Elmore Family wrote:
> Chris,
>
> Here is what I have after cmake:
>
> -- ##
> -- # Gnuradio enabled components
> -- ##
> --   * testing-support
> --   * post-install
> --   * doxygen
> --   * man-pages

You are missing lots of -devel packages for all those disabled missing
components.

As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
start at line 75:

http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/
gnuradio.spec?revision=2102453&view=markup

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris,

I did what you suggested.

I then ran cmake as before. The result was the same except that the 
following were added to the gnuradio enabled components:


python-support
libad9361

I'm considering giving up on this. I'm consuming a lot of your time and this 
is a personal project only. I really appreciate the effort you have put into 
this.


I wanted to upgrade in order to add a component to my project that requires 
3.10.


I wouldn't be upset if you want to pull the plug on this.

Jim

-Original Message- 
From: Chris Gorman

Sent: Monday, October 7, 2024 9:22 AM
To: Barry Jackson
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hello Jim,

As Barry said you're missing lots of devel packages.  I assume based
on your python version that you're using Raspbian Bullseye as your OS.
If that's the case, there is a list of packages that you'll need to
install to build gnuradio.  I would try the list of packages
recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
.

Basically,

sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins 
\

python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
python3-setuptools

sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph

and

sudo apt install libiio-dev libad9361-dev libspdlog-dev
python3-packaging python3-jsonschema python3-qtpy

Once you get those installed, you'll need to rebuild gnuradio.  You're
looking for a list of gnuradio enabled components after running cmake
similar to the one I sent you.

Hope this helps.

Chris

On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:


On 07/10/2024 01:11, Elmore Family wrote:
> Chris,
>
> Here is what I have after cmake:
>
> -- ##
> -- # Gnuradio enabled components
> -- ##
> --   * testing-support
> --   * post-install
> --   * doxygen
> --   * man-pages

You are missing lots of -devel packages for all those disabled missing
components.

As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
start at line 75:

http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/gnuradio.spec?revision=2102453&view=markup









--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hello Jim,

As Barry said you're missing lots of devel packages.  I assume based
on your python version that you're using Raspbian Bullseye as your OS.
If that's the case, there is a list of packages that you'll need to
install to build gnuradio.  I would try the list of packages
recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
.

Basically,

sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \
python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
python3-setuptools

sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph

and

sudo apt install libiio-dev libad9361-dev libspdlog-dev
python3-packaging python3-jsonschema python3-qtpy

Once you get those installed, you'll need to rebuild gnuradio.  You're
looking for a list of gnuradio enabled components after running cmake
similar to the one I sent you.

Hope this helps.

Chris

On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
>
> On 07/10/2024 01:11, Elmore Family wrote:
> > Chris,
> >
> > Here is what I have after cmake:
> >
> > -- ##
> > -- # Gnuradio enabled components
> > -- ##
> > --   * testing-support
> > --   * post-install
> > --   * doxygen
> > --   * man-pages
>
> You are missing lots of -devel packages for all those disabled missing
> components.
>
> As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
> start at line 75:
>
> http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/gnuradio.spec?revision=2102453&view=markup
>
>
>
>
>
>

Re: New install of GNU Radio executes old version

[Barry Jackson]

On 07/10/2024 01:11, Elmore Family wrote:

Chris,

Here is what I have after cmake:

-- ##
-- # Gnuradio enabled components
-- ##
--   * testing-support
--   * post-install
--   * doxygen
--   * man-pages


You are missing lots of -devel packages for all those disabled missing 
components.


As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they 
start at line 75:


http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/gnuradio.spec?revision=2102453&view=markup

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris,

Here is what I have after cmake:

-- ##
-- # Gnuradio enabled components
-- ##
--   * testing-support
--   * post-install
--   * doxygen
--   * man-pages
--
-- ##
-- # Gnuradio disabled components
-- ##
--   * python-support
--   * gnuradio-runtime
--   * common-precompiled-headers
--   * gr-ctrlport
--   * gr-blocks
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-audio
--   * gr-channels
--   * gr-pdu
--   * gr-iio
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-uhd UHD 4.0 RFNoC
--   * gr-video-sdl
--   * gr-vocoder
--   * gr-wavelet
--   * gr-zeromq
--   * gr-network
--   * gr-soapy
--
-- Using install prefix: /usr

Jim

-Original Message- 
From: Chris Gorman

Sent: Sunday, October 6, 2024 3:35 PM
To: Elmore Family
Cc: Volker Schroer ; discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim,

Firstly, let me tell you that I haven't ever tried installing on a Pi,
so I may be missing some nuances.  Apologies if that's the case.

After step 5 gnuradio-companion should be in /usr/bin based on the
steps you took.  If gnuradio-companion is not in /usr/bin I suspect
that something was missing from your build.  Given your cmake command,
you will not need to set LD_LIBRARY_PATH and PYTHONPATH.   That's only
necessary if you didn't set -DCMAKE_INSTALL_PREFIX=/usr .

You should get something like the following at the end of your cmake 
command.


-SNIP-
-- ##
-- # Gnuradio enabled components
-- ##
--   * testing-support
--   * python-support
--   * post-install
--   * doxygen
--   * man-pages
--   * gnuradio-runtime
--   * common-precompiled-headers
--   * gr-ctrlport
--   * * thrift
--   * gnuradio-companion
--   * JSON/YAML config blocks
--   * gr-blocks
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-audio
--   * * alsa
--   * * oss
--   * * jack
--   * * portaudio
--   * gr-channels
--   * gr-pdu
--   * gr-iio
--   * * libad9361
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-uhd UHD 4.0 RFNoC
--   * gr-utils
--   * gr_modtool
--   * gr_blocktool
--   * gr-video-sdl
--   * gr-vocoder
--   * * codec2
--   * * freedv
--   * * gsm
--   * gr-wavelet
--   * gr-zeromq
--   * gr-network
--   * gr-soapy
--
-- ##
-- # Gnuradio disabled components
-- ##
--
-- Using install prefix: /usr
-SNIP-

Ensure gnuradio-companion is on the list.  Also note if you have any
components in the disabled components list.

Once make install has completed you should have, roughly speaking, the
following directories / files.

/etc/gnuradio - all the system configuration files
/usr/bin/gnuradio-companion
/usr/lib/libgnuradio* - all the c++ libraries
/usr/lib/python3.9.2/site-packages/gnuradio - all the python components
/usr/share/gnuradio/grc/blocks - all the blocks files
/usr/include/gnuradio - c++ header files

Cannot import gnuradio means python can't find the gnuradio directory
and it's contents in the "python components".  This is critical as
gnuradio-companion is all python driven.  If you have all these
directories, perhaps a review of
https://wiki.gnuradio.org/index.php?title=LinuxInstall#Installing_Volk
to see if you missed a step.  (maybe running sudo ldconfig or
something like that.)

Anyway hoping you get this working.  Let me know if you're missing anything.

Take care,

Chris

On Sun, Oct 6, 2024 at 1:50 PM Elmore Family  wrote:


Chris,

I have tried what you suggested but I am still having issues. I suspect 
that

I am misunderstanding something.

1. I removed 3.9.4
2. I performed an export of LD-LIBRARY_PATH as you specified
3. I performed an export of PYTHONPATH with xx = .9.2
4. I performed
cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release 
--DPYTHON_EXECUTABLE=/usr/bin/python3
../
5. sudo make install

Everything seemed to execute with no errors.

I still find gnuradio-companion only in the /gnuradio/grc/scripts 
directory.


When I execute it from the command line, a box pops up stating "Cannot
import gnuradio" and asking if PYTHONPATH and LD_LIBRARY_PATH are set
correctly.

What is wrong now?

Jim

-Original Message-
From: Chris Gorman
Sent: Saturday, October 5, 2024 11:27 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim and Volker,

I just tried what Jim is doing on my x86 system and got the same
result.  Trying to run from the source tree runs the installed
gnuradio (i

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

Firstly, let me tell you that I haven't ever tried installing on a Pi,
so I may be missing some nuances.  Apologies if that's the case.

After step 5 gnuradio-companion should be in /usr/bin based on the
steps you took.  If gnuradio-companion is not in /usr/bin I suspect
that something was missing from your build.  Given your cmake command,
you will not need to set LD_LIBRARY_PATH and PYTHONPATH.   That's only
necessary if you didn't set -DCMAKE_INSTALL_PREFIX=/usr .

You should get something like the following at the end of your cmake command.

-SNIP-
-- ##
-- # Gnuradio enabled components
-- ##
--   * testing-support
--   * python-support
--   * post-install
--   * doxygen
--   * man-pages
--   * gnuradio-runtime
--   * common-precompiled-headers
--   * gr-ctrlport
--   * * thrift
--   * gnuradio-companion
--   * JSON/YAML config blocks
--   * gr-blocks
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-audio
--   * * alsa
--   * * oss
--   * * jack
--   * * portaudio
--   * gr-channels
--   * gr-pdu
--   * gr-iio
--   * * libad9361
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-uhd UHD 4.0 RFNoC
--   * gr-utils
--   * gr_modtool
--   * gr_blocktool
--   * gr-video-sdl
--   * gr-vocoder
--   * * codec2
--   * * freedv
--   * * gsm
--   * gr-wavelet
--   * gr-zeromq
--   * gr-network
--   * gr-soapy
-- 
-- ##
-- # Gnuradio disabled components
-- ##
--
-- Using install prefix: /usr
-SNIP-

Ensure gnuradio-companion is on the list.  Also note if you have any
components in the disabled components list.

Once make install has completed you should have, roughly speaking, the
following directories / files.

/etc/gnuradio - all the system configuration files
/usr/bin/gnuradio-companion
/usr/lib/libgnuradio* - all the c++ libraries
/usr/lib/python3.9.2/site-packages/gnuradio - all the python components
/usr/share/gnuradio/grc/blocks - all the blocks files
/usr/include/gnuradio - c++ header files

Cannot import gnuradio means python can't find the gnuradio directory
and it's contents in the "python components".  This is critical as
gnuradio-companion is all python driven.  If you have all these
directories, perhaps a review of
https://wiki.gnuradio.org/index.php?title=LinuxInstall#Installing_Volk
to see if you missed a step.  (maybe running sudo ldconfig or
something like that.)

Anyway hoping you get this working.  Let me know if you're missing anything.

Take care,

Chris

On Sun, Oct 6, 2024 at 1:50 PM Elmore Family  wrote:
>
> Chris,
>
> I have tried what you suggested but I am still having issues. I suspect that
> I am misunderstanding something.
>
> 1. I removed 3.9.4
> 2. I performed an export of LD-LIBRARY_PATH as you specified
> 3. I performed an export of PYTHONPATH with xx = .9.2
> 4. I performed
> cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release 
> --DPYTHON_EXECUTABLE=/usr/bin/python3
> ../
> 5. sudo make install
>
> Everything seemed to execute with no errors.
>
> I still find gnuradio-companion only in the /gnuradio/grc/scripts directory.
>
> When I execute it from the command line, a box pops up stating "Cannot
> import gnuradio" and asking if PYTHONPATH and LD_LIBRARY_PATH are set
> correctly.
>
> What is wrong now?
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Saturday, October 5, 2024 11:27 AM
> To: Volker Schroer
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim and Volker,
>
> I just tried what Jim is doing on my x86 system and got the same
> result.  Trying to run from the source tree runs the installed
> gnuradio (in my case 3.10.11).  My recommendations to Jim is to
>
> 1) `apt remove gnuradio` to remove gnuradio 3.9.4
> 2) install the gnuradio from his source tree
>`cd gnuradio/build/`
>`sudo make install`
> 3) then run gnuradio-companion from the command line.
>
> (Commands to run are in between ``).
>
> Some caveats from my installation experience unless
> -DCMAKE_INSTALL_PREFIX=/usr was set during the cmake configure, you
> will have to set both a LD_LIBRARY_PATH and PYTHONPATH to point to the
> directories in the install prefix.
>
> eg. with no -DCMAKE_INSTALL_PREFIX set, /usr/local becomes the default
> install prefix
> so Jim will need to export LD_LIBRARY_PATH=/usr/local/lib and export
> PYTHONPATH=/usr/local/lib/python3.xx/site-pacakges, where xx is the
> version of python on the system.
>
> Hope this helps,
>
> Good luck.
>
> Chris
>
> On Sat,

Re: New install of GNU Radio executes old version

[Elmore Family]

Chris,

I have tried what you suggested but I am still having issues. I suspect that 
I am misunderstanding something.


1. I removed 3.9.4
2. I performed an export of LD-LIBRARY_PATH as you specified
3. I performed an export of PYTHONPATH with xx = .9.2
4. I performed 
cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release --DPYTHON_EXECUTABLE=/usr/bin/python3 
../

5. sudo make install

Everything seemed to execute with no errors.

I still find gnuradio-companion only in the /gnuradio/grc/scripts directory.

When I execute it from the command line, a box pops up stating "Cannot 
import gnuradio" and asking if PYTHONPATH and LD_LIBRARY_PATH are set 
correctly.


What is wrong now?

Jim

-Original Message- 
From: Chris Gorman

Sent: Saturday, October 5, 2024 11:27 AM
To: Volker Schroer
Cc: discuss-gnuradio@gnu.org
Subject: Re: New install of GNU Radio executes old version

Hi Jim and Volker,

I just tried what Jim is doing on my x86 system and got the same
result.  Trying to run from the source tree runs the installed
gnuradio (in my case 3.10.11).  My recommendations to Jim is to

1) `apt remove gnuradio` to remove gnuradio 3.9.4
2) install the gnuradio from his source tree
  `cd gnuradio/build/`
  `sudo make install`
3) then run gnuradio-companion from the command line.

(Commands to run are in between ``).

Some caveats from my installation experience unless
-DCMAKE_INSTALL_PREFIX=/usr was set during the cmake configure, you
will have to set both a LD_LIBRARY_PATH and PYTHONPATH to point to the
directories in the install prefix.

eg. with no -DCMAKE_INSTALL_PREFIX set, /usr/local becomes the default
install prefix
so Jim will need to export LD_LIBRARY_PATH=/usr/local/lib and export
PYTHONPATH=/usr/local/lib/python3.xx/site-pacakges, where xx is the
version of python on the system.

Hope this helps,

Good luck.

Chris

On Sat, Oct 5, 2024 at 6:45 AM Volker Schroer  wrote:


Hi Jim!
How did you install gnuradio 3.10.11 ? If you had 3.10.11 installed, you
did not had to run it from the source directory. So you did not install
3.10.11. I suspect you downloaded the source code from somewhere, but
missed to build and install it.

How did you get 3.9.4 ?

I  recommend to read the gnuradio installation docs.

https://wiki.gnuradio.org/index.php?title=InstallingGR

-- Volker






--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim and Volker,

I just tried what Jim is doing on my x86 system and got the same
result.  Trying to run from the source tree runs the installed
gnuradio (in my case 3.10.11).  My recommendations to Jim is to

1) `apt remove gnuradio` to remove gnuradio 3.9.4
2) install the gnuradio from his source tree
   `cd gnuradio/build/`
   `sudo make install`
3) then run gnuradio-companion from the command line.

(Commands to run are in between ``).

Some caveats from my installation experience unless
-DCMAKE_INSTALL_PREFIX=/usr was set during the cmake configure, you
will have to set both a LD_LIBRARY_PATH and PYTHONPATH to point to the
directories in the install prefix.

eg. with no -DCMAKE_INSTALL_PREFIX set, /usr/local becomes the default
install prefix
so Jim will need to export LD_LIBRARY_PATH=/usr/local/lib and export
PYTHONPATH=/usr/local/lib/python3.xx/site-pacakges, where xx is the
version of python on the system.

Hope this helps,

Good luck.

Chris

On Sat, Oct 5, 2024 at 6:45 AM Volker Schroer  wrote:
>
> Hi Jim!
> How did you install gnuradio 3.10.11 ? If you had 3.10.11 installed, you
> did not had to run it from the source directory. So you did not install
> 3.10.11. I suspect you downloaded the source code from somewhere, but
> missed to build and install it.
>
> How did you get 3.9.4 ?
>
> I  recommend to read the gnuradio installation docs.
>
> https://wiki.gnuradio.org/index.php?title=InstallingGR
>
> -- Volker
>
>
>

Re: New install of GNU Radio executes old version

[Volker Schroer]

Hi Jim!
How did you install gnuradio 3.10.11 ? If you had 3.10.11 installed, you
did not had to run it from the source directory. So you did not install
3.10.11. I suspect you downloaded the source code from somewhere, but
missed to build and install it.

How did you get 3.9.4 ?

I  recommend to read the gnuradio installation docs.

https://wiki.gnuradio.org/index.php?title=InstallingGR

-- Volker

RE: Reading File Sink output in Python

[dave_abel]

Thank you.

Sorry, kindergarten error.  I should have read the numpy doc more carefully.

> 
> On ,Fri Oct 04 2024 18:02:46 GMT+1000 (Australian Eastern Standard Time),
> Philipp Niedermayer  wrote:
> 
> -- Original Message --
> 
> 
> 
> > Float32 has been deprecated (Numpy 1.20, 1.24).
> 
> 
> 
> 
> That is not true. What they deprecated and removed is np.float, you must
> now explicitly use float32 (aka single) or float64 (aka double). And there
> are many more float precision available.
> 
> 
> 
> 
> real_signal = np. fromfile ( fname , dtype = "float32 " )
> 
> 
> 
> 
> iq_signal = np. fromfile ( fname , dtype = "complex64 " )
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Von:* dave_a...@bigpond.com
> 
> 
> 
> 
> *Gesendet:* Donnerstag, 3. Oktober 2024 um 8:19 AM MESZ
> 
> 
> 
> 
> *An:* discuss-gnuradio@gnu.org
> 
> 
> 
> 
> *Betreff:* Reading File Sink output in Python
> 
> 
> 
> 
>> I have been trying to read, with Python/Numpy, a file created by a File
>> Sink. That file is for a stream of floats.
>> 
>> Numpy is 1.21.5. GNU Radio is 3.10.11.
>> 
>> The File Sink wiki page, in the hints on reading from Python, gives
>> float32 as a data type. Float32 has been deprecated (Numpy 1.20, 1.24). The
>> default (only?) float data type in Numpy now is float64.  Is this a known
>> issue, please?
>> 
>> The C code on the wiki page works fine.
>> 
>> Perhaps there's another simple workaround?
>> 
>> 
>> 
>> Dave Abel
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
>

RE: Reading File Sink output in Python

[Philipp Niedermayer]

> Float32 has been deprecated (Numpy1.20, 1.24).

That is not true. What they deprecated and removed is np.float, you must 
now explicitly use float32 (aka single) or float64 (aka double). And 
there are many more float precision available.


|real_signal = np.fromfile(fname, dtype="float32")
|

|iq_signal = np.fromfile(fname, dtype="complex64")
|

|
|


*Von:* dave_a...@bigpond.com

*Gesendet:* Donnerstag, 3. Oktober 2024 um 8:19 AM MESZ

*An:* discuss-gnuradio@gnu.org

*Betreff:* Reading File Sink output in Python


I have been trying to read, with Python/Numpy, a file created by a 
File Sink. That file is for a stream of floats.

Numpy is 1.21.5.GNU Radio is 3.10.11.
The File Sink wiki page, in the hints on reading from Python, gives 
float32 as a data type.Float32 has been deprecated (Numpy1.20, 
1.24).The default (only?) float data type in Numpy now is float64.  Is 
this a known issue, please?

The C code on the wiki page works fine.
Perhaps there's another simple workaround?

Dave Abel





smime.p7s
Description: Kryptografische S/MIME-Signatur

Re: unable to execute new installation

[Elmore Family]

The script now executes from the terminal but still not from the GUI.

However, the version that executes is the old 3.9.4.0 not the 3.10.11 that I 
installed. Following is the result of execution from the terminal:


pi@raspberrypi:~ $ cd gnuradio/grc/scripts
pi@raspberrypi:~/gnuradio/grc/scripts $ python3 gnuradio-companion
Running from source tree
Could not retrieve GNU Radio configuration directory from GNU Radio. Trying 
defaults.
Could not retrieve GNU Radio persistent state directory from GNU Radio. 
Trying defaults.
Using legacy state path '/home/pi/.grc_gnuradio'. Please consider moving 
state files to '/home/pi/.local/state/gnuradio'.

No section: 'main'
No section: 'main'
No section: 'main'
Warning: vocoder_codec2_decode_ps - option_attributes are for enums 
only, ignoring
Warning: vocoder_codec2_encode_sp - option_attributes are for enums 
only, ignoring

<<< Welcome to GNU Radio Companion 3.9.4.0 >>>

Block paths:
   /home/pi/.grc_gnuradio
   /usr/local/share/gnuradio/grc/blocks
   /usr/share/gnuradio/grc/blocks

Loading: "/home/pi/Softrock/Softrock_FT8.grc"

Done


Loading: "/home/pi/Softrock/softrock_QT.grc"

Done


Loading: "/home/pi/Softrock/Receive.grc"

Done


Loading: "/home/pi/Softrock/FT8_Transmit.grc"

Done


Loading: "/home/pi/Softrock/Transmit_CESSB.grc"

Done


I don't understand what is happening.
How can I execute the new version and also how can I get the GUI to execute 
it at all?
Have I somehow installed it in the wrong place? I have never before 
installed from source - I always installed using apt-get install.

Does the old version need to be uninstalled? If so, how do I do that?

I used the instructions "InstallingGRFromSource on Raspberry Pi" from the 
Wiki.


Jim

-Original Message- 
From: Volker Schroer

Sent: Monday, September 30, 2024 4:35 PM
To: Elmore Family
Cc: Chris Gorman ; GNURadio Discussion List
Subject: Re: unable to execute new installation

There is a typo in #7513, the correct fix is #7514


Am 30.09.2024 um 18:28 schrieb Elmore Family :

Thanks for the info Chris.

Now my result is as follows: (Note: the only change is in the last 2 lines 
of the message)


Running from source tree
Could not retrieve GNU Radio configuration directory from GNU Radio. 
Trying defaults.
Could not retrieve GNU Radio persistent state directory from GNU Radio. 
Trying defaults.

Traceback (most recent call last):
File "/home/pi/gnuradio/grc/main.py", line 229, in get_state_directory
  from gnuradio.gr import paths
ImportError: cannot import name 'paths' from 'gnuradio.gr' 
(/usr/lib/python3/dist-packages/gnuradio/gr/__init__.py)


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 103, in 


  run_main()
File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 96, in 
run_main

  sys.exit(main())
File "/home/pi/gnuradio/grc/main.py", line 297, in main
  log_file = os.path.join(get_state_directory(), "grc.log")
File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
  f"files to '{xdgand}'.")
NameError: name 'xdgand' is not defined

Jim

-Original Message- From: Chris Gorman
Sent: Monday, September 30, 2024 9:07 AM
To: Elmore Family
Cc: GNURadio Discussion List ; Volker Schroer
Subject: Re: unable to execute new installation

Hello Jim,

Volker is referring to a github pull request (bug fix).  You can find
his bug report number 7513 at
https://github.com/gnuradio/gnuradio/pull/7513 .

Best regards,

Chris




On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:

What does 7513 refer to? How do I find it?

-Original Message-
From: Volker Schroer
Sent: Saturday, September 28, 2024 11:22 AM
To: GNURadio Discussion List
Subject: Re: unable to execute new installation

Please stay on the list.


First:

 File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
f"files to '{newpath}'.")
UnboundLocalError: local variable 'newpath' referenced before assignment

is definitely a bug in the python code.

I proposed a fix. See #7513 on github.

This pr may not fix the reason of your problems, but you should get a
better error message.

What is the result of

gnuradio-config-info --prefix

Why do you start gnuradio-companion from the source tree and not from
the install directory?


Am 28.09.24 um 15:06 schrieb Elmore’s:
> I did perform the install command and I thought it worked. You also say
> this is a bug. Thus I am confused.
> Sent from my iPhone



--
This email has been checked for viruses by AVG antivirus software.
www.avg.com




--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: unable to execute new installation

[Volker Schroer]

There is a typo in #7513, the correct fix is #7514

> Am 30.09.2024 um 18:28 schrieb Elmore Family :
> 
> Thanks for the info Chris.
> 
> Now my result is as follows: (Note: the only change is in the last 2 lines of 
> the message)
> 
> Running from source tree
> Could not retrieve GNU Radio configuration directory from GNU Radio. Trying 
> defaults.
> Could not retrieve GNU Radio persistent state directory from GNU Radio. 
> Trying defaults.
> Traceback (most recent call last):
> File "/home/pi/gnuradio/grc/main.py", line 229, in get_state_directory
>   from gnuradio.gr import paths
> ImportError: cannot import name 'paths' from 'gnuradio.gr' 
> (/usr/lib/python3/dist-packages/gnuradio/gr/__init__.py)
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
> File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 103, in 
>   run_main()
> File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 96, in run_main
>   sys.exit(main())
> File "/home/pi/gnuradio/grc/main.py", line 297, in main
>   log_file = os.path.join(get_state_directory(), "grc.log")
> File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>   f"files to '{xdgand}'.")
> NameError: name 'xdgand' is not defined
> 
> Jim
> 
> -Original Message- From: Chris Gorman
> Sent: Monday, September 30, 2024 9:07 AM
> To: Elmore Family
> Cc: GNURadio Discussion List ; Volker Schroer
> Subject: Re: unable to execute new installation
> 
> Hello Jim,
> 
> Volker is referring to a github pull request (bug fix).  You can find
> his bug report number 7513 at
> https://github.com/gnuradio/gnuradio/pull/7513 .
> 
> Best regards,
> 
> Chris
> 
> 
> 
>> On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:
>> 
>> What does 7513 refer to? How do I find it?
>> 
>> -Original Message-
>> From: Volker Schroer
>> Sent: Saturday, September 28, 2024 11:22 AM
>> To: GNURadio Discussion List
>> Subject: Re: unable to execute new installation
>> 
>> Please stay on the list.
>> 
>> 
>> First:
>> 
>>  File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>> f"files to '{newpath}'.")
>> UnboundLocalError: local variable 'newpath' referenced before assignment
>> 
>> is definitely a bug in the python code.
>> 
>> I proposed a fix. See #7513 on github.
>> 
>> This pr may not fix the reason of your problems, but you should get a
>> better error message.
>> 
>> What is the result of
>> 
>> gnuradio-config-info --prefix
>> 
>> Why do you start gnuradio-companion from the source tree and not from
>> the install directory?
>> 
>> 
>> Am 28.09.24 um 15:06 schrieb Elmore’s:
>> > I did perform the install command and I thought it worked. You also say
>> > this is a bug. Thus I am confused.
>> > Sent from my iPhone
>> 
>> 
>> 
>> --
>> This email has been checked for viruses by AVG antivirus software.
>> www.avg.com
>> 
>> 
> 
> --
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Marcus D Leech]

   On Mon, Sep 30, 2024
  at 10:48 AM Ceren Karaköse <ceren.karak...@outlook.com>
  wrote:


  
Hi all,


This is my point of view on the
  issue:
15M sample rate is equal to 960M
  bits/sec data transmission from your USB port to
  your SDR device. 960M = 15M samples * 32
  bits/sample (lime sdr sink/source working with 32
  bit float) * 2 (because Inphase and Quadrature
  assuming you're working with complex signals). 


If you are using usb 2.0 port, which
  has 480 Mbits/sec data rate, you cannot achieve
  the desired data rate. Hence the underruns. On the
  otherhand, if you're using USB 3.0 port on your
  device, it should be *theoretically* able to
  achieve that rate as its data transfer speed is
  5Gbps. However, mind you that these values are
  *the maximum* values that can ever be achieved.
  I'm not the expert on USB communication but from
  experience never ever was I able to achieve that
  theoretical data rate from USB connections. This
  is perhaps related to computer architecture and
  how the bus is shared. For example your usb mouse
  and keyboard *may* be sharing some of the
  bandwidth allocated for USB connections in the
  computer and hence "stealing" from the theoretical
  maximum data transfer rate.


My suggestion is that if you ever
  plan to go above 10M samples/sec, use an
  ethernet-connected SDR.


Get  Outlook
for Android

From:
discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org
outlook@gnu.org>
on behalf of Ron Economos <w...@comcast.net>
Sent: Monday, September 30, 2024 5:27:19
PM
To: discuss-gnuradio@gnu.org
<discuss-gnuradio@gnu.org>
Subject: Re: dvbt2 transmitter can not be
real-time with LimeSDR
   


  Sorry, but UHD is a big CPU hog for
transmitting (at least with the B2X0 
series of devices).

Ron

On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport
parameters for UHD USB devices here:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it
kind of has to be.  It supports 
> many different hardware devices, going
back to the USRP1
>   originally sold in 2004.  But having
said that the "sample moving" 
> pathways in the code are quite
efficient.  One shouldn't
>   confuse the size of the library with
the efficiency of the critical 
> pathways.
>
>

  

  

  

  

  

  

Re: unable to execute new installation

[Elmore Family]

Thanks for the info Chris.

Now my result is as follows: (Note: the only change is in the last 2 lines 
of the message)


Running from source tree
Could not retrieve GNU Radio configuration directory from GNU Radio. Trying 
defaults.
Could not retrieve GNU Radio persistent state directory from GNU Radio. 
Trying defaults.

Traceback (most recent call last):
 File "/home/pi/gnuradio/grc/main.py", line 229, in get_state_directory
   from gnuradio.gr import paths
ImportError: cannot import name 'paths' from 'gnuradio.gr' 
(/usr/lib/python3/dist-packages/gnuradio/gr/__init__.py)


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 103, in 


   run_main()
 File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 96, in 
run_main

   sys.exit(main())
 File "/home/pi/gnuradio/grc/main.py", line 297, in main
   log_file = os.path.join(get_state_directory(), "grc.log")
 File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
   f"files to '{xdgand}'.")
NameError: name 'xdgand' is not defined

Jim

-Original Message- 
From: Chris Gorman

Sent: Monday, September 30, 2024 9:07 AM
To: Elmore Family
Cc: GNURadio Discussion List ; Volker Schroer
Subject: Re: unable to execute new installation

Hello Jim,

Volker is referring to a github pull request (bug fix).  You can find
his bug report number 7513 at
https://github.com/gnuradio/gnuradio/pull/7513 .

Best regards,

Chris



On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:


What does 7513 refer to? How do I find it?

-Original Message-
From: Volker Schroer
Sent: Saturday, September 28, 2024 11:22 AM
To: GNURadio Discussion List
Subject: Re: unable to execute new installation

Please stay on the list.


First:

  File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
 f"files to '{newpath}'.")
UnboundLocalError: local variable 'newpath' referenced before assignment

is definitely a bug in the python code.

I proposed a fix. See #7513 on github.

This pr may not fix the reason of your problems, but you should get a
better error message.

What is the result of

gnuradio-config-info --prefix

Why do you start gnuradio-companion from the source tree and not from
the install directory?


Am 28.09.24 um 15:06 schrieb Elmore’s:
> I did perform the install command and I thought it worked. You also say
> this is a bug. Thus I am confused.
> Sent from my iPhone



--
This email has been checked for viruses by AVG antivirus software.
www.avg.com




--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ron Economos]

Here's the one NEON file in UHD.

https://github.com/EttusResearch/uhd/blob/master/host/lib/convert/convert_with_neon.cpp

On 32-bit ARM, I used to use this for the CMake invocation for my 
Beagleboard X15:


cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard 
-mfpu=neon -mtune=cortex-a15 -Wno-psabi" 
-DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon 
-mtune=cortex-a15 -Wno-psabi" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a 
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -g" ../


I don't have any 64-bit ARM boards to test with (I'm all in on RISC-V 
these days), so I'm not sure what's going on there. It's possible NEON 
is enabled by default, but it needs to be checked.


Ron

On 9/30/24 08:56, Anıl Gürses wrote:


Also, UHD is super tweaked on x86 but has almost nothing for ARM.
I'm not even sure the NEON code is enabled for 64-bit ARM. On
32-bit ARM, you had to compile UHD with specific CFLAGS to enable
NEON.


That's a good point. *AFAIK* even if you enable NEON cflag, there are 
no SIMD instructions for NEON. There is most likely a delay in data 
conversion. convert_benchmark.py in uhd/host/utils can provide more 
insights about the delay.



Anil


On Mon, Sep 30, 2024 at 11:49 AM Ron Economos  wrote:

The DVB-T2 transmitter is a continuous stream.

On x86, int8 gives a little help. int12 is worse than int16.

Also, UHD is super tweaked on x86 but has almost nothing for ARM.
I'm not even sure the NEON code is enabled for 64-bit ARM. On
32-bit ARM, you had to compile UHD with specific CFLAGS to enable
NEON.

Ron

On 9/30/24 08:12, Anıl Gürses wrote:

Hi all,

960M = 15M samples * 32 bits/sample (lime sdr sink/source
working with 32 bit float) * 2 (because Inphase and
Quadrature assuming you're working with complex signals). 



The samples are converted to a different data type before being
sent to USRP (ref:
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html).
The biggest OTW data type is sc16, with a total size of 32 bits
(16 bits I & 16 bits Q).

Sorry, but UHD is a big CPU hog for transmitting (at least
with the B2X0 series of devices).


That's true but it also depends on how you handle the transmit
process. If you are using timed commands to transmit the sample
(ref.
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD),
it's easier to reach maximum throughput. Otherwise, you have to
wait for the end of the burst/transmission, which comes with a
data transfer delay (both options have this delay but timed
commands save some time).


I suggest using smaller wire formats such as complex int12 or
int8. This might affect the performance of your application (due
to the quantization) but it should eventually help you to reach
higher sampling rates.


PS. You are using an SBC to host your application, which might
not have enough computing power or USB bandwidth as mentioned by
others.


Cheers,
Anil


On Mon, Sep 30, 2024 at 10:48 AM Ceren Karaköse
 wrote:

Hi all,

This is my point of view on the issue:
15M sample rate is equal to 960M bits/sec data transmission
from your USB port to your SDR device. 960M = 15M samples *
32 bits/sample (lime sdr sink/source working with 32 bit
float) * 2 (because Inphase and Quadrature assuming you're
working with complex signals).

If you are using usb 2.0 port, which has 480 Mbits/sec data
rate, you cannot achieve the desired data rate. Hence the
underruns. On the otherhand, if you're using USB 3.0 port on
your device, it should be *theoretically* able to achieve
that rate as its data transfer speed is 5Gbps. However, mind
you that these values are *the maximum* values that can ever
be achieved. I'm not the expert on USB communication but from
experience never ever was I able to achieve that theoretical
data rate from USB connections. This is perhaps related to
computer architecture and how the bus is shared. For example
your usb mouse and keyboard *may* be sharing some of the
bandwidth allocated for USB connections in the computer and
hence "stealing" from the theoretical maximum data transfer rate.

My suggestion is that if you ever plan to go above 10M
samples/sec, use an ethernet-connected SDR.

Get Outlook for Android <https://aka.ms/AAb9ysg>

*From:*
discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org

on behalf of Ron Economos 
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Anıl Gürses]

>
> Also, UHD is super tweaked on x86 but has almost nothing for ARM. I'm not
> even sure the NEON code is enabled for 64-bit ARM. On 32-bit ARM, you had
> to compile UHD with specific CFLAGS to enable NEON.
>

That's a good point. *AFAIK* even if you enable NEON cflag, there are no
SIMD instructions for NEON. There is most likely a delay in data
conversion. convert_benchmark.py in uhd/host/utils can provide more
insights about the delay.


Anil


On Mon, Sep 30, 2024 at 11:49 AM Ron Economos  wrote:

> The DVB-T2 transmitter is a continuous stream.
>
> On x86, int8 gives a little help. int12 is worse than int16.
>
> Also, UHD is super tweaked on x86 but has almost nothing for ARM. I'm not
> even sure the NEON code is enabled for 64-bit ARM. On 32-bit ARM, you had
> to compile UHD with specific CFLAGS to enable NEON.
>
> Ron
> On 9/30/24 08:12, Anıl Gürses wrote:
>
> Hi all,
>
> 960M = 15M samples * 32 bits/sample (lime sdr sink/source working with 32
>> bit float) * 2 (because Inphase and Quadrature assuming you're working with
>> complex signals).
>
>
> The samples are converted to a different data type before being sent to
> USRP (ref:
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html). The
> biggest OTW data type is sc16, with a total size of 32 bits (16 bits I & 16
> bits Q).
>
> Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
>> series of devices).
>>
>
> That's true but it also depends on how you handle the transmit process. If
> you are using timed commands to transmit the sample (ref.
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD),
> it's easier to reach maximum throughput. Otherwise, you have to wait for
> the end of the burst/transmission, which comes with a data transfer delay
> (both options have this delay but timed commands save some time).
>
>
> I suggest using smaller wire formats such as complex int12 or int8. This
> might affect the performance of your application (due to the quantization)
> but it should eventually help you to reach higher sampling rates.
>
>
> PS. You are using an SBC to host your application, which might not have
> enough computing power or USB bandwidth as mentioned by others.
>
>
> Cheers,
> Anil
>
>
> On Mon, Sep 30, 2024 at 10:48 AM Ceren Karaköse <
> ceren.karak...@outlook.com> wrote:
>
>> Hi all,
>>
>> This is my point of view on the issue:
>> 15M sample rate is equal to 960M bits/sec data transmission from your USB
>> port to your SDR device. 960M = 15M samples * 32 bits/sample (lime sdr
>> sink/source working with 32 bit float) * 2 (because Inphase and Quadrature
>> assuming you're working with complex signals).
>>
>> If you are using usb 2.0 port, which has 480 Mbits/sec data rate, you
>> cannot achieve the desired data rate. Hence the underruns. On the
>> otherhand, if you're using USB 3.0 port on your device, it should be
>> *theoretically* able to achieve that rate as its data transfer speed is
>> 5Gbps. However, mind you that these values are *the maximum* values that
>> can ever be achieved. I'm not the expert on USB communication but from
>> experience never ever was I able to achieve that theoretical data rate from
>> USB connections. This is perhaps related to computer architecture and how
>> the bus is shared. For example your usb mouse and keyboard *may* be sharing
>> some of the bandwidth allocated for USB connections in the computer and
>> hence "stealing" from the theoretical maximum data transfer rate.
>>
>> My suggestion is that if you ever plan to go above 10M samples/sec, use
>> an ethernet-connected SDR.
>>
>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>> --
>> *From:* discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org
>>  on behalf
>> of Ron Economos 
>> *Sent:* Monday, September 30, 2024 5:27:19 PM
>> *To:* discuss-gnuradio@gnu.org 
>> *Subject:* Re: dvbt2 transmitter can not be real-time with LimeSDR
>>
>> Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
>> series of devices).
>>
>> Ron
>>
>> On 9/30/24 07:21, Marcus D. Leech wrote:
>> > You should investigate the transport parameters for UHD USB devices
>> here:
>> >
>> > https://files.ettus.com/manual/page_transport.html#transport_usb
>> >
>> > UHD *IS* a large library, because it kind of has to be.  It supports
>> > many different hardware devices, going back to the USRP1
>> >   originally sold in 2004.  But having said that the "sample moving"
>> > pathways in the code are quite efficient.  One shouldn't
>> >   confuse the size of the library with the efficiency of the critical
>> > pathways.
>> >
>> >
>>
>>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Marcus D. Leech]

On 30/09/2024 11:49, Ron Economos wrote:


The DVB-T2 transmitter is a continuous stream.

On x86, int8 gives a little help. int12 is worse than int16.

int12 requires some data "shuffling" on the CPU side that doesn't nicely 
fit into regular word sizes, so it's not a good idea

  unless you have USB bandwidth issues, but no CPU issues.


Also, UHD is super tweaked on x86 but has almost nothing for ARM. I'm 
not even sure the NEON code is enabled for 64-bit ARM. On 32-bit ARM, 
you had to compile UHD with specific CFLAGS to enable NEON.


Ron

On 9/30/24 08:12, Anıl Gürses wrote:

Hi all,

960M = 15M samples * 32 bits/sample (lime sdr sink/source working
with 32 bit float) * 2 (because Inphase and Quadrature assuming
you're working with complex signals). 



The samples are converted to a different data type before being sent 
to USRP (ref: 
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html). 
The biggest OTW data type is sc16, with a total size of 32 bits (16 
bits I & 16 bits Q).


Sorry, but UHD is a big CPU hog for transmitting (at least with
the B2X0 series of devices).


That's true but it also depends on how you handle the transmit 
process. If you are using timed commands to transmit the sample (ref. 
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD), 
it's easier to reach maximum throughput. Otherwise, you have to wait 
for the end of the burst/transmission, which comes with a data 
transfer delay (both options have this delay but timed commands save 
some time).



I suggest using smaller wire formats such as complex int12 or int8. 
This might affect the performance of your application (due to the 
quantization) but it should eventually help you to reach higher 
sampling rates.



PS. You are using an SBC to host your application, which might not 
have enough computing power or USB bandwidth as mentioned by others.



Cheers,
Anil


On Mon, Sep 30, 2024 at 10:48 AM Ceren Karaköse 
 wrote:


Hi all,

This is my point of view on the issue:
15M sample rate is equal to 960M bits/sec data transmission from
your USB port to your SDR device. 960M = 15M samples * 32
bits/sample (lime sdr sink/source working with 32 bit float) * 2
(because Inphase and Quadrature assuming you're working with
complex signals).

If you are using usb 2.0 port, which has 480 Mbits/sec data rate,
you cannot achieve the desired data rate. Hence the underruns. On
the otherhand, if you're using USB 3.0 port on your device, it
should be *theoretically* able to achieve that rate as its data
transfer speed is 5Gbps. However, mind you that these values are
*the maximum* values that can ever be achieved. I'm not the
expert on USB communication but from experience never ever was I
able to achieve that theoretical data rate from USB connections.
This is perhaps related to computer architecture and how the bus
is shared. For example your usb mouse and keyboard *may* be
sharing some of the bandwidth allocated for USB connections in
the computer and hence "stealing" from the theoretical maximum
data transfer rate.

My suggestion is that if you ever plan to go above 10M
samples/sec, use an ethernet-connected SDR.

Get Outlook for Android <https://aka.ms/AAb9ysg>

*From:*
discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org
 on
behalf of Ron Economos 
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: dvbt2 transmitter can not be real-time with LimeSDR
Sorry, but UHD is a big CPU hog for transmitting (at least with
the B2X0
series of devices).

Ron

On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport parameters for UHD USB
devices here:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it kind of has to be.  It
supports
> many different hardware devices, going back to the USRP1
>   originally sold in 2004.  But having said that the "sample
moving"
> pathways in the code are quite efficient. One shouldn't
>   confuse the size of the library with the efficiency of the
critical
> pathways.
>
>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ron Economos]

The DVB-T2 transmitter is a continuous stream.

On x86, int8 gives a little help. int12 is worse than int16.

Also, UHD is super tweaked on x86 but has almost nothing for ARM. I'm 
not even sure the NEON code is enabled for 64-bit ARM. On 32-bit ARM, 
you had to compile UHD with specific CFLAGS to enable NEON.


Ron

On 9/30/24 08:12, Anıl Gürses wrote:

Hi all,

960M = 15M samples * 32 bits/sample (lime sdr sink/source working
with 32 bit float) * 2 (because Inphase and Quadrature assuming
you're working with complex signals). 



The samples are converted to a different data type before being sent 
to USRP (ref: 
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html). The 
biggest OTW data type is sc16, with a total size of 32 bits (16 bits I 
& 16 bits Q).


Sorry, but UHD is a big CPU hog for transmitting (at least with
the B2X0 series of devices).


That's true but it also depends on how you handle the transmit 
process. If you are using timed commands to transmit the sample (ref. 
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD), 
it's easier to reach maximum throughput. Otherwise, you have to wait 
for the end of the burst/transmission, which comes with a data 
transfer delay (both options have this delay but timed commands save 
some time).



I suggest using smaller wire formats such as complex int12 or int8. 
This might affect the performance of your application (due to the 
quantization) but it should eventually help you to reach higher 
sampling rates.



PS. You are using an SBC to host your application, which might not 
have enough computing power or USB bandwidth as mentioned by others.



Cheers,
Anil


On Mon, Sep 30, 2024 at 10:48 AM Ceren Karaköse 
 wrote:


Hi all,

This is my point of view on the issue:
15M sample rate is equal to 960M bits/sec data transmission from
your USB port to your SDR device. 960M = 15M samples * 32
bits/sample (lime sdr sink/source working with 32 bit float) * 2
(because Inphase and Quadrature assuming you're working with
complex signals).

If you are using usb 2.0 port, which has 480 Mbits/sec data rate,
you cannot achieve the desired data rate. Hence the underruns. On
the otherhand, if you're using USB 3.0 port on your device, it
should be *theoretically* able to achieve that rate as its data
transfer speed is 5Gbps. However, mind you that these values are
*the maximum* values that can ever be achieved. I'm not the expert
on USB communication but from experience never ever was I able to
achieve that theoretical data rate from USB connections. This is
perhaps related to computer architecture and how the bus is
shared. For example your usb mouse and keyboard *may* be sharing
some of the bandwidth allocated for USB connections in the
computer and hence "stealing" from the theoretical maximum data
transfer rate.

My suggestion is that if you ever plan to go above 10M
samples/sec, use an ethernet-connected SDR.

Get Outlook for Android <https://aka.ms/AAb9ysg>

*From:*
discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org
 on
behalf of Ron Economos 
*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: dvbt2 transmitter can not be real-time with LimeSDR
Sorry, but UHD is a big CPU hog for transmitting (at least with
the B2X0
series of devices).

Ron

On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport parameters for UHD USB
devices here:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it kind of has to be.  It
supports
> many different hardware devices, going back to the USRP1
>   originally sold in 2004.  But having said that the "sample
moving"
> pathways in the code are quite efficient.  One shouldn't
>   confuse the size of the library with the efficiency of the
critical
> pathways.
>
>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Marcus D. Leech]

On 30/09/2024 10:27, Ron Economos wrote:
Sorry, but UHD is a big CPU hog for transmitting (at least with the 
B2X0 series of devices).


Ron
I just did a quick test using "benchmark_rate" into a B210, doing a "tx" 
test at 30Msps.  That consumed 52% of a single
  CPU on my i5-6200 system at 2.7GHz.  There were a handful of U during 
the 1 minute test.


Since I don't have LimeSDR setup on my machine, I can't compare. Nor can 
I compare to BladeRF (the other USB-based

  tx-capable SDR).




On 9/30/24 07:21, Marcus D. Leech wrote:
You should investigate the transport parameters for UHD USB devices 
here:


https://files.ettus.com/manual/page_transport.html#transport_usb

UHD *IS* a large library, because it kind of has to be.  It supports 
many different hardware devices, going back to the USRP1
  originally sold in 2004.  But having said that the "sample moving" 
pathways in the code are quite efficient.  One shouldn't
  confuse the size of the library with the efficiency of the critical 
pathways.

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ron Economos]

It's not a USB hardware problem, it's that he's trying to use a small 
ARM based SBC (the Orange Pi 5 plus).


For the DVB-T2 transmitter, there are several blocks that require 
significant CPU resources. What tends to happen is the GNU Radio 
scheduler will sometimes run all of the high CPU blocks on the same core 
for some period of time. Underruns can occur when that core exceeds 100% 
usage.


Having UHD being one of the high CPU blocks just makes things worse.

The solution is too pin each block to a specific core, but that's some 
tricky stuff. You have to use htop to determine which blocks need the 
most CPU and come up with a core layout that evenly distributes the 
load. More difficult when you only have 4 cores and the flow graph has 
15 blocks.


Ron

On 9/30/24 07:42, Ceren Karaköse wrote:

Hi all,

This is my point of view on the issue:
15M sample rate is equal to 960M bits/sec data transmission from your 
USB port to your SDR device. 960M = 15M samples * 32 bits/sample (lime 
sdr sink/source working with 32 bit float) * 2 (because Inphase and 
Quadrature assuming you're working with complex signals).


If you are using usb 2.0 port, which has 480 Mbits/sec data rate, you 
cannot achieve the desired data rate. Hence the underruns. On the 
otherhand, if you're using USB 3.0 port on your device, it should be 
*theoretically* able to achieve that rate as its data transfer speed 
is 5Gbps. However, mind you that these values are *the maximum* values 
that can ever be achieved. I'm not the expert on USB communication but 
from experience never ever was I able to achieve that theoretical data 
rate from USB connections. This is perhaps related to computer 
architecture and how the bus is shared. For example your usb mouse and 
keyboard *may* be sharing some of the bandwidth allocated for USB 
connections in the computer and hence "stealing" from the theoretical 
maximum data transfer rate.


My suggestion is that if you ever plan to go above 10M samples/sec, 
use an ethernet-connected SDR.


Get Outlook for Android <https://aka.ms/AAb9ysg>

*From:* discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org 
 on 
behalf of Ron Economos 

*Sent:* Monday, September 30, 2024 5:27:19 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: dvbt2 transmitter can not be real-time with LimeSDR
Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
series of devices).

Ron

On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport parameters for UHD USB devices 
here:

>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it kind of has to be.  It supports
> many different hardware devices, going back to the USRP1
>   originally sold in 2004.  But having said that the "sample moving"
> pathways in the code are quite efficient.  One shouldn't
>   confuse the size of the library with the efficiency of the critical
> pathways.
>
>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Anıl Gürses]

Hi all,

960M = 15M samples * 32 bits/sample (lime sdr sink/source working with 32
> bit float) * 2 (because Inphase and Quadrature assuming you're working with
> complex signals).


The samples are converted to a different data type before being sent to
USRP (ref: https://files.ettus.com/manual/structuhd_1_1stream__args__t.html).
The biggest OTW data type is sc16, with a total size of 32 bits (16 bits I
& 16 bits Q).

Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
> series of devices).
>

That's true but it also depends on how you handle the transmit process. If
you are using timed commands to transmit the sample (ref.
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD),
it's easier to reach maximum throughput. Otherwise, you have to wait for
the end of the burst/transmission, which comes with a data transfer delay
(both options have this delay but timed commands save some time).


I suggest using smaller wire formats such as complex int12 or int8. This
might affect the performance of your application (due to the quantization)
but it should eventually help you to reach higher sampling rates.


PS. You are using an SBC to host your application, which might not have
enough computing power or USB bandwidth as mentioned by others.


Cheers,
Anil


On Mon, Sep 30, 2024 at 10:48 AM Ceren Karaköse 
wrote:

> Hi all,
>
> This is my point of view on the issue:
> 15M sample rate is equal to 960M bits/sec data transmission from your USB
> port to your SDR device. 960M = 15M samples * 32 bits/sample (lime sdr
> sink/source working with 32 bit float) * 2 (because Inphase and Quadrature
> assuming you're working with complex signals).
>
> If you are using usb 2.0 port, which has 480 Mbits/sec data rate, you
> cannot achieve the desired data rate. Hence the underruns. On the
> otherhand, if you're using USB 3.0 port on your device, it should be
> *theoretically* able to achieve that rate as its data transfer speed is
> 5Gbps. However, mind you that these values are *the maximum* values that
> can ever be achieved. I'm not the expert on USB communication but from
> experience never ever was I able to achieve that theoretical data rate from
> USB connections. This is perhaps related to computer architecture and how
> the bus is shared. For example your usb mouse and keyboard *may* be sharing
> some of the bandwidth allocated for USB connections in the computer and
> hence "stealing" from the theoretical maximum data transfer rate.
>
> My suggestion is that if you ever plan to go above 10M samples/sec, use an
> ethernet-connected SDR.
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> --
> *From:* discuss-gnuradio-bounces+ceren.karakose=outlook....@gnu.org
>  on behalf
> of Ron Economos 
> *Sent:* Monday, September 30, 2024 5:27:19 PM
> *To:* discuss-gnuradio@gnu.org 
> *Subject:* Re: dvbt2 transmitter can not be real-time with LimeSDR
>
> Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
> series of devices).
>
> Ron
>
> On 9/30/24 07:21, Marcus D. Leech wrote:
> > You should investigate the transport parameters for UHD USB devices here:
> >
> > https://files.ettus.com/manual/page_transport.html#transport_usb
> >
> > UHD *IS* a large library, because it kind of has to be.  It supports
> > many different hardware devices, going back to the USRP1
> >   originally sold in 2004.  But having said that the "sample moving"
> > pathways in the code are quite efficient.  One shouldn't
> >   confuse the size of the library with the efficiency of the critical
> > pathways.
> >
> >
>
>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ceren Karaköse]

Hi all,

This is my point of view on the issue:
15M sample rate is equal to 960M bits/sec data transmission from your USB port 
to your SDR device. 960M = 15M samples * 32 bits/sample (lime sdr sink/source 
working with 32 bit float) * 2 (because Inphase and Quadrature assuming you're 
working with complex signals).

If you are using usb 2.0 port, which has 480 Mbits/sec data rate, you cannot 
achieve the desired data rate. Hence the underruns. On the otherhand, if you're 
using USB 3.0 port on your device, it should be *theoretically* able to achieve 
that rate as its data transfer speed is 5Gbps. However, mind you that these 
values are *the maximum* values that can ever be achieved. I'm not the expert 
on USB communication but from experience never ever was I able to achieve that 
theoretical data rate from USB connections. This is perhaps related to computer 
architecture and how the bus is shared. For example your usb mouse and keyboard 
*may* be sharing some of the bandwidth allocated for USB connections in the 
computer and hence "stealing" from the theoretical maximum data transfer rate.

My suggestion is that if you ever plan to go above 10M samples/sec, use an 
ethernet-connected SDR.

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: discuss-gnuradio-bounces+ceren.karakose=outlook@gnu.org 
 on behalf of Ron 
Economos 
Sent: Monday, September 30, 2024 5:27:19 PM
To: discuss-gnuradio@gnu.org 
Subject: Re: dvbt2 transmitter can not be real-time with LimeSDR

Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0
series of devices).

Ron

On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport parameters for UHD USB devices here:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it kind of has to be.  It supports
> many different hardware devices, going back to the USRP1
>   originally sold in 2004.  But having said that the "sample moving"
> pathways in the code are quite efficient.  One shouldn't
>   confuse the size of the library with the efficiency of the critical
> pathways.
>
>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ron Economos]

Sorry, but UHD is a big CPU hog for transmitting (at least with the B2X0 
series of devices).


Ron

On 9/30/24 07:21, Marcus D. Leech wrote:

You should investigate the transport parameters for UHD USB devices here:

https://files.ettus.com/manual/page_transport.html#transport_usb

UHD *IS* a large library, because it kind of has to be.  It supports 
many different hardware devices, going back to the USRP1
  originally sold in 2004.  But having said that the "sample moving" 
pathways in the code are quite efficient.  One shouldn't
  confuse the size of the library with the efficiency of the critical 
pathways.

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Marcus D. Leech]

On 30/09/2024 01:30, Ali G. Dezfuli wrote:


When I run dvbt2 transmitter examples from gr-dtv without any 
hardware, “Probe Rate” block in GRC shows 15e6 samples per second at 
the output of the Tx (which needs about 9 Msps to work in real-time.)

Next, I connected USRP B200mini, but it showed underruns.
Talking to the community, they said UHD is heavy and suggested other 
SDR modules like LimeSDR.

But the problem still exists using LimeSDR-USB!
I wonder if there is a way to make “LimeSDR Sink (TX)” catch up with 
other blocks.

Details:
HW: Orange Pi 5 plus (32GB)
OS: Ubuntu 22.04
GR: v3.10.11.0

Thanks!


You should investigate the transport parameters for UHD USB devices here:

https://files.ettus.com/manual/page_transport.html#transport_usb

UHD *IS* a large library, because it kind of has to be.  It supports 
many different hardware devices, going back to the USRP1
  originally sold in 2004.  But having said that the "sample moving" 
pathways in the code are quite efficient.  One shouldn't
  confuse the size of the library with the efficiency of the critical 
pathways.

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ron Economos]

The file gnuradio/gr-dtv/examples/README.dvbt2 contains links to TS 
files crafted with the correct bitrate for each example flow graph. For 
the vv011-1kfft.grc flow graph, it's:


https://www.w6rz.net/vv011-1kfft.ts

The correct invocation for dvbt2rate is:

./dvbt2rate 8 1 2 1966 48 1 1 0 0 3 0
FFT size = 1024
guard interval = 1/8
number of data symbols = 1966
number of FEC blocks = 48
code rate = 1/2
constellation = QPSK
frame size = normal
carrier mode = normal
pilot pattern = PP3
L1 constellation = BPSK

clock rate = 9142857.142857, TF = 249.956000 ms
Normal mode bitrate = 6169661.860487
High Efficiency mode bitrate = 6202654.704661

max symbols = 1984, max blocks = 48
symbols = 1982, max blocks = 48
cells = 1577708, stream = 1555200, L1 = 3344, dummy = 18944, unmodulated 
= 220


PAPR max symbols = 1984, max blocks = 48
symbols = 1982, max blocks = 47
cells = 1558048, stream = 1555200, L1 = 3344, dummy = -716, unmodulated 
= 220


I'll admit it's a little painful to use. 😳

Ron

On 9/30/24 06:58, Ali G. Dezfuli wrote:

Thanks Ron!
How can I make the related TS file? (e.g. for vv011-1kfft.grc)
The list in https://github.com/drmpeg/dtv-utils does not include QPSK!

On Mon, Sep 30, 2024 at 4:29 PM Ron Economos  wrote:

You could try DVB-T2 configurations that use less CPU. Both
smaller FFT size and lower bitrate help. For example try the
following test flow graphs:

vv009-4kfft.grc 27.588664 Mbps

vv010-2kfft.grc 14.364704 Mbps

vv011-1kfft.grc 6.169662 Mbps

If your receiver allows it, you can also use smaller channel
bandwidths such as 5, 6, or 7 MHz. The bitrate will be scaled
accordingly.

The DVB-T2 bitrate calculator is here.

https://github.com/drmpeg/dtv-utils/blob/master/dvbt2rate.c

Ron

On 9/29/24 22:30, Ali G. Dezfuli wrote:


When I run dvbt2 transmitter examples from gr-dtv without any
hardware, “Probe Rate” block in GRC shows 15e6 samples per second
at the output of the Tx (which needs about 9 Msps to work in
real-time.)
Next, I connected USRP B200mini, but it showed underruns.
Talking to the community, they said UHD is heavy and suggested
other SDR modules like LimeSDR.
But the problem still exists using LimeSDR-USB!
I wonder if there is a way to make “LimeSDR Sink (TX)” catch up
with other blocks.
Details:
HW: Orange Pi 5 plus (32GB)
OS: Ubuntu 22.04
GR: v3.10.11.0

Thanks!

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ali G. Dezfuli]

Thanks Ron!
How can I make the related TS file? (e.g. for vv011-1kfft.grc)
The list in https://github.com/drmpeg/dtv-utils does not include QPSK!

On Mon, Sep 30, 2024 at 4:29 PM Ron Economos  wrote:

> You could try DVB-T2 configurations that use less CPU. Both smaller FFT
> size and lower bitrate help. For example try the following test flow graphs:
>
> vv009-4kfft.grc 27.588664 Mbps
>
> vv010-2kfft.grc 14.364704 Mbps
>
> vv011-1kfft.grc 6.169662 Mbps
>
> If your receiver allows it, you can also use smaller channel bandwidths
> such as 5, 6, or 7 MHz. The bitrate will be scaled accordingly.
>
> The DVB-T2 bitrate calculator is here.
>
> https://github.com/drmpeg/dtv-utils/blob/master/dvbt2rate.c
>
> Ron
> On 9/29/24 22:30, Ali G. Dezfuli wrote:
>
> When I run dvbt2 transmitter examples from gr-dtv without any hardware,
> “Probe Rate” block in GRC shows 15e6 samples per second at the output of
> the Tx (which needs about 9 Msps to work in real-time.)
> Next, I connected USRP B200mini, but it showed underruns.
> Talking to the community, they said UHD is heavy and suggested other SDR
> modules like LimeSDR.
> But the problem still exists using LimeSDR-USB!
> I wonder if there is a way to make “LimeSDR Sink (TX)” catch up with other
> blocks.
> Details:
> HW: Orange Pi 5 plus (32GB)
> OS: Ubuntu 22.04
> GR: v3.10.11.0
>
> Thanks!
>
>

Re: unable to execute new installation

[Chris Gorman]

Hello Jim,

Volker is referring to a github pull request (bug fix).  You can find
his bug report number 7513 at
https://github.com/gnuradio/gnuradio/pull/7513 .

Best regards,

Chris



On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:
>
> What does 7513 refer to? How do I find it?
>
> -Original Message-
> From: Volker Schroer
> Sent: Saturday, September 28, 2024 11:22 AM
> To: GNURadio Discussion List
> Subject: Re: unable to execute new installation
>
> Please stay on the list.
>
>
> First:
>
>   File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>  f"files to '{newpath}'.")
> UnboundLocalError: local variable 'newpath' referenced before assignment
>
> is definitely a bug in the python code.
>
> I proposed a fix. See #7513 on github.
>
> This pr may not fix the reason of your problems, but you should get a
> better error message.
>
> What is the result of
>
> gnuradio-config-info --prefix
>
> Why do you start gnuradio-companion from the source tree and not from
> the install directory?
>
>
> Am 28.09.24 um 15:06 schrieb Elmore’s:
> > I did perform the install command and I thought it worked. You also say
> > this is a bug. Thus I am confused.
> > Sent from my iPhone
>
>
>
> --
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com
>
>

Re: dvbt2 transmitter can not be real-time with LimeSDR

[Ron Economos]

You could try DVB-T2 configurations that use less CPU. Both smaller FFT 
size and lower bitrate help. For example try the following test flow graphs:


vv009-4kfft.grc 27.588664 Mbps

vv010-2kfft.grc 14.364704 Mbps

vv011-1kfft.grc 6.169662 Mbps

If your receiver allows it, you can also use smaller channel bandwidths 
such as 5, 6, or 7 MHz. The bitrate will be scaled accordingly.


The DVB-T2 bitrate calculator is here.

https://github.com/drmpeg/dtv-utils/blob/master/dvbt2rate.c

Ron

On 9/29/24 22:30, Ali G. Dezfuli wrote:


When I run dvbt2 transmitter examples from gr-dtv without any 
hardware, “Probe Rate” block in GRC shows 15e6 samples per second at 
the output of the Tx (which needs about 9 Msps to work in real-time.)

Next, I connected USRP B200mini, but it showed underruns.
Talking to the community, they said UHD is heavy and suggested other 
SDR modules like LimeSDR.

But the problem still exists using LimeSDR-USB!
I wonder if there is a way to make “LimeSDR Sink (TX)” catch up with 
other blocks.

Details:
HW: Orange Pi 5 plus (32GB)
OS: Ubuntu 22.04
GR: v3.10.11.0

Thanks!

Re: unable to execute new installation

[Elmore Family]

What does 7513 refer to? How do I find it?

-Original Message- 
From: Volker Schroer

Sent: Saturday, September 28, 2024 11:22 AM
To: GNURadio Discussion List
Subject: Re: unable to execute new installation

Please stay on the list.


First:

 File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
f"files to '{newpath}'.")
UnboundLocalError: local variable 'newpath' referenced before assignment

is definitely a bug in the python code.

I proposed a fix. See #7513 on github.

This pr may not fix the reason of your problems, but you should get a
better error message.

What is the result of

gnuradio-config-info --prefix

Why do you start gnuradio-companion from the source tree and not from
the install directory?


Am 28.09.24 um 15:06 schrieb Elmore’s:
I did perform the install command and I thought it worked. You also say 
this is a bug. Thus I am confused.

Sent from my iPhone




--
This email has been checked for viruses by AVG antivirus software.
www.avg.com 

Re: unable to execute new installation

[Elmore’s]

The result of the config-info command is that it points to the script of the 
previous installation of 3.9.

I am running the new script from the only location that I have been able to 
find for the new gnuradio-companion.
 
I found it in the path indicated in my original post. I thought this was the 
install directory. 

Further confusion.

Sent from my iPhone

> On Sep 28, 2024, at 11:24 AM, Volker Schroer  wrote:
> 
> Please stay on the list.
> 
> 
> First:
> 
> File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>f"files to '{newpath}'.")
> UnboundLocalError: local variable 'newpath' referenced before assignment
> 
> is definitely a bug in the python code.
> 
> I proposed a fix. See #7513 on github.
> 
> This pr may not fix the reason of your problems, but you should get a
> better error message.
> 
> What is the result of
> 
> gnuradio-config-info --prefix
> 
> Why do you start gnuradio-companion from the source tree and not from
> the install directory?
> 
> 
>> Am 28.09.24 um 15:06 schrieb Elmore’s:
>> I did perform the install command and I thought it worked. You also say this 
>> is a bug. Thus I am confused.
>> Sent from my iPhone
> 
> 

Re: unable to execute new installation

[Volker Schroer]

Please stay on the list.


First:

 File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
f"files to '{newpath}'.")
UnboundLocalError: local variable 'newpath' referenced before assignment

is definitely a bug in the python code.

I proposed a fix. See #7513 on github.

This pr may not fix the reason of your problems, but you should get a
better error message.

What is the result of

gnuradio-config-info --prefix

Why do you start gnuradio-companion from the source tree and not from
the install directory?


Am 28.09.24 um 15:06 schrieb Elmore’s:

I did perform the install command and I thought it worked. You also say this is 
a bug. Thus I am confused.
Sent from my iPhone

Re: unable to execute new installation

[Volker Schroer]

This is definitely a bug. But as far as I can see you are building but
not installing gnuradio.

Otherwise the message "Running from soure tree" makes no sense.

If I start gnuradio from the build tree I get the same error message as
you did.
So to come accros this issue, install gnuradio after nuilding and run it
from the install tree.

This problem may be caused by the fact that some configuration
directories have been changed.

-- Volker
Am 28.09.24 um 02:08 schrieb Elmore Family:

I have installed the latest version of GNU Radio from source. When I
tried to execute from the RPi GUI nothing happened. I then tried the
following execution:
pi@raspberrypi:~ $ cd gnuradio/grc/scripts
pi@raspberrypi:~/gnuradio/grc/scripts $ ls
CMakeLists.txt  freedesktop  gnuradio-companion  grcc
pi@raspberrypi:~/gnuradio/grc/scripts $ python3 gnuradio-companion
Running from source tree
Could not retrieve GNU Radio configuration directory from GNU Radio.
Trying defaults.
Could not retrieve GNU Radio persistent state directory from GNU Radio.
Trying defaults.
Traceback (most recent call last):
   File "/home/pi/gnuradio/grc/main.py", line 229, in get_state_directory
     from gnuradio.gr import paths
ImportError: cannot import name 'paths' from 'gnuradio.gr' (/usr/lib/
python3/dist-packages/gnuradio/gr/__init__.py)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
   File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 103, in

     run_main()
   File "/home/pi/gnuradio/grc/scripts/gnuradio-companion", line 96, in
run_main
     sys.exit(main())
   File "/home/pi/gnuradio/grc/main.py", line 297, in main
     log_file = os.path.join(get_state_directory(), "grc.log")
   File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
     f"files to '{newpath}'.")
UnboundLocalError: local variable 'newpath' referenced before assignment
What do I need to do?
Jim

   Virus-free.www.avg.com 

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [EXTERNAL] Request for GNU Radio OOT for Sending and Receiving VITA49 Data in Amazon Format on AWS

[Nik Ansell]

The AWS Ground Station Vita49 spec is close to but not identical to the
DIFI spec.

I forked gr-difi a while back to fix some bugs and add compatibility with
AWS GS. I got as far as adding a new option that supports AWS GS for
downlink. However, I didn't get around to adding the uplink capability.

If you know c++ you can perhaps get a good starting point from this fork:

https://github.com/gamecat69/gr-difi/tree/main

Kind regards,
Nik


On Fri, 27 Sept 2024, 16:53 Jim Melton,  wrote:

> I don’t know what “Amazon format on AWS” means, but VITA-49 is an industry
> standard. That said, it is extremely customizable, so it’s always best to
> refer to the documentation of the data producer when decoding it.
>
>
>
> I have used the driver provided by CyberRadio Solutions
>  (formerly owned by G3,
> now owned by Epiq) found here: https://github.com/CyberRadio/gr-cyberradio
> (because I was using one of their radios). I hope it’s helpful
>
> ---
>
> *Jim Melton*
>
>
>
> *Sent:* Friday, September 27, 2024 06:54
> *To:* GNURadio Discussion List 
> *Subject:* [EXTERNAL] Request for GNU Radio OOT for Sending and Receiving
> VITA49 Data in Amazon Format on AWS
>
>
>
> DO NOT click on links. Never open an email attachment *unless* you're
> 100% sure it's from a trusted source and you are expecting it.
>
>
>
> Dear GNU Radio Community,
>
> I hope this message finds you well. I am currently looking for a GNU Radio
> Out-of-Tree (OOT) module that supports sending and receiving VITA49 data
> using the Amazon format on AWS. I need this to help validate my C++
> implementation. If anyone has experience with this or can share relevant
> links or resources, it would be greatly appreciated.
>
> Thank you for your assistance.
>
> Best regards,
> Moses
> CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are
> confidential, may contain proprietary, protected, or export controlled
> information, and are intended for the use of the intended recipients only.
> Any review, reliance, distribution, disclosure, or forwarding of this email
> and/or attachments outside of Sierra Nevada Company, LLC. (SNC) without
> express written approval of the sender, except to the extent required to
> further properly approved SNC business purposes, is strictly prohibited. If
> you are not the intended recipient of this email, please notify the sender
> immediately, and delete all copies without reading, printing, or saving in
> any manner. --- Thank You.
>

RE: [EXTERNAL] Request for GNU Radio OOT for Sending and Receiving VITA49 Data in Amazon Format on AWS

[Jim Melton]

I don’t know what “Amazon format on AWS” means, but VITA-49 is an industry 
standard. That said, it is extremely customizable, so it’s always best to refer 
to the documentation of the data producer when decoding it.

I have used the driver provided by CyberRadio 
Solutions (formerly owned by 
G3, now owned by Epiq) found here: https://github.com/CyberRadio/gr-cyberradio 
(because I was using one of their radios). I hope it’s helpful
---
Jim Melton

Sent: Friday, September 27, 2024 06:54
To: GNURadio Discussion List 
Subject: [EXTERNAL] Request for GNU Radio OOT for Sending and Receiving VITA49 
Data in Amazon Format on AWS

DO NOT click on links. Never open an email attachment unless you're 100% sure 
it's from a trusted source and you are expecting it.



Dear GNU Radio Community,

I hope this message finds you well. I am currently looking for a GNU Radio 
Out-of-Tree (OOT) module that supports sending and receiving VITA49 data using 
the Amazon format on AWS. I need this to help validate my C++ implementation. 
If anyone has experience with this or can share relevant links or resources, it 
would be greatly appreciated.

Thank you for your assistance.

Best regards,
Moses

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are 
confidential, may contain proprietary, protected, or export controlled 
information, and are intended for the use of the intended recipients only. Any 
review, reliance, distribution, disclosure, or forwarding of this email and/or 
attachments outside of Sierra Nevada Company, LLC. (SNC) without express 
written approval of the sender, except to the extent required to further 
properly approved SNC business purposes, is strictly prohibited. If you are not 
the intended recipient of this email, please notify the sender immediately, and 
delete all copies without reading, printing, or saving in any manner. --- Thank 
You.

Re: Timing a flowgraph execution

[Chris Gorman]

Hello Again,

Apologies for the extra email, but I found my problem and thought it
best to share my findings.  Firstly, I had an error in my flowgraph
that was causing Overflows and Underruns as well as Sequence errors
that I hadn't detected.  Fixing this fixed the problem I was having
with timing the flowgraph.

I have deleted the null source to throttle to null sink in the
flowgraph and set the "Function Probe" block to use the ID of the
"Soapy RTLSDR Source" block.  It then reports the value of
nitems_written as fprobe_val, which I use in the "QT GUI Level Gauge".
I set the value of the Level Gauge to be 'int(((fprobe_val /
samp_rate) / duration) * 100)'. When the flowgraph is run a progress
bar moves across the screen and I can tell how much of the satellite
pass has occurred and adjust the antenna position accordingly.

So I consider this fixed.

All the best,

Chris

On Wed, Sep 18, 2024 at 8:40 AM Chris Gorman  wrote:
>
> Hello all,
>
> I would like to set a timer to create a percent complete graph with
> the "QT GUI Level Gauge" block.  I've created a flowgraph that does
> this and attached a screenshot and the flowgraph.  My goal is to have
> this kind of "percent complete timer" to tell me when to move my
> antenna during a satellite pass.  This means adding a piece of
> hardware and its connections to the attached flowgraph and I am
> worried about having two timers in the same flowgraph.
>
> If I use this flowgraph and add hardware and use a head block with
> "samp_rate * duration" items it doesn't complete at the same time as
> the "percent complete timer".  There are more items to complete for
> the hardware when the "percent complete timer" ends.
>
> I have tried to use the "Function Probe" block to probe the source of
> my hardware piece, but that doesn't work properly as the timing is off
> for both timers.
>
> Does anyone have a suggestion on how to calculate the percentage
> complete from the timer on the hardware piece instead of using a
> separate null sink as I have in the attached flowgraph?
>
> Thanks in advance,
>
> Chris

Re: Regarding the calculation of SNR

[Marcus Müller]

Hi Mohammad,
you'll have to define what your signal and your noise are.

Best regards,
Marcus

On 12.09.24 17:35, Md. Sharif Hossen wrote:

Hi,

Can anyone help me find SNR from this?

image.png

Re: European GNU Radio Days conference YouTube streaming (Fri Aug. 30)

[MR169]

Hi, thanks!

On Fri, 30 Aug 2024 at 14:19, Cyrille Morin <
cyrille.mo...@centralesupelec.fr> wrote:

> Hi,
>
> The afternoon session won't be streamed
> Le 30/08/2024 à 15:04, MR169 a écrit :
>
> Are the afternoon dev sessions going to be streamed or is it just this
> morning's talks?
>
> On Fri, 30 Aug 2024 at 07:42, jmfriedt 
> wrote:
>
>> Today is the last day of the European GNU Radio days: the live stream
>> on Youtube will be available at
>> https://www.youtube.com/watch?v=JpfhgkA_nJE
>> starting at 9 AM CEST.
>>
>>

Re: European GNU Radio Days conference YouTube streaming (Fri Aug. 30)

[Cyrille Morin]

Hi,

The afternoon session won't be streamed

Le 30/08/2024 à 15:04, MR169 a écrit :
Are the afternoon dev sessions going to be streamed or is it just this 
morning's talks?


On Fri, 30 Aug 2024 at 07:42, jmfriedt 
 wrote:


Today is the last day of the European GNU Radio days: the live stream
on Youtube will be available at
https://www.youtube.com/watch?v=JpfhgkA_nJE
starting at 9 AM CEST.

Re: European GNU Radio Days conference YouTube streaming (Fri Aug. 30)

[MR169]

Are the afternoon dev sessions going to be streamed or is it just this
morning's talks?

On Fri, 30 Aug 2024 at 07:42, jmfriedt 
wrote:

> Today is the last day of the European GNU Radio days: the live stream
> on Youtube will be available at
> https://www.youtube.com/watch?v=JpfhgkA_nJE
> starting at 9 AM CEST.
>
>

Re: Unsuscribe

[Stéphane Ancelot]

Hi

I would suggest an unsubscribe web link in bottom emails

Regards

Le jeu. 29 août 2024, 09:26, Jf Devos  a écrit :

> Please unsuscribe my account
>

Re: European GNU Radio Days conference now live streaming

[Franco VENTURI]

To answer my own question, I saw this morning that yesterday afternoon's dev 
tutorials by Alex Krimm were posted on YouTube.
This is the link: https://www.youtube.com/watch?v=ce496ZCwlqA

Franco


> On 08/27/2024 7:39 PM EDT Franco VENTURI  wrote:
> 
>  
> Jean Michel,
> it looks like the YouTube link you sent out this morning does not cover the 
> dev tutorials presented by Alexander Krimm at 15:30 (Core API and Block 
> Development) and at 16:15 (Modern C++ and Advanced Techniques).
> 
> Were they recorded and do you or Alexander have the link for those as well?
> 
> Thanks,
> Franco
> 
> 
> > On 08/27/2024 2:44 AM EDT jmfriedt  wrote:
> > 
> >  
> > The European GNU Radio Days is now streaming at 
> > https://www.youtube.com/live/Pt77jXpzwFU
> > do not miss the introductory presentation and Eric Blossom's
> > perspective on GNU Radio development.

Re: European GNU Radio Days conference now live streaming

[jmfriedt]

Today's European GNU Radio Days conference YouTube stream is available
at https://www.youtube.com/watch?v=2KRrEuwvfC4, starting now at 9 AM CEST
with ``Pushing Boundaries: Femtoscale Research with Large-Scale Tech" by
Johan Messchendorp.

Re: European GNU Radio Days conference now live streaming

[Franco VENTURI]

Jean Michel,
it looks like the YouTube link you sent out this morning does not cover the dev 
tutorials presented by Alexander Krimm at 15:30 (Core API and Block 
Development) and at 16:15 (Modern C++ and Advanced Techniques).

Were they recorded and do you or Alexander have the link for those as well?

Thanks,
Franco


> On 08/27/2024 2:44 AM EDT jmfriedt  wrote:
> 
>  
> The European GNU Radio Days is now streaming at 
> https://www.youtube.com/live/Pt77jXpzwFU
> do not miss the introductory presentation and Eric Blossom's
> perspective on GNU Radio development.

Re: Segmentation fault trying to run gnuradio-companion

[Grace Yeung]

Thank you Marcus again for your help. We figured out it was an updated 
kernel that was not compatible with the existing nvidia driver. After 
updating the driver all works fine now.


Grace

On 8/25/24 11:36 PM, Grace Yeung wrote:

Here you go thanks!

grace@sage:~$ gnuradio-config-info --version
3.10.1.1
grace@sage:~$ gnuradio-config-info --prefix
/usr/
grace@sage:~$ python3 -c 'import gi; print(gi.__file__, gi.version_info)'
/usr/lib/python3/dist-packages/gi/__init__.py (3, 42, 1)



On 8/24/24 1:28 PM, Marcus Müller wrote:

python3 -c 'import gi; print(gi.__file__, gi.version_info)'


--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl., Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com


--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl., Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Segmentation fault trying to run gnuradio-companion

[Grace Yeung]

Here you go thanks!

grace@sage:~$ gnuradio-config-info --version
3.10.1.1
grace@sage:~$ gnuradio-config-info --prefix
/usr/
grace@sage:~$ python3 -c 'import gi; print(gi.__file__, gi.version_info)'
/usr/lib/python3/dist-packages/gi/__init__.py (3, 42, 1)



On 8/24/24 1:28 PM, Marcus Müller wrote:

python3 -c 'import gi; print(gi.__file__, gi.version_info)'


--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl., Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Segmentation fault trying to run gnuradio-companion

[Marcus Müller]

Interesting! Could you run `gnuradio-config-info --version` and `gnuradio-config-info 
--prefix`  for me and also `python3 -c 'import gi; print(gi.__file__, gi.version_info)'`?


Thanks,
Marcus

On 24.08.24 17:36, Grace Yeung wrote:

Thanks Marcus as always!

I upgraded from Ubuntu 20 to 22 April 2023 and everything has been working since until 
this week. And it happened after a hard reboot. I don’t recall manually installing gnuradio…


Thanks.

Grace

—​
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl., Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com
--
*From:* discuss-gnuradio-bounces+grace=nwra@gnu.org 
 on behalf of Marcus Müller 


*Sent:* Friday, August 23, 2024 6:14 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: Segmentation fault trying to run gnuradio-companion
Hey, I just saw that your mail where you figured out the command line, and it 
was too big
for our mail server to forward.

Indeed, the crash log is 3.4 MB of the GTK functions calling themselves in a 
recursive
ring. Since that's a GTK bug we've never encountered: What operating system 
exactly are
you on, and how did you install GNU Radio? And: did you perhaps install GTK or 
pygtk
manually somehow?

Best,
Marcus

On 23.08.24 19:50, Grace Yeung wrote:

Thank you Marcus. It's not running, did I type something wrong?...



Also our IT saw this earlier which pointed to the gtk3 library:

 ... gnuradio-companion is a python script, so the python interpreter is 
crashing.

   gnuradio-compan[38828]: segfault at 7ffd5a46dff8 ip 72ee877923bb sp
 7ffd5a46e000 error 6 in libgtk-3.so.0.2404.29[72ee87684000+38300

 In the gtk3 library, which is graphics related - which could be a 
difference between a
 console and remote X11 session.


Thank you!

Grace

On 8/23/24 8:04 AM, Marcus Müller wrote:

Hi Grace,

this happens when one of the libraries that gnuradio-companion needs to load 
crashes.
Sadly, it's kind of hard to guess which one that would be, but on long-term 
expectation,
it's a version mismatch somewhere.

But why guess when we can find out? The segfault error message looks like 
Linux, so if
you have `gdb` installed, you can:

$ gdb --args $(which gnuradio-companion)
(gdb) set logging file gdblog.txt
(gdb) set logging enabled
(gdb) run
… wait for the crash to happen
(gdb) thread apply all backtrace
(gdb) quit

and share the resulting gdblog.txt with us :)

Gdb might ask you underway whether to enable debuginfo downloads, don't let 
yourself be
irritated by that, "y" is fine.

Best regards,
Marcus

On 22.08.24 22:35, Grace Yeung wrote:

Hi, I am getting a segmentation fault trying to run gnuradio-companion from the
command-line. Any advise what to look into? Thanks.

$ gnuradio-companion &
[1] 6671
$ >>> Warning: vocoder_codec2_decode_ps - option_attributes are for enums only, 
ignoring
 >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums only, 
ignoring

[1]+  Segmentation fault  (core dumped) gnuradio-companion


Grace

--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com <https://www.nwra.com>





--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com <https://www.nwra.com>

Re: Segmentation fault trying to run gnuradio-companion

[Grace Yeung]

Thanks Marcus as always!

I upgraded from Ubuntu 20 to 22 April 2023 and everything has been working 
since until this week. And it happened after a hard reboot. I don’t recall 
manually installing gnuradio…

Thanks.

Grace

—​
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl., Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com

From: discuss-gnuradio-bounces+grace=nwra@gnu.org 
 on behalf of Marcus Müller 

Sent: Friday, August 23, 2024 6:14 PM
To: discuss-gnuradio@gnu.org 
Subject: Re: Segmentation fault trying to run gnuradio-companion

Hey, I just saw that your mail where you figured out the command line, and it 
was too big
for our mail server to forward.

Indeed, the crash log is 3.4 MB of the GTK functions calling themselves in a 
recursive
ring. Since that's a GTK bug we've never encountered: What operating system 
exactly are
you on, and how did you install GNU Radio? And: did you perhaps install GTK or 
pygtk
manually somehow?

Best,
Marcus

On 23.08.24 19:50, Grace Yeung wrote:
> Thank you Marcus. It's not running, did I type something wrong?...
>
>
>
> Also our IT saw this earlier which pointed to the gtk3 library:
>
> ... gnuradio-companion is a python script, so the python interpreter is 
> crashing.
>
>   gnuradio-compan[38828]: segfault at 7ffd5a46dff8 ip 72ee877923bb sp
> 7ffd5a46e000 error 6 in libgtk-3.so.0.2404.29[72ee87684000+38300
>
> In the gtk3 library, which is graphics related - which could be a 
> difference between a
> console and remote X11 session.
>
>
> Thank you!
>
> Grace
>
> On 8/23/24 8:04 AM, Marcus Müller wrote:
>> Hi Grace,
>>
>> this happens when one of the libraries that gnuradio-companion needs to load 
>> crashes.
>> Sadly, it's kind of hard to guess which one that would be, but on long-term 
>> expectation,
>> it's a version mismatch somewhere.
>>
>> But why guess when we can find out? The segfault error message looks like 
>> Linux, so if
>> you have `gdb` installed, you can:
>>
>> $ gdb --args $(which gnuradio-companion)
>> (gdb) set logging file gdblog.txt
>> (gdb) set logging enabled
>> (gdb) run
>> … wait for the crash to happen
>> (gdb) thread apply all backtrace
>> (gdb) quit
>>
>> and share the resulting gdblog.txt with us :)
>>
>> Gdb might ask you underway whether to enable debuginfo downloads, don't let 
>> yourself be
>> irritated by that, "y" is fine.
>>
>> Best regards,
>> Marcus
>>
>> On 22.08.24 22:35, Grace Yeung wrote:
>>> Hi, I am getting a segmentation fault trying to run gnuradio-companion from 
>>> the
>>> command-line. Any advise what to look into? Thanks.
>>>
>>> $ gnuradio-companion &
>>> [1] 6671
>>> $ >>> Warning: vocoder_codec2_decode_ps - option_attributes are for enums 
>>> only, ignoring
>>>  >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums 
>>> only, ignoring
>>>
>>> [1]+  Segmentation fault  (core dumped) gnuradio-companion
>>>
>>>
>>> Grace
>>>
>>> --
>>> Grace K. Yeung, MS
>>> Research Support Scientist
>>> NorthWest Research Associates
>>> 139 Bonifacio Pl, Suite 200
>>> Monterey, CA 93940
>>> gr...@nwra.com
>>> https://www.nwra.com
>>>
>>
>
> --
> Grace K. Yeung, MS
> Research Support Scientist
> NorthWest Research Associates
> 139 Bonifacio Pl, Suite 200
> Monterey, CA 93940
> gr...@nwra.com
> https://www.nwra.com
>

Re: Segmentation fault trying to run gnuradio-companion

[Marcus Müller]

Hey, I just saw that your mail where you figured out the command line, and it was too big 
for our mail server to forward.


Indeed, the crash log is 3.4 MB of the GTK functions calling themselves in a recursive 
ring. Since that's a GTK bug we've never encountered: What operating system exactly are 
you on, and how did you install GNU Radio? And: did you perhaps install GTK or pygtk 
manually somehow?


Best,
Marcus

On 23.08.24 19:50, Grace Yeung wrote:

Thank you Marcus. It's not running, did I type something wrong?...



Also our IT saw this earlier which pointed to the gtk3 library:

... gnuradio-companion is a python script, so the python interpreter is 
crashing.

  gnuradio-compan[38828]: segfault at 7ffd5a46dff8 ip 72ee877923bb sp
7ffd5a46e000 error 6 in libgtk-3.so.0.2404.29[72ee87684000+38300

In the gtk3 library, which is graphics related - which could be a 
difference between a
console and remote X11 session.


Thank you!

Grace

On 8/23/24 8:04 AM, Marcus Müller wrote:

Hi Grace,

this happens when one of the libraries that gnuradio-companion needs to load crashes. 
Sadly, it's kind of hard to guess which one that would be, but on long-term expectation, 
it's a version mismatch somewhere.


But why guess when we can find out? The segfault error message looks like Linux, so if 
you have `gdb` installed, you can:


$ gdb --args $(which gnuradio-companion)
(gdb) set logging file gdblog.txt
(gdb) set logging enabled
(gdb) run
… wait for the crash to happen
(gdb) thread apply all backtrace
(gdb) quit

and share the resulting gdblog.txt with us :)

Gdb might ask you underway whether to enable debuginfo downloads, don't let yourself be 
irritated by that, "y" is fine.


Best regards,
Marcus

On 22.08.24 22:35, Grace Yeung wrote:
Hi, I am getting a segmentation fault trying to run gnuradio-companion from the 
command-line. Any advise what to look into? Thanks.


$ gnuradio-companion &
[1] 6671
$ >>> Warning: vocoder_codec2_decode_ps - option_attributes are for enums only, 
ignoring
 >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums only, 
ignoring

[1]+  Segmentation fault  (core dumped) gnuradio-companion


Grace

--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com





--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com

Re: Segmentation fault trying to run gnuradio-companion

[Marcus Müller]

ah! my bad!

That first line should have read

$ gdb --args python3 $(which gnuradio-companion)

Sorry,
Marcus

On 23.08.24 19:50, Grace Yeung wrote:

Thank you Marcus. It's not running, did I type something wrong?...



Also our IT saw this earlier which pointed to the gtk3 library:

... gnuradio-companion is a python script, so the python interpreter is 
crashing.

  gnuradio-compan[38828]: segfault at 7ffd5a46dff8 ip 72ee877923bb sp
7ffd5a46e000 error 6 in libgtk-3.so.0.2404.29[72ee87684000+38300

In the gtk3 library, which is graphics related - which could be a 
difference between a
console and remote X11 session.


Thank you!

Grace

On 8/23/24 8:04 AM, Marcus Müller wrote:

Hi Grace,

this happens when one of the libraries that gnuradio-companion needs to load crashes. 
Sadly, it's kind of hard to guess which one that would be, but on long-term expectation, 
it's a version mismatch somewhere.


But why guess when we can find out? The segfault error message looks like Linux, so if 
you have `gdb` installed, you can:


$ gdb --args $(which gnuradio-companion)
(gdb) set logging file gdblog.txt
(gdb) set logging enabled
(gdb) run
… wait for the crash to happen
(gdb) thread apply all backtrace
(gdb) quit

and share the resulting gdblog.txt with us :)

Gdb might ask you underway whether to enable debuginfo downloads, don't let yourself be 
irritated by that, "y" is fine.


Best regards,
Marcus

On 22.08.24 22:35, Grace Yeung wrote:
Hi, I am getting a segmentation fault trying to run gnuradio-companion from the 
command-line. Any advise what to look into? Thanks.


$ gnuradio-companion &
[1] 6671
$ >>> Warning: vocoder_codec2_decode_ps - option_attributes are for enums only, 
ignoring
 >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums only, 
ignoring

[1]+  Segmentation fault  (core dumped) gnuradio-companion


Grace

--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com





--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com

Re: Segmentation fault trying to run gnuradio-companion

[Marcus Müller]

Hi Grace,

this happens when one of the libraries that gnuradio-companion needs to load crashes. 
Sadly, it's kind of hard to guess which one that would be, but on long-term expectation, 
it's a version mismatch somewhere.


But why guess when we can find out? The segfault error message looks like Linux, so if you 
have `gdb` installed, you can:


$ gdb --args $(which gnuradio-companion)
(gdb) set logging file gdblog.txt
(gdb) set logging enabled
(gdb) run
… wait for the crash to happen
(gdb) thread apply all backtrace
(gdb) quit

and share the resulting gdblog.txt with us :)

Gdb might ask you underway whether to enable debuginfo downloads, don't let yourself be 
irritated by that, "y" is fine.


Best regards,
Marcus

On 22.08.24 22:35, Grace Yeung wrote:
Hi, I am getting a segmentation fault trying to run gnuradio-companion from the 
command-line. Any advise what to look into? Thanks.


$ gnuradio-companion &
[1] 6671
$ >>> Warning: vocoder_codec2_decode_ps - option_attributes are for enums only, 
ignoring
 >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums only, 
ignoring

[1]+  Segmentation fault  (core dumped) gnuradio-companion


Grace

--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com

Re: Segmentation fault trying to run gnuradio-companion

[Marcus Müller]

Hi Grace,

this happens when one of the libraries that gnuradio-companion needs to load crashes. 
Sadly, it's kind of hard to guess which one that would be, but on long-term expectation, 
it's a version mismatch somewhere.


But why guess when we can find out? The segfault error message looks like Linux, so if you 
have `gdb` installed, you can:


$ gdb --args $(which gnuradio-companion)
(gdb) set logging file gdblog.txt
(gdb) set logging enabled
(gdb) run
… wait for the crash to happen
(gdb) thread apply all backtrace
(gdb) quit

and share the resulting gdblog.txt with us :)

Gdb might ask you underway whether to enable debuginfo downloads, don't let yourself be 
irritated by that, "y" is fine.


Best regards,
Marcus

On 22.08.24 22:35, Grace Yeung wrote:
Hi, I am getting a segmentation fault trying to run gnuradio-companion from the 
command-line. Any advise what to look into? Thanks.


$ gnuradio-companion &
[1] 6671
$ >>> Warning: vocoder_codec2_decode_ps - option_attributes are for enums only, 
ignoring
 >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums only, 
ignoring

[1]+  Segmentation fault  (core dumped) gnuradio-companion


Grace

--
Grace K. Yeung, MS
Research Support Scientist
NorthWest Research Associates
139 Bonifacio Pl, Suite 200
Monterey, CA 93940
gr...@nwra.com
https://www.nwra.com

Re: European GNU Radio 4.0 Days 2024 video stream?

[Krimm, Alexander]

Hello Franco,

yes, the event will be livestreamed on the youtube channel of the European 
GNURadio Days and after the event recordings of the talks will be uploaded 
there: https://www.youtube.com/@europeangnuradiodays1445

We will add a link to that to the event indico page, thanks for the heads up 
that it is missing there.

See you (virtually) there!

Alexander

--
Alexander Krimm, System Design SIS100/SIS18

Phone / Telefon: +49 6159 71 3216 Mail: a.kr...@gsi.de

GSI Helmholtzzentrum für Schwerionenforschung GmbH Planckstraße 1, 64291 
Darmstadt, Germany, www.gsi.de

Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung: Dr. Katharina Stummeyer, Jörg Blaurock
Chairman of the GSI Supervisory Board / Vorsitzender des GSI-Aufsichtsrats: 
Ministerialdirigent Dr. Volkmar Dietz


From: discuss-gnuradio-bounces+a.krimm=gsi...@gnu.org 
 on behalf of Franco VENTURI 

Sent: Thursday, August 22, 2024 3:41:07 AM
To: discuss-gnuradio@gnu.org
Subject: European GNU Radio 4.0 Days 2024 video stream?

Do you know if the European GNU Radio 4.0 Days 2024 
(https://events.gnuradio.org/event/23/) taking place next week at FAIR in 
Germany will be streamed somewhere for those who can't attend in person?

I am especially interested in the GNU Radio 4.0 presentations and tutorials for 
developers.

I looked on the page above and I couldn't find info about streaming, but 
perhaps I missed it.

Thanks,
Franco Venturi

Re: [GSoC] FEC week 10 blog post

[Marcus Müller]

Hi Kayla,

thanks for the updates :) I'm very happy to read all the progress you are making in 
bringing the aff3ct channel coders/decoders to GNU Radio!


You write you're experiencing segfaults in the BCH implementation. Especially if you get 
to run a backtrace¹ and want to share it with the mailing list, I bet there's a lot of 
people that can have a look at it.


Best regards,
Marcus

¹ something like
$> gdb --args python3 /path/to/your/testscript.py
(gdb) set logging file gdblog.txt
(gdb) set logging enabled
(gdb) run
(… wait till it crashes. you can also `run` multiple times until it does)
(gdb) thread apply all backtrace
(gdb) quit

and then share the gdblog.txt

On 20.08.24 15:08, Kayla Comer wrote:

Hi all,

Here's an update on the project from last week: 
https://kaylacomer.github.io/blog/posts/week10/ 



Best,
Kayla

Re: "File Source" to "Packet Tx" connection

[Marcus Müller]

Hi,
the "File transfer using Packet and PSK" on tutorials.gnuradio.org uses a custom python 
block to read a file into messages, which is available from the described source there.


Best regards,
Marcus

On 19.08.24 09:11, Ali G. Dezfuli wrote:

Hi all,
I want to connect a "File Source" to "Packet Tx" (the hier block).
I wonder what the best practice is.

The deprecated "Packet Encoder" got streams as input, but the new "Packet 
Encoder" just gets
messages.

versions:
     Ubuntu 22.04
     GR 3.10.11.0

Thank you!

Re: Porting an Out-of-Tree Module from GNU Radio 3.8 to 3.10

[Marcus Müller]

Hi Kunal,

as you probably have guessed, the answer is "it depends".
Usually it's not very hard to port things; just make a new module using gr_modtool, make 
the same blocks as you had before, and copy over the core functionality from your existing 
blocks – in many cases, that's just the content of the constructor and the "work" 
function. Many blocks have zero custom code aside from that!


However, some do. Most blocks don't make extensive use of the finer parts of PMT (which 
has gotten better API lately) etc. Some do!


Also, we don't know the quality of the code you'll be porting. Do you know the feeling 
when you sit down with some code and are unsure whether you're just not understanding 
things correctly or the code has errors, and you start to look for the test cases, so you 
know whether things you try are still correct? And then there's no test cases and you need 
to write them yourself, and then you realize the original author never bothered to 
actually verify whether what they do is correct? That might be the point where you decide 
to rewrite from scratch, anyways.


So, really, you'll need to sit down and try with the code you have. It **probably** is 
pretty easy to get ported (and seriously, people will be helpful if you ask questions 
here!). Most GNU Radio OOT modules aren't badly written and well worth porting!


Best,
Marcus

On 18.08.24 05:11, KunalPrabhakar Sangurmath wrote:

Hi everyone,

I'm currently working on an Out-of-Tree (OOT) module that was originally developed for GNU 
Radio 3.8. I need some advice on the best approach to port this module to GNU Radio 3.10:


1. Should I port the existing 3.8 version directly to 3.10, if yes, how or
2. Would it be better to start from scratch and implement the module in 3.10?

I'd appreciate your thoughts on which option might be more efficient and 
reliable.

Thanks,
Kunal.

Re: [Clarification] Order of filter

[Marcus D. Leech]

On 12/08/2024 11:07, Steve Hageman wrote:
One clarification - On Stacking the digital filters - the bandwidth 
does not narrow - I misspoke. Naturally being a Hardware Guy I forgot 
that the digital filters do no load each other, like analog filters can.


(I should never type before two cups of coffee in the morning - 
forgive me).  ;-)



Actually, considering the quick flow-graph below, using a 
complex-low-pass as a symmetric bandpass, you can see that
  doubling-up the same filter produces much more out-of-band 
attenuation, but also slightly-steeper "skirts".




filters.grc
Description: application/gnuradio-grc

Re: [Clarification] Order of filter

[Muhammad Anas]

Thanks for the explanation.

On Mon, Aug 12, 2024, 8:07 PM Steve Hageman 
wrote:

> One clarification - On Stacking the digital filters - the bandwidth does
> not narrow - I misspoke. Naturally being a Hardware Guy I forgot that
> the digital filters do no load each other, like analog filters can.
>
> (I should never type before two cups of coffee in the morning - forgive
> me).  ;-)
>
>
>

Re: Order of filter

[Steve Hageman]

Hello Muhammad - Analog filters are designed much like Digital filters, 
but the implementation is different.


In any filter there are these general parameters,

Filter function: Lpw Pass, High Pass, Bandpass
Filter type (butterworth, chebychev, bessel, linear phase, etc)
Passband ripple,
Cutoff frequency (with some dB specification at the cutoff),
Stopband frequency
Stopband attenuation

In an analog filter one can look at the classic textbook attenuation 
curves to determine the filter 'Order' for the specifications above.


In a digital filter we can use a tool like the GNU Radio supplied 
'Filter Design Tool' to determine the number of 'Taps'.


Point 1) There really isn't an equivalent between the Analog Filter 
Order and the Digital Filter 'Taps', but for a specific design you can 
do the design back and forth between both domains and you will probably 
see some correlation between Order and Taps for that specific design.


Point 2) If you wish to get a rough equivalent to the 'Analog Order' of 
a digital filter you can go look in any filter textbook and check the 
curves out for the specifications given.


Point 3) If you stack two say: 1st Order, 1 kHz cutoff low pass filters 
Active Analog Filters together and measure the response you will find 
that the cutoff frequency measures around 640 Hz. This is because the 
filters react with each other to make a narrower passband. For higher 
order filters the design must take into account the number of stages (ot 
Taps) to properly calculate the pole locations. The same thing happens 
with a digital filter, namely stacking identical filters will result in 
the passband getting narrower, although the ultimate stopband 
attenuation will increase. (I talked about the LPF case here, the 
classic BPF and HPF equivalents can be found in any filter textbook).


A quick way to play with filters in GNURadio is to design a filter 
block, add a noise source as the input and look at the 'Averaged' output 
with a QT Frequency Sink Block - there you will see the basic response 
curve.


Hope this brief overview helps.

Steve Hageman

Re: Ettus N200 Connecting to Device

[Marcus D. Leech]

On 08/08/2024 20:48, Q W wrote:

Hi Marcus,

Thanks very much for your comments. I am sorry for sending my enquiry 
to the wrong mail-list. I agree with you that usrp users mailing list 
would be a better place to seek for help.


I am new to SDRs and this mail list system, and really appreciate your 
feedback. I come from the theoretical study of wireless 
communications, and this is my first practical project. Would you 
please be more specific on SPI and GPIO on N200? I reckon there won't 
be heavy traffic on the SPI/GPIO connection for control signals, so 
not sure if high data rate is necessary. Also can you please advise if 
there is any other interface on N200/N210 which I can use for the 
control purpose?


Kind regards,
Tom
The SPI interface from the motherboard is really intended for 
communication with the internal workings of the daughtercards

  it connects to.

The GPIO is normally controlled by a host-based API, but one could write 
custom FPGA code to make GPIO do things in a more
  "clocked" fashion. One could even, I suppose, bring the SPI signals 
out of the box, but that isn't a supported thing, and

  both host-side and FPGA code would likely be required to make that work.

The N200 isn't really intended to operate without *SOME* kind of 
daughtercard(s) installed.  The motherboard itself

  doesn't really "do" RF by itself.




On Friday, 9 August 2024 at 10:28:00 am AEST, Marcus D. Leech 
 wrote:



On 08/08/2024 20:18, Q W wrote:
Hi there,

We are considering using a USRP N200 for a project, and want to figure 
out some technical details before placing the order. We plan to use 
N200 to control our own device based on the analog RF signal sent from 
the device.


The general structure is to have the device’s output connected to the 
Rx port of N200. The outputsignal is processed in N200 and leads to 
the control (digital) signals which are fed back to tune the device. 
We plan to use SPI/GPIO ports for the feedback channel. My question is 
if such SPI/GPIO ports are available on N200? Please note that our 
device is not a daughter board, so I am not sure if the SPI/GPIO shown 
on the data sheet of N200 can be used for the control purpose.


If SPI/GPIO is not available for such control, is there any other 
connection interface for the control signal sent from N200? Our own 
device can be relatively flexible, so any connection scheme can be 
considered.


Kind regards,

Tom


USRP-specific questions should probably be posted on the usrp-users 
mailing list, rather than here.


However.  In the N200/N210 devices, the GPIO was exposed on the 
daughtercards.  SPI was really only used internally,

  between the motherboard and whatever daughter card(s) were installed.

The GPIO wasn't really designed for high-speed "stuff", which is what 
you'd need to "bit bang" an SPI interface out of

 the GPIO pins on whatever daughtercard you're using.

Re: Ettus N200 Connecting to Device

[Q W]

 Hi Marcus,
Thanks very much for your comments. I am sorry for sending my enquiry to the 
wrong mail-list. I agree with you that usrp users mailing list would be a 
better place to seek for help.
I am new to SDRs and this mail list system, and really appreciate your 
feedback. I come from the theoretical study of wireless communications, and 
this is my first practical project. Would you please be more specific on SPI 
and GPIO on N200? I reckon there won't be heavy traffic on the SPI/GPIO 
connection for control signals, so not sure if high data rate is necessary. 
Also can you please advise if there is any other interface on N200/N210 which I 
can use for the control purpose?
Kind regards,Tom 
On Friday, 9 August 2024 at 10:28:00 am AEST, Marcus D. Leech 
 wrote:  
 
  On 08/08/2024 20:18, Q W wrote:
  
 
 Hi there,   
We are considering using a USRP N200 for a project, and want to figure out some 
technical details before placing the order. We plan to use N200 to control our 
own device based on the analog RF signal sent from the device.
 The general structure is to have the device’s output connected to the Rx port 
of N200. The output signal is processed in N200 and leads to the control 
(digital) signals which are fed back to tune the device. We plan to use 
SPI/GPIO ports for the feedback channel. My question is if such SPI/GPIO ports 
are available on N200? Please note that our device is not a daughter board, so 
I am not sure if the SPI/GPIO shown on the data sheet of N200 can be used for 
the control purpose.  
  If SPI/GPIO is not available for such control, is there any other connection 
interface for the control signal sent from N200? Our own device can be 
relatively flexible, so any connection scheme can be considered.   
Kind regards,
 
Tom
  
   USRP-specific questions should probably be posted on the usrp-users mailing 
list, rather than here.
 
 However.  In the N200/N210 devices, the GPIO was exposed on the daughtercards. 
 SPI was really only used internally,
   between the motherboard and whatever daughter card(s) were installed.
 
 The GPIO wasn't really designed for high-speed "stuff", which is what you'd 
need to "bit bang" an SPI interface out of
  the GPIO pins on whatever daughtercard you're using.
 
 
   

Re: Ettus N200 Connecting to Device

[Marcus D. Leech]

On 08/08/2024 20:18, Q W wrote:

Hi there,

We are considering using a USRP N200 for a project, and want to figure 
out some technical details before placing the order. We plan to use 
N200 to control our own device based on the analog RF signal sent from 
the device.


The general structure is to have the device’s output connected to the 
Rx port of N200. The outputsignal is processed in N200 and leads to 
the control (digital) signals which are fed back to tune the device. 
We plan to use SPI/GPIO ports for the feedback channel. My question is 
if such SPI/GPIO ports are available on N200? Please note that our 
device is not a daughter board, so I am not sure if the SPI/GPIO shown 
on the data sheet of N200 can be used for the control purpose.


If SPI/GPIO is not available for such control, is there any other 
connection interface for the control signal sent from N200? Our own 
device can be relatively flexible, so any connection scheme can be 
considered.


Kind regards,

Tom


USRP-specific questions should probably be posted on the usrp-users 
mailing list, rather than here.


However.  In the N200/N210 devices, the GPIO was exposed on the 
daughtercards.  SPI was really only used internally,

  between the motherboard and whatever daughter card(s) were installed.

The GPIO wasn't really designed for high-speed "stuff", which is what 
you'd need to "bit bang" an SPI interface out of

 the GPIO pins on whatever daughtercard you're using.

Re: Synchronising CSI readings from 2 receivers.

[Sourya Saha]

Thanks, I'll check it out.

On Thu, 8 Aug 2024, 1:09 pm Marcus Müller,  wrote:

> Hi Sourya,
>
> that is a different thing than you asked about originally :)
>
> But in this case, this is "just" a matter of phase synchronizing different
> USRPs. See
> http://kb.ettus.com (and the Application notes there) on how, and for
> which specific USRP
> types, that can be achieved. All the things described there translate to
> GNU Radio.
>
> Best,
> Marcus
>
> On 08.08.24 18:47, Sourya Saha wrote:
> > Hi Marcus,
> > By synchronized, I mean synchronization in phase and clock. I am not
> worrying about the
> > CSI estimate because I can get that through the gr-ieee802-11 module
> itself. I am worried
> > about phase and clock synchronizing 2 different USRPs in GNURadio. I do
> know that an
> > octoclock can be used. But is there any other way to do it without any
> external hardware?
> >
> > On Thu, Aug 8, 2024 at 12:44 PM Marcus Müller  > > wrote:
> >
> > Hi,
> > can you elaborate what you mean with "synchronized"? A CSI estimate
> can only happen when
> > the necessary pilots have been observed, and that will, due to
> finite speed of light,
> > necessarily happen at different times at different receivers.
> >
> > Best,
> > Marcus
> >
> > On 08.08.24 18:19, Sourya Saha wrote:
> >  > Hi.
> >  > I am working on an application which utilises the gr-ieee802-11
> module. I need to
> > collect
> >  > readings from 2 receivers. However, I want them synchronised.
> What would be the
> > best way
> >  > to do that in GNURadio?
> >
>

Re: Synchronising CSI readings from 2 receivers.

[Marcus Müller]

Hi Sourya,

that is a different thing than you asked about originally :)

But in this case, this is "just" a matter of phase synchronizing different USRPs. See 
http://kb.ettus.com (and the Application notes there) on how, and for which specific USRP 
types, that can be achieved. All the things described there translate to GNU Radio.


Best,
Marcus

On 08.08.24 18:47, Sourya Saha wrote:

Hi Marcus,
By synchronized, I mean synchronization in phase and clock. I am not worrying about the 
CSI estimate because I can get that through the gr-ieee802-11 module itself. I am worried 
about phase and clock synchronizing 2 different USRPs in GNURadio. I do know that an 
octoclock can be used. But is there any other way to do it without any external hardware?


On Thu, Aug 8, 2024 at 12:44 PM Marcus Müller > wrote:


Hi,
can you elaborate what you mean with "synchronized"? A CSI estimate can 
only happen when
the necessary pilots have been observed, and that will, due to finite speed 
of light,
necessarily happen at different times at different receivers.

Best,
Marcus

On 08.08.24 18:19, Sourya Saha wrote:
 > Hi.
 > I am working on an application which utilises the gr-ieee802-11 module. 
I need to
collect
 > readings from 2 receivers. However, I want them synchronised. What would 
be the
best way
 > to do that in GNURadio?

Re: Synchronising CSI readings from 2 receivers.

[Marcus Müller]

Hi,
can you elaborate what you mean with "synchronized"? A CSI estimate can only happen when 
the necessary pilots have been observed, and that will, due to finite speed of light, 
necessarily happen at different times at different receivers.


Best,
Marcus

On 08.08.24 18:19, Sourya Saha wrote:

Hi.
I am working on an application which utilises the gr-ieee802-11 module. I need to collect 
readings from 2 receivers. However, I want them synchronised. What would be the best way 
to do that in GNURadio?

Re: cmakelists.txt fot C++ IDE

[Ali G. Dezfuli]

Done! Big Thanks!
I just connected a "Signal Source" to a "Null Sink" in GRC, changed the
Option's "Output Language" to C++,
pushed "Generate" (F5), took a look at the generated CMakeLists.txt, and
found the answer.

Thanks!

On Thu, Aug 1, 2024 at 10:15 PM Marcus Müller  wrote:

> Hi Ali,
>
> since CMake is the default build system we use both for our OOT templates
> (as used by
> gr_modtool) and by the C++ code generated throug GRC, I'd say:
>
> just use the existing work as template.
>
> What you're doing here is mixing modern CMake, i.e. a config/target-based
> method of
> defining the compiler and linker properties of your compilation units,
> with manual
> "include_directories" things. Probably not a great idea! If you compare
> that with what
> `gr_modtool` generates in its lib/CMakeLists.txt, you'll find how we'd, as
> a project,
> would recommend you do it.
>
> Best,
> Marcus
>
> On 01.08.24 11:17, Ali G. Dezfuli wrote:
> > Hi all,
> > I want to work with simple gnuradio objects in a C++ IDE (e.g.
> Qtcreator) using CMake
> > build system.
> > I am running ubuntu 22.04 and gnuradio 3.10.11.0.
> > How can I write its cmakelists.txt?
> >
> > For example, to just test these PMT lines:
> >
> > #include// [...]
> >
> pmt::pmt_tP=pmt::from_long(23);std::cout< >
> > I add the following lines to its cmakelists.tx
> >
> > # Find GNU Radio package, specifying required components
> > find_package(Gnuradio "3.10" REQUIRED COMPONENTS pmt)  # Adjust the
> version and components
> > as needed
> >
> > # Check if GNU Radio is found
> > if(Gnuradio_FOUND)
> >  message(STATUS "GNU Radio found.")
> >  message(STATUS "GNU Radio include dirs: ${Gnuradio_INCLUDE_DIRS}")
> >  message(STATUS "GNU Radio libraries: ${Gnuradio_LIBRARIES}")
> > else()
> >  message(FATAL_ERROR "GNU Radio not found!")
> > endif()
> >
> > # Include directories for your project
> > include_directories(
> >  ${Gnuradio_INCLUDE_DIRS}  # GNU Radio include directories
> >  ${CMAKE_SOURCE_DIR}/include  # Your custom include directories
> > )
> >
> > # Define the executable
> > add_executable(myproject${SOURCES})
> >
> > # Link the executable with GNU Radio libraries
> > target_link_libraries(myproject ${GNURADIO_LIBRARIES})
> >
> > but it doesn't work.
> >
> > I'd be grateful if someone help me write working cmakelists.txt.
> >
> > Thanks!
> >
>
>

Re: cmakelists.txt fot C++ IDE

[Marcus Müller]

Hi Ali,

since CMake is the default build system we use both for our OOT templates (as used by 
gr_modtool) and by the C++ code generated throug GRC, I'd say:


just use the existing work as template.

What you're doing here is mixing modern CMake, i.e. a config/target-based method of 
defining the compiler and linker properties of your compilation units, with manual 
"include_directories" things. Probably not a great idea! If you compare that with what 
`gr_modtool` generates in its lib/CMakeLists.txt, you'll find how we'd, as a project, 
would recommend you do it.


Best,
Marcus

On 01.08.24 11:17, Ali G. Dezfuli wrote:

Hi all,
I want to work with simple gnuradio objects in a C++ IDE (e.g. Qtcreator) using CMake 
build system.

I am running ubuntu 22.04 and gnuradio 3.10.11.0.
How can I write its cmakelists.txt?

For example, to just test these PMT lines:

#include// [...] 
pmt::pmt_tP=pmt::from_long(23);std::cout<

I add the following lines to its cmakelists.tx

# Find GNU Radio package, specifying required components
find_package(Gnuradio "3.10" REQUIRED COMPONENTS pmt)  # Adjust the version and components 
as needed


# Check if GNU Radio is found
if(Gnuradio_FOUND)
     message(STATUS "GNU Radio found.")
     message(STATUS "GNU Radio include dirs: ${Gnuradio_INCLUDE_DIRS}")
     message(STATUS "GNU Radio libraries: ${Gnuradio_LIBRARIES}")
else()
     message(FATAL_ERROR "GNU Radio not found!")
endif()

# Include directories for your project
include_directories(
     ${Gnuradio_INCLUDE_DIRS}  # GNU Radio include directories
     ${CMAKE_SOURCE_DIR}/include  # Your custom include directories
)

# Define the executable
add_executable(myproject${SOURCES})

# Link the executable with GNU Radio libraries
target_link_libraries(myproject ${GNURADIO_LIBRARIES})

but it doesn't work.

I'd be grateful if someone help me write working cmakelists.txt.

Thanks!

Re: cmakelists.txt fot C++ IDE

[A. Maitland Bottoms]

"Ali G. Dezfuli"  writes:

> Hi all,
> I want to work with simple gnuradio objects in a C++ IDE (e.g. Qtcreator)
> using CMake build system.
> I am running ubuntu 22.04 and gnuradio 3.10.11.0.
> How can I write its cmakelists.txt?

The components are now available as CMake gnuradio::gnuradio-COMPONENT targets.

> # Link the executable with GNU Radio libraries
> target_link_libraries(myproject ${GNURADIO_LIBRARIES})

instead:

target_link_libraries(myproject gnuradio::gnuradio-pmt)

should do the trick.

73 de aa4hs,
-Maitland