Re: ALSA sink

[Marcus Müller]

Hi Ivan,

excellent investigation. I must admit that I don't know what could've gone wrong there, 
because if the program flow reaches the point at which it can throw that error,


https://github.com/gnuradio/gnuradio/blob/0425a9c9b5b4934fdab89812bce315e2f47d9956/gr-audio/lib/alsa/alsa_sink.cc#L175-L178

the setting of the sample rate must have already worked. Maybe the ALSA sink is expecting 
things that aren't true for your PCM device? Maybe the PCM device is strrange? Hard to 
tell, not enough of an internals expert for ALSA, to be honest. Hm.


I'd propose this:

1. we do a quick sanity check on the demand on the length of the period with a 
debugger
2. we try whether the portaudio wrapper around ALSA is smarter than the 
alsa_sink itself.

So, diving straight in:


   1. debugging

you have your C++ program, awesome, that makes a lot of things easier.

Install gdb, and debugging symbols for GNU Radio and ALSA (I'm not sure whether Arch does 
that automatically, or supports debuginfod?); then run


gdb --args ./yourprogram [arguments if any]

on the gdb shell

(gdb) start
(gdb) break snd_pcm_hw_params_set_periods
(gdb) continue

… you wait until it hits the point at which we call into snd_pcm_hw_params_set_periods; 
you should see something like


Thread 1 "dial_tone" hit Breakpoint 2, snd_pcm_hw_params_set_periods 
(pcm=0x47a9b0, params=0x423360, val=32, dir=0) at pcm/pcm.c:5601

What's the value of "val" for you?

we can also explicitly print d_nperiods, min_nperiods, and max_nperiods

(gdb) frame 1
(gdb) printf "max: %d, min: %d; d_: %d\n", max_nperiods, min_nperiods, 
d_nperiods

Hope these numbers make sense?



   2. trying whether portaudio sets up ALSA "smarter"

run

gnuradio-config-info --userprefsdir

and make a new file in that directory, let's call it "use_portaudio.conf", with 
the content

[audio]
audio_module=portaudio

and try again to run your Python or C++ flowgraph.




Hope this gets us closer to a solution!

Best regards,
Marcus

On 01.05.24 15:51, Ivan wrote:


Hey, everybody.

I am just starting to try GNUradio and I am facing some difficulties. Maybe someone can 
comment and suggest a direction to find an answer to my question.


I have GNUradio 3.10.9.2 installed on ArchLinux; in gnuradio-companion I created a 
simple flowgraph: noise source -> throttle -> audio sink.


My problem is that if I specify as device name my device in audio sink, the start of the 
flowgraph fails:


File “/home/user/gnuradio/alsa1.py”, line 70, in __init__
 self.audio_sink_0 = audio.sink(48000, 'k15', True)
    ^^
RuntimeError: audio_alsa_sink


I'll clarify at this point that the name of the ALSA device, k15, is defined in 
~/.asoundrc and the device itself is a software audio resampler implemented in the ALSA 
subsystem, that's how it's defined:


pcm.k15 {
   type rate
  slave {
 pcm default
 rate 48000
  }
   converter “samplerate_linear”
}

This device takes an audio stream, resamples it to 48000 and sends it to the sound 
controller with a sampling rate of 48000 allowed for it.


This device works great when using different programs, like aplay, with different sample 
rates and parameters, example:


aplay -D k15 -c 1 -r 1 -f S32_LE /dev/urandom (sound mono, sample rate 1, format 
S32_LE).


But it doesn't work with GNUradio.

Can anyone suggest what could be the reason for the error of working with this sound 
device ?


Another thing: if I compile the flowgraph into C++ and then into an executable file, the 
error looks like this:


audio_alsa_sink :error: [k15]: set_periods failed: Invalid argument

Thank you.

Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer

[Marcus Müller]

Hi Adrian,

that's definitely quite cool! Thanks for sharing it with us :)

I gave it a quick skim, and it's a bit surprising how much latency you get; this might 
have to do with GNU Radio's buffer sizes. The growing latency on UHD does in fact worry 
me, but I think it would indeed need more investigation (the good news is that there's no 
space for the USRP to store that much signal for it to have that much latency on the 
hardware side, so this must be something on the host).


Out of interest: how long are these timeslots?

Best,
Marcus

On 17.04.24 17:50, Adrian Musceac wrote:

Hello,

I would like to share with you the following page containing details of a
project to create a DMR tier III trunked radio base transceiver station
(usable for amateur radio digital voice comms and experimentation) in software
defined radio:
http://qradiolink.org/DMR-tier-3-trunked-radio-BTS-software-defined-radio.html

It involves GNU Radio since the lower physical layer, concerned with frequency
modulation and demodulation, filtering, resampling, as well as frequency
division and time division multiplexing are performed in GNU Radio C++
flowgraphs and also using some custom blocks created for this purpose.

I hope you find this interesting and on-topic for this list, and thanks for all
the help received in the community discussion channels. Since it is likely the
page and code may contain mistakes, I would welcome any corrections or
additions.

Best regards,
Adrian YO8RZZ

Re: Audio source - device or resource busy error

[Marcus Müller]

Hi Jim,
so, that's an interesting problem with your sound system. I don't see why it *should* fail 
at six created sources (my suspicion is that the non-deterministic destruction of objects 
that is inherent to Python means there's six parallel endpoints active, from a perspective 
of ALSA and pulseaudio).

Sadly, we don't have a test that covers this (yet?).
Maybe this is a problem specific to the way the ALSA source works.

Would be able to test the portaudio sink? For that, we'll have to force GNU Radio to use 
it (because it uses ALSA by default). You can do that by adding


[audio]
audio_module = portaudio

to your GNU Radio configuration, so to a file ending in .conf (e.g., audio.conf) in the 
directory that `gnuradio-config-info --userprefsdir` shows.


Best regards,
Marcus


On 15.04.24 02:18, Elmore Family wrote:

Marcus,

I first tried:
For ALSA users with audio trouble, follow this procedure ( which I followed):

The result was the same.

Then I selected pulse as the device name. it worked for 6 iterations of the loop and then 
gave the following error:


mmap() failed: Cannot allocate memory
mmap() failed: Cannot allocate memory
gr::log :ERROR: audio_alsa_source6 - [pulse]: Input/output error
Traceback (most recent call last):
  File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 337, in 
    main()
  File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 320, in main
    FT8_Receive.main()
  File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 205, in main
    tb = top_block_cls()
  File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 85, in __init__
    self.audio_source_0 = audio.source(samp_rate, 'pulse', True)
RuntimeError: audio_alsa_source

Jim

-Original Message- From: Marcus Müller
Sent: Sunday, April 14, 2024 3:45 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Audio source - device or resource busy error

Hi Jim,

try not using the direct hardware device, but the device provided by your sound 
system;
see the "for users wiht audio trouble" section on the Audio Source 
documentation page.

Best regards,
Marcus

On 14.04.24 18:02, Elmore Family wrote:
I am getting the subject error when running a Python script called repeatedly from 
another script.

The snippet_ft8_rxtx.py shows the call, FT8_Receive.main(), in the while loop.
FT8_Receive.py shows the called script.
FT8_Receive.pdf is the flowgraph used to generate the called script which as you can see 
has been modified in main() and with check_time added.
The first call to the script is OK but the second call results in the error shown in 
audio_error.txt.
Why is the audio source busy when the flowgraph is stopped (or is it not stopped?) and 
how do I fix the issue?

Jim

<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
 Virus-free.www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

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

Re: Audio source - device or resource busy error

[Marcus Müller]

Hi Jim,

try not using the direct hardware device, but the device provided by your sound system; 
see the "for users wiht audio trouble" section on the Audio Source documentation page.


Best regards,
Marcus

On 14.04.24 18:02, Elmore Family wrote:
I am getting the subject error when running a Python script called repeatedly from another 
script.

The snippet_ft8_rxtx.py shows the call, FT8_Receive.main(), in the while loop.
FT8_Receive.py shows the called script.
FT8_Receive.pdf is the flowgraph used to generate the called script which as you can see 
has been modified in main() and with check_time added.
The first call to the script is OK but the second call results in the error shown in 
audio_error.txt.
Why is the audio source busy when the flowgraph is stopped (or is it not stopped?) and how 
do I fix the issue?

Jim


  Virus-free.www.avg.com 


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

Re: Modulation and demodulation issues

[Marcus Müller]

Hi Jiya,

that image is too small. I can't read anything. You could use the "Screen Capture" Feature 
of GRC to export an arbitrary zoomable PDF document.


Best regards,
Marcus

On 13.04.24 10:53, Jiya Johnson wrote:

Greetings everyone,
Done with BPSK,PM modulation with some doppler effects but not able to the effective 
demodulation back with the gnuradio not able to trace back ASM after decoding the data 
bits are completely different.

image.png

Re: Inquiring about an old GSoC

[Marcus Müller]

I'll brazenly forward that question to Luca here :) The honest answer is 
that you should really not blame Luca, time was short (and is always 
short), and we (and especially I) never gotten around to bring this to a 
state where it can be upstreamed.


Any help achieving that would be greatly appreciated! Regarding 
necessary changes: yes, a few things will need to be updated to GNU 
Radio 3.10, but that's mostly syntax, not functionality. If you want to 
pick up the job of updating things to 3.10, you can be sure I'd support you.


Best regards,
Marcus Müller

On 2024-04-11 03:03, Chaz Maschman wrote:

Hello GNU Radio folk,


I have been attempting to use MIMO technology within GNU Radio and have 
stumbled upon an old Google Summer of Code project sponsored by GNU Radio that 
does everything I could have wanted to do but in a more competent manner:
https://mimognuradio.wordpress.com/
https://github.com/kit-cel/gnuradio

The commentary by the developer surrounding this suggests that he expected or 
intended for the final code to be merged into GNU Radio, but it seems like it 
never was. Is there a reason for this? Is there anything that needs to be 
changed from the code for it to be merged?

Sincerely,
Chaz M.

Re: Viewing other signals in OFDM

[Marcus Müller]

Hi Sourya,

> However, I want to attempt to view signals in OFDM receiver which are being sent using 
a non-OFDM transmitter.


how is that supposed to work? An OFDM receiver necessarily needs to synchronize to the 
OFDM transmission.


Without an OFDM transmission, there's nothing to synchronize to.

A working OFDM receiver will hence simply *not* receive something outside of the 
possibility of mis-detecting something as OFDM that isn't, and in that rare and probably 
very intermittent case, what you then get would be totally random nonsense.


You can throw out the OFDM part and just use the DFT to estimate the spectrum, but that's 
just that: the spectrum of the reception, not giving you much to go on about the frequency 
responses of the channels observed:


> What I actually want to see is the frequency response of the signals on the subcarriers 
on the receiving side.


Without OFDM, no subcarriers exist. So, we can talk about the frequency response of the 
channel, if you like. Yes, you can do *blind* channel estimation (i.e., estimating the 
channel without knowing characteristics of the signal transmitted over said channel), but 
it's not going to be possible with an OFDM receiver.


> What would be the right way to move forward with this?

Honestly: forget about OFDM, and learn about *blind channel estimation*.

In multiple of your previous emails (including this) I had the feeling that, although I've 
pointed you to OFDM literature, you at best skimmed that and never developed a 
mathematical understanding for why you use it, how it works, and why it's implemented that 
way.¹


Channel estimation is a more mathematical problem, and you won't build something useful 
without having a solid understanding of the fundamentals; you need books at this point, 
not software:


I'd personally re-read the basics chapters of Kay, Steven: Statistical Signal Processing 
Vol 1: Estimation Theory, because that's what some of the material that I learned with was 
based on, then followed by the famous Kailath report on sampling time-variant filters 
(which fits the channel model you'd use OFDM in, anyways), but I think this might not fit 
you well. However,


D. Manolakis, V. Ingle, and S. Kogon, Statistical and Adaptive Signal 
Processing. 2005.

might be more of your way! You'd need to understand what an equalizer is, in detail, why 
you need one, and what the problems estimating the channel for one are. But these are the 
same basics you would have to learn to really understand why you're doing OFDM, so you 
need to read that, anyways.


---

So here comes the part were I advise you if we'd be working at the same institute. You 
seem to be doing a thesis on this, so:


Write an email to your advisor. Advisors are typically people that are busy, and have to, 
but also want to, supervise students. Their least favorite kind of student is the one that 
doesn't come and ask questions and delivers no results; their favorite kind of student is 
the one that comes, asks good questions that help the advisor understand their own 
research better and help refine the goal of the thesis the student is doing, and then in 
the end deliver interesting results. I've myself been the question-answering, 
does-more-on-other-student's-projects-than-he-should kind of student, back in the day; I 
leave the assessment of my results up to my former advisors. I learned a lot during my 
theses! It does mean reading stuff you don't understand the first time around, noting down 
questions, trying to answer these yourself, dropping by your advisor's office occasionally 
(or them dropping by at your desk), getting the rest answered or categorized as "that's 
not relevant to your thesis right now".


So, write an email to your advisor. Start it with a short description of what you think 
your current task is, and a sentence on why you think that. Just forward this email to 
them and say that while you were researching (and I swear your advisor will love that 
you've been researching and talking to experts on your own!) this grumpy guy on the 
internet told you that an OFDM receiver is not what you need, that a blind channel 
estimation / blind equalization approach is probably what you need, and had literature 
recommendations. Say you're attaching the email, because you want to discuss the right way 
to move forward.


I say this because your question,

> What would be the right way to move forward with this?

is one that makes advisors very happy. You've researched stuff, you hit an obstacle, you 
identified the obstacle, and you wonder where to go next. Helping you choose where to go 
next is *literally* the advisor's job. And it's also *literally* in their own interest, 
because they *want* you to succeed in your thesis because ideally, your results help them 
understand their own topics better.


Best regards,
Marcus

¹ per my mail from the 13th of March:

If you have a good basic education in digital communications, Proakis' 

Re: Building OOT module on windows

[Marcus Müller]

Yes; https://lists.gnu.org/archive/html/discuss-gnuradio/2022-03/msg00047.html

On 23.03.24 20:14, Sourya Saha wrote:

Is there any way to build OOT module on Windows

Beginner-Friendly Issue of the week

[Marcus Müller]

Hi everybody,

we're cleaning out the issue tracker. Some things are important, but falling off our list 
of things we can reasonably manage to do. Some of these things are not actually hard, I 
think, but need someone who can work with GRC and attack these.


This is one of these issues:

https://github.com/gnuradio/gnuradio/issues/1106, "Deprecate packet 
synchronizers"

These blocks have been around forever, and I don't even know whether every single one of 
them still exists. Someone could go through the list and just search for the strings that 
don't have a file name attached to them and see whether they still exist, and comment on that.


Afterwards, they could go through that list and do:

for each individual block mentioned

1. add the |flags: [deprecated]| property to each block's
   gr-something/grc/something_blockname.block.yml,
2. Make sure the block still shows up correctly in GRC, but marked as 
deprecated (orange!)
3. search the examples whether any existing example uses the block
4. open a new issue "remove or update example XYZ to not use deprecated block" 
for each
   affected example
5. (equally important) add a remark to the block's wiki page (if it exists) 
that it's
   deprecated, in bold, quite at the beginning of each page

while doing this, talking to the people in the #docs Matrix chat room is probably a good 
idea, they have a good idea of existing examples, and the wiki.



Best regards,
Marcus

Re: Prospective GSoC contributor introduction

[Marcus Müller]

Hi Hamza,

I don't know whether someone else has reached out to you already. In any case, I'm happy 
you found your way to the mailing list!
It's great to hear you've been going through the tutorials already, that is a good basis. 
If you want to ask questions about anything code-related, or about an approach you have 
for what you'll be doing, do reach out to use here on the mailing list or in the 
#gnuradio:gnuradio.org matrix chat room, as explained in [1].


Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php?title=Chat

On 15.03.24 22:38, Hamza Mohammed wrote:

Hi,
My name is Hamza Hasan, I am a 3rd year Student in Egypt, majoring in Communication 
Engineering. I am interested in contributing to gnu-radio through GsoC, specifically the 
project titled "Forward Error Correction in GNU Radio". I just heard about gnu radio 
recently (in my university we mostly use Matlab for DSP) from GsoC and I have been going 
over the tutorials for the past days. As I am becoming more familiar with the repository 
and software, I figured I might introduce myself here on the mailing list.

Steps towards a GSoC proposal for project "GRC: built-in flowgrpahs…" (was: Regarding GSoC)

[Marcus Müller]

Hi Adarsh,

nice to have you around!
Since you are choosing a topic where familiarity with the workflow in GRC is necessary, it 
would be a good point in time to start working through the tutorials 
https://tutorials.gnuradio.org ; you'll want to know how to create your own flow graph, be 
familiar with the terminology (Blocks, flow graphs, hierarchical block, …) when you start 
writing your proposal.


If while working through the tutorials you have questions, you can always find helpful 
people here on the mailing list, or on the #gnuradio:gnuradio.org chat room (see [1] on 
how to reach that). The same, and even more, applies when you want to discuss approaches 
to the problem before finalizing your proposal!


Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php?title=Chat

On 23.03.24 14:41, Adarsh Sudheer wrote:

Hello Everyone,

I am Adarsh Sudheer and i am currently pursuing my 2nd year CS undergraduate at 
Amrita
University. I am interested in learning technologies related to python  and cpp. I will be 
very happy to work with you all in accomplishing our goals. I will very happy to work on 
the topic of GRC: Build-in sub flowgraphs involving python


With Regards
Adarsh Sudheer

Re: Constellation object for ASK

[Marcus Müller]

Hi,

that would be called "OOK", on-off-keying, usually, because 0·3 = 0; it has very low 
spectral efficiency. Its constellation points would hence be 0 and 3, so the argument to 
the constellation object would be [0, 3].


Do note that by default, SDR frontend drivers are configured to map numbers with magnitude 
1 to maximum DAC output; you using 3 does sound a bit questionable here, unless you use 
that constellation then in a different more complex system and adjust the amplitude of the 
result.


Best regards,
Marcus


On 21.03.24 17:32, Sourya Saha wrote:

Hi.
I was wondering what would the parameters of the constellation object be if I am doing 
ASK modulation by multiplying each bit with a constant 3?

Re: GNURadio OFDM multiple data in subcarriers.

[Marcus Müller]

Hi Sourya,

before embarking on that endeavour: Have you made sure you can transmit a single file on 
all subcarriers?


Best,
Marcus

On 18.03.24 18:15, Sourya Saha wrote:

Hi all,
I was trying to send contents of a file using a single subcarrier in OFDM. As Marcus 
pointed out, it is a complex process and i found out that using a single data carrier 
for the main data apart from the carriers for the header and sync words, the channel 
estimation takes forever. The data is never decoded.


What I want to do is use different subcarriers of the OFDM transmitter to send different 
file contents. Say use subcarrier 3, 4 to send contents of file 1 and subcarriers 7, 8 
to send contents of file 2. I want to do it simultaneously. I am using USRP B200 on 
both. I tried using 2 flowgraphs, one for each file, in the same grc file for doing it. 
The transmitter seems to send the required data. I tried decoding it with the loopback 
flowgraph. The output was redirected to the terminal. The contents were being printed 
properly.  But whenever I use the USRP, the receiver side just stops working. The 
receiver side also has 2 flowgraphs running with the corresponding values of the 
subcarriers.


For ofdm transmitter 1, the parameter values are:
Occupied carriers- ((-2, -1, 2, 1 3, 4),)
Pilot carriers- ((-21, -11, 11, 21),)
Pilot symbols- ((-1, 1, -1, 1),)


For ofdm transmitter 2, the parameter values are:
Occupied carriers- ((-4, -3, -5, -6, 6, 7),)
Pilot carriers- ((-26, -25, 26, 25),)
Pilot symbols- ((-1, 1, -1, 1),)

I want to do it using a single flowgraph. What would be the right way to 
proceed with this?

Re: Transmitting on a single subcarrier

[Marcus Müller]

Hi Sourya,

On 16.03.24 22:30, Sourya Saha wrote:
I am using an OFDM transmitter and receiver blocks from GNU radio. Essentially what i want 
to do is split up the bandwidth into 64 subcarriers and trasmit on any one of the 
subcarriers, say subcarrier 3.


Remark: that is just FSK, but due to the nature of OFDM an FSK with a less-than-pretty 
symbol shaping, and due to the cyclic prefix, an FSK with a phase jump within each symbol.


*Usually*, you'd avoid doing that, and just build an FSK system. Especially, since if you 
only use one carrier at a time, you lose the ability to sense the channel, or use 
Schmidl (or similar methods) for synchronization, so there's no arguments going for 
OFDM here – that's why I pointed out that OFDM was a rather advanced topic, you need to 
understand *why* you're using it, fighting *which* channel problems.
You get all the complexity, the overhead and all the problems of OFDM, without any data 
rate benefit.


However, nothing in GNU Radio would stop you from doing that:
Data vectors with a lot of zero entries and a single non-zero entry.


If that is to be done, in the data carriers field of the  ofdm transmitter and 
receiver, mentioning just '3' as the subcarrier should work.


Not sure what "mentioning" means, but as described above: data vector with all zeros, but 
a non-zero value in the third entry.



Best,
Marcus

Re: B200-mini not detected thru GNU Radio

[Marcus Müller]

Hi Alex,

On 13.03.24 21:13, Woods, Alex C wrote:

Hello,

I've constructed the Spectrum Analyzer as seen on this page (see following link to GNU 
radio wiki) in hopes to test the functionality of GNU radio's compatibility with the 
b200-mini I plan to use for a project:


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



Unfortunately, when I run execute the flow graph, I get:

RuntimeError: LookupError: KeyError: No devices found for -> Empty Device 
Address

and it doesn't run as intended. I've verified the connection of the device through UHD 
command uhd_find_devices (as well as several other commands), where it sees the b200-mini 
just fine, but GNU Radio isn't seeing it for some reason. The device is interfaced via USB.


This is similar to the error this StackExchange user encountered (see link below), but I 
was slightly confused on how to fix it with the advice provided in the highest-upvoted 
response.


https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for
 



Ha, that's my answer :)

If it has any effect on anything, I downloaded GNU Radio using the three lines at the top 
of the UbuntuInstall page on the wiki (linked below):


https://wiki.gnuradio.org/index.php/UbuntuInstall#:~:text=There%27s%20generally%20no%20need%20to%20build%20GNU%20Radio,for%20anyone%20who%20is%20new%20to%20GNU%20Radio.
 




What's the reason for going this complicated route rather than the easy, 
https://wiki.gnuradio.org/index.php?title=InstallingGR recommended route of


`apt-get install gnuradio`

here? That has effect on what I'd recommend you do.

Best regards,
Marcus

Re: B200-mini not detected thru GNU Radio

[Marcus Müller]

Hi Alex,

On 13.03.24 21:13, Woods, Alex C wrote:

Hello,

I've constructed the Spectrum Analyzer as seen on this page (see following link to GNU 
radio wiki) in hopes to test the functionality of GNU radio's compatibility with the 
b200-mini I plan to use for a project:


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



Unfortunately, when I run execute the flow graph, I get:

RuntimeError: LookupError: KeyError: No devices found for -> Empty Device 
Address

and it doesn't run as intended. I've verified the connection of the device through UHD 
command uhd_find_devices (as well as several other commands), where it sees the b200-mini 
just fine, but GNU Radio isn't seeing it for some reason. The device is interfaced via USB.


This is similar to the error this StackExchange user encountered (see link below), but I 
was slightly confused on how to fix it with the advice provided in the highest-upvoted 
response.


https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for
 



Ha, that's my answer :)

If it has any effect on anything, I downloaded GNU Radio using the three lines at the top 
of the UbuntuInstall page on the wiki (linked below):


