Re: Getting `Assertion s < d_bufsize' failed` error

Thanks Ed! Do you have any idea how I can go about debugging/fixing this?

On Thu, Apr 22, 2021 at 9:39 AM Ed Criscuolo <ed@chessie.com> wrote:

Looks like a memory allocation failed. 

@(^.^)@ Ed

Sent from my iPhone

On Apr 22, 2021, at 11:15 AM, Roman A Sandler <rsandler00@gmail.com> wrote:

Hi, I am running some simulations w/ GNURadio where I run top blocks repeatedly inside a nested for loop in python. e.g.:

```
for scheme_set in range(len(schemes)):
    name = scheme_names[scheme_set]
    for snr_set in snr_list:
        print(color.GREEN + 'Starting modulation scheme: ' + name + ' at SNR: ' + str(snr_set) + color.END)

        tb = top_block_cls(ota=False)
        tb.set_file_num_and_scheme(name, snr_set)
        tb.start()
        tb.wait()
```

I randomly get this error:
```
python3: /build/gnuradio-sO0YW3/gnuradio-3.8.2.0-0~gnuradio~bionic/gnuradio-runtime/lib/../include/gnuradio/buffer.h:193: unsigned int gr::buffer::index_add(unsigned int, unsigned int): Assertion `s < d_bufsize' failed.
Aborted (core dumped)
```

The weird thing is that it happens at totally random iterations of the for loop - sometimes in the 1st iteration, sometimes at the 10th, which makes me think that the flowgraph is fine, but there is a GNURadio issue.

Does anyone have any insight into the nature of this error?

Thanks!

RE: InvalidArchiveError and/or TypeError when installing GNURadio via conda

Hi Ryan,

Thanks for your reply, was out all day yesterday and didn't see this. I have tried deleting in manually. Clean -all does delete it as well

Casey

-----Original Message-----
From: Ryan Volz <ryan.volz@gmail.com>
Sent: Monday, April 26, 2021 11:02 PM
To: discuss-gnuradio@gnu.org; Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV <Carl.L.Wolsieffer@erdc.dren.mil>
Subject: Re: InvalidArchiveError and/or TypeError when installing GNURadio via conda

Hi Casey,

On April 26, 2021 11:09:20 AM EDT, "Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV" <Carl.L.Wolsieffer@erdc.dren.mil> wrote:
>Hello All,
>
>Been using GNU Radio for a couple months now and so I've had to install
>it on a couple machines here including Ubuntu and Windows 7. However we
>have a field laptop running windows 10 and I can't seem to get past the
>'>conda install gnuradio' step.
>
>Using conda 4.9.2:
>
>After creating a virtual environment and ensuring priority to
>conda-forge as per wiki instructions, I get the following error:
>
>InvalidArchiveError("Error with archive
>C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1.tar.bz2.
>You probably need to delete and re-download or re-create this file.
>Message from libarchive was:\n\nCan't create
>'\\\\?\\C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1\
>\Library\\bin\\fdmdv_get_test_bits.exe'")

Did you try deleting that file (C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1.tar.bz2)? Clean --all might do that, but better to do it explicitly yourself to make sure.

>
>This occurs after downloading and extracting pywin32-300
>
>
>
>For conda version 4.10.1 I instead get:
>
>After
>> conda clean --all
>> conda install gnuradio
>
>I get
>
>TypeError('not all arguments converted during string formatting')
>
>
>This occurs after reaching package libopus-1.3.1

I unfortunately have no lead on that error, without knowing where exactly it's coming from.

>
>Any help would be greatly appreciated!
>
>Thanks,
>Casey

The fact that you're running into multiple vague issues like this makes me wonder if there is something wrong with your conda installation. If it's an option, I'd consider wiping the whole thing and starting from scratch.

You could also try installing 'mamba' and using that in place of 'conda', i.e.:

conda install -n base mamba
mamba install gnuradio

Finally, you could try the radioconda installer: Blockedhttps://github.com/ryanvolz/radiocondaBlocked. By installing everything at once, it could sidestep whatever is causing the issues you're seeing.

Cheers,
Ryan

Re: Merging Multiple blocks into one

There is currently no way to merge blocks in GNU Radio without manually merging as you describe.  In the future we are aiming to be able to run multiple blocks within a single thread, and have more control over the buffers that are created in the blocks.

In the meantime, perhaps this presentation on controlling latency could be of use:

https://www.youtube.com/watch?v=jq0RewceCwc&list=PLE7tQUdRKcyaaF1pm1MfQm_g1TF2CP1JZ&index=35

To use it I believe would involve using some out of tree blocks.

Josh

On Tue, Apr 27, 2021 at 5:34 AM mehtap özkan <kurtulmehtap@gmail.com> wrote:

Dear All, 

I have a flowgraph where I use multiple Standart Blocks.

The Application requires low sample and symbol rates, therefore the buffers between the blocks cause a lot of Latency. 

 Is there a way to merge the standart blocks or do I have to manually merge the c++ sources and   re-compile them.

Thank you in advance.

Merging Multiple blocks into one

Dear All, 

I have a flowgraph where I use multiple Standart Blocks.

The Application requires low sample and symbol rates, therefore the buffers between the blocks cause a lot of Latency. 

 Is there a way to merge the standart blocks or do I have to manually merge the c++ sources and   re-compile them.

Thank you in advance.

Re: InvalidArchiveError and/or TypeError when installing GNURadio via conda

Hi Casey,

On April 26, 2021 11:09:20 AM EDT, "Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV" <Carl.L.Wolsieffer@erdc.dren.mil> wrote:
>Hello All,
>
>Been using GNU Radio for a couple months now and so I've had to install
>it on a couple machines here including Ubuntu and Windows 7. However we
>have a field laptop running windows 10 and I can't seem to get past the
>'>conda install gnuradio' step.
>
>Using conda 4.9.2:
>
>After creating a virtual environment and ensuring priority to
>conda-forge as per wiki instructions, I get the following error:
>
>InvalidArchiveError("Error with archive
>C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1.tar.bz2.
>You probably need to delete and re-download or re-create this file.
>Message from libarchive was:\n\nCan't create
>'\\\\?\\C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1\\Library\\bin\\fdmdv_get_test_bits.exe'")

Did you try deleting that file (C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1.tar.bz2)? Clean --all might do that, but better to do it explicitly yourself to make sure.

>
>This occurs after downloading and extracting pywin32-300
>
>
>
>For conda version 4.10.1 I instead get:
>
>After
>> conda clean --all
>> conda install gnuradio
>
>I get
>
>TypeError('not all arguments converted during string formatting')
>
>
>This occurs after reaching package libopus-1.3.1

I unfortunately have no lead on that error, without knowing where exactly it's coming from.

>
>Any help would be greatly appreciated!
>
>Thanks,
>Casey

The fact that you're running into multiple vague issues like this makes me wonder if there is something wrong with your conda installation. If it's an option, I'd consider wiping the whole thing and starting from scratch.

You could also try installing 'mamba' and using that in place of 'conda', i.e.:

conda install -n base mamba
mamba install gnuradio

Finally, you could try the radioconda installer: https://github.com/ryanvolz/radioconda. By installing everything at once, it could sidestep whatever is causing the issues you're seeing.

Cheers,
Ryan

Re: USRP E310 based transceiver

Also—missed this the first time around. The AD9361 has only a single LO synthesizer in each duration. Meaning that both RX channels will be tuned to the same RF frequency.

Sent from my iPhone

> On Apr 26, 2021, at 7:58 PM, Marcus D Leech <patchvonbraun@gmail.com> wrote:
>
> The RX gain range on the RF front end goes up to 72dB, so you're about 40dB below maximum RX gain.
>
> Sent from my iPhone
>
>> On Apr 26, 2021, at 6:09 PM, Ivan Zahartchuk <adray0001@gmail.com> wrote:
>>
>> 
>> Hello. I want to make a transceiver based on USRP E310. That is, on one channel, reception and on another transceiver. But I can't see signals on the receive channel. And the LEDs do not show transmission. Tell me in which direction to look.
>> <Снимок экрана от 2021-04-27 00-55-22.png>
>>
>>

Re: USRP E310 based transceiver

The RX gain range on the RF front end goes up to 72dB, so you're about 40dB below maximum RX gain.

Sent from my iPhone

> On Apr 26, 2021, at 6:09 PM, Ivan Zahartchuk <adray0001@gmail.com> wrote:
>
> 
> Hello. I want to make a transceiver based on USRP E310. That is, on one channel, reception and on another transceiver. But I can't see signals on the receive channel. And the LEDs do not show transmission. Tell me in which direction to look.
> <Снимок экрана от 2021-04-27 00-55-22.png>
>
>

USRP E310 based transceiver

Hello. I want to make a transceiver based on USRP E310. That is, on one channel, reception and on another transceiver. But I can't see signals on the receive channel. And the LEDs do not show transmission. Tell me in which direction to look.

Re: Nyquist Rate & Distortion, A Visual Example: Issues

of course twice not half.

Thanks Jerry and sorry for writing to fast without correcting these evidences!

On 26/04/2021 16:58, geraldfenkell wrote:

is it not: The sampling frequency must be twice the max frequency to avoid aliasing?

 

regards

 

Jerry VE3OBX

 

------------------------

Hi James

Your first signal (upper branch) is one of those I like to show to my students to explain the Nyquist sampling theorem.

1- As Daniel said, sampling frequency Fs  must be higher than twice the maximum frequency Fmax: This is the Nyquist Sampling theorem, but don't forget that this writes : Fmax*2 > Fs

So in your flowgraph, the signal source breaks the rule: 1kHz=Fmax=Fs/2 is not allowed. you could theoretically use Fs=0.8 0.9 or 0.99 kHz, not 1.000 kHz ... but things are not so simple as explained below (3).

2- You signal (upper flowgraph branch) is a sine wave sample with 2 samples / period since Fmax=F=Fs/2. So you are sampling a sine wave at time  t=kTs/2, that is exactly when your sine wave is zero. What you get (nanoscale) is the error in the sin(kTs/2) computation. This result clearly demonstrates that sampling with 2 samples/period is not possible (sometimes it works, sometime not!).

2-bis- take your flowgraph, replace sine by cosine so that the signal get sampled exactly when it amplitude is +1 or 1. Your time sink is closer to the expected results, a sine wave... but the amplitude (I've got 0.04) is not the one expected (lower than 1). This is due to the next point (3).

3- The sampling theorem states that is is possible to recover the original signal from the sampled signal using an ideal low-pass filter, with a transfer function H(f) so that H(f)=1 for f<Fmax/2 and  H(f)=0 for f>=Fmax/2, that is a filter with a transition bandwith of 0 Hz. This ideal filter is not physically realizable. In gnuradio simulating this would require and infinite number of coefficient.

3-bis- this explain why you don't get the correct amplitude in (2) : because the filter used in the rational resampler has a finite transition bandwidth. Try to lower the frequency to 0.8 or 0.9 to get a correct time result (this depends on the transition bandwidth used in the rational resampler).

4- This is why in real hardware and simulation, we generally use more than 3 or 4 samples per period

Regards

On 25/04/2021 22:26, James Hayek wrote:

It definitely helps, thank you. One thing I noticed, and don't know how to address is why the ""Correctly Sampled Signal"" Time Sink shows the amplitude on the nanoscale.My signal source has an amplitude of one and the Time Sink should be displaying a range from -1 to 1. 

 

I placed a rational resampler like you mentioned. I placed it after the throttle block and before the Time Sink. I used an interpolation of 5 for the signal that uses a variable sampling rate (2*freq) and see a nice sine wave now. I am unsure how to do that for the signal source where I keep the sample rate constant since a constant value of 5 distorts the signal. Is there a way to tie this parameter to another?

 

Yes, that's a good example. I see when freq is greater than samp_rate/2 that the frequency sink displays an incorrect frequency. Maybe that's the way to go about showing aliasing in GRC.  

 

 

 

On Sun, Apr 25, 2021 at 2:55 PM Daniel Estévez <daniel@destevez.net> wrote:

El 25/4/21 a las 18:42, James Hayek escribió:
> Apologies if I missed any response from my prior thread.
> I wanted to elaborate more here, on what I am attempting to do.
>
> The goal is to create a GRC file to show how sampling rates affect a
> generated signal. Knowing, for real samples, fs (sampling rate,
> "samp_rate) would be greater than twice that of the highest
> bandwidth (f, "freq"), I created a flow graph where one can adjust
the
> frequency whilst keeping the sampling rate constant.
>
> I would have imagined (since fs > 2B) for any frequency I set past
> 1/2*fs, I would see distortion, and anything less would yield accurate
> results.
>
> I created two sine wave Signal Sources. One where the _sample rate_ was

> set to freq*2 and the _frequency_ was set to an adjustable variable, freq.
>
> The other where the _sample rate_ was set to a fixed samp_rate and the
> _frequency_ was set to the same adjustable variable, freq.
>
> Both signals output to a QT GUI Time SInk. When I run the program, I see
> the signal using a sampling rate of freq*2 is distorted
> (triangular waveform) and the signal with the fixed sampling rate
> distorts past a frequency of 1K Hz. I have the sampling rate to 32KSps.

> Wouldn't it distort around 16KHz? What have I set up incorrectly?

Hi James,

Your results are perfectly fine. Nyquist theorem tells us that if we
sample at a rate higher than 2*freq, then _it is possible_ to recover
the original waveform. That's it. A key ingredient that sometimes is
forgotten is the _it is possible_.

What Nyquist doesn't say is that if you sample at a rate higher than
2*freq and join your samples with straight lines, then the result will
look like a sine wave. Think about it, if you have very few samples per
cycle of the sine wave, then you'll get something just like the
triangular-ish wave you see. In order to have a very nice sine wave you
need to have many, many points per cycle. And even so, if you zoom all
the way in, the fact that you have a bunch of samples joined with
straight lines will be visible. That always happens with discrete time
sampling.

The interesting question is then, how is it possible to recover the
original waveform? This is basically done with sinc interpolation. You
can try it yourself in GNU Radio by using the "Rational Resampler" block
(for example) to interpolate your ugly triangular-ish waveform so that
you get many points per cycle. You'll see a pretty sine wave of the
correct frequency.

Now the interesting part comes when you set your frequency higher than
samp_rate/2. As long as you're generating a sine wave, you'll also get a
pretty sine wave when you interpolate. However, the frequency of this
sine wave will no longer be the "expected" one. In this way you can
demonstrate aliasing.

Hope this helps.

Best,

Dani.
 

 

 

--

Thanks,
James G Hayek

Youtube.com/JamesHayek

InvalidArchiveError and/or TypeError when installing GNURadio via conda

Hello All,

Been using GNU Radio for a couple months now and so I've had to install it on a couple machines here including Ubuntu and Windows 7. However we have a field laptop running windows 10 and I can't seem to get past the '>conda install gnuradio' step.

Using conda 4.9.2:

After creating a virtual environment and ensuring priority to conda-forge as per wiki instructions, I get the following error:

InvalidArchiveError("Error with archive C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1.tar.bz2. You probably need to delete and re-download or re-create this file. Message from libarchive was:\n\nCan't create '\\\\?\\C:\\Users\\RDCRLCLW\\Miniconda3\\pkgs\\codec2-0.9.2-h301d43c_1\\Library\\bin\\fdmdv_get_test_bits.exe'")

This occurs after downloading and extracting pywin32-300



For conda version 4.10.1 I instead get:

After
> conda clean --all
> conda install gnuradio

I get

TypeError('not all arguments converted during string formatting')


This occurs after reaching package libopus-1.3.1

Any help would be greatly appreciated!

Thanks,
Casey

open jobs at Spire

Spire has exciting open positions to join a growing, highly-talented, GNSS-enabled science and engineering team. Spire is a dynamic, global company designing, building, and operating one of the world's largest constellations of Earth observation nanosatellites. The jobs are posted at:

Signal Processing Engineer III (Glasgow): https://grnh.se/99bbfe4f1us

RF Engineer - Earth Observation Payloads  (Glasgow): https://grnh.se/3551a0731us

Software Developer (Python, AWS) - Earth Observations (Luxembourg): https://grnh.se/a2bdf8761us

Similar positions in other Spire teams are posted at: https://grnh.se/22adeee81us

Feel free to distribute and/or contact me with any inquiries.

--

Dallas Masters, Ph.D.
Director, Earth Observations/GNSS
Spire Global, Inc.

1690 38th Street, Boulder, CO 80301 USA

+1-720-643-2244 (o)

+1-720-235-8643 (m)

Re: Nyquist Rate & Distortion, A Visual Example: Issues

Hi James

Your first signal (upper branch) is one of those I like to show to my students to explain the Nyquist sampling theorem.

1- As Daniel said, sampling frequency Fs  must be higher than half the maximum frequency Fmax: This is the Nyquist Sampling theorem, but don't forget that this writes : Fmax/2 > Fs

So in your flowgraph, the signal source breaks the rule: Fmax=2Fs is not allowed. you could theoretically use Fs=0.8 0.9 or 0.99 kHz, not 1.000 kHz ... but things are not so simple as explained below (3).

2- You signal (upper flowgraph branch) is a sine wave sample with 2 samples / period since Fmax=2F. So you are sampling a sine wave at time  t=kTs/2, that is exactly when your sine wave is zero. What you get (nanoscale) is the error in the sin(kTs/2) computation. This result clearly demonstrates that sampling with 2 samples/period is not possible (sometimes it works, sometime not!).

2-bis- take your flowgraph, replace sine by cosine so that the signal get sampled exactly when it amplitude is +1 or 1. Your time sink is closer to the expected results, a sine wave... but the amplitude (I've got 0.04) is not the one expected (lower than 1). This is due to the next point (3).

3- The sampling theorem states that is is possible to recover the original signal from the sampled signal using an ideal low-pass filter, with a transfer function H(f) so that H(f)=1 for f<Fmax/2 and  H(f)=0 for f>=Fmax/2, that is a filter with a transition bandwith of 0 Hz. This ideal filter is not physically realizable. In gnuradio simulating this would require and infinite number of coefficient.

3-bis- this explain why you don't get the correct amplitude in (2) : because the filter used in the rational resampler has a finite transition bandwidth. Try to lower the frequency to 0.8 or 0.9 to get a correct time result (this depends on the transition bandwidth used in the rational resampler).

4- This is why in real hardware and simulation, we generally use more than 3 or 4 samples per period

Regards

On 25/04/2021 22:26, James Hayek wrote:

It definitely helps, thank you. One thing I noticed, and don't know how to address is why the ""Correctly Sampled Signal"" Time Sink shows the amplitude on the nanoscale.My signal source has an amplitude of one and the Time Sink should be displaying a range from -1 to 1. 

I placed a rational resampler like you mentioned. I placed it after the throttle block and before the Time Sink. I used an interpolation of 5 for the signal that uses a variable sampling rate (2*freq) and see a nice sine wave now. I am unsure how to do that for the signal source where I keep the sample rate constant since a constant value of 5 distorts the signal. Is there a way to tie this parameter to another?

Yes, that's a good example. I see when freq is greater than samp_rate/2 that the frequency sink displays an incorrect frequency. Maybe that's the way to go about showing aliasing in GRC.  

On Sun, Apr 25, 2021 at 2:55 PM Daniel Estévez <daniel@destevez.net> wrote:

El 25/4/21 a las 18:42, James Hayek escribió:
> Apologies if I missed any response from my prior thread.
> I wanted to elaborate more here, on what I am attempting to do.
>
> The goal is to create a GRC file to show how sampling rates affect a
> generated signal. Knowing, for real samples, fs (sampling rate,
> "samp_rate) would be greater than twice that of the highest
> bandwidth (f, "freq"), I created a flow graph where one can adjust
the
> frequency whilst keeping the sampling rate constant.
>
> I would have imagined (since fs > 2B) for any frequency I set past
> 1/2*fs, I would see distortion, and anything less would yield accurate
> results.
>
> I created two sine wave Signal Sources. One where the _sample rate_ was

> set to freq*2 and the _frequency_ was set to an adjustable variable, freq.
>
> The other where the _sample rate_ was set to a fixed samp_rate and the
> _frequency_ was set to the same adjustable variable, freq.
>
> Both signals output to a QT GUI Time SInk. When I run the program, I see
> the signal using a sampling rate of freq*2 is distorted
> (triangular waveform) and the signal with the fixed sampling rate
> distorts past a frequency of 1K Hz. I have the sampling rate to 32KSps.

> Wouldn't it distort around 16KHz? What have I set up incorrectly?

Hi James,

Your results are perfectly fine. Nyquist theorem tells us that if we
sample at a rate higher than 2*freq, then _it is possible_ to recover
the original waveform. That's it. A key ingredient that sometimes is
forgotten is the _it is possible_.

What Nyquist doesn't say is that if you sample at a rate higher than
2*freq and join your samples with straight lines, then the result will
look like a sine wave. Think about it, if you have very few samples per
cycle of the sine wave, then you'll get something just like the
triangular-ish wave you see. In order to have a very nice sine wave you
need to have many, many points per cycle. And even so, if you zoom all
the way in, the fact that you have a bunch of samples joined with
straight lines will be visible. That always happens with discrete time
sampling.

The interesting question is then, how is it possible to recover the
original waveform? This is basically done with sinc interpolation. You
can try it yourself in GNU Radio by using the "Rational Resampler" block
(for example) to interpolate your ugly triangular-ish waveform so that
you get many points per cycle. You'll see a pretty sine wave of the
correct frequency.

Now the interesting part comes when you set your frequency higher than
samp_rate/2. As long as you're generating a sine wave, you'll also get a
pretty sine wave when you interpolate. However, the frequency of this
sine wave will no longer be the "expected" one. In this way you can
demonstrate aliasing.

Hope this helps.

Best,

Dani.

--

Thanks,
James G Hayek

Youtube.com/JamesHayek

Re: Solved! - Re: USRP UHD Source problem

Thank you for following up on this issue. The grc cache has turned up a few times recently as the cause of a few issues. So yes a github issue would be a very good idea to track this. 

Thanks!

On Sun, Apr 25, 2021 at 3:52 PM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

I effectively proposed Mike to remove the cache.json file, in case it
could help. As I thought this was probably not the solution I sent him a
private email and asked him to answer to the list in case of success.

So to resume; it appears that the problem originates from simply
upgrading GNURadio installed from PPA.

Question: should we fire an issue on Github? I think that this cache
problem should be solved by cleaning the cache each time GR is updated
or its version is changed (some users may also downgrade GR in some case)

Regards, Christophe


On 25/04/2021 15:06, Mike Markowski wrote:
> With thanks to Christophe for his excellent advice, removing
> ~/.cache/grc_gnuradio/cache.json fixed things up.  After needing to do
> this now & then, I have a new gr heuristic:
>
>   if (weirdnessReigns) { delete cache.json; }
>
> Thanks, Christophe!
>
> Mike
>
> On 4/24/21 2:55 PM, Mike Markowski wrote:
>> Some progress.  When I log in as another user, gr runs fine with a
>> usrp.   Logging in as me, I get the errors previously posted.  My
>> environment seems to (suddenly) be the issue, so I:
>>
>> 1. Moved ~/.bashrc to a new name to avoid any improper env var settings.
>>
>> 2. Moved ~/.config/GNU\ RADIO
>>
>> But I still get errors previously posted.  Are there other files
>> gnuradio-companion is looking at that could be the culprit?
>>
>> Thanks,
>> Mike
>>
>> On 4/24/21 1:04 PM, Mike Markowski wrote:
>>> Thanks for checking, Christophe.  I agree that it's strange.  I've
>>> been away from gnuradio doing some cyclostationary work, so haven't
>>> touched any flowgraphs in weeks.  I see that my newest flowgraphs
>>> were built April 7 and that gnuradio-companion, no doubt after an
>>> Ubuntu upgrade, shows a date of April 9.
>>>
>>> I'll share debugging breakthroughs, but would be glad to hear from
>>> others if your GR 3.8.1.0 is or isn't running fine.  Most likely,
>>> it's my environment since I don't see a flurry of 'me too' notes.
>>>
>>> Mike
>>>
>>> On 4/24/21 12:16 PM, Christophe Seguinot wrote:
>>>> This flowgraph is correctly build under GR 3.9.0.0 (no USRP source
>>>> to test further)
>>>>
>>>> The error is quite strange, I think there is no "len_tag_name"
>>>> parameter in such a simple flowgraph
>>>>
>>>> On 24/04/2021 16:35, Mike Markowski wrote:
>>>>> I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
>>>>> 2020.10.  After a few weeks away from gnuradio, today I get errors
>>>>> with the USRP UHD Source, and previously working flowgraphs no
>>>>> longer build. (Previously built flowgraph python files still run
>>>>> fine.)  The attached flowgraph doesn't get much simpler, but
>>>>> building yields:
>>>>>
>>>>> Generating: '/home/mm/sdr/fm/uhdTest.py'
>>>>> Generate Error: (NameError("'len_tag_name' is not defined"),
>>>>> 'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n
>>>>> uhd.stream_args(\n cpu_format="${type}",\n
>>>>>
>>>>> [... on and on ...]
>>>>>
>>>>> , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n%
>>>>> endif\n')
>>>>> >>> Failure
>>>>> Traceback (most recent call last):
>>>>>   File "memory:0x7f3082ab36d0", line 136, in render_body
>>>>>   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106,
>>>>> in __getitem__
>>>>>     return compat_builtins.__dict__[key]
>>>>> KeyError: 'len_tag_name'
>>>>>
>>>>> [... still more...]
>>>>>
>>>>> Is anyone else seeing this error?
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>
>

Re: Nyquist Rate & Distortion, A Visual Example: Issues

It definitely helps, thank you. One thing I noticed, and don't know how to address is why the ""Correctly Sampled Signal"" Time Sink shows the amplitude on the nanoscale.My signal source has an amplitude of one and the Time Sink should be displaying a range from -1 to 1. 

I placed a rational resampler like you mentioned. I placed it after the throttle block and before the Time Sink. I used an interpolation of 5 for the signal that uses a variable sampling rate (2*freq) and see a nice sine wave now. I am unsure how to do that for the signal source where I keep the sample rate constant since a constant value of 5 distorts the signal. Is there a way to tie this parameter to another?

Yes, that's a good example. I see when freq is greater than samp_rate/2 that the frequency sink displays an incorrect frequency. Maybe that's the way to go about showing aliasing in GRC.  

On Sun, Apr 25, 2021 at 2:55 PM Daniel Estévez <daniel@destevez.net> wrote:

El 25/4/21 a las 18:42, James Hayek escribió:
> Apologies if I missed any response from my prior thread.
> I wanted to elaborate more here, on what I am attempting to do.
>
> The goal is to create a GRC file to show how sampling rates affect a
> generated signal. Knowing, for real samples, fs (sampling rate,
> "samp_rate) would be greater than twice that of the highest
> bandwidth (f, "freq"), I created a flow graph where one can adjust
the
> frequency whilst keeping the sampling rate constant.
>
> I would have imagined (since fs > 2B) for any frequency I set past
> 1/2*fs, I would see distortion, and anything less would yield accurate
> results.
>
> I created two sine wave Signal Sources. One where the _sample rate_ was

> set to freq*2 and the _frequency_ was set to an adjustable variable, freq.
>
> The other where the _sample rate_ was set to a fixed samp_rate and the
> _frequency_ was set to the same adjustable variable, freq.
>
> Both signals output to a QT GUI Time SInk. When I run the program, I see
> the signal using a sampling rate of freq*2 is distorted
> (triangular waveform) and the signal with the fixed sampling rate
> distorts past a frequency of 1K Hz. I have the sampling rate to 32KSps.

> Wouldn't it distort around 16KHz? What have I set up incorrectly?

Hi James,

Your results are perfectly fine. Nyquist theorem tells us that if we
sample at a rate higher than 2*freq, then _it is possible_ to recover
the original waveform. That's it. A key ingredient that sometimes is
forgotten is the _it is possible_.

What Nyquist doesn't say is that if you sample at a rate higher than
2*freq and join your samples with straight lines, then the result will
look like a sine wave. Think about it, if you have very few samples per
cycle of the sine wave, then you'll get something just like the
triangular-ish wave you see. In order to have a very nice sine wave you
need to have many, many points per cycle. And even so, if you zoom all
the way in, the fact that you have a bunch of samples joined with
straight lines will be visible. That always happens with discrete time
sampling.

The interesting question is then, how is it possible to recover the
original waveform? This is basically done with sinc interpolation. You
can try it yourself in GNU Radio by using the "Rational Resampler" block
(for example) to interpolate your ugly triangular-ish waveform so that
you get many points per cycle. You'll see a pretty sine wave of the
correct frequency.

Now the interesting part comes when you set your frequency higher than
samp_rate/2. As long as you're generating a sine wave, you'll also get a
pretty sine wave when you interpolate. However, the frequency of this
sine wave will no longer be the "expected" one. In this way you can
demonstrate aliasing.

Hope this helps.

Best,

Dani.

--

Thanks,
James G Hayek

Youtube.com/JamesHayek

Re: Solved! - Re: USRP UHD Source problem

Hi

I effectively proposed Mike to remove the cache.json file, in case it
could help. As I thought this was probably not the solution I sent him a
private email and asked him to answer to the list in case of success.

So to resume; it appears that the problem originates from simply
upgrading GNURadio installed from PPA.

Question: should we fire an issue on Github? I think that this cache
problem should be solved by cleaning the cache each time GR is updated
or its version is changed (some users may also downgrade GR in some case)

Regards, Christophe


On 25/04/2021 15:06, Mike Markowski wrote:
> With thanks to Christophe for his excellent advice, removing
> ~/.cache/grc_gnuradio/cache.json fixed things up.  After needing to do
> this now & then, I have a new gr heuristic:
>
>   if (weirdnessReigns) { delete cache.json; }
>
> Thanks, Christophe!
>
> Mike
>
> On 4/24/21 2:55 PM, Mike Markowski wrote:
>> Some progress.  When I log in as another user, gr runs fine with a
>> usrp.   Logging in as me, I get the errors previously posted.  My
>> environment seems to (suddenly) be the issue, so I:
>>
>> 1. Moved ~/.bashrc to a new name to avoid any improper env var settings.
>>
>> 2. Moved ~/.config/GNU\ RADIO
>>
>> But I still get errors previously posted.  Are there other files
>> gnuradio-companion is looking at that could be the culprit?
>>
>> Thanks,
>> Mike
>>
>> On 4/24/21 1:04 PM, Mike Markowski wrote:
>>> Thanks for checking, Christophe.  I agree that it's strange.  I've
>>> been away from gnuradio doing some cyclostationary work, so haven't
>>> touched any flowgraphs in weeks.  I see that my newest flowgraphs
>>> were built April 7 and that gnuradio-companion, no doubt after an
>>> Ubuntu upgrade, shows a date of April 9.
>>>
>>> I'll share debugging breakthroughs, but would be glad to hear from
>>> others if your GR 3.8.1.0 is or isn't running fine.  Most likely,
>>> it's my environment since I don't see a flurry of 'me too' notes.
>>>
>>> Mike
>>>
>>> On 4/24/21 12:16 PM, Christophe Seguinot wrote:
>>>> This flowgraph is correctly build under GR 3.9.0.0 (no USRP source
>>>> to test further)
>>>>
>>>> The error is quite strange, I think there is no "len_tag_name"
>>>> parameter in such a simple flowgraph
>>>>
>>>> On 24/04/2021 16:35, Mike Markowski wrote:
>>>>> I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
>>>>> 2020.10.  After a few weeks away from gnuradio, today I get errors
>>>>> with the USRP UHD Source, and previously working flowgraphs no
>>>>> longer build. (Previously built flowgraph python files still run
>>>>> fine.)  The attached flowgraph doesn't get much simpler, but
>>>>> building yields:
>>>>>
>>>>> Generating: '/home/mm/sdr/fm/uhdTest.py'
>>>>> Generate Error: (NameError("'len_tag_name' is not defined"),
>>>>> 'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n
>>>>> uhd.stream_args(\n cpu_format="${type}",\n
>>>>>
>>>>> [... on and on ...]
>>>>>
>>>>> , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n%
>>>>> endif\n')
>>>>> >>> Failure
>>>>> Traceback (most recent call last):
>>>>>   File "memory:0x7f3082ab36d0", line 136, in render_body
>>>>>   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106,
>>>>> in __getitem__
>>>>>     return compat_builtins.__dict__[key]
>>>>> KeyError: 'len_tag_name'
>>>>>
>>>>> [... still more...]
>>>>>
>>>>> Is anyone else seeing this error?
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>
>

Passing a "Tag Value" to "Multiply by Tag Value" block

Hello GNURadio Community:

In my GRC signal flowgraph, I would like to make use of a complex value computed down stream to multiply upstream input values. Gnuradio has a "Multiply by Tag Value" block which I think would work wonderfully, if I knew how to use it. 

I am building an OOT downstream block that takes in a complex input stream and outputs a complex output stream. In addition, this OOT block runs an algorithm to determine if an upstream block needs to have its input values multiplied by different run time complex values, which is where the  "Multiply by Tag Value" block would come in handy. The output data from the OOT block does not need tagging (will be fine as long as the upstream multiplication value is good). How do I create in the OOT a complex tag value which the upstream multiplication block can read? 

Thanks for the help.

Regards,

George 

Re: Nyquist Rate & Distortion, A Visual Example: Issues

El 25/4/21 a las 18:42, James Hayek escribió:
> Apologies if I missed any response from my prior thread.
> I wanted to elaborate more here, on what I am attempting to do.
>
> The goal is to create a GRC file to show how sampling rates affect a
> generated signal. Knowing, for real samples, fs (sampling rate,
> "samp_rate) would be greater than twice that of the highest
> bandwidth (f, "freq"), I created a flow graph where one can adjust
the
> frequency whilst keeping the sampling rate constant.
>
> I would have imagined (since fs > 2B) for any frequency I set past
> 1/2*fs, I would see distortion, and anything less would yield accurate
> results.
>
> I created two sine wave Signal Sources. One where the _sample rate_ was

> set to freq*2 and the _frequency_ was set to an adjustable variable, freq.
>
> The other where the _sample rate_ was set to a fixed samp_rate and the
> _frequency_ was set to the same adjustable variable, freq.
>
> Both signals output to a QT GUI Time SInk. When I run the program, I see
> the signal using a sampling rate of freq*2 is distorted
> (triangular waveform) and the signal with the fixed sampling rate
> distorts past a frequency of 1K Hz. I have the sampling rate to 32KSps.

> Wouldn't it distort around 16KHz? What have I set up incorrectly?

Hi James,

Your results are perfectly fine. Nyquist theorem tells us that if we
sample at a rate higher than 2*freq, then _it is possible_ to recover
the original waveform. That's it. A key ingredient that sometimes is
forgotten is the _it is possible_.

What Nyquist doesn't say is that if you sample at a rate higher than
2*freq and join your samples with straight lines, then the result will
look like a sine wave. Think about it, if you have very few samples per
cycle of the sine wave, then you'll get something just like the
triangular-ish wave you see. In order to have a very nice sine wave you
need to have many, many points per cycle. And even so, if you zoom all
the way in, the fact that you have a bunch of samples joined with
straight lines will be visible. That always happens with discrete time
sampling.

The interesting question is then, how is it possible to recover the
original waveform? This is basically done with sinc interpolation. You
can try it yourself in GNU Radio by using the "Rational Resampler" block
(for example) to interpolate your ugly triangular-ish waveform so that
you get many points per cycle. You'll see a pretty sine wave of the
correct frequency.

Now the interesting part comes when you set your frequency higher than
samp_rate/2. As long as you're generating a sine wave, you'll also get a
pretty sine wave when you interpolate. However, the frequency of this
sine wave will no longer be the "expected" one. In this way you can
demonstrate aliasing.

Hope this helps.

Best,

Dani.

Nyquist Rate & Distortion, A Visual Example: Issues

Apologies if I missed any response from my prior thread. 

I wanted to elaborate more here, on what I am attempting to do.

The goal is to create a GRC file to show how sampling rates affect a generated signal. Knowing, for real samples, fs (sampling rate, "samp_rate) would be greater than twice that of the highest bandwidth (f, "freq"), I created a flow graph where one can adjust the frequency whilst keeping the sampling rate constant.

I would have imagined (since fs > 2B) for any frequency I set past 1/2*fs, I would see distortion, and anything less would yield accurate results.

I created two sine wave Signal Sources. One where the sample rate was set to freq*2 and the frequency was set to an adjustable variable, freq.

The other where the sample rate was set to a fixed samp_rate and the frequency was set to the same adjustable variable, freq.

Both signals output to a QT GUI Time SInk. When I run the program, I see the signal using a sampling rate of freq*2 is distorted (triangular waveform) and the signal with the fixed sampling rate distorts past a frequency of 1K Hz. I have the sampling rate to 32KSps. Wouldn't it distort around 16KHz? What have I set up incorrectly?

.GRC file attached. Thanks in advance! 

--

Thanks,
James G Hayek

Youtube.com/JamesHayek

Solved! - Re: USRP UHD Source problem

With thanks to Christophe for his excellent advice, removing
~/.cache/grc_gnuradio/cache.json fixed things up. After needing to do
this now & then, I have a new gr heuristic:

if (weirdnessReigns) { delete cache.json; }

Thanks, Christophe!

Mike

On 4/24/21 2:55 PM, Mike Markowski wrote:
> Some progress.  When I log in as another user, gr runs fine with a usrp.
>  Logging in as me, I get the errors previously posted.  My environment
> seems to (suddenly) be the issue, so I:
>
> 1. Moved ~/.bashrc to a new name to avoid any improper env var settings.
>
> 2. Moved ~/.config/GNU\ RADIO
>
> But I still get errors previously posted.  Are there other files
> gnuradio-companion is looking at that could be the culprit?
>
> Thanks,
> Mike
>
> On 4/24/21 1:04 PM, Mike Markowski wrote:
>> Thanks for checking, Christophe.  I agree that it's strange.  I've
>> been away from gnuradio doing some cyclostationary work, so haven't
>> touched any flowgraphs in weeks.  I see that my newest flowgraphs were
>> built April 7 and that gnuradio-companion, no doubt after an Ubuntu
>> upgrade, shows a date of April 9.
>>
>> I'll share debugging breakthroughs, but would be glad to hear from
>> others if your GR 3.8.1.0 is or isn't running fine.  Most likely, it's
>> my environment since I don't see a flurry of 'me too' notes.
>>
>> Mike
>>
>> On 4/24/21 12:16 PM, Christophe Seguinot wrote:
>>> This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to
>>> test further)
>>>
>>> The error is quite strange, I think there is no "len_tag_name"
>>> parameter in such a simple flowgraph
>>>
>>> On 24/04/2021 16:35, Mike Markowski wrote:
>>>> I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
>>>> 2020.10.  After a few weeks away from gnuradio, today I get errors
>>>> with the USRP UHD Source, and previously working flowgraphs no
>>>> longer build. (Previously built flowgraph python files still run
>>>> fine.)  The attached flowgraph doesn't get much simpler, but
>>>> building yields:
>>>>
>>>> Generating: '/home/mm/sdr/fm/uhdTest.py'
>>>> Generate Error: (NameError("'len_tag_name' is not defined"),
>>>> 'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n
>>>> uhd.stream_args(\n        cpu_format="${type}",\n
>>>>
>>>> [... on and on ...]
>>>>
>>>> , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n%
>>>> endif\n')
>>>> >>> Failure
>>>> Traceback (most recent call last):
>>>>   File "memory:0x7f3082ab36d0", line 136, in render_body
>>>>   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106,
>>>> in __getitem__
>>>>     return compat_builtins.__dict__[key]
>>>> KeyError: 'len_tag_name'
>>>>
>>>> [... still more...]
>>>>
>>>> Is anyone else seeing this error?
>>>>
>>>> Thanks,
>>>> Mike
>>>

Re: USRP UHD Source problem

Some progress. When I log in as another user, gr runs fine with a usrp.
Logging in as me, I get the errors previously posted. My environment
seems to (suddenly) be the issue, so I:

1. Moved ~/.bashrc to a new name to avoid any improper env var settings.

2. Moved ~/.config/GNU\ RADIO

But I still get errors previously posted. Are there other files
gnuradio-companion is looking at that could be the culprit?

Thanks,
Mike

On 4/24/21 1:04 PM, Mike Markowski wrote:
> Thanks for checking, Christophe.  I agree that it's strange.  I've been
> away from gnuradio doing some cyclostationary work, so haven't touched
> any flowgraphs in weeks.  I see that my newest flowgraphs were built
> April 7 and that gnuradio-companion, no doubt after an Ubuntu upgrade,
> shows a date of April 9.
>
> I'll share debugging breakthroughs, but would be glad to hear from
> others if your GR 3.8.1.0 is or isn't running fine.  Most likely, it's
> my environment since I don't see a flurry of 'me too' notes.
>
> Mike
>
> On 4/24/21 12:16 PM, Christophe Seguinot wrote:
>> This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to
>> test further)
>>
>> The error is quite strange, I think there is no "len_tag_name"
>> parameter in such a simple flowgraph
>>
>> On 24/04/2021 16:35, Mike Markowski wrote:
>>> I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
>>> 2020.10.  After a few weeks away from gnuradio, today I get errors
>>> with the USRP UHD Source, and previously working flowgraphs no longer
>>> build. (Previously built flowgraph python files still run fine.)  The
>>> attached flowgraph doesn't get much simpler, but building yields:
>>>
>>> Generating: '/home/mm/sdr/fm/uhdTest.py'
>>> Generate Error: (NameError("'len_tag_name' is not defined"),
>>> 'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n
>>> uhd.stream_args(\n        cpu_format="${type}",\n
>>>
>>> [... on and on ...]
>>>
>>> , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
>>> >>> Failure
>>> Traceback (most recent call last):
>>>   File "memory:0x7f3082ab36d0", line 136, in render_body
>>>   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in
>>> __getitem__
>>>     return compat_builtins.__dict__[key]
>>> KeyError: 'len_tag_name'
>>>
>>> [... still more...]
>>>
>>> Is anyone else seeing this error?
>>>
>>> Thanks,
>>> Mike
>>

Re: USRP UHD Source problem

Thanks for checking, Christophe. I agree that it's strange. I've been
away from gnuradio doing some cyclostationary work, so haven't touched
any flowgraphs in weeks. I see that my newest flowgraphs were built
April 7 and that gnuradio-companion, no doubt after an Ubuntu upgrade,
shows a date of April 9.

I'll share debugging breakthroughs, but would be glad to hear from
others if your GR 3.8.1.0 is or isn't running fine. Most likely, it's
my environment since I don't see a flurry of 'me too' notes.

Mike

On 4/24/21 12:16 PM, Christophe Seguinot wrote:
> This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to
> test further)
>
> The error is quite strange, I think there is no "len_tag_name" parameter
> in such a simple flowgraph
>
> On 24/04/2021 16:35, Mike Markowski wrote:
>> I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
>> 2020.10.  After a few weeks away from gnuradio, today I get errors
>> with the USRP UHD Source, and previously working flowgraphs no longer
>> build. (Previously built flowgraph python files still run fine.)  The
>> attached flowgraph doesn't get much simpler, but building yields:
>>
>> Generating: '/home/mm/sdr/fm/uhdTest.py'
>> Generate Error: (NameError("'len_tag_name' is not defined"),
>> 'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n
>> uhd.stream_args(\n        cpu_format="${type}",\n
>>
>> [... on and on ...]
>>
>> , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
>> >>> Failure
>> Traceback (most recent call last):
>>   File "memory:0x7f3082ab36d0", line 136, in render_body
>>   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in
>> __getitem__
>>     return compat_builtins.__dict__[key]
>> KeyError: 'len_tag_name'
>>
>> [... still more...]
>>
>> Is anyone else seeing this error?
>>
>> Thanks,
>> Mike
>

Re: USRP UHD Source problem

This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to
test further)

The error is quite strange, I think there is no "len_tag_name" parameter
in such a simple flowgraph

On 24/04/2021 16:35, Mike Markowski wrote:
> I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
> 2020.10.  After a few weeks away from gnuradio, today I get errors
> with the USRP UHD Source, and previously working flowgraphs no longer
> build. (Previously built flowgraph python files still run fine.)  The
> attached flowgraph doesn't get much simpler, but building yields:
>
> Generating: '/home/mm/sdr/fm/uhdTest.py'
> Generate Error: (NameError("'len_tag_name' is not defined"),
> 'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n
> uhd.stream_args(\n        cpu_format="${type}",\n
>
> [... on and on ...]
>
> , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
> >>> Failure
> Traceback (most recent call last):
>   File "memory:0x7f3082ab36d0", line 136, in render_body
>   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in
> __getitem__
>     return compat_builtins.__dict__[key]
> KeyError: 'len_tag_name'
>
> [... still more...]
>
> Is anyone else seeing this error?
>
> Thanks,
> Mike

USRP UHD Source problem

I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu 2020.10.
After a few weeks away from gnuradio, today I get errors with the USRP
UHD Source, and previously working flowgraphs no longer build.
(Previously built flowgraph python files still run fine.) The attached
flowgraph doesn't get much simpler, but building yields:

Generating: '/home/mm/sdr/fm/uhdTest.py'
Generate Error: (NameError("'len_tag_name' is not defined"),
'uhd.usrp_source(\n ",".join((${dev_addr}, ${dev_args})),\n
uhd.stream_args(\n cpu_format="${type}",\n

[... on and on ...]

, uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
>>> Failure
Traceback (most recent call last):
File "memory:0x7f3082ab36d0", line 136, in render_body
File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in
__getitem__
return compat_builtins.__dict__[key]
KeyError: 'len_tag_name'

[... still more...]

Is anyone else seeing this error?

Thanks,
Mike

Re: Rust-lang

On Fri, Apr 23, 2021, 3:03 PM Derek Kozel <dkozel@gnuradio.org> wrote:

Hi Sam,

I started looking at using the CXX library for this, there's even a few CMake examples. My hope is to make a Rust block similar to the current embedded Python Block available in GRC. I've not made it to the point of even test code though. If you want to look further into this I'd be very interested.
https://cxx.rs

This is a good place to start, a few years ago I was able to build a simple rust block with cbindgen and a had some CMake rules that cleanly integrated into GNU Radio with cargo and everything. 

Today I would certainly use cxx to do the binding.

--Brennan 

Re: Rust-lang

My feeling is that it would be Herculean to take a framework 17 years in the making, and move to an entirely new language. 

Inevitably, there's be *years* of crossover time with people using both environments in the field. There's be pressure for back-ports and a general support headache. 

That said, I am an old fart. My son likes Python and is comfortable in C++ and has often said "hey dad, Rust is cool". But he also

loves 60s and 70s-era music :)

Sent from my iPhone

On Apr 23, 2021, at 6:03 PM, Derek Kozel <dkozel@gnuradio.org> wrote:

 Hi Sam,

I started looking at using the CXX library for this, there's even a few CMake examples. My hope is to make a Rust block similar to the current embedded Python Block available in GRC. I've not made it to the point of even test code though. If you want to look further into this I'd be very interested.
https://cxx.rs

There are no plans to port the core of GNU Radio to Rust, but Bastian Blossel has been doing some experiments around SDR runtimes in Rust.
https://github.com/bastibl/FutureSDR

There are bindings for UHD and the SOAPY SDR device API, but I haven't tried either.
https://github.com/samcrow/uhd-rust
https://github.com/kevinmehall/rust-soapysdr

Has anyone else looked or thought about this?

Cheers,
Derek

On 4/23/2021 8:53 PM, Carey, Samuel Craig via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote:

Howdy,

 

I've written GNU Radio blocks with C++ and Python in the past, but lately I've been transitioning to using Rust-lang for many of my other projects.

Does anyone know of any current Rust integration/porting/rewriting plans or efforts for GNU Radio (or other SDR frameworks)?

 

I'm really enjoying using Rust, so I'd really like to be able to use it for SDR applications.

 

Thanks,

Sam

Re: Rust-lang

Hi Sam,

I started looking at using the CXX library for this, there's even a few CMake examples. My hope is to make a Rust block similar to the current embedded Python Block available in GRC. I've not made it to the point of even test code though. If you want to look further into this I'd be very interested.
https://cxx.rs

There are no plans to port the core of GNU Radio to Rust, but Bastian Blossel has been doing some experiments around SDR runtimes in Rust.
https://github.com/bastibl/FutureSDR

There are bindings for UHD and the SOAPY SDR device API, but I haven't tried either.
https://github.com/samcrow/uhd-rust
https://github.com/kevinmehall/rust-soapysdr

Has anyone else looked or thought about this?

Cheers,
Derek

On 4/23/2021 8:53 PM, Carey, Samuel Craig via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote:

Howdy,

 

I've written GNU Radio blocks with C++ and Python in the past, but lately I've been transitioning to using Rust-lang for many of my other projects.

Does anyone know of any current Rust integration/porting/rewriting plans or efforts for GNU Radio (or other SDR frameworks)?

 

I'm really enjoying using Rust, so I'd really like to be able to use it for SDR applications.

 

Thanks,

Sam

Re: Windows 7 x64 problem...

Hi Alberto - this is the last release of python-2.x

  https://www.python.org/downloads/release/python-2718/

Since your problem doesn't appear to be  a gnuradio problem, you might
want to contact a python discussion group

   https://stackoverflow.com/questions/tagged/python

- or a Windows 7 group.

-- Cinaed

On 4/22/21 1:01 PM, Alberto wrote:
> No idea ?
>
>
>
> Inviato da iPhone
>
>> Il giorno 19 apr 2021, alle ore 17:55, Alberto <alberto_gnuradio@libero.it> ha scritto:
>>
>> Hi !
>> I have created a simple example to View 100MHz signal from sdr receiver...but i have a problem.
>>
>> My OS is Windows 7 x64, GNURadio 3.7.13.5.
>>
>> When i start a receiver with gnuradio an window error open:
>>
>> Pyton.exe has stop working
>>
>> Can you help me ?
>>
>> Alberto
>>
>> <image0.jpeg>
>>
>>
>> Inviato da iPhone
>

Rust-lang

Howdy,

 

I’ve written GNU Radio blocks with C++ and Python in the past, but lately I’ve been transitioning to using Rust-lang for many of my other projects.

Does anyone know of any current Rust integration/porting/rewriting plans or efforts for GNU Radio (or other SDR frameworks)?

 

I’m really enjoying using Rust, so I’d really like to be able to use it for SDR applications.

 

Thanks,

Sam

Re: GNU Radio 3.9 OOT derived class

Indeed, that was the error. Now everything works fine. Thank you very much for your help.

Regards,

Álvaro

El vie, 23 abr 2021 a las 10:27, Vasil Velichkov (<vvvelichkov@gmail.com>) escribió:

Hi Alvaro,

On 23/04/2021 02.43, Alvaro Pendas Recondo wrote:
> The source code is available here https://github.com/apruhd/gr-TFMv3

You have two find_package(Gnuradio "3.9" ...) in your CMakeLists.txt - lines 77 and 177

https://github.com/apruhd/gr-TFMv3/blob/master/CMakeLists.txt#L77
https://github.com/apruhd/gr-TFMv3/blob/master/CMakeLists.txt#L177

You need to add the required components (digital, blocks, analog, ...) on line 77 and delete line 177

Regards,
Vasil

Re: FFT MARKER

Hello Alberto,

No, no one has implemented markers for the QT GUIs. We have mentors willing to help anyone interested in improving the GUIs, but no one has started coding. We also have a Google Summer of Code project idea listed for this, but no students have applied for it.

Here's the summary of that project proposal, in case anyone is interested.

QT Widgets Improvements:

The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.
This project is cleanly divided into several sub-projects:

• Add new widgets
  • Compass display (e.g. for direction-finding applications)
  • MPEG display (e.g. for video demod output)
  • Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)

• Improve current widgets
  • Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets
  • More Control Panels on other widgets (follow lead on the frequency sink)
  • Improve UI, make more intuitive, more power to mouse users
  • Set trigger point with mouse

• Integration / Support for QT Creator
  • QML design
  • Allow to build full GUI applications from, say, GRC

Prerequisites

• Familiarity with QT is essential.
• Widgets are written in C+, so some C+ knowledge is also required.
• Python skills are highly useful.

On 4/22/2021 12:31 PM, Alberto Alletto wrote:

Hi!  There is a mode to make an Marker on FFT signal as spectrum analyzer instruments ?    Alberto  Inviato da iPhone    

Re: GNU Radio 3.9 OOT derived class

Hi Alvaro,

On 23/04/2021 02.43, Alvaro Pendas Recondo wrote:
> The source code is available here https://github.com/apruhd/gr-TFMv3

You have two find_package(Gnuradio "3.9" ...) in your CMakeLists.txt - lines 77 and 177

https://github.com/apruhd/gr-TFMv3/blob/master/CMakeLists.txt#L77
https://github.com/apruhd/gr-TFMv3/blob/master/CMakeLists.txt#L177

You need to add the required components (digital, blocks, analog, ...) on line 77 and delete line 177

Regards,
Vasil

Re: Windows 7 x64 problem...

Hi Alberto,

Since your error is "Python.exe stopped working", it might be a Python
issue. Besides, Windows 7's time has run out for over a year. Further,
you use GR 3.7 and Python 2. Again, Python 2's time has run out for over
a year. Please update your system.

GR is supposed to run on supported platforms but MS does not support W7
anymore. Thus, GR might or might not run on it.

As far as GR is concerned, there are conda packages to install newer GR
versions. I recommend GR 3.9.

You should never use a Throttle and a Hardware block (your osmocom
source). This might cause issues.

Please don't send pictures of your screen, use screenshots. Even better:
don't send screenshots but copy and paste the error message.

Cheers
Johannes

On 22.04.21 22:01, Alberto wrote:
> No idea ?
>
>
>
> Inviato da iPhone
>
>> Il giorno 19 apr 2021, alle ore 17:55, Alberto <alberto_gnuradio@libero.it> ha scritto:
>>
>> Hi !
>> I have created a simple example to View 100MHz signal from sdr receiver...but i have a problem.
>>
>> My OS is Windows 7 x64, GNURadio 3.7.13.5.
>>
>> When i start a receiver with gnuradio an window error open:
>>
>> Pyton.exe has stop working
>>
>> Can you help me ?
>>
>> Alberto
>>
>> <image0.jpeg>
>>
>>
>> Inviato da iPhone
>
>

Re: GNU Radio 3.9 OOT derived class

I'd suggest starting over with modtool. There are a number of directories in your code that should not be there (e.g., gnuradio-runtime, gr-fec, gr-fft, gr-blocks, ...). Something went wrong in the process of getting all this set up.

On Thu, Apr 22, 2021 at 7:45 PM Alvaro Pendas Recondo <apruhd@gmail.com> wrote:

I've tried with no result. The full output is

-- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Found LOG4CPP: /usr/lib/x86_64-linux-gnu/liblog4cpp.so
-- Checking for module 'gmp'
--   Found gmp, version 6.2.0
-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so  
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so  
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.71.0") found components: date_time program_options filesystem system regex thread unit_test_framework
-- Found Volk: Volk::volk  
-- User set python executable /usr/bin/python3
-- Found PythonInterp: /usr/bin/python3 (found version "3.8.5")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found suitable exact version "3.8.5")
-- Found Git: /usr/bin/git  
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found components: doxygen missing components: dot
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so
-- Using install prefix: /usr/local
-- Building for version: v1.0-compat-xxx-xunknown / 1.0.0git
-- No C++ unit tests... skipping
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - found
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- LTO enabled
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
-- Checking for module 'sndfile'
--   Found sndfile, version 1.0.28
-- Found SNDFILE: /usr/lib/x86_64-linux-gnu/libsndfile.so  
-- Checking for module 'fftw3f >= 3.0'
--   Found fftw3f , version 3.3.8
-- Found FFTW3f: /usr/lib/x86_64-linux-gnu/libfftw3f.so  
-- Configuring done
CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-digital" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-analog" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-blocks" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-fft" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-filter" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-digital" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-analog" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-blocks" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-fft" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library):
  Target "TFMv3_python" links to target "gnuradio::gnuradio-filter" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /usr/local/lib/cmake/gnuradio/GrPybind.cmake:243 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-digital" but
  the target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-analog" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-blocks" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-fft" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-filter" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-digital" but
  the target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-analog" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-blocks" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-fft" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?


CMake Error at lib/CMakeLists.txt:26 (add_library):
  Target "gnuradio-TFMv3" links to target "gnuradio::gnuradio-filter" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

The source code is available here https://github.com/apruhd/gr-TFMv3

Thank you for your time,

Álvaro

El jue, 22 abr 2021 a las 18:30, Vasil Velichkov (<vvvelichkov@gmail.com>) escribió:

Hi Alvaro,

On 22/04/2021 19.02, Alvaro Pendas Recondo wrote:
> Thank you for your answer. Should not be Gnuradio "3.9" instead of "3.9"?.

Yes, use the version you are developing for.

> Anyway, I tried with both options and I got the same error:
>
> Target "TFMv3_python" links to target "gnuradio::gnuradio-digital" but the
>   target was not found.  Perhaps a find_package() call is missing for an
>   IMPORTED target, or an ALIAS target is missing?

Try deleting the build directory (or at least delete CMakeCache.txt file), re-run cmake again and provide the full output.

Can you share the whole source code? As a github repo for example.

Regards,
Vasil