https://wiki.gnuradio.org/index.php/UbuntuInstall#:~:text=There%27s%20generally%20no%20need%20to%20build%20GNU%20Radio,for%20anyone%20who%20is%20new%20to%20GNU%20Radio.
 




What's the reason for going this complicated route rather than the easy, 
https://wiki.gnuradio.org/index.php?title=InstallingGR recommended route of


`apt-get install gnuradio`

here? That has effect on what I'd recommend you do.

Best regards,
Marcus

Re: FW: Bug in File Meta Source: Repeat does not work for detached headers

[Marcus Müller]

Hi Adrian,

thanks for the report! Yes, if you can, please create a ticket! If you want, you could 
throw your recording and your playback flow graphs into a zip file and attach that to your 
issue text, that makes reproduction 100% reliable.


This is excellent bug reporting, by the way, thank you very much!

Just as perspective:

We have two other issues, https://github.com/gnuradio/gnuradio/issues/3516 and 
https://github.com/gnuradio/gnuradio/issues/5568 , concerning the metadata file sink. Both 
of them use the non-detached header, so they seem to be different from yours.


Best,
Marcus

On 13.03.24 13:27, Adrian Winter wrote:

Hey,

I'm pretty sure I discovered a bug in GNURadio and am now following the steps 
to report the bug, starting with sending this mail to the mailing list 
according to the development instructions.

Short description:

The File Meta Source block does not repeat the file, if a detached header is 
used.

Used Software:

   *   GNURadio 3.10.9.2
   *   Python 3.11.8
   *   Installed through radioconda
   *   X86-64 running Ubuntu 20.04 LTS

Steps to reproduce:


   1.  Create any IQ file using the File Meta Sink block with Detached Header being set 
to "True"
   2.  Replay this file with File Meta Source block, Detached Header = True and 
Repeat = True, with the data being sent to any sink (e.g. Tag Debug)

Observed Behaviour:

The file's contents are being loaded, but when EOF is reached no more samples 
are being produced, essentially stalling the flowgraph

Expected Behaviour:

The file should reset to the beginning and continue to produce samples 
indefinitely.

Other Notes:

   *   Replaying the IQ file without the information in the header using File 
Source and Repeat = True works as expected.
   *   Replaying a file using the File Meta Source with Repeat = True, but 
inline headers works as expected.
   *   The data type does not appear to have an influence (same behaviour for 
IShort and Complex Float)

Any help would of course be appreciated, and please let me know if you can 
reproduce the issue and if I should create a ticket in Github.

Thank you in advance and kind regards!
Adrian Winter

Researcher,
SINTEF Digital
Trondheim, Norway

PS: this is the third time I send this message in various states of being 
subscribed to this mailing list. I really hope that the older two versions are 
actually filtered and I'm not spamming the mailing list. If I accidentally did, 
please accept my apologies - first time interacting with a mailing list.

Re: Ofdm transmitter and receiver

[Marcus Müller]

Hi Sourya,

On 12.03.24 20:09, Sourya Saha wrote:

I am working with an OFDM transmitter and receiver. Some article says that
the number of subcarriers decides the SCS. I could not find any formula
that relates to it.


Is SCS = subcarrier spacing?

In that case, yes,  the number of subcarriers is directly inverse to the subcarrier 
spacing. Remember that OFDM is "just" doing a DFT, so you get the sampling rate divided by 
the number of DFT bins. Which is the number of subcarriers.


You shouldn't be reading "some articles"; OFDM isn't hard when one learns it from a good 
textbook. It *is* hard when one needs to learn it from research articles, spectrum 
analyzer application notes and random blog articles :)


If you have a good basic education in digital communications, Proakis' "Digital 
Communications", I think starting from 4th or 5th edition. In the third edition (which can 
be bought very cheaply used), it's called "An FFT-based Multicarrier System",  but it's 
really OFDM, just without the name. Either way, that chapter would have explained the same 
as I did above!


If you need a slightly gentler entry to OFDM (in the lectures on digital communications 
that I've been part of, we treated it as something rather advanced, because explaining 
*why* it is like it is requires understanding of a lot of channel concepts), you would 
probably *not* want to rely on Proakis.


Instead, you could try the free "Software-Defined Radio for Engineers" by Travis Collins 
et al.,

https://www.analog.com/en/resources/technical-books/software-defined-radio-for-engineers.html

it does come with the motivation, it illustrates the OFDM spectral shape well, and 
introduces the terminology; it is nice and will (mostly) only require you to have 
understood the chapters 2, 4 and 9.


> Also, if I want to operate the OFDM in a frequency

range of 490Mhz to 680 Mhz for example, how do i make the blocks use that
frequency range?


None. Because OFDM deal with the radio frequencies at all, it deals with the *equivalent 
baseband*.


You might be really a bit confused about the basics here; I'd recommend "SDR for 
engineers" as quoted above, or the even gentler entry through pysdr.org (but pysdr.org 
doesn't cover OFDM, so you'd need to switch to different material once you're through with 
the content on pysdr.org).


Best regards,
Marcus

Re: Sine OOT module

[Marcus Müller]

Hi Sourya,

ha! nice one, this will require you to take a piece of graph paper and make a 
drawing:

horizontal axis: t, make it run from 0 to 1 ms over say 10cm
vertical axis: sin(2\pi ft), so from -1 to +1

you know the sine is 0 for t=0, and it's again after one period, and there's another 0 in 
the middle. So, since in 1 ms, there's 10 periods of a 10 kHz sine, distribute your 20 
zero-crossing evenly between t=0 and t=1ms on the horizontal axis (make a green dot there).


Then, make another green dot at vertical +1 in the middle between t=0 and the first 
zero-crossing after. That's the position of the first maximum of the sine.


Then make a green dot at -1 in the middle between the first and second zero crossing after 
t=0. That's the position of the first minimum of the sine.


Hope you're still with me, we're just making a drawing of the 10 kHz sine!

So, it's alternating dots at +1 and -1 in the (horizontal) middle between the 
zero-crossings.
In the end, connect them with a somewhat smooth curve. Precision really doesn't matter, 
the only thing important is that you can look at it and go "ok, that's periods of a sine 
wave!".


Now, take a different color. Red, or so. Make a fat circle around the value the sine wave 
has at t=0 (that should be sin(0) = 0, right).


These red circles are our samples. Your sampling rate is 2 kHz, so the next circle appears 
at 1/(2 kHz) = 0.5 ms, and the next another 0.5 ms later.


Where did you put all your circles?

That's what *Nyquist rate* is all about. You can only properly reconstruct sine waves 
where you get more than 2 points per period, meaning that your sample rate needs to 
fulfill a condition relative to the signal frequency.


Hope this helps!

Marcus



On 11.03.24 19:02, Sourya Saha wrote:

Hi marcus,
I corrected my typo and did everything as you said. I still do not have any
output.
Following is my code:

import numpy as np
from gnuradio import gr

class sine(gr.sync_block):
 """
 docstring for block sine
 """
 def __init__(self, sample_rate, duration=1000, freq=0, phase=0):
 gr.sync_block.__init__(self,
 name="sine",
 in_sig=None,
 out_sig=[np.float32, ])
 self.sample_rate = sample_rate
 self.duration = duration
 self.freq = freq
 self.phase = 0


 def work(self, input_items, output_items):
 #out = output_items[0]

 t = np.arange(0, len(output_items[0]),
len(output_items[0])/self.sample_rate)

 s = np.sin(2*np.pi*self.freq*t + self.phase)
 self.phase += 2 * np.pi *  self.freq / self.sample_rate

 # <+signal processing here+>
 output_items[0][:] = s
 return len(output_items[0])

Attached is a screenshot of the flowgraph.
How do i get a sine wave just like the signal source?

Regards,
Sourya Saha

Re: Sine wave from OOT module

[Marcus Müller]

Hi Sourya,

that does indeed look pretty nice!

I think you made a minor typo:

self.freq = 0

should probably read

self.freq = freq


Best regards,
Marcus


On 11.03.24 00:01, Sourya Saha wrote:

I am trying to make a custo wave through an OOT python module. I am very
new to DSP and GNU Radio. I decided to replicate the Sine wave from Signal
source block. I seem to get no output. My code is as follows:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Copyright 2024 sourya.
#
# SPDX-License-Identifier: GPL-3.0-or-later
#


import numpy as np
from gnuradio import gr

class sine(gr.sync_block):
 """
 docstring for block sine
 """
 def __init__(self, sample_rate, duration=1000, freq=0, phase=0):
 gr.sync_block.__init__(self,
 name="sine",
 in_sig=None,
 out_sig=[np.float32, ])
 self.sample_rate = sample_rate
 self.duration = duration
 self.freq = 0
 self.phase = 0


 def work(self, input_items, output_items):
 #out = output_items[0]

 t = np.arange(0, len(output_items[0]),
len(output_items[0])/self.sample_rate)

 s = np.sin(2*np.pi*self.freq*t + self.phase)
 self.phase += 2 * np.pi *  self.freq / self.sample_rate

 # <+signal processing here+>
 output_items[0][:] = s
 return len(output_items[0])

Last time I made some mistakes which I have corrected in this code. I am
not sure about what the phase part will be and what value it will be
updated to. Also, detailed help about this will really be appreciated since
I am very new to this field and Mailing lists doesnt simply allow to get
back to the solution provider in form of a reply like a forum does.

Re: Creating a wave in OOT modules

[Marcus Müller]

Hi Sourya,

multiple things:

1. You return 1 in work. That literally tells GNU Radio that you only produced a single 
sample! I think we explain what work does in our tutorials on 
https://tutorials.gnuradio.org , so you might want to go back and read them a bit more 
carefully!


2. you assume you have self.duration * self.sample_rate in space in the output buffer. 
That is wrong. You get as much space in the output buffer as you get; you need to check 
len(output_items[0]) !


3. you assume the phase at the beginning of your work function is always 0; that is 
probably a result of the previous mistake. That's not the case! You need to save your last 
sample's phase for the next time "work" is called


4. You assign the output "output_items[0] = s", but that's wrong (and not like our 
examples at all): you need to do output_items[0][:] = s, because you need to replace the 
values, not just the reference to the vector. You need to solve 1.–3. first though!


Best regards,
Marcus


On 09.03.24 16:14, Sourya Saha wrote:

Hi.
I am trying to create a custom wave through an OOT module. To do that, I
tried replicating the sine wave of the signal source block. I have used the
following Python code:

import numpy as np

from gnuradio import gr

class sine(gr.sync_block):

"""

docstring for block sine

"""

def __init__(self, sample_rate, duration=1000, freq=0):

  gr.sync_block.__init__(self,

  name="sine",

  in_sig=None,

  out_sig=[np.float32, ])

  self.sample_rate = sample_rate

  self.duration = duration

  self.freq = 0


def work(self, input_items, output_items):

  #out = output_items[0]



  t = np.arange(0, self.duration, 1/self.sample_rate)



  s = np.sin(2*np.pi*self.freq*t)



  # <+signal processing here+>

  output_items[0] = s
  return 1 #len(output_items[0])




However, I do not get any output from the output line. Could you suggest
what could have gone wrong?

Re: uhd.find_devices() - AttributeError

[Marcus Müller]

Hi Trung Trieu,

I can reproduce this, by running `podman run --rm -it ubuntu:22.04`, and in 
there

apt update; apt install -y gnuradio;
python3 -c 'from gnuradio import uhd;uhd.find_devices()'

so you're not alone!

The honest truth is that this line has been there since GNU Radio 3.4.2 , and as you can 
see, nobody remembered to remove it when it became dysfunctional. Oops!


For you, I'd have a workaround. Try this:

from gnuradio import uhd
from uhd import find as find_devices

find_devices("")

Best regards,
Marcus

On 05.03.24 22:56, Trung Trieu wrote:

Hello all,

I've been having some issues with gnuradio 3.10 and still haven't figured
it out yet. I'd really appreciate it if anyone could help me or have any
pointers that I can follow.

For your reference, I have an Ubuntu 22 virtual machine running on VMware
and installed gnuradio (as well as other dependencies) from the
instructions at https://wiki.gnuradio.org/index.php/InstallingGR (I tried
both installation methods via apt and via ppa but no luck).

The error message I have is:

-
Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line 73,
in find_devices
 return __builtins__['map'](to_pythonized_dev_addr,
uhd_python.find_devices_raw(*args, **kwargs))
AttributeError: module 'gnuradio.uhd.uhd_python' has no attribute
'find_devices_raw'. Did you mean: 'find_devices'?
-

Steps to reproduce:
1. Install gnuradio 3.10
2. From the command line, launch python3 by typing "python3"
 - >>> from gnuradio import uhd
 - >>> print(uhd.find_devices())
That's where the error occurs.

The content of '/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py'
can also be found at
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/python/uhd/__init__.py

Note that I don't have this issue with Ubuntu 20, which uses gruradio 3.8
and SWIG instead of PyBind11. So instead of 'uhd_python', it'll be
'uhd_swig' from the above error message. The code with gnuradio 3.8 can
also be found at
https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-uhd/python/uhd/__init__.py

Thank you all in advance!!
*Trung Trieu*

Re: Faq? GRC and gnuradio versions don't match?

[Marcus Müller]

Awesome! You can, by the way, just keep the "install_manifest.txt" from the build/ 
directory around, and then clean up (instead of `make uninstall`) using


xargs rm -rf < install_manifest.txt

Note that the command above will happily delete things, so do be a bit careful!

Best regards,
Marcus
On 02.03.24 02:39, David Cherkus wrote:

  Thank you!

I followed your steps, now I have 3.10.9.2 working!
dcherkus@dmin:~$ gnuradio-companion *grc<<< Welcome to GNU Radio Companion 3.10.9.2 
>>>
I made myself a note to do 'make uninstall' before trying a new version.
Regards,Dave

Re: Faq? GRC and gnuradio versions don't match?

[Marcus Müller]

Hi Dave,

nope, not the way it should be. You should have uninstalled your GNU Radio 
3.10.6.0 first!
Anyways, what is happening now is that Python loads the Python GRC module in version 
3.10.6.0, but your GNU Radio binaries (and also probably your libraries) are loaded in 
version 3.10.9.2.


That's going to fail. Please uninstall your 3.10.9.2 (go to the build/ directory, `sudo 
make uninstall`) first, then check /usr/local for all things that might be remainders of 
your now dysfunctional 3.10.6.0 installation, and remove them. Especially 
/usr/local/lib*/python*/{site,dist}-packages/gnuradio* will contain outdated stuff.


Afterwards, do a clean build (meaning: remove everything from build/, and run `cmake` 
again, run make, run make install).


Best regards,
Marcus

On 01.03.24 14:19, David Cherkus wrote:

Hi,
I just built GNUradio from source on Debian 11 x86 64 bit.
Even after a reboot, GRC and GNUradio's versions don't match?
dcherkus@dmin:~$ gnuradio-config-info --version3.10.9.2dcherkus@dmin:~$ 
gnuradio-companion --helpusage: gnuradio-companion [-h] [--log 
{debug,info,warning,error,critical}] [flow_graphs ...]
GNU Radio Companion 3.10.6.0 This program is part of GNU Radio GRC comes with 
ABSOLUTELY NO WARRANTY.This is free software, and you are welcome to 
redistribute it.
Both programs have the same date stamp and are the only ones installed (I never 
install the Debian packages).
dcherkus@dmin:~$ ls -lLt /usr/bin/gnu*ls: cannot access '/usr/bin/gnu*': No such 
file or directorydcherkus@dmin:~$ ls -lLt /usr/local/bin/gnu*-rwxr-xr-x 1 root root 
1182160 Mar  1 07:35 /usr/local/bin/gnuradio-config-info*-rwxr-xr-x 1 root root    
2985 Mar  1 07:34 /usr/local/bin/gnuradio-companion*dcherkus@dmin:~$ apt list 
|& grep gnuradio | grep installed
Is this the way things are supposed to be?
Regards,Dave

Conda installation on Windows broken, both minconda & radioconda installer (Was: Please help out a new guy)

[Marcus Müller]

Good Morning!

I'm looping the mailing list back in, so that more people can look at it!

So, this looks generally pretty good; you have exactly one environment. But: that might 
mean when you said you were using miniforge, you might have installed things into the same 
environment, so that problems stemming from that might persist.


Hm; aside from trying to make a new environment, activating it and installing GNU Radio in 
there, my honest assessment is that I'm out of my conda depth!


I hope someone else on the list has a clever idea.

Best regards,
Marcus

On 29.02.24 14:54, Dave Borch wrote:

Good morning, Marcus.
Here is the result of my query:

(base) C:\Users\Dave>conda info --envs
# conda environments:
#
base  *  C:\Users\Dave\radioconda

Does this shed any light on the problem?
Thanks,
Dave


On Wed, Feb 28, 2024 at 6:24 PM Marcus Müller  wrote:

Hi Dave,

welcome to the GNU Radio community! We certainly try to make it entry-friendly; 
and the
good news is that the errors you're seeing don't seem to be UNIX-related :)

So, I'd have to guess a lot here, but the error you're describing could mean 
there's a
wrong version of a library being found – which is supporting, usually *conda 
installations
are quite self-contained!

This is but a stab in the dark, but: Is it possible you set up radioconda, and 
used the
same conda prefix as you used for miniforge? Don't really understand how that 
would break,
but it's my best guess for now.

Maybe there's multiple conda environments? Does `conda info --envs` say 
something to that end?

Best regards,
Marcus

On 27.02.24 22:22, Dave Borch wrote:

Friends,
I'm brand new to Gnu Radio and haven't really used Unix for years. So
please be patient with me here. I loaded Gnu Radio Companion onto my
Windows 10 system and whenever I try to execute a flow graph involving
any of the QT tools I get the following message:

DLL load failed while importing qtgui_python: The specified procedure
could not be found.

Listed below are the packages that didn't load properly:

Failed \Device\HarddiskVolume3\Users\
Dave\radioconda\Library\bin\volk.dll
Failed 
\Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
Failed 
\Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icuuc73.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icudt73.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\libomp.dll

I get the same error whether I load radioconda using the radioconda
installer from github or by using miniforge.

Running Gnu Radio Companion on a laptop, also running Windows 10, I
don't experience this problem. I don't experience the problem on my
Raspberry Pi either.

I'd be grateful for any help, and please direct me to the appropriate
forum if I'm here in error.

Thanks,
Dave

Re: Please help out a new guy

[Marcus Müller]

Hi Dave,

welcome to the GNU Radio community! We certainly try to make it entry-friendly; and the 
good news is that the errors you're seeing don't seem to be UNIX-related :)


So, I'd have to guess a lot here, but the error you're describing could mean there's a 
wrong version of a library being found – which is supporting, usually *conda installations 
are quite self-contained!


This is but a stab in the dark, but: Is it possible you set up radioconda, and used the 
same conda prefix as you used for miniforge? Don't really understand how that would break, 
but it's my best guess for now.


Maybe there's multiple conda environments? Does `conda info --envs` say 
something to that end?

Best regards,
Marcus

On 27.02.24 22:22, Dave Borch wrote:

Friends,
I'm brand new to Gnu Radio and haven't really used Unix for years. So
please be patient with me here. I loaded Gnu Radio Companion onto my
Windows 10 system and whenever I try to execute a flow graph involving
any of the QT tools I get the following message:

DLL load failed while importing qtgui_python: The specified procedure
could not be found.

Listed below are the packages that didn't load properly:

Failed \Device\HarddiskVolume3\Users\
Dave\radioconda\Library\bin\volk.dll
Failed 
\Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
Failed 
\Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icuuc73.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icudt73.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\libomp.dll

I get the same error whether I load radioconda using the radioconda
installer from github or by using miniforge.

Running Gnu Radio Companion on a laptop, also running Windows 10, I
don't experience this problem. I don't experience the problem on my
Raspberry Pi either.

I'd be grateful for any help, and please direct me to the appropriate
forum if I'm here in error.

Thanks,
Dave

Re: FFT block - change window type on runtime

[Marcus Müller]

Hi Jakub,

that's right! When you open the block properties of your FFT block, you will see that the 
names of some parameters are underlined: That means they have a method of being updated at 
runtime.


However, the window field is not underlined!

You can work around that, though, easily! Set your FFT's window to [] (no windowing), and 
do the windowing before:


input ---> multiply const --> FFT -->

where the "constant" of "multiply const" is what you adjust at runtime :)

Best regards,
Marcus

On 21.02.24 17:07, Šerých Jakub wrote:

Hi there!
I'm pretty new to gnu radio and this is my first time posting to this mailing 
list, so excuse me if my question is nonsensical.

I am trying to switch the window type in FFT block during runtime. I added QT 
GUI chooser with window.blackmanharris() etc. options, called it win and I put 
the variable name win to the Window parameter of FFT block. On start, it works 
perfectly (if I change default value of the chooser and start the flowchart) 
but nothing happens if I change value of chooser during runtime. It seems to 
me, that FFT initialises window type only on startup and doesn't look at it 
during runtime.
Is there any way how to do it?

Thanks for any help

Jakub

GRC 3.10.4.0 (Python 3.10.12) on DragonOS

Re: Help to remove DC offset

[Marcus Müller]

no, but I proposed a different way in my first reply.

On 15.02.24 12:41, Arhum Ahmad wrote:
Yes, in that case, could we reduce the strength of DC so that it won't interfere while 
detecting the signal's frequency (on the run)?


On Thu, Feb 15, 2024 at 4:40 PM Marcus Müller <mailto:marcus.muel...@ettus.com>> wrote:


__

Hey,

can we keep this on the mailing list, please?

But logically, if you have signal of interest where your DC is, then a 
high-pass
filter is not an option.

Best,
Marcus

On 15.02.24 10:55, Arhum Ahmad wrote:

Hey Marcus,
I am using it to find the signal frequency present in the given band. 
However, in
some cases, I found DC is more dominant, and I am unable to detect the 
presence of
the signal and its frequency.
If I use the high pass filter to remove the DC offset, how should I 
calculate the
cut-off? Considering the fact that there might be a signal at the center.

On Sun, Feb 11, 2024 at 10:52 PM Marcus Müller mailto:marcus.muel...@ettus.com>> wrote:

Hi Arhum,

some limited amount of DC offset is sadly to be expected from any direct
conversion architecture (that's a result of LO leakage as well as 
systematic DC
offset).

Since DC is the lowest of all possible frequencies, a high-pass filter 
can be
used to eliminate it. The design of that filter depends on what you 
want to do
with the signal afterwards – for example, for some communication system 
signals,
the DC offset literally doesn't matter.

Another option is, if your signal is sufficiently more narrowband than 
the
Nyquist bandwidth dictated by your receiver's sampling rate, to 
"offset-tune";
i.e., to put your signal of interest to the positive (or negative) side 
of your
LO frequency, and then digitally shift the signal of interest to actual 
baseband
and filter.

The USRPs bring that functionality out of the box, integrated into the 
device's
digital part, so you can just deal with the signal decimated to the 
bandwidth
you need in your computer. I'm not sure, but I don't think the HackRF 
allows for
that. You'd have to offset-tune within your full sampling rate, and in 
GNU Radio
use something like the "freq. X-lating FIR filter" to get the part of 
the
spectrum you want.

Best regards,
Marcus

On 10.02.24 12:02, Arhum Ahmad wrote:

Hey all,

I'm currently working on frequency sensing using the HackRF SDR. 
However, when
I calculate the FFT, I encounter a DC offset that's higher than the 
actual
signal strength itself. This offset is interfering with my ability to 
detect
the intended output accurately. Could you please assist me in 
understanding how
to remove this DC offset?

-- 
*Thanks and Regards**

*
*Arhum Ahmad*
Ph.D. Scholar, Electrical Engineering Department, IIT Ropar

+91- 7974897279 | arhum.19eez0...@iitrpr.ac.in
<mailto:2016eez0...@iitrpr.ac.in>

Lab No. 323, Communication Research Lab, J.C.Bose Building


*
/CONFIDENTIALITY NOTICE: The contents of this email message and any 
attachments
are intended solely for the addressee(s) and may contain confidential 
and/or
privileged information and may be legally protected from disclosure. If 
you are
not the intended recipient of this message or their agent, or if this 
message
has been addressed to you in error, please immediately alert the sender 
by
reply email and then delete this message and any attachments. If you 
are not
the intended recipient, you are hereby notified that any use, 
dissemination,
copying, or storage of this message or its attachments is strictly 
prohibited./
* 




-- 
*Thanks and Regards**

*
*Arhum Ahmad*
Ph.D. Scholar, Electrical Engineering Department, IIT Ropar

+91- 7974897279 | arhum.19eez0...@iitrpr.ac.in
<mailto:2016eez0...@iitrpr.ac.in>

Lab No. 323, Communication Research Lab, J.C.Bose Building


*
/CONFIDENTIALITY NOTICE: The contents of this email message and any 
attachments are
intended solely for the addressee(s) and may contain confidential and/or 
privileged
information and may be legally protected from disclosure. If you are not the
intended recipient of this message or their agent, or if this message has 
been
addressed to you in error, please immediately alert the sender by reply 
email and
then delete this message and any attachments. If you are not the intended 
recipient,
you are hereby notified that any use, dissemination, copying, or storage of 
this
message or its attachments is strictly prohibited./
* 




--
*Thanks and Regards**
*
*Arhum Ahmad*
Ph.D. Scholar, El

Re: How to get average execution time of a block?

[Marcus Müller]

Hi Bob,

complicated answer: yes, but.

So, we do have the performance counters that can be enabled at compile time in GNU Radio, 
and which can be queried through ctrlport. Ctrlport has been hard to or impossible to use 
for quite a while, so it's pretty possible this is not a viable option to you. However, if 
it is: the gr-perf-monitorx program connects to a running flowgraph's ctrlport server and 
displays statistics like average and per-item runtime. These performance counters do come 
with performance overhead, so use at your own risk.


A lot easier would be to attach a "Probe Rate" block to the filter's output (unless you 
inherently know the rate already), and use `perf top -ag` to check how much time your CPU 
cores spend in which function (pretty much randomly sampled); this won't give you an exact 
"time per call", but it would give you a "CPU usage percentage per call" and inherently 
"usage percentage per sample", if you will. That might be what you need, but it might also 
*not* be what you need.


In case you really want to get the time in seconds per call, and relate that to the number 
of items produces: see the attached bpftrace script. This uses modern Linux and bpftrace 
capabilities to hook user functions. It still does have some, but usually, much more 
benign, overhead.


Best regards,
Marcus


On 13.02.24 16:47, Bob Gnu wrote:
I'm using the 'Lowpass Filter Block'. Is there a way to get the average execution time 
for that block? Per sample or per 1000 samples, for example? The sample rate is 2 MHz.


thanks
#!/usr/bin/bpftrace
/*
 * Trace Runtime of a GNU Radio block
 *  For Linux, uses bpftrace and eBPF.
 *
 * Usage: 
 * 
 * 0. Install GNU Radio and bpftrace
 * 1. change the path to the library you want to probe
 *(in this example, that was /path/to/my/libgnuradio-filter.so).
 *If the library is installed in a system-default location, the
 *name alone should suffice.
 * 2. change the C++ name of the work function you want to probe
 *(in this example,
 *gr::filter::fir_filter_blk_impl::work)
 * 3. run this script as root:
 *`sudo bpftrace thisscript.bt | tee statistics.txt` 
 * 4. Start your GNU Radio flow graph
 * 5. Marvel at the numbers you're getting!
 *
 * Copyright (c) 2021 Tao Xu (as sslsnoop.bt)
 * Copyright (c) 2024 Marcus Müller 
 * Licensed under the Apache License, Version 2.0 (the "License")
 *
 * 15-Dec-2021  Tao Xu  created this.
 * 14-Feb-2024  Marcus Müller  adopted to GR
 */

BEGIN
{
printf("Tracing work call runtimes... Hit Ctrl-C to end.\n");
printf("NOTE: this assumes that the block never manually calls 
produce(), but returns the items produced in each call!\n");
printf("%8s %7s %5s\n", "TID", "Δt [ns]", "Ret (s/S)");
}

uprobe:/path/to/my/libgnuradio-filter.so:cpp:"gr::filter::fir_filter_blk_impl::work"
{
  @start_work[tid] = nsecs;
}

uretprobe:/path/to/my/libgnuradio-filter.so:cpp:"gr::filter::fir_filter_blk_impl::work"
/@start_work[tid] != 0/
{
printf("%-8d %7u %5d\n", tid, (nsecs - @start_work[tid]), 1e9 * retval 
/ (nsecs - @start_work[tid]));
delete(@start_work[tid]);
}

Re: USRP X410 Underflows and Overflows

[Marcus Müller]

Hi Olivia,

generally, Python blocks for signal processing are pretty limited in speed; so I'd really 
recommend you compare your code's performance with Signal Source (sawtooth) -> frequency 
modulator or Signal Source (sawtooth) -> multiply with itself (giving you the square) -> 
phase modulator (maybe you remember Lars Gölz's chirp modulation Bachelor Thesis: that's 
what he did!).


Other than that, you're sadly not sharing the code of your chirp generation, nor the flow 
graph, but only partial screenshots of text – that's not very helpful to help you!


Best,
Marcus

On 14.02.24 12:48, Mammadova, Olivia wrote:

Hello together,

i wrote a code for a linear chirp and added the code to the python generated by grc, 
because GNU Radio has no building block for a linear chirp  except using Signal source and 
VCO Block.


I tried to simulate the linear chirp signal on USRP X410 and send  the chirp signa to USRP 
X410 l and check the output with the spectrum analyzer. Unfortunately, the simulation 
causes underflows and overflows for  the sample rate starting at 1 MHz and i cannot 
receive a proper linear chirp at UHD Source. Moreover, the CPU Usage during the python 
simulation is below 10%..  When i stop the simulation and want to restart the simulation, 
RFoncError occurs: Attempting to reconnect input port.


I tried to resize the buffer using sudo nano /etc/sysctl.d/99-custom.conf and added 
net.core.rmem_max=25000 and applied the changes using sudo sysctl -p 
/etc/sysctl.d/99-custom.conf.  The the buffer size is resized, but the overflows and 
underflows are yet occuring and the cpu usage is below 10%.


I am sending you the screenshots of my simulation console and hope that you 
help me!

Thank you in advance!

Best regards,

Olivia Mammadova

Re: Help to remove DC offset

[Marcus Müller]

Hi Arhum,

some limited amount of DC offset is sadly to be expected from any direct conversion 
architecture (that's a result of LO leakage as well as systematic DC offset).


Since DC is the lowest of all possible frequencies, a high-pass filter can be used to 
eliminate it. The design of that filter depends on what you want to do with the signal 
afterwards – for example, for some communication system signals, the DC offset literally 
doesn't matter.


Another option is, if your signal is sufficiently more narrowband than the Nyquist 
bandwidth dictated by your receiver's sampling rate, to "offset-tune"; i.e., to put your 
signal of interest to the positive (or negative) side of your LO frequency, and then 
digitally shift the signal of interest to actual baseband and filter.


The USRPs bring that functionality out of the box, integrated into the device's digital 
part, so you can just deal with the signal decimated to the bandwidth you need in your 
computer. I'm not sure, but I don't think the HackRF allows for that. You'd have to 
offset-tune within your full sampling rate, and in GNU Radio use something like the "freq. 
X-lating FIR filter" to get the part of the spectrum you want.


Best regards,
Marcus

On 10.02.24 12:02, Arhum Ahmad wrote:

Hey all,

I'm currently working on frequency sensing using the HackRF SDR. However, when I 
calculate the FFT, I encounter a DC offset that's higher than the actual signal strength 
itself. This offset is interfering with my ability to detect the intended output 
accurately. Could you please assist me in understanding how to remove this DC offset?


--
*Thanks and Regards**
*
*Arhum Ahmad*
Ph.D. Scholar, Electrical Engineering Department, IIT Ropar

+91- 7974897279 | arhum.19eez0...@iitrpr.ac.in 



Lab No. 323, Communication Research Lab, J.C.Bose Building


*
/CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are 
intended solely for the addressee(s) and may contain confidential and/or privileged 
information and may be legally protected from disclosure. If you are not the intended 
recipient of this message or their agent, or if this message has been addressed to you 
in error, please immediately alert the sender by reply email and then delete this 
message and any attachments. If you are not the intended recipient, you are hereby 
notified that any use, dissemination, copying, or storage of this message or its 
attachments is strictly prohibited./

* 

Re: Help on creating an intermittent beacon transmission using HackRF

[Marcus Müller]

Hi David!

I'd be very lazy: just pad your pre-recorded signal with zeros, and play it on loop with 
the file source.


Padding of files is easy, and essentially free in terms of storage space if your file 
system supports sparse files (and if you're on linux, yes, it almost certainly does).


#!/bin/bash
# or #!/bin/zsh, whatever you prefer

# Calculate the number of bytes a 10 minute long sample file has:
reals_per_complex=2 # complex has real and an imaginary part
bytes_per_real=4# for float or int32
sample_rate_hz=$(( 8* 10**6 ))  # 8 MS/s
duration_s=$(( 10 * 60 ))   # 10 Minutes

filesize=$(( reals_per_complex * bytes_per_real * sample_rate_hz * duration_s ))

# resize your recording to the calculated length
# This only works because on any computer architecture I can think of, numbers 
consisting
# solely of zero-valued octets are zeros, numerically

fallocate --length ${filesize} yourrecording.cfile

Best,
Marcus


On 07.02.24 17:09, David Barnhart wrote:
Hi all:   I teach a course at USC on satellite ground communications that is a lab-based 
class.


I would like to setup an intermittent transmission using a recorded beacon that we have 
used before (in cfile format) to have them practice “catching signals” using lab Spectrum 
Analyzers and SDRSharp tools in the lab.  I can get the beacon transmitting continuously 
with its recorded waveform, however am not familiar enough to figure what block structure 
to use to only intermittently transmit this signal every 10 or 20 seconds.   Might there 
be some easy way to do this?  Am using osmocom to transmit via bench top HackRF in closed 
lab room, with a cfile recording.


Thanks so much!    Dave

Research Professor &

Director, Space Engineering Research Center

Department of Astronautical Engineering and Information Sciences Institute

https://www.isi.edu/centers-serc/ 

University of Southern California

4676 Admiralty Way, Suite 1001

Marina del Rey, CA  90292

Office:  310-448-8644

ISI e-mail: barnh...@isi.edu 

USC E-mail: dbarn...@usc.edu 

Re: Group name of python scripts generated by GRC

[Marcus Müller]

Ah!

No, that's not implemented in GRC. It's also relative unusual for that to be done, as far 
as I can tell – for example, if you use gcc to compile a C file into an executable, then 
that executable will have the GID of the executing user.


Best regards,
Marcus

On 09.02.24 12:43, kron...@tiscali.it wrote:

Hi Marcus,
No, I'm not referring to the category. I'm talking about the file group 
ownership.
I would like that the generated python scripts had the same user/group owner of the grc 
file opened in GRC.

Thanks for help.
Ivan

Il 08.02.2024 11:14 Marcus Müller ha scritto:


Hi Ivan,

I think you mean the category in the GRC block library, right, and you're 
referring to
hier blocks? If that's the case, you'll find that setting in the "Options" 
block, under
"Category".

  >  but i would like the generated python scripts belong to the same group 
name of the
relative grc file.

Not quite sure what that means, though!

Best regards,
Marcus

On 07.02.24 15:33,krono86@tiscali.itwrote:
Hello guys! I am searching for a GRC option such that the group name of the generated 
python scripts is automatically set. I do not know if this option is already 
available, but i would like the generated python scripts belong to the same group name 
of the relative grc file. Thanks for help. Ivan

Re: Group name of python scripts generated by GRC

[Marcus Müller]

Hi Ivan,

I think you mean the category in the GRC block library, right, and you're referring to 
hier blocks? If that's the case, you'll find that setting in the "Options" block, under 
"Category".


>  but i would like the generated python scripts belong to the same group name of the 
relative grc file.


Not quite sure what that means, though!

Best regards,
Marcus

On 07.02.24 15:33, kron...@tiscali.it wrote:

Hello guys!
I am searching for a GRC option such that the group name of the generated python scripts 
is automatically set.
I do not know if this option is already available, but i would like the generated python 
scripts belong to the same group name of the relative grc file.

Thanks for help.
Ivan

Re: Python Block : no access to code

[Marcus Müller]

I see where confusion arises!

The code for the embedded python block is, as the name suggests, 
embedded in the GRC flow graph file.


Only for the task of editing it gets this internal representation copied 
to a separate file, and after the editor editing that file finishes, 
gets the (modified) version copied from the file back into the flow 
graph. The temporary file should get removed afterwards. In the case of 
your operating system, the path where that temporary "work copy" of the 
block code is put is /tmp. I've not yet witnessed a Linux system where a 
normal user has no access to the /tmp directory, and it's also not what 
the error implies!


This error, to me, looks like that instead of a text editor opening, 
somehow you're trying to execute the file; and since it's not marked 
executable, that's a permission error. Would that be possible?


Best regards,
Marcus M

On 2024-02-01 20:37, tom sutherland wrote:
I am running a VirtualBox Ubuntu 22.043 with 
Radioconda/gnuradio-companion. I have a python block that I want to 
use but when I try to open it, I get the error */usr/bin/env: 
‘/tmp/epy_block_0_nlgw0hml.py’: Permission denied*. Its a 
directory/file that I don't have access to.

1)  How do I fix this issue?
2) Why does the Python Block, name = MyBlock, save anything to such a 
non-descriptive name like *epy_block_0_nlgw0hml.py* ?


Thanks...Tom

Re: Using RFNoC blocks for satellite systems

[Marcus Müller]

This is a bit from the top of my head, so take with a grain of salt, but:

The problem with a port, aside from the space in the FPGA of the B210 simply being too 
small, is that the CHDR crossbar, i.e., the actual "network operation center" for the 
namesake Network-on-Chip, is based on an AXI crossbar core that Xilinx doesn't offer for 
the 6th gen FPGAs.
Now, one could argue "well, write it yourself!", and they'd probably hit a wall the moment 
they start trying to work the same kind of asynchronous clock domain crossings that the 
7th gen Xilinx FPGAs bring. But, that's hearsay to me, never looked into what the IP core 
actually uses on the FPGA.


Best regards,
Marcus M

On 26.01.24 23:32, Marcus D. Leech wrote:

On 26/01/2024 17:28, Kevin McQuiggin wrote:

No it doesn’t!

Are we violently agreeing here?

The  B2xx family FPGAs aren't supported by the RFNOC toolchain, and they're not very big.  
You could, probably "port"
   the RFNOC toolchain to these FPGAs, but my understanding is that it would be a lot of 
work.


Regardless, officially, RNOC IS NOT SUPPORTED on B2xx hardware.




Sent from my iPhone


On Jan 26, 2024, at 14:22, Marcus D. Leech  wrote:

On 26/01/2024 17:07, Daniel Estévez wrote:

Hi Yotam,

As far as I know, the B200 doesn't support RFNOC. From

https://www.ettus.com/sdr-software/rfnoc/

"all USRP devices from the third-generation on (X300 Series, E300 Series) are 
supported by RFNoC out-of-the-box".


Best,
Daniel.
This is the case, yes.  The FPGAs in the B2xx series aren't compatible with the RFNOC 
toolchain for one, and aren't really

   big enough to support the RFNOC framework inside the FPGA.



On 26/01/2024 21:04, יותם זיס wrote:
Hi everyone, I'm currently working on a bpsk modem for S-band communication with the 
Tevel and TAUSAT satellites. I recently started reading about RFNoc and it intrigued 
me for use in my project since I own a USRP B200. Would love some advice on whether 
or not to try this out and if so how to implement it correctly, thanks.


Attached - a picture of my flowgraph, currently the uplink is connected directly to 
the downlink but usually i use a lime mini for transmission.

Re: 2 SDRs – Parallel Programming

[Marcus Müller]

Hi,

I explicitly mentioned the time stamps you need to set. You're not setting these, so it 
doesn't use timed commands.


Best,
Marcus

On 05.01.24 13:38, Oğuzhan Gedikli wrote:


Hello Marcus,

The boards  I have are b200 and b210.

I want to change the frequency of 2 SDRs at the same time. Even if I write the codes in 
parallel, the frequency of one of the SDRs changes first, and then the frequency of the 
other one changes. I want 2 of them to run in parallel.


I looked at the resources you shared and the examples on GitHub. Based on these, I wrote 
the following code. But I can't say it worked. I guess I couldn't get it to work.


tune_rx = pmt.make_dict()

tune_rx = pmt.dict_add(tune_rx, pmt.intern("freq"), 
pmt.from_double(center_freq))

self.blocks_message_strobe_0 = blocks.message_strobe(tune_rx, 20)

self.msg_connect((self.blocks_message_strobe_0, "strobe"), (self.uhd_usrp_source_0, 
"command"))


self.msg_connect((self.blocks_message_strobe_0, "strobe"), (self.uhd_usrp_sink_0, 
"command"))


The hopped frequencies vary, usually in 100MHz steps, and are higher than my master 
clock rate.


Sent from Mail  for Windows

Re: 2 SDRs – Parallel Programming

[Marcus Müller]

Hello Oğuzhan,

so, what radios are these?

Generally, this *very* much sounds like you need to use timed commands, which trigger the 
tuning at a specific sample time, instead of "yeah, whenever the connection between PC and 
the USRP has delivered the command".


You can send these commands to the "command" message port on the USRP Sink[1]; the set of 
things you can set (depending on the actual hardware model) are documented in [2]. Note 
that you'll want to sent in a PMT dictionary. Such a dictionary can nicely be created 
using the pmt.pmt_to_python.python_to_pmt function, e.g.


command_dictionary = pmt.pmt_to_python.python_to_pmt(
 { "time": (full_seconds, fractional_seconds),
   "tune": (target_frequency, dsp_offset) })

Also note that especially if you're doing this tuning within a range smaller than your 
USRP's master clock rate, you can use DSP-only tuning, and achieve "instant" tuning at the 
specified time stamp.


Note that the time the USRP gets initialized is "0" from the device's perspective. You can 
see the current time of the device in the rx_time tags on the USRP Source's stream.


Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php?title=USRP_Sink
[2] https://www.gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax_cmds
On 04.01.24 15:43, Oğuzhan Gedikli wrote:

Hello,

I have a system I set up with 2 different SDRs. One of the SDRs works as a transmitter and 
the other works as a receiver. When I want to change the center frequency of both of them, 
I use the code below.


usrp_sink.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
usrp_source.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)


I measured how long each one took. One of them (of course, I know it changes depending on 
the hopping frequency. I applied all the tests I mentioned at the same frequencies) takes 
180ms, and the other one takes 50ms.


50ms is of great importance to me because it repeats this process thousands of times 
during a measurement. For this reason, I wanted to run the 2 lines of code you see in 
parallel and I noticed that there was no change in the time. I tested the code I wrote to 
parallelize it; the code works. It starts both functions at the same time. Later, when I 
debugged the parts containing 'set_center_freq', I saw that the 'wait' command took up 
most of the time spent. I have not examined the contents of your library. I'm saying what 
I see on the debug screen. I did not write any 'wait' command myself. But I don't 
understand why one SDR keeps threading and prevents applying commands to the other.



footnote: There is no situation due to GIL. I tested this too.

Re: Modifying existing GNURadio blocks

[Marcus Müller]

Heyo Kimmo,

sorry for the delayed response:

On 29.12.23 01:00, Kimmo Lehtinen wrote:

I would like to make modifications to the following two GNURadio blocks:
1) QT GUI number sink---
I would like to modify it so that it can also display integers and strings. 
Currently it can display floats, shorts and bytes.
I raised an issue about this at the Github page of GNURadio, and I got the following 
reply:"A number of GR blocks infer type from item size, and that's what this block 
does (in its constructor). Unfortunately, float and int32 are the same size, so int32 is 
not usable.It would be possible to add another constructor that uses an explicit type 
instead of item size."


Warning: this is probably more involved than you hoped for. If you've worked with C++ 
before: No problem, you can at any point always ask for help. It's also super helpful to 
use "Draft PR" on github to share your current state of affairs!


If you haven't: I think this might be a bit too hard.

Yep, you would need to copy the make function as declared in number_sink.h in 
[0]:

    static sptr make(size_t itemsize,
 float average = 0,
 graph_t graph_type = NUM_GRAPH_HORIZ,
 int nconnections = 1,
 QWidget* parent = NULL);

to a second make function that has a different signature, for example

    static sptr make(item_type_t itemtype,
 float average = 0,
 graph_t graph_type = NUM_GRAPH_HORIZ,
 int nconnections = 1,
 QWidget* parent = NULL);

where item_type_t is a "Scoped enum"/class enum [1]; something like, within 
number_sink class,

enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever types you 
want to support

Then you would actually need to implement that in number_sink_impl.cc like [2]. But for 
that you need to modify the actual constructor to not take size_t itemsize as argument 
[3], but item_type_t itemtype!


You would add a field const item_type_t d_itemtype and remove d_itemsize in 
number_sink_impl.h [4] and add it to the initializer list [5]; you'd want a switch()/case 
construct to set the alignment_multiple [6].


Then, you replace the switch (d_itemsize) in get_item [7] with an appropriate 
switch(d_itemtype).


Test it successfully compiles!

Now you only need to do two things to 
gr-qtgui/python/qtgui/bindings/number_sink_python.cc

1. add the new class enum item_type_t to bind_number_sink [8],
2. add the new make function:
1. modify the existing definition and
2. copy it to replace size_t itemsize with number_sink::item_type_t itemtype

In detail: following [9], you need to change

    py::class_>(m, "number_sink", D(number_sink))

    .def(py::init(_sink::make),
    ………

into

    py::class_>
    number_sink_wrapper(m, "number_sink", D(number_sink));

    py::enum_(number_sink_wrapper, "item_type_t");

    number_sink_wrapper
    .def(py::init(_sink::make),
    

Please compile the result (make sure to make clean before, we've changed bindings), and 
test it works, from python!


Now, we need to tell GRC that there's a new way to create a Qt GUI number sink! So, modify 
qtgui_humber_sink.block.yml [10] to use the new make function instead of the old (both in 
the python templates: directive, and in the C++ cpp_templates: directive), and add the 
integer option toid: type. Then make; make install and open GRC and try!


Definitely make sure you also add an example GRC flowgraph to the 
gr-qtgui/examples director.

Then, please make a commit with a title that starts with "qtgui: ", for example "qtgui: 
add type-based number_sink, allowing for int32", and don't forget to use the -s flag with 
git commit, so that your commit is signed off! Push to your fork of GNU Radio, and open a 
Pull Request against main.


[0] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/include/gnuradio/qtgui/number_sink.h#L55-L68

[1] https://en.cppreference.com/w/cpp/language/enum#Scoped_enumerations
[2] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L38-L43
[3] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L46
[4] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.h#L28
[5] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L50
[6] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L64
[8] 
https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/python/qtgui/bindings/number_sink_python.cc

[9] 
https://pybind11.readthedocs.io/en/stable/classes.html#enumerations-and-internal-types

Re: How to run the program without showing the block diagram in windows 10?

[Marcus Müller]

Hi Sreejith RK Nair,

that means you're not running the command from an environment that was set up so that 
Python finds your GNU Radio installation.


How did you install GNU Radio on that machine? With that installation probably came a 
shell with everything set up correctly.


Best regards,
Marcus

On 21.12.23 08:03, Sreejith RK Nair wrote:

I tried executing the python file but it keeps showing errors. I'm new to
this and with my limited knowledge I've set the paths. This is the error
that keeps popping up everytime.




*C:\GNURadio-3.8>python NBFM.pyTraceback (most recent call last):  File
"C:\GNURadio-3.8\NBFM.py", line 23, in import
gnuradioModuleNotFoundError: No module named 'gnuradio' *
*Also thank you for your help*.
On Wed, Dec 20, 2023 at 10:33 PM  wrote:

Re: qa_fir_filter test fails in make test

[Marcus Müller]

Hi Ali,

this is due to Clayton fixing a VOLK bug: the current GNU Radio test is buggy and expects 
wrong results. Fixing the VOLK bug made the test fail:


https://github.com/gnuradio/gnuradio/pull/6980

So, don't worry: although it doesn't look like it, this test failing is a good thing :) 
And: He also already fixed the bug in GNU Radio, and Jeff backported the fix to the 
maint-3.10 line, so that GNU Radio 3.10.9.0 will contain a fixed test.


Best regards,
Marcus Müller


On 16.12.23 13:27, Ali G. Dezfuli wrote:

Hi all,
I am installing gnuradio v3.10.8.0
Both UHD and Volk have passed their tests in make test completely (100%)
but as I run make test after building gnuradio v3.10.8.0 I get this single
error:


139/263 Testing: qa_fir_filter
139/263 Test: qa_fir_filter
Command: "/usr/bin/sh" "qa_fir_filter_test.sh"
Directory: /home/ali/opt/gnuradio/build/gr-filter/python/filter
"qa_fir_filter" start time: Dec 16 15:35 +0330
Output:
--
...FF..
==
FAIL: test_fir_filter_fsf_001 (__main__.test_filter)
--
Traceback (most recent call last):
   File "/home/ali/opt/gnuradio/gr-filter/python/filter/qa_fir_filter.py",
line 173, in test_fir_filter_fsf_001
 self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
   File
"/home/ali/opt/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 73, in assertComplexTuplesAlmostEqual
 return all([
   File
"/home/ali/opt/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 74, in 
 self.assertComplexAlmostEqual(x, y, places, msg)
   File
"/home/ali/opt/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 37, in assertComplexAlmostEqual
 raise self.failureException(
AssertionError: 1 != 2 within 5 places

==
FAIL: test_fir_filter_fsf_002 (__main__.test_filter)
--
Traceback (most recent call last):
   File "/home/ali/opt/gnuradio/gr-filter/python/filter/qa_fir_filter.py",
line 188, in test_fir_filter_fsf_002
 self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
   File
"/home/ali/opt/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 73, in assertComplexTuplesAlmostEqual
 return all([
   File
"/home/ali/opt/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 74, in 
 self.assertComplexAlmostEqual(x, y, places, msg)
   File
"/home/ali/opt/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 37, in assertComplexAlmostEqual
 raise self.failureException(
AssertionError: 5 != 6 within 5 places

--
Ran 11 tests in 0.028s

FAILED (failures=2)

Test time =   0.12 sec
--
Test Failed.
"qa_fir_filter" end time: Dec 16 15:35 +0330
"qa_fir_filter" time elapsed: 00:00:00
--


I am using Ubuntu 22.04.3.
On a core i9 13900K

p.s. I changed the branch to 3.10.7.0 and v3.10.6.0 but the error remains
the same

Thanks!

[CfP] Last day to send in your FOSDEM talk proposals!

[Marcus Müller]

Last reminder: 23 hours to go.

On 24.11.23 16:57, Marcus Müller wrote:

Dear community,

a friendly reminder that on the first of December, the window for handing in your talk 
proposals for FOSDEM'24's SDR and ham radio devroom closes. Make sure you send in your 
proposal by then!


Best,
Marcus


 Forwarded Message 
Subject: [CfP] Software-Defined Radio and Amateur Radio Devroom 2024
Date: Wed, 8 Nov 2023 20:52:00 +0100
From: Marcus Müller 
To: GNURadio Discussion List , usrp-users 
, sdrbelg...@lists.uba.be


Dear Friends of Free and Open Source Radio!

FOSDEM 2024, the Free and Open Source Developer’s Meeting taking place in
Brussels, Belgium, 3. & 4. February 2024, will once again feature a track on
FOSS-powered Radio; this year, there will be a combined Amateur Radio and SDR
Devroom:

https://fosdem.org/2024/schedule/track/radio/

In case you're wondering what Amateur Radio and Software-Defined Radio are, we
have a small introduction below. See the "Recommended Topics" section!

We invite developers and users of Free Software from these fields and to
contribute to this event by presenting their projects, ideas and their work.

Please read our Call for Presentations below:
See you in Brussels!

Bastien, Marc and Marcus

Submit Your Presentations!
=

To suggest a talk, go to

https://pretalx.fosdem.org/fosdem-2024/cfp

"Submit a proposal" and fill in the fields; make sure it's in the Software
Defined Radio and Amateur Radio track!

Content and Shape of Presentations
--

Please aim for your talk to be 20 to 25 minutes long, which leaves enough time
for questions & answers within a 30 minute slot. Should you definitely need
more time, we can combine time slots; but please reach out to us before
submitting your overlength talk proposal!

The final schedule will be available through Pretalx and the official FOSDEM
website. Notice that the reference time will be Brussels local time (CET).

In the Software Defined Radio and Amateur Radio devroom, we aren’t constrained
to holding slideshow presentation – bring your demo, your prototype! However,
since this is a software community conference, please refrain from offering
marketing-style presentations. Give the radio experts something to chew on! We
like the nitty-gritty technical details.

Travel Aid
--

If you are a young person, and cannot afford to travel to Brussels and stay
there, please do contact us as early as possible with an itemized estimate of
your financial needs, and remark that you've done so in your proposal's
"Submission Notes". The International Amateur Radio Union Region 1 has
generously offered to assist financially for up to two contributors.

Recommended Topics
--

Topics discussed in the devroom include, but are not limited to:

- SDR frameworks and the tools that make them useful
- New SDR-based developments in ham radio modes
- Cellular/telecom software
- Amateur radio operator software tooling
- Free / Open radio hardware
- Wireless security research
- Entertaining wireless hacks
- SDR & ham radio in mass and higher education
- Satellite, spacecraft and interplanetary communication

Software-Defined Radio is the technology of enabling radio signals to be
processed and generated algorithmically,  typically within general purpose
processors, but also within FPGAs and GPUs; Free and Open Source (FOSS)
Software Radio allows these  algorithms to be inspectable and improvable. With
the advent of ubiquitous IoT, sky-filling satellite megaconstellations and
5G/6G as standards designed with commercial Software Radios in mind, wireless
is an exploding field of interest in the FOSS realm.

Ham Radio, also known as amateur radio, is more than just a hobby orbiting the
usage of radio communication – it's a passion that merges the realms of
electronics, human interaction, and communication. At its core, ham radio is
about establishing connections: with people, with technology, and with the
world at large. It is a free and open community effort at heart!

Important Dates
===

- Submission Deadline: 1. December 2023
- Announcement of selected talks: 15. December 2023
- Conference: 3. & 4. February 2024

Organizer's Contacts


- Software-Defined Radio & Amateur Radio Matrix Space:
   https://matrix.to/#/#fosdem2024:c1.uba.be
- Devroom Chat:
   https://matrix.to/#/#sdr-and-ham-radio-fosdem24:gnuradio.org
- Amateur Radio Program Committee:
   Bastien Cabay, ON4BCY , Marc Balmer, HB9SSB 
- Software-Defined Radio Program Committee:
   Marcus Müller 

You can also find this announcement on
https://gnuradio.org/news/2023-11-08-FOSDEM24-CfP
should you want to share it.

Re: Discussion about gnu radio

[Marcus Müller]

Hi Nithin,

you're on the discuss-gnuradio mailing list, with a lot of people discussing GNU Radio 
every day. So discuss!


Best,
Marcus

On 30.11.23 11:59, cb.en.u4ece20121--- via GNU Radio, the Free & Open-Source Toolkit for 
Software Radio wrote:

Hi I am Nithin
i want to discuss about gnu radio
please give response


[https://intranet.cb.amrita.edu/sig/RankingLogo.png]

Disclaimer

Re: Rational Resampler - block executor error

[Marcus Müller]

Hi Al,

On 27.11.23 06:44, Al Grant wrote:

Thanks for the detailed reply Marcus.


you're most welcome!


*M=800*
Where is M=800 in my rational resampler? I see looking at the link to the
picture I posted I had Decimation=100 (is M shorthand for decimation?)


https://imgur.com/a/B2HqCKc shows "Rational Resampler" with "Decimation: 800", 
not 100.


*PICTURE*
To your picture:

[image: image.png]

But my sample only has a repeating tone on 1 frequency, but in the picture
above with frequency on the x axis (and power on the y?), and  3 peaks I
have circled in red, at first glance I would have said this shows a signal
on the 3 different frequencies?


No, it doesn't have 3 different frequencies! You missed my point there: this is *one* 
signal. The frequency axis extends to - infinity and to + infinity; there's infinitely 
many (light green) repetitions, not 3, in a discrete-time signal. (I just couldn't draw 
infinitely wide pictures!)
We just conveniently decide that, to look at the signal, it suffices to look at the 
baseband one repetition, the dark green one.


It does suffice to describe all the information in the signal! But: it breaks down when 
you do things like decimating or interpolating, because suddenly you get the effects of 
these repetitions you "just tried very hard to forget about" :D



I am assuming you didn't mean what I have written above, but I
can't reconcile the picture with the concept you are trying to convey.


Hope the above helps!



*FILTER TYPE*
I see you have suggested a series of resampling filters, instead of 1 big
one, is that for computing efficiency or because it wont work the way I
expect the way I have done it?

What is the difference between just a straight decimating block and
rational resampler?


If you choose to use a filter that cuts out the lower 1/M of the original bandwidth, it's 
the same. (assuming the rational resampler is set to "Interpolation: 1")



*BASEBAND*
Since my original post I have a slightly better understanding of a baseband
file. Correct me if I get it wrong, but for example a RTL-SDR can capture
baseband at 2.4Mhz (i.e. spectral width). 


Sounds right!


To my example I am interested in
160.100Mhz to 160.200 with 100 channels spaced at 160.100, 160.110Mhz etc
etc.


So, a bandwidth of 100 · 0.01 MHz, if I get you correctly, or 1 MHz. Add a bit "left and 
right", because the analog filters aren't perfect, so maybe 1.2 MHz, just because we can 
trivially afford to be so generous.



So in one baseband file I can capture all 100 channels. Cool.


Exactly!


For the moment I just want to focus on 1 disaster (channel) at a time, and
am interested in getting the file into Java and doing the processing there.


And you seem to be doing the right thing in principle (I didn't look at the numbers being 
sensible here): you're selecting a single channel, say "OK, because that channel is only 
1/M of the overall bandwidth, I decimate by M".


The thing I'm not understanding about your flow graph is then why the following low-pass 
filter at all?
(it's also incorrectly parameterized, as far as I can tell, because your input sampling 
rate wasn't 32 kHz (as specified in the low-pass filter) times 800 (=25.6 MHz) (or 100, 
assuming the 800 was a typo, so 100·32 kHz = 3.2 MHz), but probably a bandwidth that your 
RTL dongle actually supports.)



Best regards,
Marcus

[CfP] Last week to send in your FOSDEM talk proposals! (was: [CfP] Software-Defined Radio and Amateur Radio Devroom 2024)

[Marcus Müller]

Dear community,

a friendly reminder that on the first of December, the window for handing in your talk 
proposals for FOSDEM'24's SDR and ham radio devroom closes. Make sure you send in your 
proposal by then!


Best,
Marcus


 Forwarded Message 
Subject: [CfP] Software-Defined Radio and Amateur Radio Devroom 2024
Date: Wed, 8 Nov 2023 20:52:00 +0100
From: Marcus Müller 
To: GNURadio Discussion List , usrp-users 
, sdrbelg...@lists.uba.be


Dear Friends of Free and Open Source Radio!

FOSDEM 2024, the Free and Open Source Developer’s Meeting taking place in
Brussels, Belgium, 3. & 4. February 2024, will once again feature a track on
FOSS-powered Radio; this year, there will be a combined Amateur Radio and SDR
Devroom:

https://fosdem.org/2024/schedule/track/radio/

In case you're wondering what Amateur Radio and Software-Defined Radio are, we
have a small introduction below. See the "Recommended Topics" section!

We invite developers and users of Free Software from these fields and to
contribute to this event by presenting their projects, ideas and their work.

Please read our Call for Presentations below:
See you in Brussels!

Bastien, Marc and Marcus

Submit Your Presentations!
=

To suggest a talk, go to

https://pretalx.fosdem.org/fosdem-2024/cfp

"Submit a proposal" and fill in the fields; make sure it's in the Software
Defined Radio and Amateur Radio track!

Content and Shape of Presentations
--

Please aim for your talk to be 20 to 25 minutes long, which leaves enough time
for questions & answers within a 30 minute slot. Should you definitely need
more time, we can combine time slots; but please reach out to us before
submitting your overlength talk proposal!

The final schedule will be available through Pretalx and the official FOSDEM
website. Notice that the reference time will be Brussels local time (CET).

In the Software Defined Radio and Amateur Radio devroom, we aren’t constrained
to holding slideshow presentation – bring your demo, your prototype! However,
since this is a software community conference, please refrain from offering
marketing-style presentations. Give the radio experts something to chew on! We
like the nitty-gritty technical details.

Travel Aid
--

If you are a young person, and cannot afford to travel to Brussels and stay
there, please do contact us as early as possible with an itemized estimate of
your financial needs, and remark that you've done so in your proposal's
"Submission Notes". The International Amateur Radio Union Region 1 has
generously offered to assist financially for up to two contributors.

Recommended Topics
--

Topics discussed in the devroom include, but are not limited to:

- SDR frameworks and the tools that make them useful
- New SDR-based developments in ham radio modes
- Cellular/telecom software
- Amateur radio operator software tooling
- Free / Open radio hardware
- Wireless security research
- Entertaining wireless hacks
- SDR & ham radio in mass and higher education
- Satellite, spacecraft and interplanetary communication

Software-Defined Radio is the technology of enabling radio signals to be
processed and generated algorithmically,  typically within general purpose
processors, but also within FPGAs and GPUs; Free and Open Source (FOSS)
Software Radio allows these  algorithms to be inspectable and improvable. With
the advent of ubiquitous IoT, sky-filling satellite megaconstellations and
5G/6G as standards designed with commercial Software Radios in mind, wireless
is an exploding field of interest in the FOSS realm.

Ham Radio, also known as amateur radio, is more than just a hobby orbiting the
usage of radio communication – it's a passion that merges the realms of
electronics, human interaction, and communication. At its core, ham radio is
about establishing connections: with people, with technology, and with the
world at large. It is a free and open community effort at heart!

Important Dates
===

- Submission Deadline: 1. December 2023
- Announcement of selected talks: 15. December 2023
- Conference: 3. & 4. February 2024

Organizer's Contacts


- Software-Defined Radio & Amateur Radio Matrix Space:
  https://matrix.to/#/#fosdem2024:c1.uba.be
- Devroom Chat:
  https://matrix.to/#/#sdr-and-ham-radio-fosdem24:gnuradio.org
- Amateur Radio Program Committee:
  Bastien Cabay, ON4BCY , Marc Balmer, HB9SSB 
- Software-Defined Radio Program Committee:
  Marcus Müller 

You can also find this announcement on
https://gnuradio.org/news/2023-11-08-FOSDEM24-CfP
should you want to share it.

Re: Rational Resampler - block executor error

[Marcus Müller]

Hi Al,

you'll laugh, but under the hood, the rational resampler *is* a filter! And the way you 
configured it, it has very many taps. So, the correct solution is actually to reduce the taps.


Let me quickly explain:

Here's an example for a complex baseband digital signal; already sampled at a sampling 
rate of f_sample


Figure 1: Spectrum of a discrete-time signal

What you see there is, across the a horizontal axis denoting the frequency within your 
signal, how much power there is for each "blot" of frequency; a "power spectral density" 
(PSD); we typically call this a "Spectrum".


Now, you'll notice that your signal spectrum is periodic – it repeats every multiple of 
f_sample. In complex baseband, we typically "try really hard to forget that" and just deal 
with one of these repetitions – the "zero-centered" (hence the name, baseband) swath from 
-f_sample/2 to +f_sample/2 (darker green).


As you can infer from that repetition, a discrete-time signal (so, any signal that you 
deal with in GNU Radio: signal is represented by values, so-called samples, one after the 
other, not by some smooth function) can only hold frequency content if the whole 
represented signal fits inside the sampling rate – otherwise, due to the periodicity, 
something from another repetition "zone" (say, from the –3/2 f_sample to - 1/2 f_sample 
zone) overlays your original zone. We call that phenomenon "aliasing", by the way.


That's exactly what happens when you reduce the sampling rate. Say, we throw away every 
even sample, and get half as many samples per second. What happens? We halfed the number 
of samples, so we halfed the sampling rate; we should just be able to relabel the 
horizontal axis, right?



Figure 2


But wait, we've just learned that the spectrum repeats every sampling rate multiple – now 
f_sample,new; and we see that in the spectrum, also (now in blue):


Figure 3: Now with aliases!

Uh-oh. Now the green original and the blue repetitions overlap, within our nice 
-f_sample,new / 2 to +f_sample,new / 2 baseband. That's not usable anymore!


So what the clever signal processing person does is go back and first low-pass filter the 
original signal to the part that will not overlap. We know how wide that part can be: as 
wide as the new sampling rate, so in this case, half the original bandwidth:


Figure 4: Low-pass filtered (to half bandwidth) original signal at original 
sampling rate

and now throwing away every other sample, i.e., reducing the sampling rate to 
its half:

Figure 5: Low-pass filtered (to half bandwidth) original signal at half 
sampling rate


Oh neat, no spectral overlapping!


Coming back to what your resampler does: It is a "filter to the new 1/M bandwidth, then 
throw away every but the M. samples" block. When set to decimation = 2 (so, M=2), it does 
what you see above!


But, your decimation is M=800. That means the filtering needs to first restrict the green 
signal to 1/800 of its original bandwidth. Doing that filtering takes a very complicated 
(long) filter. If you ever heard of the Heisenberg uncertainty principle, that you can't 
know the impulse (hence the frequency) of a particle and its location at the same time 
more exactly than a specific constant, the same math underlies this principle: narrow 
filters, or more precisely, filters that are very sharp in the frequency domain, need to 
be very long and drawn out in the time domain.


So your filter is 27861 taps long – and GNU Radio fails to construct a method of getting 
so many samples for a single iteration of the filter into the filtering, so it tells you 
"hey, you want only sample packets of at least 27862 samples, but the most I could offer 
you at once is 8192, sorry, this can't work out".



**How to solve it**, now, is realizing that you don't need to do all this at once. How 
about you do


--> resampler decimation=8 --> resampler decimation=4 --> resampler decimation=5 --> 
resampler decimation=5


That achieves the same result, decimation by 8·4·5·5=800 but with much shorter filters 
(and more of these filters can also run at a lower sampling rate, which is also 
computationally cheaper).


Cheers,
Marcus

On 24.11.23 07:28, Al Grant wrote:

I am still trying to learn how GR works.

Coming from Java the idea of being able to do some processing there
interests me.

So I am trying to use a baseband file from SDR++ as a file source, and
process it in such a way that I can get the amplitude in Java. I
presume this would mean reading in the bin file and decoding the bits
to the I and Q values.

The source file is an unmodulated pulse on about 160.7807Mhz about 2
times per second.

Here is my block setup:https://imgur.com/a/B2HqCKc
And a link to the github project with the baseband file :
https://github.com/bigalnz/java_test

The issue I am currently having :

block_executor :error: sched:  (1)> is requesting more input
data  than we can provide.  ninput_items_required = 27862
max_possible_items_available = 

[CfP] Software-Defined Radio and Amateur Radio Devroom 2024

[Marcus Müller]

Dear Friends of Free and Open Source Radio!

FOSDEM 2024, the Free and Open Source Developer’s Meeting taking place in
Brussels, Belgium, 3. & 4. February 2024, will once again feature a track on
FOSS-powered Radio; this year, there will be a combined Amateur Radio and SDR
Devroom:

https://fosdem.org/2024/schedule/track/radio/

In case you're wondering what Amateur Radio and Software-Defined Radio are, we
have a small introduction below. See the "Recommended Topics" section!

We invite developers and users of Free Software from these fields and to
contribute to this event by presenting their projects, ideas and their work.

Please read our Call for Presentations below:
See you in Brussels!

Bastien, Marc and Marcus

Submit Your Presentations!
=

To suggest a talk, go to

https://pretalx.fosdem.org/fosdem-2024/cfp

"Submit a proposal" and fill in the fields; make sure it's in the Software
Defined Radio and Amateur Radio track!

Content and Shape of Presentations
--

Please aim for your talk to be 20 to 25 minutes long, which leaves enough time
for questions & answers within a 30 minute slot. Should you definitely need
more time, we can combine time slots; but please reach out to us before
submitting your overlength talk proposal!

The final schedule will be available through Pretalx and the official FOSDEM
website. Notice that the reference time will be Brussels local time (CET).

In the Software Defined Radio and Amateur Radio devroom, we aren’t constrained
to holding slideshow presentation – bring your demo, your prototype! However,
since this is a software community conference, please refrain from offering
marketing-style presentations. Give the radio experts something to chew on! We
like the nitty-gritty technical details.

Travel Aid
--

If you are a young person, and cannot afford to travel to Brussels and stay
there, please do contact us as early as possible with an itemized estimate of
your financial needs, and remark that you've done so in your proposal's
"Submission Notes". The International Amateur Radio Union Region 1 has
generously offered to assist financially for up to two contributors.

Recommended Topics
--

Topics discussed in the devroom include, but are not limited to:

- SDR frameworks and the tools that make them useful
- New SDR-based developments in ham radio modes
- Cellular/telecom software
- Amateur radio operator software tooling
- Free / Open radio hardware
- Wireless security research
- Entertaining wireless hacks
- SDR & ham radio in mass and higher education
- Satellite, spacecraft and interplanetary communication

Software-Defined Radio is the technology of enabling radio signals to be
processed and generated algorithmically,  typically within general purpose
processors, but also within FPGAs and GPUs; Free and Open Source (FOSS)
Software Radio allows these  algorithms to be inspectable and improvable. With
the advent of ubiquitous IoT, sky-filling satellite megaconstellations and
5G/6G as standards designed with commercial Software Radios in mind, wireless
is an exploding field of interest in the FOSS realm.

Ham Radio, also known as amateur radio, is more than just a hobby orbiting the
usage of radio communication – it's a passion that merges the realms of
electronics, human interaction, and communication. At its core, ham radio is
about establishing connections: with people, with technology, and with the
world at large. It is a free and open community effort at heart!

Important Dates
===

- Submission Deadline: 1. December 2023
- Announcement of selected talks: 15. December 2023
- Conference: 3. & 4. February 2024

Organizer's Contacts


- Software-Defined Radio & Amateur Radio Matrix Space:
  https://matrix.to/#/#fosdem2024:c1.uba.be
- Devroom Chat:
  https://matrix.to/#/#sdr-and-ham-radio-fosdem24:gnuradio.org
- Amateur Radio Program Committee:
  Bastien Cabay, ON4BCY , Marc Balmer, HB9SSB 
- Software-Defined Radio Program Committee:
  Marcus Müller 

You can also find this announcement on
https://gnuradio.org/news/2023-11-08-FOSDEM24-CfP
should you want to share it.

Re: error

[Marcus Müller]

Hi David,

nothing's corrupted. This just literally says gr-osmosdr is trying to load a library, in 
this case, the core library of GNU Radio, which isn't there where your Python looks.


Two options:

1. You installed GNU Radio somewhere Python doesn't look by default, and you haven't told 
Python where to look, or
2. you installed GNU Radio, then installed a gr-osmosdr that was built against that 
version of GNU Radio, and then updated GNU Radio, but did not rebuild gr-osmosdr.


I don't know how you installed both GNU Radio and gr-osmosdr, so I can't really 
advise!

Best regards,
Marcus

On 28.10.23 18:00, David Martini wrote:

Hi all

I'm getting the following error using rtl-sdr.

    from .osmosdr_python import *
ImportError: libgnuradio-runtime.so.3.10.5: cannot open shared object file: No such file 
or directory.


Can someone help?

I suspect some configuration file is corrupted...

Thanks

David
IW5BNL

Re: Processor_Cache

[Marcus Müller]

Hi Jiya,

none of what you asked makes sense, I'm afraid. GNU Radio is software, not hardware. 
Python is software, too.


Best regards,
Marcus

Re: Some GRC files run with no errors but don't plot

[Marcus Müller]

Hi Tom,

well, you need to fix the fact that you're trying to feed streams with different rates 
into the same Visualization, that's just not /sensible/, DSP-wise. So, what's the purpose 
of doing that? To me, it's quite intuitive that when I have something that shows me my 
signal, and that something just gets the signal as sequence of numbers, that it's gotta be 
all the same rate. But you're intentionally breaking with that notion here, so I *bet* you 
have an intent there, and thus me saying "well don't do that, then" isn't going to solve 
your problem.


Best regards,
Marcus

On 12.10.23 18:12, tom sutherland wrote:

Any solution to the problem of running out of date in one path?
Tom

On Thursday, October 12, 2023 at 11:02:06 AM CDT, discuss-gnuradio-requ...@gnu.org 
 wrote:



Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org

You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

  1. Some GRC files run with no errors but don't plot (tom sutherland)
  2. Re: Some GRC files run with no errors but don't plot
      (Marcus Müller)


--

Message: 1
Date: Thu, 12 Oct 2023 11:36:24 + (UTC)
From: tom sutherland 
To: "discuss-gnuradio@gnu.org" 
Subject: Some GRC files run with no errors but don't plot
Message-ID: <1055450876.6185365.1697110585...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

I have a simple grc file that shows the difference in Interpolation and Decimation using 
the Rational Re-sampler blocks. The program runs once, a "Time Sink" shows the 
signals(once) and then stops plotting and the Frequency Sink does not show a frequency 
plot at all. I've had other programs that do similar things, runs but nothing shows, 
once and freezes or for a few cycles and stops. Any thoughts on causes and /or how to 
solve/debug it would be appreciated. I am running GRC 3.10.5.0 on a Windows 10 
Enterprise 12th Gen i7 machine with 32GB RAM. I've attached the grc/py and plot files.

Thanks...Tom



-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231012/233cf07a/attachment.htm>

-- next part --
A non-text attachment was scrubbed...
Name: RationalResamplerInterpAndDecimation.grc
Type: application/octet-stream
Size: 7734 bytes
Desc: not available
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231012/233cf07a/attachment.obj>

-- next part --
A non-text attachment was scrubbed...
Name: RationalResamplerInterpAndDecimation.png
Type: image/png
Size: 83107 bytes
Desc: not available
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231012/233cf07a/attachment.png>

-- next part --
A non-text attachment was scrubbed...
Name: RationalResamplerInterpAndDecimation.py
Type: application/octet-stream
Size: 10462 bytes
Desc: not available
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231012/233cf07a/attachment-0001.obj>

-- next part --
A non-text attachment was scrubbed...
Name: 1697110214110blob.jpg
Type: image/png
Size: 255699 bytes
Desc: not available
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231012/233cf07a/attachment-0001.png>


------

Message: 2
Date: Thu, 12 Oct 2023 13:59:07 +0200
From: Marcus Müller 
To: discuss-gnuradio@gnu.org
Subject: Re: Some GRC files run with no errors but don't plot
Message-ID: 
Content-Type: text/plain; charset=UTF-8; format=flowed

I think I can explain!


Both sinks need to always consume the same number of input items from all their 
inputs.
So, even if you disabled the time sink, the upper sink would quickly grind to a 
halt,
because the "lowest rate" Rational Resampler (interp=1,decim=4) would not be 
able to
produce the samples needed to keep up with the "highest rate" resample 
(interp=4,
decim=1). Both resamplers work on the same input, just that the lowest-rate one 
takes 16×
the amount of input to produce the same amount of output as the highest-rate 
one. Since
both share the same input, and that input has a finite buffer, this can't work 
for long.

So, your flow graph has an architectural shortcoming, either way.

The time sink hits that bug you've built quicker, because it has no throttle in 
the way.


Best,
Marcus




--

Subject: Digest Footer

__

Re: Some GRC files run with no errors but don't plot

[Marcus Müller]

I think I can explain!


Both sinks need to always consume the same number of input items from all their inputs. 
So, even if you disabled the time sink, the upper sink would quickly grind to a halt, 
because the "lowest rate" Rational Resampler (interp=1,decim=4) would not be able to 
produce the samples needed to keep up with the "highest rate" resample (interp=4, 
decim=1). Both resamplers work on the same input, just that the lowest-rate one takes 16× 
the amount of input to produce the same amount of output as the highest-rate one. Since 
both share the same input, and that input has a finite buffer, this can't work for long.


So, your flow graph has an architectural shortcoming, either way.

The time sink hits that bug you've built quicker, because it has no throttle in 
the way.


Best,
Marcus

Re: Volk sqrt ARM performance

[Marcus Müller]

Hi Jeff,

you'll want to compile with optimization, otherwise you'd be intentionally making the 
native `sqrt` slower than it would be in a real application; you need to add `-O2` or 
`-O3` to your compilation. Also, you're using floats, not doubles, so use `sqrtf` in your 
C code, not `sqrt`! (your code is C, not necessarily how you'd write the same program in C++).


Also, compared to the time for the math you're doing, both in the volk and in the libm 
sqrt case, your time measurement's uncertainty is large. (taking the square root of only 
16k values – that's nearly nothing.) You need to run that in a loop of many iterations, 
preferably with some warm-up to get the branch predictors trained. (assuming the CPU *has* 
branch prediction – the ARM1176JZ-S doesn't, as far as I know).


Hey, luckily your VOLK already ships with such a loop-running benchmark mockup: 
`volk_profile -R sqrt` will do exactly that. The `generic` implementation literally just 
calls `sqrtf`. Could you share the output of `volk_profile -R sqrt` with us?


Furthermore, I'm **highly** confused by your results: ARM1176JZ-S is a 32 bit processor, 
developed somewhere in the early 2000s; so, it's –by modern standards– a painfully slow 32 
bit armv6 CPU. It predates both aarch64 and NEON! So, I'm pretty sure cpu_features must be 
wrong, or this is not the CPU you're using. In this rare case, I think you must be wrong 
and not the software, because you're also using a /usr/local/lib64 library path, which 
would quite unambigously point to a 64 bit OS, which couldn't run on an ARM11.


Could you double-check and *confirm* you're using an ARM1176JZ-S processor? If you are, 
are you perhaps running this with qemu-aarch64 on your armv6 (32 bit!) machine? Can you 
send us the `volk_sqrt` you're getting, or at least share what `file volk_sqrt` says about 
that binary?
We then would need to help you file a bug upstream against cpu_features, because it'd be 
impossible for us to build a working VOLK if cpu_features goes and miscategorizes an 
ancient 32 bit machine as aarch64.


Best regards,
Marcus

On 08.10.23 00:22, Jeff R wrote:


I modified a simple Volk sqrt program for an ARM1176JZ-S processor to test performance, 
and the results are puzzling. The following program prints:


dur_VolkSqrt=(0.00)0.001721 dur_CRTLSqrt=(0.00)0.000318

The following processor information is displayed. It appears as though NEON is 
supported.


~/volk-3.0.0/build# cpu_features/list_cpu_features

arch : aarch64

implementer :  65 (0x41)

variant :   0 (0x00)

part : 3336 (0xD08)

revision :   3 (0x03)

flags : asimd,cpuid,crc32,fp

Why are the numbers so slow for Volk versus the CRTL? I may be missing something 
obvious. Thank you in advance.


Here’s the test program:

// g++ -I /usr/local/include/volk volk_sqrt.cpp -o volk_sqrt -L 
/usr/local/lib64/ -lvolk

// export LD_LIBRARY_PATH=/usr/local/lib64; ./volk_sqrt


#include 

#include 

#include 

#include 

#include 

#include 


double get_wall_time()

{

struct timeval time;


if (gettimeofday(,NULL))

{

//  Handle error

return 0;

}

return (double)time.tv_sec + (double)time.tv_usec * .01;

}


int main(int argc, char* args[])

{

double walStop;

double walStart;

double dur_VolkSqrt;

double dur_CRTLSqrt;

int N = 1024*16;


unsigned int alignment = volk_get_alignment();

float* in = (float*)volk_malloc(sizeof(float)*N, alignment);

float* out = (float*)volk_malloc(sizeof(float)*N, alignment);


for(unsigned int ii = 0; ii < N; ++ii)

{

in[ii] = (float)(ii*ii);

}


walStart = get_wall_time();

volk_32f_sqrt_32f_a(out, in, N);

//volk_32f_sqrt_32f(out, in, N);

walStop = get_wall_time();

dur_VolkSqrt = walStop - walStart;


walStart = get_wall_time();

for(unsigned int ii = 0; ii < N; ++ii)

{

out[ii] = sqrt(in[ii]);

}

walStop = get_wall_time();

dur_CRTLSqrt = walStop - walStart;


printf("dur_VolkSqrt=(%f)%f dur_CRTLSqrt=(%f)%f\n", dur_VolkSqrt/N, dur_VolkSqrt, 
dur_CRTLSqrt/N, dur_CRTLSqrt);


volk_free(in);

volk_free(out);

return 0;

}

Re: Index Error: output_index < noutputs

[Marcus Müller]

Hi Vasil,

just wanted to express my appreciation for the detail of investigation you're doing there. 
Thanks!


Marcus

On 27.09.23 19:55, Vasil Velichkov wrote:

Hi Elmore,

On 27/09/2023 03.17, Elmore Family wrote:

I am using a gnu radio flowgraph to attempt to select the appropriate Selector 
Block output as explained below. The following error occurs when I run the 
flowgraph: Index Error: output_index must be < noutputs.



I forgot to include the version: 3.9.4.0.


Lets try analyzing the source code where this error is thrown.

$ git checkout v3.9.4.0

$ grep "output_index must be < noutputs" . -R
./gr-blocks/lib/selector_impl.cc:throw std::out_of_range("output_index must be 
< noutputs");

https://github.com/gnuradio/gnuradio/blob/v3.9.4.0/gr-blocks/lib/selector_impl.cc#L66-L73

  66 void selector_impl::set_output_index(unsigned int output_index)
  67 {
  68 gr::thread::scoped_lock l(d_mutex);
  69 if (output_index < d_num_outputs)
  70 d_output_index = output_index;
  71 else
  72 throw std::out_of_range("output_index must be < noutputs");
  73 }

The code is pretty simple, the only possible case is the value of output_index 
variable to be greater or equal to d_num_outputs variable. You are calling 
set_output_index with 1 so d_num_outputs must be either 0 or 1.

Now let's check where d_num_outputs gets its value.

$ grep -n d_num_outputs ./gr-blocks/lib/selector_impl.cc
40:  d_num_outputs(0)
69:if (output_index < d_num_outputs)
100:if (new_port < d_num_outputs)
138:d_num_outputs = (unsigned int)noutputs;

It is initialized to 0 in the constructor on line 40 and get assigned in 
selector_impl::check_topology function on line 138.

https://github.com/gnuradio/gnuradio/blob/v3.9.4.0/gr-blocks/lib/selector_impl.cc#L134-L145

So it looks that you are calling set set_output_index(1) before 
check_topology() has been called, before the flowgraph is started.

Looks like you need to start the flowgraph first and then call 
set_output_index(1)

Hope this helps.

Regards,
Vasil

Re: Index Error: output_index < noutputs

[Marcus Müller]

Hi Jim,

since we've worked on Selector recently, it would **really** be important to know the 
version of GNU Radio you're dealing with!


Best regards,
Marcus

Re: 3D plotting in GNU Radio

[Marcus Müller]

Hi Ivan,

if you want to display 2D data with a color dimension, the QT GUI Time Raster Sink would a 
possible choice. I made a quick flow graph to demonstrate:


https://wiki.gnuradio.org/index.php?title=QT_GUI_Time_Raster_Sink#Example_Flowgraph

On 26.09.23 13:30, kron...@tiscali.it wrote:

Hi all!
I wrote a custom python block that emits items consisting on flattened matrices.
I would like to dynamically plot these matrices as a coloured surface (similar to the 
waterfall sink) and update the surface based on refresh rate provided by the user.

How could I implement this using gnuradio? Could you provide me an example code?
Thanks a lot in advance!

Ivan

Re: self.set_history error for python custom block

[Marcus Müller]

Yep, most methods of classes are like that; you need to initialize the class first, then 
can work on its state :) That's why other programming languages than Python don't even 
give you that much freedom about when to call the superclass constructor.


Anyway, I'm very glad you were able to fix that! Happy developing!

Cheers,
Marcus

On 25.09.23 23:01, Ivan Iudice wrote:

I found out to make it work!
The problem was that set_history needs to be called after the constructor of 
the super class. Probably it needs to know first the input signature. You will 
be able to confirm me that.
Thanks for help!

Ivan


Il giorno 25 set 2023, alle ore 16:12, Marcus Müller  ha 
scritto:

Python incompatibility can safely be ruled out; you wouldn't get far enough. 
Please share a minimal example of a block that triggers the behaviour.

Best,
Marcus


On 25.09.23 15:49, Ivan Iudice wrote:
Nobody knows where could be the problem?
I thought an incompatibility between gnuradio and python versions.
Regards.
Ivan

Il giorno 21 set 2023, alle ore 18:13, Ivan Iudice  ha 
scritto:


Dear Jeff,
thank you for answer.
My code does exactly the same things.
Regards.

Ivan


Il giorno 21 set 2023, alle ore 17:55, Jeff Long  ha 
scritto:


Here is an example (from the QA code) of using history from a Python block.

https://github.com/gnuradio/gnuradio/blob/5953d3c96b42086c5f8c5f97b6fd7e57717f9aa5/gr-blocks/python/blocks/qa_block_gateway.py#L60
 
<https://github.com/gnuradio/gnuradio/blob/5953d3c96b42086c5f8c5f97b6fd7e57717f9aa5/gr-blocks/python/blocks/qa_block_gateway.py#L60>

See if your code appears to be doing the same thing.

On Thu, Sep 21, 2023 at 11:03 AM mailto:kron...@tiscali.it>> wrote:

__
Hello List!
I'm trying to implement a sync block into a OOT module that use previous 
samples of
the input streams.
So, I'm using the method set_history in the constructor.
The problem is that when I use self.set_history(N) I obtain the following 
errors:

Generating: 
'/home/userr/workspace/gnuradio-oot/gr-customModule/examples/untitled.py'

Executing: /usr/bin/python3 -u
/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py

QSocketNotifier: Can only be used with threads started with QThread
Traceback (most recent call last):
  File 
"/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py",
line 291, in 
main()
  File 
"/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py",
line 269, in main
tb = top_block_cls()
 ^^^
  File 
"/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py",
line 179, in __init__
self.customModule_testBlock_0_0 = customModule.testBlock(1, max_lag, 
lags,
alpha, win_len, 1, False)
 
^^
  File

"/usr/local/lib/python3.11/dist-packages/gnuradio/customModule/testBlock.py", 
line
33, in __init__
self.set_history(self.max_pos_lag-self.min_neg_lag+1)

  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 129, in
__getattr__
if not hasattr(self, "gateway"):
   
  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 129, in
__getattr__
if not hasattr(self, "gateway"):
   
  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 129, in
__getattr__
if not hasattr(self, "gateway"):
   
  [Previous line repeated 984 more times]
RecursionError: maximum recursion depth exceeded

>>> Done (return code 1)

I'm using GNU Radio 3.10.5.1 (Python 3.11.2) on Debian 12.
What is going on?
Thanks in advance!
Ivan

Re: self.set_history error for python custom block

[Marcus Müller]

Python incompatibility can safely be ruled out; you wouldn't get far enough. Please share 
a minimal example of a block that triggers the behaviour.


Best,
Marcus

On 25.09.23 15:49, Ivan Iudice wrote:

Nobody knows where could be the problem?
I thought an incompatibility between gnuradio and python versions.
Regards.

Ivan


Il giorno 21 set 2023, alle ore 18:13, Ivan Iudice  ha 
scritto:

Dear Jeff,
thank you for answer.
My code does exactly the same things.
Regards.

Ivan


Il giorno 21 set 2023, alle ore 17:55, Jeff Long  ha 
scritto:


Here is an example (from the QA code) of using history from a Python block.

https://github.com/gnuradio/gnuradio/blob/5953d3c96b42086c5f8c5f97b6fd7e57717f9aa5/gr-blocks/python/blocks/qa_block_gateway.py#L60
 


See if your code appears to be doing the same thing.

On Thu, Sep 21, 2023 at 11:03 AM mailto:kron...@tiscali.it>> wrote:

__
Hello List!
I'm trying to implement a sync block into a OOT module that use previous 
samples of
the input streams.
So, I'm using the method set_history in the constructor.
The problem is that when I use self.set_history(N) I obtain the following 
errors:

Generating: 
'/home/userr/workspace/gnuradio-oot/gr-customModule/examples/untitled.py'

Executing: /usr/bin/python3 -u
/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py

QSocketNotifier: Can only be used with threads started with QThread
Traceback (most recent call last):
  File 
"/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py",
line 291, in 
    main()
  File 
"/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py",
line 269, in main
    tb = top_block_cls()
 ^^^
  File 
"/home/user/workspace/gnuradio-oot/gr-customModule/examples/untitled.py",
line 179, in __init__
    self.customModule_testBlock_0_0 = customModule.testBlock(1, max_lag, 
lags,
alpha, win_len, 1, False)
 
^^

  File

"/usr/local/lib/python3.11/dist-packages/gnuradio/customModule/testBlock.py", 
line
33, in __init__
    self.set_history(self.max_pos_lag-self.min_neg_lag+1)
    
  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 129, in
__getattr__
    if not hasattr(self, "gateway"):
   
  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 129, in
__getattr__
    if not hasattr(self, "gateway"):
   
  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 129, in
__getattr__
    if not hasattr(self, "gateway"):
   
  [Previous line repeated 984 more times]
RecursionError: maximum recursion depth exceeded

>>> Done (return code 1)

I'm using GNU Radio 3.10.5.1 (Python 3.11.2) on Debian 12.
What is going on?
Thanks in advance!
Ivan

Re: how can we implement a pool/worker structure in gnuradio?

[Marcus Müller]

Whatever your problem is, you really *never* need a copy block to distribute work; for 
that, GNU Radio's buffer are already there. You just added unnecessary copying to your 
problem. And GNU Radio blocks are all running in their own thread by themselves, so I 
think you might be missing the point alltogether here


Stackprogrammer, as usual: you wrote a less-than-10-lines vague description of the 
problem, gave no context, and hoped for competent answers. That doesn't work here, and it 
doesn't work anywhere else – I've heard from more than one party that has been in direct 
contact with you that was quite frustrated that you repeatedly just throw out random 
"problems" without any context. Please be more considerate of the time of people trying to 
help you.


Best regards,
Marcus

On 13.09.23 08:43, sp wrote:
After examination I found a solution, you can use copy block in gnuradio for 
the implementation of a pool structure.


On Tue, Aug 29, 2023 at 3:42 PM sp  wrote:

In programming, I need to define a pooling layer that updates the last usrp 
samples
and other blocks use these pool samples and compute some operations, I 
emphasize
that my means from pool,the pool is shared for all blocks(the blocks that 
use pool
name as worker)
Can anyone guide me? thanks in advance
more info: https://en.wikipedia.org/wiki/Thread_pool

Re: embedded python block-Can't interpret source code: "'__name__' not in globals"

[Marcus Müller]

Hi Liya,

the code you refer to is not an embedded python block, so it can't work 
as one. As you can see from the python code, it imports things from the 
same directory. So this can't work! Never forget to read the code you're 
copying :)


Best regards,
Marcus

On 9/6/23 22:34, Jiya Johnson wrote:

Good morning community,
I was trying to create an embedded python module with the same code 
for fec extended encoder in GNU RADIO 3.10.7 version .I am 
encountering this problem "Param - Code(_source_code):

Can't interpret source code: "'__name__' not in globals""
it will be very helpful if someone can help me to clear this..The used 
code is 
*https://github.com/gnuradio/gnuradio/blob/master/gr-fec/python/fec/extended_encoder.py#L21*

Re: [GRCon] GNU Radio Conference 2023 about to kick off – virtually and in-person!

[Marcus Müller]

I've been notified that an unwanted space has slid into that link; the 
correct URL is of course


https://grcon.stream

On 9/5/23 07:46, Marcus Müller wrote:

Dear GNU Radio community,

in about an hour at 9am local time, the GNU Radio conference 2023 
starts at the Arizona State University in Tempe.


Because not everyone can make it to such an event, as usual, we 
live-stream all talks (and will later cut and upload them!). You'll 
find today's stream on

https://grcon. stream , for free.

Whether in chat or in person:
We all are looking forward to talking to you!

[GRCon] GNU Radio Conference 2023 about to kick off – virtually and in-person!

[Marcus Müller]

Dear GNU Radio community,

in about an hour at 9am local time, the GNU Radio conference 2023 starts 
at the Arizona State University in Tempe.


Because not everyone can make it to such an event, as usual, we 
live-stream all talks (and will later cut and upload them!). You'll find 
today's stream on

https://grcon. stream , for free.

Whether in chat or in person:
We all are looking forward to talking to you!

[GRcon23] Reminder: GRCon'23 starts Tuesday! Watch the (free) streams,

[Marcus Müller]

Dearest GNU Radio community,

Just a quick reminder: on Tuesday, September the fifth, GNU Radio conference 2023 kicks 
off in Tempe, Arizona.


As usual, the event will be life-streamed. If you want to join the discussions, you're 
**very** much invited to, even if you're not physically at the event!
All the infos on how to join the discussion, and where to watch the streams can be found 
at [1] in our participant's guide.


You're invited, but by no technical nor social means forced, to register as online 
participant under [2]; the idea is simply that next year, we can brag with the audience 
size – which in turn makes it easier for our supporters in companies to lobby for 
corporate sponsorship.
(So, registering, even if you decide to pay exactly nothing, does help offset the cost of 
running the infrastructure, paying for A/V and other services a bit; of course, if you 
feel that watching GRCon streams is something that brings you forward professionally, we'd 
be more than delighted if you chose to pay more).


So: See you on Tuesday, in Tempe or in Chat,
Marcus

[1] https://events.gnuradio.org/event/21/page/95-participants-guide
[2] https://tickets.gnuradio.org/grcon23/

Re: FM Carrier Recovery for AOA Calculation

[Marcus Müller]

Always wondered what the state-of-the-art is in oscillator drift compensation; I bet 
there's more to it than estimating a second derivative of one LO's phase against the other 
and throwing Kalman at it until it doesn't move anymore, or whether there's better models...


but you're right. If this is more than "a one-shot measurement immediately after 
calibration", you'll need to share a reference clock; even an extremely nice frequency 
error of $2\cdot 10^{-8}$ between the two receivers would, at 1 GHz carrier, mean that the 
phase of one rotates away from the other by $40 \pi$ every second, so you have like 10 ms 
until you lose any sensible idea of direction. I don't know how well the calibration 
routine is able to compensate such small frequency errors, it might actually be OK for 
longer, or it might not.


Best regards,
Marcus

On 01.09.23 22:48, Marcus D. Leech wrote:


On 01/09/2023 16:39, Marcus Müller wrote:
Ah, nice! yeah, then this would work – but! any oscillator has drift, so two local 
oscillators will not stay on the same phase for long; if your first couple measurements 
are correct, but suddenly your directions become very wrong, that's what I'd investigate.


Cheers,
Marcus
Looks like the BB60C supports an external 10MHz reference clock, which would be utterly 
mandatory for anything requiring
  mutual phase-coherence, whether that's *sufficient* depends very very much on the 
internal architecture of the BB60C.





On 01.09.23 19:16, Michael Berman wrote:
The gr-aoa module has a calibration phase where you connect a source with a splitter 
and roughly equally lengthened cables to the two sources and it cross-correlates the 
two inputs to determine an initial phase difference.  Then, while the script is still 
running, you disconnect the calibration source and connect the antenna's, again with 
roughly equally lengthened cables to run the MUSIC algorithm.



Thank you very much,

Michael Berman

On Fri, Sep 1, 2023 at 11:00 AM Marcus Müller <mailto:marcus.muel...@ettus.com>> wrote:


    If you don't know the relative phase of your two receiver chains, how are you 
going to

    know the direction of a signal?

    On 01.09.23 17:37, Michael Berman wrote:

    Marcus,

    Thanks for the reply!  I apologize, the GR package is gr-aoa, not gr-music, 
and can
    be found here (https://github.com/MarcinWachowiak/gr-aoa
    <https://github.com/MarcinWachowiak/gr-aoa>). The NOAA broadcast is a NBFM 
signal.     I am using 2 Signal Hound receivers (https://signalhound.com/products/bb60c/

    <https://signalhound.com/products/bb60c/>) with 2 antennas spaced on a 
beam.  Do I
    need to synchronize the 2 receivers with an external clock, or should they 
be fine
    free running independently?


    Thank you very much,

    Michael Berman

    On Fri, Sep 1, 2023 at 9:25 AM Marcus Müller mailto:mmuel...@gnuradio.org>> wrote:

    Not familiar with the details of NOAA signalling, but isn't the carrier 
of an FM
    signal
    *the FM signal*?

    For a DoA estimate, you'd correlate the different receive chains with 
each other
    to get a
    phase; so, as long as the signals do have some bandwidth that makes the 
problem
    less
    ambiguous, it'd work with any signal. I'm sadly not familiar with 
gr-music (and
    can't find
    it on cgran.org <http://cgran.org>), but MUSIC works as long as the 
signals at
    the different receive antennas
    are correlated and noise is not. You do not have to preprocess your FM 
signal!

    Best,
    Marcus

    On 01.09.23 17:09, Michael Berman wrote:
    > Does anybody know if there is a way to recover a carrier of an FM 
signal to
    use for an
    > Angle of Arrival calculation?  I am using GNURadio and gr-music and I 
am
    trying to use the
    > NOAA Weather Radio signals.
    >
    > Thank you very much,
    >
    > Michael Berman

Re: FM Carrier Recovery for AOA Calculation

[Marcus Müller]

Ah, nice! yeah, then this would work – but! any oscillator has drift, so two local 
oscillators will not stay on the same phase for long; if your first couple measurements 
are correct, but suddenly your directions become very wrong, that's what I'd investigate.


Cheers,
Marcus

On 01.09.23 19:16, Michael Berman wrote:
The gr-aoa module has a calibration phase where you connect a source with a splitter and 
roughly equally lengthened cables to the two sources and it cross-correlates the two 
inputs to determine an initial phase difference.  Then, while the script is still running, 
you disconnect the calibration source and connect the antenna's, again with roughly 
equally lengthened cables to run the MUSIC algorithm.



Thank you very much,

Michael Berman

On Fri, Sep 1, 2023 at 11:00 AM Marcus Müller <mailto:marcus.muel...@ettus.com>> wrote:


If you don't know the relative phase of your two receiver chains, how are 
you going to
know the direction of a signal?

On 01.09.23 17:37, Michael Berman wrote:

Marcus,

Thanks for the reply!  I apologize, the GR package is gr-aoa, not gr-music, 
and can
be found here (https://github.com/MarcinWachowiak/gr-aoa
<https://github.com/MarcinWachowiak/gr-aoa>). The NOAA broadcast is a NBFM signal. 
I am using 2 Signal Hound receivers (https://signalhound.com/products/bb60c/

<https://signalhound.com/products/bb60c/>) with 2 antennas spaced on a 
beam.  Do I
need to synchronize the 2 receivers with an external clock, or should they 
be fine
free running independently?


Thank you very much,

Michael Berman

On Fri, Sep 1, 2023 at 9:25 AM Marcus Müller mailto:mmuel...@gnuradio.org>> wrote:

Not familiar with the details of NOAA signalling, but isn't the carrier 
of an FM
signal
*the FM signal*?

For a DoA estimate, you'd correlate the different receive chains with 
each other
to get a
phase; so, as long as the signals do have some bandwidth that makes the 
problem
less
ambiguous, it'd work with any signal. I'm sadly not familiar with 
gr-music (and
can't find
it on cgran.org <http://cgran.org>), but MUSIC works as long as the 
signals at
the different receive antennas
are correlated and noise is not. You do not have to preprocess your FM 
signal!

Best,
Marcus

On 01.09.23 17:09, Michael Berman wrote:
> Does anybody know if there is a way to recover a carrier of an FM 
signal to
use for an
> Angle of Arrival calculation?  I am using GNURadio and gr-music and I 
am
trying to use the
> NOAA Weather Radio signals.
>
> Thank you very much,
>
> Michael Berman

Re: FM Carrier Recovery for AOA Calculation

[Marcus Müller]

If you don't know the relative phase of your two receiver chains, how are you going to 
know the direction of a signal?


On 01.09.23 17:37, Michael Berman wrote:

Marcus,

Thanks for the reply!  I apologize, the GR package is gr-aoa, not gr-music, and can be 
found here (https://github.com/MarcinWachowiak/gr-aoa). The NOAA broadcast is a NBFM 
signal.  I am using 2 Signal Hound receivers (https://signalhound.com/products/bb60c/) 
with 2 antennas spaced on a beam.  Do I need to synchronize the 2 receivers with an 
external clock, or should they be fine free running independently?



Thank you very much,

Michael Berman

On Fri, Sep 1, 2023 at 9:25 AM Marcus Müller  wrote:

Not familiar with the details of NOAA signalling, but isn't the carrier of 
an FM signal
*the FM signal*?

For a DoA estimate, you'd correlate the different receive chains with each 
other to
get a
phase; so, as long as the signals do have some bandwidth that makes the 
problem less
ambiguous, it'd work with any signal. I'm sadly not familiar with gr-music 
(and
can't find
it on cgran.org <http://cgran.org>), but MUSIC works as long as the signals 
at the
different receive antennas
are correlated and noise is not. You do not have to preprocess your FM 
signal!

Best,
Marcus

On 01.09.23 17:09, Michael Berman wrote:
> Does anybody know if there is a way to recover a carrier of an FM signal 
to use
for an
> Angle of Arrival calculation?  I am using GNURadio and gr-music and I am 
trying to
use the
> NOAA Weather Radio signals.
>
> Thank you very much,
>
> Michael Berman

Re: FM Carrier Recovery for AOA Calculation

[Marcus Müller]

Not familiar with the details of NOAA signalling, but isn't the carrier of an FM signal 
*the FM signal*?


For a DoA estimate, you'd correlate the different receive chains with each other to get a 
phase; so, as long as the signals do have some bandwidth that makes the problem less 
ambiguous, it'd work with any signal. I'm sadly not familiar with gr-music (and can't find 
it on cgran.org), but MUSIC works as long as the signals at the different receive antennas 
are correlated and noise is not. You do not have to preprocess your FM signal!


Best,
Marcus

On 01.09.23 17:09, Michael Berman wrote:
Does anybody know if there is a way to recover a carrier of an FM signal to use for an 
Angle of Arrival calculation?  I am using GNURadio and gr-music and I am trying to use the 
NOAA Weather Radio signals.


Thank you very much,

Michael Berman

Re: How send message with when message is less than sample rate?

[Marcus Müller]

Hi sp,

like many of your questions here and on usrp-users, this only makes sense once we ask for 
context in a chain of emails.
I think we could do with slightly better rounded-off questions that give a reader that 
doesn't know what you're doing insight without having to ask back.


Best,
Marcus

Re: Transmit / Receive Text On VHF/UHF Frequency w/ HackRF One

[Marcus Müller]

Hi Adam,

The magic of GNU Radio is that wherever you put something like "Network sink/source + 
channel model", you could also put a hardware interface block.


So, the "Packet Communications" Tutorial from https://tutorials.gnuradio.org 
does apply :)

I'd recommend doing that tutorial; soon as it works through ZMQ network sockets, you can 
read the "Using GNU Radio with SDRs" tutorial (It's by far not as long!).


So here comes the part where I have a strong recommendations:

You want to use GNU Radio 3.8, but that's really in maintenance mode, and for people who 
want to interface HackRFs, is a pretty bad choice. If you get GNU Radio 3.10, you're 
automatically getting the gr-soapysdr interface, which means that, as soon as you install 
soapy-hackrf, you can talk to your hackrf – no external GNU Radio blocks needed. Also, 
you'll find that in the parts of the "Packet Communications" tutorial that differ between 
GNU Radio 3.8 and 3.9+, the 3.9+ parts are a bit shorter and "less confusing"; that is 
result of the GNU Radio developers trying to make packet communications less of a hassle. 
You really don't want to do this on 3.8.


It's not hard to install a newer version of GNU Radio; typically, all you need to do is 
either use a somewhat modern version of your Linux distro, or use the Radioconda installer 
(does also exist for Linux, not only Windows and MacOS).


Best,
Marcus

On 25.08.23 00:59, Arndt, Adam (LCDR) wrote:


Good Afternoon,

I am conducting research with the Naval Postgraduate School and we’re experimenting with 
sending data from text files over VHF/UHF frequencies using GNU Radio with a HackRF One 
attached.  I have been searching through the internet and see many of the ways it used 
to be done have since been deprecated.  Furthermore, many of the example files provided 
within GNU use TCP streams or are self contained examples using artificial sources.


Is there anyone that can help walk through how to accomplish this using GNU 
Radio 3.8?

Thanks in advance.

V/r,

LCDR Adam Arndt

Sent from Mail  for Windows

Re: cmd time errors occurred - solution in gnuradio?

[Marcus Müller]

Hi Theo,

yep, that's a problem within the scope of UHD – GNU Radio doesn't see any of the low-level 
communications, and these are the only thing that has changed. (if you haven't, say high 
on the usrp-users mailing list[1], we usually don't bite.)


So, unless you're really setting time stamps in your own application too closely to the 
USRP's notion of "now", there's nothing GNU Radio can do about this.


Best,
Marcus

[1] Simply send a message from your email address to usrp-users-j...@lists.ettus.com to 
join the mailing list; click on the confirmation link, and then you can write to 
usrp-us...@lists.ettus.com


On 22.08.23 15:38, theow...@web.de wrote:

Dear all,
I am afraid my issue is actually a UHD issue, but I think it must be solved in gnuradio, 
and therefore I might also ask gnuradios great community.
I am working on a measurement setup with the USRP X410. Since we wanted a higher 
sampling rate, we sitched from ethernet to 10gbit/s thunderbold.
With ethernet and a sampling rate of 2MHz, the flowgraph worked perfectly fine. Now, 
with 10gibt/s, also with 2MHz sampling rate (for the beginning), the setup does not work 
well anymore.

GNUradio prints now
"LLL" and
"usrp_sink :error: In the last 802 ms, 181 cmd time errors occurred."
I did all what the suggestions I found here: 
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

E.g., MTU rates in the network configuration to 9000 etc.
Because I did more or less all, that is possible in the PC configurations, I wonder if 
there is something I can do in gnuradio to fix this...

Thank you very much for every little help.
Best,
Theo

Re: Python tutorials (was: Re: Discuss-gnuradio Digest, Vol 250, Issue 16)

[Marcus Müller]

Hi Tom

On 21.08.23 14:29, tom sutherland wrote:

To answer your question* below, here is an example that may clarify what I am 
asking.
Example:
I have a 'vector source' of 63 floating point numbers, [1.2,  4.5, 2.3, 8.1 ...], that 
is outputting one floating point point number. It sends out one number at each sample 
time (Can I assume one sample at a time i.e. it only sends 1 32bit number at a time).


No, you can't make such assumptions.

To say that explicitly: Your block does not control with how many input items it is 
called. It might be called with a block of 1 input items, and then next time it's 
being called with 3.


Your work function must make sure that a) it doesn't consume input that is not there, and 
b) it doesn't produce more input than there is output space.


If I create a python block that takes the input value. I want a "work" function that can 
calculate the average of the current input value and 5 previous inputs. I have these 
questions:



Questions:
1) How do I save the previous values in "memory" that are used to generate the 
new average?
you don't! You just consume at most as many items so that there's 4 items left in your 
input. Then, these four items will be the first four items when your work is being called 
again.

    A) Does/can the python module store old previous values? If so how?
That's a basic Python question: using a class member variable. That's the same as the 
tutorial shows with "self.additionFlag"! You don't need that here, though, due to the 
underlying "only the input that is consumed disappears" logic of GNU Radio.
    B) How much delay does the the python code cause? i.e If I have the original data 
and "delay" data and plot them on a time sync are the aligned?
That doesn't make sense to ask; the computational delay doesn't matter. Your block, and 
any other block, doesn't care about the "time on the clock on the wall". It sees a 
sequence of samples. If a block has two inputs, and always consumes the same number of 
items from both inputs (like, for example, the "Add" block does), then it doesn't matter 
whether one input has more time delay: it will wait until there's input items on both inputs.
    C) Can the output of the python block ever send data back to an another block that 
was in the signal path before it, i.e. feedback


Not through streams. Only by messages, which, unlike I explain above for the synchronous 
consumption of values on input ports, are **not** sample-synchronous and will arrive at 
any specific item number. You probably don't want to deal with that.


Best,
Marcus

Re: Python tutorials

[Marcus Müller]

Hi Shakti,

On 21.08.23 03:16, SHAKTHIVEL S 2021 Batch,PES University wrote:

Hi Marcus,
I got small doubt after looking at your reply, the /*self.consume*/ takes /*(inputport , 
len(in0)) */as arguments but the input length depends on the number of output_items / 
input_items as /*in0 = input_items[0][:len(output_items[0])] */which inturn depends on 
the noutput_items / ninput_items variable , right?


No; you can consume as much as you have available input, or less, and you can produce as 
much as you have available output space, or less.


the sync block (see the "Block Types" document) is a special case, where "producing N 
items" also means "consuming N items", and the work function is always presented with the 
same amount of input and output space.


My doubt is ,aren't the below functions in */top_block/*./*py*/ define the default 
length of input vectors / value of ninput_items?


No, not at all.

Best regards,
Marcus

Python tutorials (was: Re: Discuss-gnuradio Digest, Vol 250, Issue 16)

[Marcus Müller]

Hi Shakti, hi Tom,

first off: a friendly reminder to **not** forget to change the subject line when replying 
to digest emails, see the sentence you literally replied to:



When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Anyways, what Shakti recommends makes not too much sense, sorry! All the files are 
"exported from wiki", in other words, the original version is in the very wiki with the 
tutorials in it. That's why it says that in the file name :)


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

To address Tom's questions:

> If I use the "input" to the block, how many samples are processed each time the Python 
code is called?


As many as you process. That's up to your code! In a general block, you need to call 
`self.consume` (or `consume_each`) yourself to tell the runtime how much of the available 
input you consumed.


You need to return the number of samples you have produced at the end of your (`general_`) 
work method.


In the sync block (and fixed-rate decimator and interpolators), what you return inherently 
defines how much you consumed, so don't call `consume` or `consume_each` in that case.


> Does it pass a byte, float, complex, vector, etc... on at a time?

No, but that's really clearly illustrated in the Python tutorial! See 
https://wiki.gnuradio.org/index.php?title=Creating_Your_First_Block#Editing_Work_Function 
: As you can see, `input_items` is a vector of vectors, each row containing the input 
items from one of the input ports your block has, and then each vector there is many items.


> Does it work on each sample or can you send it an array? Is the Python in/out 
synchronized with the data stream?


It's not clear what you mean here. "the data stream" is what you're processing 
here.

Cheers,

Marcus


On 20.08.23 05:03, SHAKTHIVEL S 2021 Batch,PES University wrote:

Hi,
You may check in the docs folder in the GitHub page under usage-manual, Handling 
flowgraphs.txt and types of blocks.txt files until someone who is expert answer your 
questions.

Hope that helps.
Thanks..
Shakti

On Sun, Aug 20, 2023, 04:54 tom sutherland  wrote:

I've gone through the Python tutorial but have some questions. If I use the 
"input"
to the block, how many samples are processed each time the Python code is 
called?
Does it pass a byte, float, complex, vector, etc... on at a time? Does it 
work on
each sample or can you send it an array? Is the Python in/out synchronized 
with the
data stream?
Thanks...Tom

On Friday, August 18, 2023 at 11:03:02 AM CDT, 
discuss-gnuradio-requ...@gnu.org
 wrote:


Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org

You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

  1. [GRCon'23] Keynotes, Workshops, Sponsors: It's all coming
      together! (Marcus Müller)
  2. Re: Using a signal as a parameter in a block? (Marcus Müller)
  3. Re: Discuss-gnuradio Digest, Vol 250, Issue 15 (Sowji Srinithi)
  4. LookupError: KeyError: No devices found (was: Re:
      Discuss-gnuradio Digest, Vol 250, Issue 15) (Marcus Müller)


--

Message: 1
Date: Thu, 17 Aug 2023 18:04:52 +0200
From: Marcus Müller 
To: Gnuradio Mailing List 
Cc: srsran-us...@lists.srsran.com
Subject: [GRCon'23] Keynotes, Workshops, Sponsors: It's all coming
    together!
Message-ID: <3cc7fed1-4a23-d428-a16c-4670e01d3...@gnuradio.org>
Content-Type: text/plain; charset=UTF-8; format=flowed

Dear Community,

GNU Radio Conference 2023 is coming closer! (It takes place starting
Sep. 5 in Tempe, Arizona, USA. Tickets happen to be $100 cheaper until
2023-08-18 [0].)

== Keynotes ==

The Conference Organizers are quite happy to see an excellent list of
Keynote speakers[1] come together for the four conference days:

With Lindy Elkins-Tanton, we have been able to secure the NASA Principal
Investigator for the Psyche Mission, and an all-around impressive
scientist and research leader on the formation of rocky planets. If
being elected into the National Academy of Sciences is not enough
credit: there's an asteroid named after her.
On the technical and historical side, I'm personally looking forward to
seeing Eric Blossom again: he, as the first head of architecture, has
been formative to the things that mak

LookupError: KeyError: No devices found (was: Re: Discuss-gnuradio Digest, Vol 250, Issue 15)

[Marcus Müller]

Hi Sowji,

according to the text you've replied to:


When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


I changed the subject line to actually describe the contents of your email. Please get in 
the habit of doing that :)


Anyways, as you notice, this is an error related to UHD not finding any USRP devices. 
Since we don't know which device you have, we can't help you with that. But to expedite a 
solution: Guides to this are found in dozens of corners on the internet, for example
https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for 



Best,

Marcus


On 18.08.23 10:11, Sowji Srinithi wrote:
Qt GUI: Could not restore geometry: restoreGeometry(self, geometry: Union[QByteArray, 
bytes, bytearray]): argument 1 has unexpected type 'NoneType' [INFO] [UHD] linux; GNU 
C++ version 12.3.0; Boost_107400; UHD_4.4.0.0+ds1-4 Traceback (most recent call last): 
File "/home/sowjanya/Downloads/fm_example.py", line 238, in  main() File 
"/home/sowjanya/Downloads/fm_example.py", line 216, in main tb = top_block_cls() 
^^^ File "/home/sowjanya/Downloads/fm_example.py", line 84, in __init__ 
self.uhd_usrp_source_0 = uhd.usrp_source(  RuntimeError: LookupError: 
KeyError: No devices found for -> Empty Device Address how to fix this error


How to fix the above error

On Thu, 17 Aug 2023 at 21:37,  wrote:

Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org

You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Using a signal as a parameter in a block? (tom sutherland)


--

Message: 1
Date: Thu, 17 Aug 2023 12:59:58 + (UTC)
From: tom sutherland 
To: "discuss-gnuradio@gnu.org" 
Subject: Using a signal as a parameter in a block?
Message-ID: <661605185.819399.1692277198...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

I want to use the output value of a signal generator as the delay value of 
a delay
block. Is there a way to pass the output of a signal generator(saw tooth) 
to the
delay block? I have attached an initial grc file and a picture of what I 
want to do.
Any help would be appreciated.Thanks...TomPS Do you know if I need to sign 
up for
any workshops, etc.. at the GNURadio Conference next month or do I just 
show up and
take a seat? I've already registered.




-- next part --
An HTML attachment was scrubbed...
URL:


-- next part --
A non-text attachment was scrubbed...
Name: 1692277050668blob.jpg
Type: image/png
Size: 41672 bytes
Desc: not available
URL:


-- next part --
A non-text attachment was scrubbed...
Name: rampAsDelayInput.grc
Type: application/octet-stream
Size: 4072 bytes
Desc: not available
URL:


-- next part --
A non-text attachment was scrubbed...
Name: RampAsDelayInput.png
Type: image/png
Size: 30385 bytes
Desc: not available
URL:



--

Subject: Digest Footer

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


--

End of Discuss-gnuradio Digest, Vol 250, Issue 15
*

Re: Using a signal as a parameter in a block?

[Marcus Müller]

Hi Tom,

You are assuming the "delay" input of the Delay block was sample-synchronous – 
it's not!
Messages are asynchronous to samples by design. Repeating the same message hence doesn't 
do what you want:
What you're trying to do, keep the delay constant for 1023 samples, then change it, keep 
it constant… but that would require that the delay block "waits" for a new message for 
every sample it processes. It doesn't (and it can't).


I think in your situation, learning how to write a Python (or C++, if that's easier for 
you) block to do in one place what you want to happen here would be the only solution – 
and not too hard.


Best regards,
Marcus

On 17.08.23 14:59, tom sutherland wrote:
I want to use the output value of a signal generator as the delay value of a delay block. 
Is there a way to pass the output of a signal generator(saw tooth) to the delay block? I 
have attached an initial grc file and a picture of what I want to do. Any help would be 
appreciated.

Thanks...Tom
PS Do you know if I need to sign up for any workshops, etc.. at the GNURadio Conference 
next month or do I just show up and take a seat? I've already registered.


Inline image

[GRCon'23] Keynotes, Workshops, Sponsors: It's all coming together!

[Marcus Müller]

Dear Community,

GNU Radio Conference 2023 is coming closer! (It takes place starting 
Sep. 5 in Tempe, Arizona, USA. Tickets happen to be $100 cheaper until 
2023-08-18 [0].)


== Keynotes ==

The Conference Organizers are quite happy to see an excellent list of 
Keynote speakers[1] come together for the four conference days:


With Lindy Elkins-Tanton, we have been able to secure the NASA Principal 
Investigator for the Psyche Mission, and an all-around impressive 
scientist and research leader on the formation of rocky planets. If 
being elected into the National Academy of Sciences is not enough 
credit: there's an asteroid named after her.
On the technical and historical side, I'm personally looking forward to 
seeing Eric Blossom again: he, as the first head of architecture, has 
been formative to the things that make GNU Radio what it is. Currently, 
he's working on high-speed satellite radios.
Don't forget that SDR involves, famously, not only software, but also 
radio. Constantine Balanis' contributions to the field of radio 
technology are not limited to his authorship of the standard textbook on 
antennas – he's been at the forefront of EM simulation and RF channel 
theory and thus set many cornerstones for wireless communications and 
sensing applications everywhere.
Of course, if we invite GNU Radio's history, we should also be inviting 
someone working on the future of GNU Radio: That'd be Ralph Steinhagen, 
head developer for systems integration at FAIR, one of the largest and 
technically most advanced particle accelerators, who, together with his 
team, is putting in all the work to bring a shared vision of GNU Radio 
4.0 to life.


== Workshops ==

But the value of a conference is not found exclusively in the 
higher-profile talks, but also in the ways that it enables people to 
actually have a closer look at things, together. Workshops [2] have been 
a staple of GRCon's popularity for years, and this year is no exception 
with a total count of 10 workshops, covering topics from basic DSP, over 
GNU Radio use, transceiver design, embedded Linux-based SDR development, 
and FPGA usage on SDR devices, to FOSS 5G network setup with srsRAN.


== Sponsors ==

As you might guess, organizing all this takes effort – and executing 
takes a lot of funds. Hence, we're very glad we've found sponsors [3] 
for this year's GRCon. Next to a few industry-standard names, it's 
especially nice to see breakthrough startups and research organizations 
take up the chance to present themselves to the GNU Radio audience. You 
can, when buying tickets [0], directly choose a Patron Ticket, which 
gives you a cheap opportunity to place your logo on the GRCon website; 
if that's what you want to do, or if you care for other sponsorship 
packages, don't hesitate to reach out to spon...@gnuradio.org.


So, for now: I'm looking forward to seeing you there!

-- Marcus

[0] https://tickets.gnuradio.org/
[1] https://events.gnuradio.org/event/21/page/111-keynote-speakers
[2] 
https://events.gnuradio.org/event/21/contributions/?config=9e736ba3-8af2-4446-b8ba-bf634ad0ff33

[3] https://events.gnuradio.org/event/21/page/94-our-sponsors

Re: File Sink Block

[Marcus Müller]

I think you might have misunderstood what I intended with the "Head" block. The Head's 
block job is just shutting down everything finally after all the measurements have been 
done. Wouldn't that work?


Best,

Marcus

On 14.08.23 08:47, Henry Powell wrote:

Hello again, Marcus.

I can collect the data using Vector Sink, but it always collects the data because there 
are no open and close commands. I can never stop Vector Sink.


On the other hand, I tried considering the scheme you suggested. The problem is that 
even if I reset the head block with the "tb.blocks_head_0.reset()" command, it doesn't 
work again. The receiver turns itself off and I cannot have the process repeated.


I am sharing all the links with you below.


self.connect((self.analog_sig_source_x_0, 0), (self.uhd_usrp_sink_0, 0))


self.connect((self.uhd_usrp_source_0, 0), (self.blocks_stream_to_vector_0_0_0, 
0))

self.connect((self.blocks_stream_to_vector_0_0_0, 0), (self.fft_vxx_0, 0))

self.connect((self.fft_vxx_0, 0), (self.blocks_head_0, 0))

self.connect((self.blocks_head_0, 0), (self.blocks_vector_to_stream_0, 0))

self.connect((self.blocks_vector_to_stream_0, 0), 
(self.blocks_multiply_const_xx_0, 0))

self.connect((self.blocks_multiply_const_xx_0, 0), (self.blocks_skiphead_0, 0))

self.connect((self.blocks_skiphead_0, 0), (self.blocks_keep_one_in_n_0, 0))

self.connect((self.blocks_keep_one_in_n_0, 0), 
(self.blocks_complex_to_mag_squared_0, 0))

self.connect((self.blocks_complex_to_mag_squared_0, 0), 
(self.blocks_nlog10_ff_0, 0))

self.connect((self.blocks_nlog10_ff_0, 0), (self.blocks_max_xx_0, 0))

self.connect((self.blocks_max_xx_0, 0), (self.blocks_file_sink_0, 0))

# self.connect((self.blocks_nlog10_ff_0, 0), (self.blocks_vector_sink_x_0, 0))


What do I need to perform the transaction without the head block receiver ever shutting 
down?


On the other hand, can I keep Vector Sink on or off whenever I want with the connect and 
disconnect commands?



Marcus Müller , 9 Ağu 2023 Çar, 12:40 tarihinde şunu 
yazdı:

Hey Henry,
I'm forwarding this to the mailing list, so that others can have a look at 
it as well!
Let me quickly address a few things:

On 08.08.23 21:32, Henry Powell wrote:
> The flow graph starts. I collect data and save it to a file with 
file_sink. I read
the
> file and get the maximum value from the file (differently, I can do this 
with keep
1 in n,
> but I would be happy if we proceed through the current situation), then I 
am
saving the
> maximum value in a list from the data I have saved in the file. I reset 
the file
with the
> file_sink open and close commands.

Interesting! How do you know when to open / close? I ask because this 
sounds a bit
difficult, as, depending on the blocks with which you capture and process 
your data,
there
might still be samples "in flight" after your collection finishes.

> I repeat this maybe 2000 times, varying from
> measurement to measurement. After recording all the maximum values in a 
list, the
flow
> graph terminates itself.
>
> Writing data to a file and reading from there makes me lose speed. I am 
looking
for an
> alternative solution to it.

Ah, what about this concept:

                                    ┌───┐
   ┌┐    ┌──┐   │Make Chunks│ ┌─┐    ┌──┐   
 ┌─┐
   │            │    │          │   │of constant│    │Find max-│    │ Head 
│    │   
     │
   │Data Capture│───►│Processing│──►│ "single-  │───►│imum per │───►│     
│───►│File Sink│
   │            │    │          │   │experiment"│    │  chunk │    │N=2000│ 
   │   
     │
   └┘    └──┘   │   size    │ └─┘    └──┘   
 └─┘
                                    └───┘


Instead of "taking the data out of GNU Radio" in an asynchronous manner, 
you could look
for the maximum within the framework of GNU Radio itself. That solves all 
the file
handling overhead.

You can also still save all your experimental data to a file for later 
analysis
(just add
*another* File Sink, after "Processing" in parallel with "Make Chunks…").

> If you're saying that I can do it with a vector sink block, I'm trying it 
right
now. I
> will let you know the results tomorrow.

Well, the Vector Sink would be easier than the File Sink, but as sketched 
above I
think a
different solution might be preferable.

> Thank you for your reply. Have a nice day.
You have good days, as well!

Marcus

> Marcus Müller mailto:mmuel...@gnuradio.org>>, 8 
Ağu 2023 Sal,
> 11:55 tarihinde şunu yazdı:
>
>     Hi Henry,
>
>     that sounds like the description of the Vector Sink block!
&g

Re: QT GUI Time Raster Sink - missing MSG port

[Marcus Müller]

Hi Vittorio,

what you're doing is sending a feature request – and that's more than fine! It's actually 
*welcome*! Because we need to keep track of these, prioritize and implement things at some 
point, we actually connect these in the issue tracker. If you go to [1], log in, click on 
"New issue", and then select "Feature Request", you do the hardest part of that thing – 
and your email's text is good enough, I'd say, so just copy and paste it into there :)


Thank you!
Marcus

[1] https://github.com/gnuradio/gnuradio/issues

On 10.08.23 20:50, vitt...@pm.me wrote:
Hi everybody,,I'm I am working on a larger project, a "remote" transceiver for satellite 
traffic, trying to limit the need for bandwidth via Internet since the remote location 
does not have enough bandwidth available.
To further reduce bandwidth consumption and to have a spectral representation I do not 
send the IQ stream to the control terminal, but only the vectors obtained from the FFT; so 
I went from about 20Mb/s to 500kb/s, I would say more than acceptable!
In the control terminal, however, I have the need to "return" the "point and click" 
frequency indication to the remote side. This works correctly on the QT GUI Vector Sink ( 
spectral representation ), which has an MSG port but, from an operational point of view, 
it would be better to be able to have the same functionality via the QT GUI Time Raster 
Sink ( waterfall representation ) block, which does not have an MSG port available, even 
if the Xval value it's there.


I realize that this is not a "real problem" but just a missing feature that I hope can be 
implemented in the future ( I'm not so skilled to do it myself ;-) )

In the meantime, I continue to have fun with this project!

Thank you for your attention, maybe someone can suggest me some other solution.
  de Vittorio, I3VFJ

[attached pdf flowgraph  -- Gnuradio 3.10.7.0 -- Ubuntu 20.04.06]

fingerprint: |fb5f492a54e016c632c933d3ee4b7e38203c79ca|

Inviato con l'email sicura Proton Mail .

Re: Change variable within the python module

[Marcus Müller]

Hi Bob,

the osmosdr source and sink blocks definitely have messaghe input ports, so you *should* 
use them. The fact that you *want* to "just change a variable" really doesn't help – 
that's not a recommendable architecture for your program.


Best regards,
Marcus

On 10.08.23 16:39, Bob Wong wrote:

Hello!

I now want to build a timer to calculate the transmission time of Osmocom Sink 
and store it in two variables(minutes and seconds), how can I do that? I search 
the mailing list and find that it is advised to use the message but in this 
case, I cannot use a message since I just want to change the value of a 
variable. And next, I need to send the time value to another python module to 
control whether to transmit it or not at a specific time with a multiply const 
with variable value set 1 or 0. Again, I cannot use message since the module 
doesn't have a port for that. How can I achieve both of them? I search the 
Internet but still couldn't figure out how to achieve that goal. And in the 
attachment is the grc file.

Best Regards,
Bob

Re: File Sink Block

[Marcus Müller]

Hey Henry,
I'm forwarding this to the mailing list, so that others can have a look at it 
as well!
Let me quickly address a few things:

On 08.08.23 21:32, Henry Powell wrote:
The flow graph starts. I collect data and save it to a file with file_sink. I read the 
file and get the maximum value from the file (differently, I can do this with keep 1 in n, 
but I would be happy if we proceed through the current situation), then I am saving the 
maximum value in a list from the data I have saved in the file. I reset the file with the 
file_sink open and close commands. 


Interesting! How do you know when to open / close? I ask because this sounds a bit 
difficult, as, depending on the blocks with which you capture and process your data, there 
might still be samples "in flight" after your collection finishes.


I repeat this maybe 2000 times, varying from 
measurement to measurement. After recording all the maximum values in a list, the flow 
graph terminates itself.


Writing data to a file and reading from there makes me lose speed. I am looking for an 
alternative solution to it.


Ah, what about this concept:

   ┌───┐
  ┌┐┌──┐   │Make Chunks│┌─┐┌──┐
┌─┐
  │││  │   │of constant││Find max-││ Head │
│ │
  │Data Capture│───►│Processing│──►│ "single-  │───►│imum per │───►│  
│───►│File Sink│
  │││  │   │experiment"││  chunk  ││N=2000│
│ │
  └┘└──┘   │   size│└─┘└──┘
└─┘
   └───┘


Instead of "taking the data out of GNU Radio" in an asynchronous manner, you could look 
for the maximum within the framework of GNU Radio itself. That solves all the file 
handling overhead.


You can also still save all your experimental data to a file for later analysis (just add 
*another* File Sink, after "Processing" in parallel with "Make Chunks…").


If you're saying that I can do it with a vector sink block, I'm trying it right now. I 
will let you know the results tomorrow.


Well, the Vector Sink would be easier than the File Sink, but as sketched above I think a 
different solution might be preferable.



Thank you for your reply. Have a nice day.

You have good days, as well!

Marcus

Marcus Müller mailto:mmuel...@gnuradio.org>>, 8 Ağu 2023 Sal, 
11:55 tarihinde şunu yazdı:


Hi Henry,

that sounds like the description of the Vector Sink block!

But in all honesty, maybe you want to take a different approach altogether; 
really
depends
on when during the life cycle of a flow graph you need that data. Could you 
maybe
describe
how often and when you want to get data from your GNU Radio flowgraph?

Best regards,
Marcus

On 08.08.23 07:26, Henry Powell wrote:
 > Hello, at the end of my grc I use file sink and then, I read the data 
from the file. I
 > repeat this process so many times. My problem is that writing to files 
and reading
from
 > them takes too much time, approximately 120ms. I know this does not seem 
too much but
 > for my application it's too much. So, I want to append data to a list 
and get from
there.
 >
 > I tried writing an embedded python block via this link:
 > https://wiki.gnuradio.org/index.php/Embedded_Python_Block
<https://wiki.gnuradio.org/index.php/Embedded_Python_Block> but i failed.
 >  Is there any example embedded python block you wrote about before? Or a 
different
solution?
 >
 > If you can help me, I would really appreciate it.

Re: Fw: Help Feedback with GNURadio Companion

[Marcus Müller]

Hi Tom,

GNU Radio, the way it's currently written, does not allow you to build a loop with sample 
streams – that's why you can't build a proper PLL from components in GRC :)


But: there's ready-made PLLs for some use cases, namely for automatically locking onto a 
carrier (and mixing down with it) [1], for detecting the frequency of a carrier [2] and 
for detecting a carrier and generating a "clean" version of it [3].


Now, these blocks do the PLL "block-internally", so if these PLLs don't fulfill your phase 
locking purposes, then you'd need to implement that yourself (for example, in a Python 
block, or in C++).


So, maybe we should talk about what you need your PLL for? It's quite possible we already 
have something like that ready-made or easy to modify.


Best,
Marcus

[1] https://wiki.gnuradio.org/index.php?title=PLL_Carrier_Tracking
[2] https://wiki.gnuradio.org/index.php?title=PLL_Frequency_Detector
[3] https://wiki.gnuradio.org/index.php?title=PLL_Carrier_Regeneration

On 08.08.23 13:12, tom sutherland wrote:
Is there a tutorial, example or guide to creating feedback loop (PLL, Costas, etc...) 
using Companion/python?

Thanks...Tom

Re: File Sink Block

[Marcus Müller]

Hi Henry,

that sounds like the description of the Vector Sink block!

But in all honesty, maybe you want to take a different approach altogether; really depends 
on when during the life cycle of a flow graph you need that data. Could you maybe describe 
how often and when you want to get data from your GNU Radio flowgraph?


Best regards,
Marcus

On 08.08.23 07:26, Henry Powell wrote:
Hello, at the end of my grc I use file sink and then, I read the data from the file. I 
repeat this process so many times. My problem is that writing to files and reading from 
them takes too much time, approximately 120ms. I know this does not seem too much but 
for my application it's too much. So, I want to append data to a list and get from there.


I tried writing an embedded python block via this link: 
https://wiki.gnuradio.org/index.php/Embedded_Python_Block but i failed.

 Is there any example embedded python block you wrote about before? Or a 
different solution?

If you can help me, I would really appreciate it.

Re: Rolling QT GUI Time Sink?

[Marcus Müller]

Pair that "partially-repeating vector source" with a new-style Throttle 
block to keep the vectors trickle in  more uniformly, by the way


On 8/2/23 04:53, Marcus D. Leech wrote:

On 01/08/2023 22:41, Derek Kozel wrote:
There used to be the WX Strip chart which internally handled 
displaying slow signals and scrolling them. I keep hoping to 
implement it, but haven't yet made the time.

I wrote that WX feature "back in the day".

One can achieve the same effect by using the vector sink and having a 
Python block that produces the correct vector
  on the appropriate schedule.    Not as slick as have a "first class" 
implementation,  but I've been using that to produce

  strip-charts for quite a while.




https://github.com/gnuradio/gnuradio/issues/1629

On 7/19/2023 7:59 PM, Marcus Müller wrote:

Hi Fabian,

I'm afraid we currently don't have that, no :(

Best I can offer is the "new" throttle block, which can, at lower 
rates, make "blocks" of items appear in pieces smaller than a full 
maximum buffer size (i.e., that solves the problem that if 10s of 
samples fit in a buffer, GNU Radio will possibly only process a 
block of items every 10s, which makes e.g. the Qt time sink 
"stutter" very badly.)


Best,
Marcus!

On 19.07.23 18:09, Fabian Schwartau wrote:

Hi,
is there a way in GRC to get a rolling time sink?
That means no trigger, the signal just scrolls from right to left.

Best,
Fabian

Re: Incompatible function arguments

[Marcus Müller]

Hi Jim,

that reads as if `Receive.blocks.head` is not an instance of Head block, but the *type* 
(think as in "blueprint")!


Could you share your hier block's Python source code with us?

Best regards,
Marcus

On 31.07.23 15:40, Elmore's wrote:
I have created a flowgraph which has a hierarchical block called Receive. In the Receive 
block is a Head block.
The primary block has an OOT containing a callback in which I wish to call the reset() 
function in the Head block as follows:

    Receive.blocks.head.reset()
This call results in the following error:
    TypeError: reset(): incompatible function arguments. The following argument 
types are supported:

    1. (self: gnuradio.blocks_python.head) –> None
I’m confused since reset takes no arguments and I don’t understand the meaning of the 
argument types shown.

Jim

 
	Virus-free.www.avg.com 
 



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

Re: Time difference between between different GUI Instruments.

[Marcus Müller]

Hi Igor,

well you set the sampling rate in your QT GUI Sink to twice the value of what you use in 
your QT GUI Time Sink.


So, this is correct!

Best regards,
Marcus

On 31.07.23 14:40, Igor wrote:

Hi community,

I noticed the double time difference between two different time  related QT GUI 
Instruments:
Inline image

My graph is:
Inline image

Is it a bug or feature or my mistake ;)?

Regards
Igor

Re: Experience on how to publish data on Zenodo

[Marcus Müller]

Can you tell us what kind of documents you stored in the elasticsearch database? I'm not 
familiar with using elasticsearch myself, but as far as my understanding reaches, it's a 
full-text index for JSON-style hierarchical data. So I guess it does both fulltext search 
and structured retrieval.


Now, if your database is really just JSON-style documents, I'd keep that as exchange 
format: A directory full of JSON files. Throw it all in a compressed archive¹, or if that 
still is of significant size, first convert the JSON to BJSON prior to compression².


If things just *happen* to be in JSON, but could actually reasonably be considered tabular 
data, things look differently.


In any case, some datasets I saw on zenodo also include the (typically, R or python) 
scripts to convert the data from the archive format to the deployment format (in your 
case, the elasticsearch-dump link and maybe a script to run it and its inverse?). I like 
that, because data without a clear guidance on how to read it correctly can, at worst, 
become useless.


Cheers,
Marcus


¹ a .tar and run `zstd -15` on that (GNU tar doesn't let you set zstd compression options 
through command line options), or run `mksquashfs directory/ archive.squash -comp zst`, if 
you think the consumers will have Linux, which can directly mount that, or a modern 7zip 
installation.


² If that is any better – zstd isn't bad about grammatically strict syntax, and IIRC 
LZMA-derivatives are actually pretty good about it, so try with lzlib or fastlzma2, maybe



On 27.07.23 09:40, Johannes Demel wrote:

Hi everyone,

I'd like to publish some of the data I recorded with my GNU Radio demo on zenodo.org. It 
is not IQ data but other data that we stored in an elasticsearch database.
Maybe some of you know about a suitable data format or a source that discusses best 
practices. Right now, I export everything via

https://github.com/elasticsearch-dump/elasticsearch-dump
But they use their custom format and change it over time. I doubt it is suitable for 
archiving purposes.


I'd appreciate hints on how to do that properly.

Cheers
Johannes

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Marcus Müller]

That is correct. SoapyUHD contains UHDSoapy, a UHD plugin, which "hooks" Soapy devices 
into UHD.


On 25.07.23 17:20, Sylvain Munaut wrote:

If that's the case, then Mint are now packaging a version of UHD that is NOT
from NI/Ettus.


Doesn't UHD have like a plugin system that can dynamically load .so
files ? The UHD_MODULE_PATH thing ?

So it could be a perfectly legit UHD just with some soapy plugin
loaded dynamically.

Cheers,

 Sylvain

Re: GPS module USRP x410

[Marcus Müller]

Hi Theo,

for some USRPs, UHD used to export GPS strings as *sensors*:

https://files.ettus.com/manual/page_usrp_x4xx.html#x4xx_usage_sensors

You can make calls on the UHD USRP Source block to query these sensors:

https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html#a249fddbb3710046963c5a13fa5f47c2f

both from C++ and Python.

There's currently no graphical way to sensibly do such a thing, but with the "Python 
Snippet" block, it's not hard.


I must admit I haven't tried that, but if I remember correctly, the X4xx architecture is 
such that the MPM daemon running on the X400 itself serves these sensor requests, and 
sends the data it requests from the gpsd running on the X4xx in response to these over the 
network to your local machine.


> In the "UHD: USRP Source" block there is no possibility to do that ( I guess, because 
the x410 is the only one with GPS module?) .


Nah, it's just that requesting non-sample data from a device really fits badly into GNU 
Radio paradigms and hence, we don't have a good way of exposing it. Most (all that you can 
currently buy) USRP families can be or are equipped with GPS receivers!



Best,
Marcus

On 25.07.23 14:37, theow...@web.de wrote:

Hello everybody,
I am working with a USRP x410, which includes a Jackson Labs LTE-Lite GPS 
module.
I have a GPS antenna at the antenna port.
My goal is, that gnuradio prints the gps location. Sadly, I only found little 
information on how to use the GPS antenna port of the USRP x410.
In the "UHD: USRP Source" block there is no possibility to do that ( I guess, because 
the x410 is the only one with GPS module?) .
I am relatively unexperienced with gnuradio, and I would appreciate anything that could 
help. Even if someone knows how to use the GPS module from the terminal (so without 
gnuradio) would already be a great help.

Thank you very much,
Theo

Re: how can build gr-osmocomsdr in a linux that gnuradio is built and installed in a custom dir?

[Marcus Müller]

Hi sp,

just as you did for GNU Radio:

On 25.07.23 10:10, sp wrote:

-- Using install prefix: /usr/local


You need to define -DCMAKE_INSTALL_PREFIX when running cmake on the gr-osmosdr sources as 
well.


Best,
Marcus

Re: Gnuradio Update on ubuntu 20.04 lts

[Marcus Müller]

Hey David,

thanks for using GNU Radio, getting in touch, trying out our crazy software :) and the 
fixes that this necessitates :)


Cheers,
 Marcus

On 19.07.23 21:29, David Martini wrote:

Hi Marcus,

I made point 2.
Icon now is on the desktop and running ok.
Thank you for help and for all great job on gnuradio.

Best Regards

David


Il Mer 19 Lug 2023, 18:08 David Martini <mailto:martini.david...@gmail.com>> ha scritto:


Hi Marcus

Thanks a lot!

Best Regards

David

Il Mer 19 Lug 2023, 17:41 Marcus Müller mailto:mmuel...@gnuradio.org>> ha scritto:

Hi David,

so, reporting back: fresh installation on a freshly set up Ubuntu 20.04 
does
indeed not
install /usr/share/applications/gnuradio-grc.desktop

Possible "hotfix" solutions:

1. run full "gnuradio-companion" from wherever you start programs; that 
should
work without
2. put the attached file into your home (~) in the dirctory
~/.local/share/applications/ ,
run (once)
update-desktop-database ~/.local/share/applications

Best regards,
Marcus

    On 19.07.23 17:35, Marcus Müller wrote:
 > Hi David,
 >
 > are you *sure* it's 3.10.5? It really should be 3.10.7.0 now, that's 
the latest
update we
 > made, and it literally came out this week.
 >
 > I'm currently running the installation
 >
 > sudo add-apt-repository ppa:gnuradio/gnuradio-releases
 > sudo apt-get update
 > sudo apt-get install gnuradio python3-packaging
 >
 > (that's what you did, right? If you were on the native Ubuntu 
packaging, you'd
be getting
 > GNU Radio 3.8 on Ubuntu 20.04)
 >
 > I'll report back after.
 >
 > Best regards,
 > Marcus
 >
 >
 > On 19.07.23 14:32, Marcus Müller wrote:
 >> Hi David!
 >>
 >> Thanks for reaching out; couldn't find time to answer you yesterday.
 >>
 >> So, in best engineering manner, let's check a few assumptions with 
you:
 >>
 >> - I'm interpreting your "routine update as "I updated Ubuntu 20.04 
to Ubuntu
23.04",
 >> because that's the only version of Ubuntu that I'm aware of that 
ships GNU
Radio  3.10.5.
 >>
 >> - I'm interpreting your "icon of gnuradio" as the GNU Radio 
companion launcher
icon that
 >> you get (for example, if you're on Gnome desktop, by pressing the 
"windows"
key and
 >> starting to type gnuradio).
 >>
 >> Are these assumptions correct?
 >> Which desktop are you using? If that's unclear, I think we could 
work with a
screenshot
 >> of where you expect the icon to be.
 >>
 >> So, I just checked¹, and the Ubuntu 23.04 package still installs the
 >> gnuradio-grc.desktop file which *should* make any modern desktop 
environment
list GNU
 >> Radio companion in its launchable programs, hence my confusion.
 >> I compared the desktop files themselves, and they haven't changed.
 >>
 >> Best,
 >> Marcus
 >>
 >> ——
 >> ¹ that means I went to packages.ubuntu.com 
<http://packages.ubuntu.com>,
looked up the `gnuradio` package in both the
 >> version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 
(lunar),
got the
 >> "list of files" for amd64 (bottom of the package page), and 
compared these
using `comm -3`.
 >>
 >> On 18.07.23 15:25, David Martini wrote:
 >>> Hi all
 >>>
 >>> After a routine update of ubuntu 20.04 (gnuradio was also in the 
list of sw
update) the
 >>> icon of gnuradio disappeared.
 >>> The gnuradio start properly from terminal.
 >>> The gnuradio is 3.10.5.
 >>> Any help?
 >>>
 >>> Thanks
 >>>
 >>> David Martini
 >>>

Re: Rolling QT GUI Time Sink?

[Marcus Müller]

Hi Fabian,

I'm afraid we currently don't have that, no :(

Best I can offer is the "new" throttle block, which can, at lower rates, make "blocks" of 
items appear in pieces smaller than a full maximum buffer size (i.e., that solves the 
problem that if 10s of samples fit in a buffer, GNU Radio will possibly only process a 
block of items every 10s, which makes e.g. the Qt time sink "stutter" very badly.)


Best,
Marcus!

On 19.07.23 18:09, Fabian Schwartau wrote:

Hi,
is there a way in GRC to get a rolling time sink?
That means no trigger, the signal just scrolls from right to left.

Best,
Fabian

Re: Missings packets on OFDM system simulation

[Marcus Müller]

Definitely not dBW, unless you have a massive amplifier attached, AND somehow calibrated 
your system, AND apply that calibration. From where would the "decibel relative to Watts" 
know what a Watt is?



On 14.07.23 17:56, JORGE GONZALEZ ORELLANA via GNU Radio, the Free & Open-Source Toolkit 
for Software Radio wrote:

Hi Johannes,

I'm not sure what you mean with "Did you check the actual sample level on the "OFDM 
Transmitter" output port?" but in the output of the OFDM transmitter block I got about 15 
[dBW], this measurement was done like this: OFDM Transmitter -> complex to mag^2 -> moving 
average -> 10log(input) -> file sink


For the SNR, I calculate it with the attach flowgraph and test different levels of ''Noise 
Voltage", I can share the values if need it.


i understand that adding noise it results in losing packets, but I don't think it should 
be that aggressive, i really think there is something that I'm doing wrong or not seeing


thanks for your time and comments

kindly
Jorge

El vie, 14 jul 2023 a las 4:12, Johannes Demel (<mailto:de...@ant.uni-bremen.de>>) escribió:


Hi Jorge,

a couple of observations first:
- the "throttle" block needs to be part of the actual flowgraph to have
any effect. You might want to remove your null source -> throttle ->
null sink chain.
- for the sake of a Minimum Working Example (MWE) I suggest to remove
the file sink and virtual sinks as well.
- Did you check the actual sample level on the "OFDM Transmitter" output
port? I suspect these values do not have a mean energy of 1 but way
less. In your case probably 1/sqrt(64). You'd need to adopt the "Noise
Voltage" parameter in your "Channel Model" block accordingly.
- How did you compute your SNR value?
- As long as there's noise, you'd eventually lose packets.

Cheers
Johannes

On 13.07.23 20:08, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
Open-Source Toolkit for Software Radio wrote:
 > As you can see, it's the basic implementation of OFDM.
 > My goal it's to measure the BER, but as I mentioned earlier, below
 > certain level or SNR (20dB)
 >
 > El jue, 13 jul 2023 a las 8:05, Marcus Müller (mailto:mmuel...@gnuradio.org>
 > <mailto:mmuel...@gnuradio.org <mailto:mmuel...@gnuradio.org>>>) escribió:
 >
 >     Hi Jorge,
 >
 >     yes, please share your flowgraph. It's moot even beginning talking
 >     about it without
 >     knowing it.
 >
 >     Best regards,
 >     Marcus
 >
 >     On 12.07.23 20:53, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
 >     Open-Source Toolkit
 >     for Software Radio wrote:
 >      > Hello everyone, I have some question related with a OFDM
 >     transmission simulation, in
 >      > particular, about losing packets.
 >      >
 >      > I am using the OFDM Transmitter and Receiver blocks to do the
 >     transmission (if you need
 >      > more details, I can upload an image of the flowgraph).
 >      >
 >      > The problem that I get is when put some noise (to get some level
 >     of SNR), when I have
 >      > about 20dB (or more) of SNR I don't lose any packet, but if I put
 >     less than 20dB of SNR,
 >      > almost all packets gets lost, (just 1 or 2 packets are received),
 >     all of this happen over
 >      > simulation.
 >      >
 >      > Any suggestions on why this might happen?
 >

Re: Gnuradio Update on ubuntu 20.04 lts

[Marcus Müller]

No need to be sorry, thanks for chiming in :)



On 19.07.23 17:38, Volker Schroer wrote:

Sorry, I was wrong . cmake is not PPA related


Am 19.07.2023 um 17:31 schrieb Marcus Müller :

Hi Volker,

I believe David is referring to the PPA installation, i.e.,

sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio python3-packaging


But that's what confuses me: starting yesterday, that should have installed GR 
3.10.7.0 :-)

Anyways, huh, gotta check that package twice.

Best,
Marcus

On 19.07.23 17:23, Volker Schroer wrote:
Did you run cmake with
-DENABLE_POSTINSTALL=ON ?
— Volker

Am 19.07.2023 um 17:16 schrieb David Martini :



Hi Marcus

Thak you for answer
I don't update the the Ubuntu. Ubuntu is 20.04 lts.
Only gnuradio was update using the instruction on wiki ('InstallingGR' ) to 
version v3 10.7.0
Everything working ok but no icon is present. To lauch gnuradio we need to open 
the terminal and lauch it.
Not a big deal..but I would like to understand way.

Best Regards

David




Il Mer 19 Lug 2023, 14:32 Marcus Müller mailto:mmuel...@gnuradio.org>> ha scritto:

Hi David!

Thanks for reaching out; couldn't find time to answer you yesterday.

So, in best engineering manner, let's check a few assumptions with you:

- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to Ubuntu 
23.04",
because that's the only version of Ubuntu that I'm aware of that ships GNU 
Radio 3.10.5.

- I'm interpreting your "icon of gnuradio" as the GNU Radio companion 
launcher icon
that
you get (for example, if you're on Gnome desktop, by pressing the "windows" 
key and
starting to type gnuradio).

Are these assumptions correct?
Which desktop are you using? If that's unclear, I think we could work with a
screenshot of
where you expect the icon to be.

So, I just checked¹, and the Ubuntu 23.04 package still installs the
gnuradio-grc.desktop
file which *should* make any modern desktop environment list GNU Radio 
companion in its
launchable programs, hence my confusion.
I compared the desktop files themselves, and they haven't changed.

Best,
Marcus

——
¹ that means I went to packages.ubuntu.com <http://packages.ubuntu.com>, 
looked up
the `gnuradio` package in both the
version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 
(lunar), got the
"list
of files" for amd64 (bottom of the package page), and compared these using 
`comm -3`.


On 18.07.23 15:25, David Martini wrote:

> Hi all
>
> After a routine update of ubuntu 20.04 (gnuradio was also in the list of 
sw
update) the
> icon of gnuradio disappeared.
> The gnuradio start properly from terminal.
> The gnuradio is 3.10.5.
> Any help?
>
> Thanks
>
> David Martini
>

Re: Gnuradio Update on ubuntu 20.04 lts

[Marcus Müller]

Hi David,

so, reporting back: fresh installation on a freshly set up Ubuntu 20.04 does indeed not 
install /usr/share/applications/gnuradio-grc.desktop


Possible "hotfix" solutions:

1. run full "gnuradio-companion" from wherever you start programs; that should 
work without
2. put the attached file into your home (~) in the dirctory ~/.local/share/applications/ , 
run (once)

update-desktop-database ~/.local/share/applications

Best regards,
Marcus

On 19.07.23 17:35, Marcus Müller wrote:

Hi David,

are you *sure* it's 3.10.5? It really should be 3.10.7.0 now, that's the latest update we 
made, and it literally came out this week.


I'm currently running the installation

sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio python3-packaging

(that's what you did, right? If you were on the native Ubuntu packaging, you'd be getting 
GNU Radio 3.8 on Ubuntu 20.04)


I'll report back after.

Best regards,
Marcus


On 19.07.23 14:32, Marcus Müller wrote:

Hi David!

Thanks for reaching out; couldn't find time to answer you yesterday.

So, in best engineering manner, let's check a few assumptions with you:

- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to Ubuntu 23.04", 
because that's the only version of Ubuntu that I'm aware of that ships GNU Radio  3.10.5.


- I'm interpreting your "icon of gnuradio" as the GNU Radio companion launcher icon that 
you get (for example, if you're on Gnome desktop, by pressing the "windows" key and 
starting to type gnuradio).


Are these assumptions correct?
Which desktop are you using? If that's unclear, I think we could work with a screenshot 
of where you expect the icon to be.


So, I just checked¹, and the Ubuntu 23.04 package still installs the 
gnuradio-grc.desktop file which *should* make any modern desktop environment list GNU 
Radio companion in its launchable programs, hence my confusion.

I compared the desktop files themselves, and they haven't changed.

Best,
Marcus

——
¹ that means I went to packages.ubuntu.com, looked up the `gnuradio` package in both the 
version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 (lunar), got the 
"list of files" for amd64 (bottom of the package page), and compared these using `comm -3`.


On 18.07.23 15:25, David Martini wrote:

Hi all

After a routine update of ubuntu 20.04 (gnuradio was also in the list of sw update) the 
icon of gnuradio disappeared.

The gnuradio start properly from terminal.
The gnuradio is 3.10.5.
Any help?

Thanks

David Martini


gnuradio-grc.desktop
Description: application/desktop

Re: Gnuradio Update on ubuntu 20.04 lts

[Marcus Müller]

Hi David,

are you *sure* it's 3.10.5? It really should be 3.10.7.0 now, that's the latest update we 
made, and it literally came out this week.


I'm currently running the installation

sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio python3-packaging

(that's what you did, right? If you were on the native Ubuntu packaging, you'd be getting 
GNU Radio 3.8 on Ubuntu 20.04)


I'll report back after.

Best regards,
Marcus


On 19.07.23 14:32, Marcus Müller wrote:

Hi David!

Thanks for reaching out; couldn't find time to answer you yesterday.

So, in best engineering manner, let's check a few assumptions with you:

- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to Ubuntu 23.04", 
because that's the only version of Ubuntu that I'm aware of that ships GNU Radio  3.10.5.


- I'm interpreting your "icon of gnuradio" as the GNU Radio companion launcher icon that 
you get (for example, if you're on Gnome desktop, by pressing the "windows" key and 
starting to type gnuradio).


Are these assumptions correct?
Which desktop are you using? If that's unclear, I think we could work with a screenshot of 
where you expect the icon to be.


So, I just checked¹, and the Ubuntu 23.04 package still installs the gnuradio-grc.desktop 
file which *should* make any modern desktop environment list GNU Radio companion in its 
launchable programs, hence my confusion.

I compared the desktop files themselves, and they haven't changed.

Best,
Marcus

——
¹ that means I went to packages.ubuntu.com, looked up the `gnuradio` package in both the 
version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 (lunar), got the "list 
of files" for amd64 (bottom of the package page), and compared these using `comm -3`.


On 18.07.23 15:25, David Martini wrote:

Hi all

After a routine update of ubuntu 20.04 (gnuradio was also in the list of sw update) the 
icon of gnuradio disappeared.

The gnuradio start properly from terminal.
The gnuradio is 3.10.5.
Any help?

Thanks

David Martini

Re: Gnuradio Update on ubuntu 20.04 lts

[Marcus Müller]

Hi Volker,

I believe David is referring to the PPA installation, i.e.,

sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio python3-packaging


But that's what confuses me: starting yesterday, that should have installed GR 
3.10.7.0 :-)

Anyways, huh, gotta check that package twice.

Best,
Marcus
On 19.07.23 17:23, Volker Schroer wrote:

Did you run cmake with

-DENABLE_POSTINSTALL=ON ?

— Volker


Am 19.07.2023 um 17:16 schrieb David Martini :


Hi Marcus

Thak you for answer
I don't update the the Ubuntu. Ubuntu is 20.04 lts.
Only gnuradio was update using the instruction on wiki ('InstallingGR' ) to version v3 
10.7.0
Everything working ok but no icon is present. To lauch gnuradio we need to open the 
terminal and lauch it.

Not a big deal..but I would like to understand way.

Best Regards

David




Il Mer 19 Lug 2023, 14:32 Marcus Müller <mailto:mmuel...@gnuradio.org>> ha scritto:


Hi David!

Thanks for reaching out; couldn't find time to answer you yesterday.

So, in best engineering manner, let's check a few assumptions with you:

- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to Ubuntu 
23.04",
because that's the only version of Ubuntu that I'm aware of that ships GNU Radio 
3.10.5.


- I'm interpreting your "icon of gnuradio" as the GNU Radio companion 
launcher icon
that
you get (for example, if you're on Gnome desktop, by pressing the "windows" 
key and
starting to type gnuradio).

Are these assumptions correct?
Which desktop are you using? If that's unclear, I think we could work with a
screenshot of
where you expect the icon to be.

So, I just checked¹, and the Ubuntu 23.04 package still installs the
gnuradio-grc.desktop
file which *should* make any modern desktop environment list GNU Radio 
companion in its
launchable programs, hence my confusion.
I compared the desktop files themselves, and they haven't changed.

Best,
Marcus

——
¹ that means I went to packages.ubuntu.com <http://packages.ubuntu.com>, 
looked up
the `gnuradio` package in both the
version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 
(lunar), got the
"list
of files" for amd64 (bottom of the package page), and compared these using 
`comm -3`.

On 18.07.23 15:25, David Martini wrote:
> Hi all
>
> After a routine update of ubuntu 20.04 (gnuradio was also in the list of 
sw
update) the
> icon of gnuradio disappeared.
> The gnuradio start properly from terminal.
> The gnuradio is 3.10.5.
> Any help?
>
> Thanks
>
> David Martini
>

Re: Gnuradio Update on ubuntu 20.04 lts

[Marcus Müller]

Hi David!

Thanks for reaching out; couldn't find time to answer you yesterday.

So, in best engineering manner, let's check a few assumptions with you:

- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to Ubuntu 23.04", 
because that's the only version of Ubuntu that I'm aware of that ships GNU Radio  3.10.5.


- I'm interpreting your "icon of gnuradio" as the GNU Radio companion launcher icon that 
you get (for example, if you're on Gnome desktop, by pressing the "windows" key and 
starting to type gnuradio).


Are these assumptions correct?
Which desktop are you using? If that's unclear, I think we could work with a screenshot of 
where you expect the icon to be.


So, I just checked¹, and the Ubuntu 23.04 package still installs the gnuradio-grc.desktop 
file which *should* make any modern desktop environment list GNU Radio companion in its 
launchable programs, hence my confusion.

I compared the desktop files themselves, and they haven't changed.

Best,
Marcus

——
¹ that means I went to packages.ubuntu.com, looked up the `gnuradio` package in both the 
version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 (lunar), got the "list 
of files" for amd64 (bottom of the package page), and compared these using `comm -3`.


On 18.07.23 15:25, David Martini wrote:

Hi all

After a routine update of ubuntu 20.04 (gnuradio was also in the list of sw update) the 
icon of gnuradio disappeared.

The gnuradio start properly from terminal.
The gnuradio is 3.10.5.
Any help?

Thanks

David Martini

Re: Error strange: The daughterboard manager encountered a recoverable error in init.

[Marcus Müller]

Hi sp,

wrong mailing list – you already know this is appropriate for usrp-users, as you're active 
over there.


Best,
Marcus

On 17.07.23 08:16, sp wrote:
when I want to use USRP x310 with ubx-160 and twin-rx daughterboard I have faced this 
strange log...


The daughterboard manager encountered a recoverable error in init.
Loading the "unknown" daughterboard implementations to continue.
The daughterboard cannot operate until this error is resolved.

when I used uhd_usrp_probe I faced that TX for UBX-160 is unknown.
TX Frontend: 0
|   |   | *Name: Unknown (0x0094) - 0
|   |   |   Antennas:
|   |   |   Sensors:
|   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   Gain Elements: None
|   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   Connection Type: IQ
|   |   |   Uses LO offset: No*

How can solve these errors?

*complete log:*

uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.2.0.0-0-unknown
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush!
   _
  /
|       Device: X-Series Device
|     _
|    /
|   |       Mboard: X310
|   |   revision: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:32:72:23
|   |   mac-addr1: 00:80:2f:32:72:24
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 3216766
|   |   FW Version: 6.0
|   |   FPGA Version: 38.0
|   |   FPGA git hash: 26793b8
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|     _
|    /
|   |       RFNoC blocks on this device:
|   |
|   |   * 0/DDC#0
|   |   * 0/DDC#1
|   |   * 0/DUC#0
|   |   * 0/DUC#1
|   |   * 0/Radio#0
|   |   * 0/Radio#1
|   |   * 0/Replay#0
|     _
|    /
|   |       Static connections on this device:
|   |
|   |   * 0/SEP#0:0==>0/DUC#0:0
|   |   * 0/DUC#0:0==>0/Radio#0:0
|   |   * 0/Radio#0:0==>0/DDC#0:0
|   |   * 0/DDC#0:0==>0/SEP#0:0
|   |   * 0/Radio#0:1==>0/DDC#0:1
|   |   * 0/DDC#0:1==>0/SEP#1:0
|   |   * 0/SEP#2:0==>0/DUC#1:0
|   |   * 0/DUC#1:0==>0/Radio#1:0
|   |   * 0/Radio#1:0==>0/DDC#1:0
|   |   * 0/DDC#1:0==>0/SEP#2:0
|   |   * 0/Radio#1:1==>0/DDC#1:1
|   |   * 0/DDC#1:1==>0/SEP#3:0
|   |   * 0/SEP#4:0==>0/Replay#0:0
|   |   * 0/Replay#0:0==>0/SEP#4:0
|   |   * 0/SEP#5:0==>0/Replay#0:1
|   |   * 0/Replay#0:1==>0/SEP#5:0
|     _
|    /
|   |       TX Dboard: 0/Radio#0
|   |   ID: UBX-160 v2 (0x007d)
|   |   Serial: 325406E
|   |     _
|   |    /
|   |   |       TX Frontend: 0
|   |   |   Name: UBX TX
|   |   |   Antennas: TX/RX, CAL
|   |   |   Sensors: lo_locked
|   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   Connection Type: QI
|   |   |   Uses LO offset: No
|     _
|    /
|   |       RX Dboard: 0/Radio#0
|   |   ID: UBX-160 v2 (0x007e)
|   |   Serial: 325406E
|   |     _
|   |    /
|   |   |       RX Frontend: 0
|   |   |   Name: UBX RX
|   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   Sensors: lo_locked
|   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   Connection Type: IQ
|   |   |   Uses LO offset: No
|     _
|    /
|   |       TX Dboard: 0/Radio#1
|   |   ID: Unknown (0x0094)
|   |   Serial: 31EF996
|   |     _
|   |    /
|   |   |       TX Frontend: 0
|   |   |   Name: Unknown (0x0094) - 0
|   |   |   Antennas:
|   |   |   Sensors:
|   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   Gain Elements: None
|   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   Connection Type: IQ
|   |   |   Uses LO offset: No
|     _
|    /
|   |       RX Dboard: 0/Radio#1
|   |   ID: TwinRX Rev C (0x0095)
|   |   Serial: 31D7212
|   |     _
|   |    /
|   |   |       RX Frontend: 0
|   |   |   Name: TwinRX RX0
|   |   |   Antennas: RX1, RX2
|   |   |   Sensors: lo_locked
|   |   |   Freq 

Re: Missings packets on OFDM system simulation

[Marcus Müller]

Hi Jorge,

yes, please share your flowgraph. It's moot even beginning talking about it without 
knowing it.


Best regards,
Marcus

On 12.07.23 20:53, JORGE GONZALEZ ORELLANA via GNU Radio, the Free & Open-Source Toolkit 
for Software Radio wrote:
Hello everyone, I have some question related with a OFDM transmission simulation, in 
particular, about losing packets.


I am using the OFDM Transmitter and Receiver blocks to do the transmission (if you need 
more details, I can upload an image of the flowgraph).


The problem that I get is when put some noise (to get some level of SNR), when I have 
about 20dB (or more) of SNR I don't lose any packet, but if I put less than 20dB of SNR, 
almost all packets gets lost, (just 1 or 2 packets are received), all of this happen over 
simulation.


Any suggestions on why this might happen?

Re: Request for help with Comprehensive RFID module in GNU Radio on Linux

[Marcus Müller]

Hi stackprogrammer,

pick one, and do a bit more research!
The technologies involved are pretty different. Then research based on that! "RFID" is a 
wide topic, and as you can imagine, getting data out of an animal identification chip with 
a reader held onto the chip works differently than reading your credit card, and works 
differently than scanning pallets full of tagged goods when unloading them.


Best regards,
Marcus

On 30.06.23 19:35, sp wrote:

Dear GNU Radio community,

I am working on a project involving RFID modules in GNU Radio on Linux. I have come across 
some projects, but they seem to be imperfect. I would appreciate any guidance or 
suggestions from the community on how to approach this problem.

RFID UHF
RFID 125Khz
RFID 13.56MHZ

Thank you in advance for your help.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: why udp source and sink not work effieciny in gnuradio?

[Marcus Müller]

Exactly this. By choosing UDP, you chose to drop packets when they are not 
handled in time.
So, this is working 100% as expected.

Best regards,
Marcus

On 04.07.23 09:20, Fabian Schwartau wrote:

Hi,
my guess would be that the file source and UDP sink are much faster than the UDP source 
and QT GUI Sink. As UDP is "fire and forget", the "transmitter" may be pushing more data 
over the network than the QT GUI Sink can handle.
To test this, you can replace the QT GUI Sink with a NULL sink, which just deletes the 
data. Or you can add a throttle block after the File Source to reduce the data rate.


Best,
Fabian

Am 04.07.23 um 09:07 schrieb sp:

why do UDP source and sink not work efficiently in Gnuradio?
I want to use a UDP  source and sink in Gnuradio, for a low sample rate of 10k I see 
that there is too many packet drop. why network tools does not work effectively?

can anyone guide you? thanks in advance

*more info:*
I set payload size 1408 I set send null pkt as true or false all  state I had not a good 
response

see the screenshot and log

Screenshot from 2023-07-04 10-30-22.png

gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet.
gr::log :WARN: udp_source0 - Too much data; dropping packet





smime.p7s
Description: S/MIME Cryptographic Signature