Re: SoapySDR Question

Hi Jeff,

Thanks for your quick reply.

I was having trouble figuring out what to put in the Soapy Source block.
Do you have a flow graph example?

Thanks

Glen

In the mean time I'll try pybombs


> On Sep 30, 2021, at 9:11 PM, Jeff Long <willcode4@gmail.com> wrote:
>
> I installed gr-soapy for 3.8 (using PyBOMBS), plugged in a RSP1A, and it worked. This is the LibreSpace code, as we don't have in-tree Soapy support in 3.8.
>
> I'd already installed the soapy libs (v0.8.1-g1cf5a539) and driver modules, also via PyBOMBS. Make sure it's not a soapy or usb problem by running
>
> SoapySDRUtil --probe
>
> My test was just a Soapy Source connected to a QT GUI Sink. Sample rate is 1M, and so is the bandwidth in the Soapy Source on the RF tab. Don't know if that matters. Everything else is defaults.
>
> On Thu, Sep 30, 2021 at 8:46 PM Glen Langston <glen.i.langston@gmail.com> wrote:
> Thanks for all everyone's efforts.
>
> We hope to give them a try.
>
> I've got a Soapy SDR question. Does anyone have a SDRPlay RSP1A running
> with Gnuradio 3.8. I've not been able to find a running example.
>
> Please send a link, if you've got a good example.
>
> Thanks!
>
> Glen
>
> For our successes in Radio Astronomy work see the memos at
> https://github.com/WVURAIL/lightwork
>
>
> > On Sep 30, 2021, at 7:39 PM, Jeff Long <willcode4@gmail.com> wrote:
> >
> > GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target date with hours to spare. For details, see the Github release pages:
> >
> > https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> > https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
> >
> > Next releases are expected in December.
>

Re: SoapySDR Question

I installed gr-soapy for 3.8 (using PyBOMBS), plugged in a RSP1A, and it worked. This is the LibreSpace code, as we don't have in-tree Soapy support in 3.8.

I'd already installed the soapy libs (v0.8.1-g1cf5a539) and driver modules, also via PyBOMBS. Make sure it's not a soapy or usb problem by running

  SoapySDRUtil --probe

My test was just a Soapy Source connected to a QT GUI Sink. Sample rate is 1M, and so is the bandwidth in the Soapy Source on the RF tab. Don't know if that matters. Everything else is defaults.

On Thu, Sep 30, 2021 at 8:46 PM Glen Langston <glen.i.langston@gmail.com> wrote:

Thanks for all everyone's efforts.   

We hope to give them a try.

I've got a Soapy SDR question.   Does anyone have a SDRPlay RSP1A running
with Gnuradio 3.8.  I've not been able to find a running example.

Please send a link, if you've got a good example.

Thanks!

Glen

For our successes in Radio Astronomy work see the memos at
https://github.com/WVURAIL/lightwork


> On Sep 30, 2021, at 7:39 PM, Jeff Long <willcode4@gmail.com> wrote:
>
> GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target date with hours to spare. For details, see the Github release pages:
>
> https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
>
> Next releases are expected in December.

Re: Releases v3.8.4.0 and v3.9.3.0

Thanks for all everyone's efforts.

We hope to give them a try.

I've got a Soapy SDR question. Does anyone have a SDRPlay RSP1A running
with Gnuradio 3.8. I've not been able to find a running example.

Please send a link, if you've got a good example.

Thanks!

Glen

For our successes in Radio Astronomy work see the memos at
https://github.com/WVURAIL/lightwork


> On Sep 30, 2021, at 7:39 PM, Jeff Long <willcode4@gmail.com> wrote:
>
> GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target date with hours to spare. For details, see the Github release pages:
>
> https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
>
> Next releases are expected in December.

Re: VectorSourceBlock-GRC

Hello

Thank you for your replies. It works!

Regards

Isaac T.

El jue, 30 sept 2021 a las 3:11, Cyrille Morin (<cyrille.morin@insa-lyon.fr>) escribió:

Hello Isaac,

Adding a delay block set to at least 24 could indeed allow you to see your square signal.
But you can also solve the cause of the issue:
By default, the time sink I assume you are using, is set to display 1024 samples at a time. So it waits for that amount of samples before plotting anything. In your case, you are generating only 1000 samples, so the time sink is stuck waiting for the last 24.
The delay block, as part of its operation, starts by outputting samples with 0s according to its delay setting, so you can create the 24 you are missing that way.
You can also set your time sink to display just 1000 samples, and you should see just what you generated.

Hope that was clear,
Cyrille

Le 30 septembre 2021 08:36:34 GMT+02:00, "dominik.walach" <dominik.walach@pekasat.com> a écrit :

Hello Isaac,

The solution is quite simple, just add a delay block to the flowgraph (see the attachment). Vector Source pushes all the samples at the beginning faster than Time Sink can even display it.

Best,

Dominik

Od "Discuss-gnuradio" discuss-gnuradio-bounces+dominik.walach=pekasat.com@gnu.org

Komu discuss-gnuradio@gnu.org

Kopie

Datum Wed, 29 Sep 2021 17:25:04 -0500

Předmět VectorSourceBlock-GRC

Hello

I'm Isaac. I'm trying to produce a 1KHz square signal for only one period. So I decided to do it with the vector source block (500 ones and 500 zeros). But when I run it with the option repeat = No, I only see zero. When I put repeat=yes, I see the square but continuous, not only one period.

¿What am I missing? Any help or advice is welcomed.

Regards

Isaac T.

Cyrille Morin

Releases v3.8.4.0 and v3.9.3.0

GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target date with hours to spare. For details, see the Github release pages:

https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0

https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0

Next releases are expected in December.

Macports GRC on M1 Mac

I noticed that Macports py-gobject3 was recently updated. GRC no longer crashes on M1 Mac with the Macports install of gnuradio. I'm still having some other issues, but glad there is progress. Are there other M1 Mac owners running gnuradio?

Royce

Re: re-synchronize data transmission when parameter changes

Hi Wei,

On 30.09.21 12:04, Huang Wei wrote:
> Hi Marcus,
>
> Thank you very much for the detailed explanation. 
> Basically, in my case, the two repeat blocks will be connected to two USRPs separately,
> and they are operated through two PCs. So sharing one repeat block might not be very
> practical.

ah, ok. That's really a very different problem.

> My thought was, when you first execute the transmission, the two channels are synchronized
> until you change the repetition factor in the two repeat blocks. Is it possible that each
> time the repetition factor changes, the whole flowgraphs restart just like I click the
> execute button at the beginning, then they are synchronized again?

No, because the timing of the restart would be random.

Best regards,
Marcus

Re: re-synchronize data transmission when parameter changes

Hi Marcus,

Thank you very much for the detailed explanation. 

Basically, in my case, the two repeat blocks will be connected to two USRPs separately, and they are operated through two PCs. So sharing one repeat block might not be very practical.

My thought was, when you first execute the transmission, the two channels are synchronized until you change the repetition factor in the two repeat blocks. Is it possible that each time the repetition factor changes, the whole flowgraphs restart just like I click the execute button at the beginning, then they are synchronized again? (it could be better still keeping the USRPs synchronized, but could do it again after restart)

I tried stop(), wait(), start() and lock(), unlock() commands in the top_block, but seems they are not for that purpose. If the flowgraphs is not killed and execute again, the buffers are not flushed, so not exactly as restart the whole flowgraph.

Could it be feasible in Gnuradio doing what I thought?

Thank you and best regards,

Wei

Marcus Müller <mueller@kit.edu> 于2021年9月29日周三 下午6:15写道：

Hi Wei,

it sounds to me like a bit of an "esoteric" use to adjust the number of
repetitions at runtime for a transmission, but that should not stop you!

Not all things can work, though:

 >  For example, by asking the two repeat blocks always
 > process the same amount of samples,

No, that's not how GNU Radio works!

 > or each time I change the
 > parameters, the two file sources re-transmit the file from the beginning
 > simultaneously?

That wouldn't solve the fact that the repetition factor of your two
"Repeat" blocks aren't set synchronously.

Instead:
If you want, you can:

Stream A -->|Streams to|               |Vector to|--->
Stream B -->|  Vector  |--->|repeat|-->| Streams |--->

By far the most elegant way would be if you wrote your own C++ repeat
block that has an arbitrary number (instead of just 1) input (and the
same number of outputs). Then, you could avoid the "Streams to vector"
and "vector to streams" trickery.

Best regards,
Marcus

On 29/09/2021 18.10, Huang Wei wrote:
> Hello everyone,
>
> I am testing the transmission of the same signal in parallel through two
> repeat blocks (see attached flowgraph). The repeat times of both repeat
> blocks are set by the same GUI range from 2 to 10.
> When I start running the flowgraph, the two output signals are exactly
> the same as expected. But when I change the repeat times from the GUI
> range, the two signals are not synchronized anymore (see attached signal
> plot).
>
> I am wondering, is there a way to keep the two signals always
> synchronized? For example, by asking the two repeat blocks always
> process the same amount of samples, or each time I change the
> parameters, the two file sources re-transmit the file from the beginning
> simultaneously?
>
> I am doing this because I want to transmit the signals simultaneously
> through two synchronized USRPs, and I don't want the mis-match of the
> signals due to changing the parameter in the repeat blocks every time.
>
> Appreciate if someone could help me!
>
> Regards,
> Wei
>

Re:VectorSourceBlock-GRC

Hello Isaac,

Adding a delay block set to at least 24 could indeed allow you to see your square signal.
But you can also solve the cause of the issue:
By default, the time sink I assume you are using, is set to display 1024 samples at a time. So it waits for that amount of samples before plotting anything. In your case, you are generating only 1000 samples, so the time sink is stuck waiting for the last 24.
The delay block, as part of its operation, starts by outputting samples with 0s according to its delay setting, so you can create the 24 you are missing that way.
You can also set your time sink to display just 1000 samples, and you should see just what you generated.

Hope that was clear,
Cyrille

Le 30 septembre 2021 08:36:34 GMT+02:00, "dominik.walach" <dominik.walach@pekasat.com> a écrit :

Hello Isaac,

The solution is quite simple, just add a delay block to the flowgraph (see the attachment). Vector Source pushes all the samples at the beginning faster than Time Sink can even display it.

Best,

Dominik

Od "Discuss-gnuradio" discuss-gnuradio-bounces+dominik.walach=pekasat.com@gnu.org

Komu discuss-gnuradio@gnu.org

Kopie

Datum Wed, 29 Sep 2021 17:25:04 -0500

Předmět VectorSourceBlock-GRC

Hello

I'm Isaac. I'm trying to produce a 1KHz square signal for only one period. So I decided to do it with the vector source block (500 ones and 500 zeros). But when I run it with the option repeat = No, I only see zero. When I put repeat=yes, I see the square but continuous, not only one period.

¿What am I missing? Any help or advice is welcomed.

Regards

Isaac T.

Cyrille Morin

Re: re-synchronize data transmission when parameter changes

Because hacktoberfest is upon us: Made this a formal feature request, with quite a lot of
instructions on how to implement it

https://github.com/gnuradio/gnuradio/issues/5113

On 29.09.21 19:11, Marcus Müller wrote:
> Hi Wei,
>
> it sounds to me like a bit of an "esoteric" use to adjust the number of repetitions at
> runtime for a transmission, but that should not stop you!
>
> Not all things can work, though:
>
>>  For example, by asking the two repeat blocks always
>> process the same amount of samples,
>
> No, that's not how GNU Radio works!
>
>> or each time I change the
>> parameters, the two file sources re-transmit the file from the beginning
>> simultaneously?
>
> That wouldn't solve the fact that the repetition factor of your two "Repeat" blocks aren't
> set synchronously.
>
> Instead:
> If you want, you can:
>
> Stream A -->|Streams to|               |Vector to|--->
> Stream B -->|  Vector  |--->|repeat|-->| Streams |--->
>
> By far the most elegant way would be if you wrote your own C++ repeat block that has an
> arbitrary number (instead of just 1) input (and the same number of outputs). Then, you
> could avoid the "Streams to vector" and "vector to streams" trickery.
>
> Best regards,
> Marcus
>
> On 29/09/2021 18.10, Huang Wei wrote:
>> Hello everyone,
>>
>> I am testing the transmission of the same signal in parallel through two repeat blocks
>> (see attached flowgraph). The repeat times of both repeat blocks are set by the same GUI
>> range from 2 to 10.
>> When I start running the flowgraph, the two output signals are exactly the same as
>> expected. But when I change the repeat times from the GUI range, the two signals are not
>> synchronized anymore (see attached signal plot).
>>
>> I am wondering, is there a way to keep the two signals always synchronized? For example,
>> by asking the two repeat blocks always process the same amount of samples, or each time
>> I change the parameters, the two file sources re-transmit the file from the beginning
>> simultaneously?
>>
>> I am doing this because I want to transmit the signals simultaneously through two
>> synchronized USRPs, and I don't want the mis-match of the signals due to changing the
>> parameter in the repeat blocks every time.
>>
>> Appreciate if someone could help me!
>>
>> Regards,
>> Wei
>>
>

Re: Completely blank flowgraph takes a minute to generate

Hi Jameson,

yep, and if it's not IO-bound, it's still a lot of YAML files to parse,
so it's really a nice mini-benchmark for your filesystem and python's
yaml implementation. By the way, which version of GNU Radio are you running?
If you want to have a look into what your OS is up to while you run
grcc, I'd run `sudo perf record -a -g grcc parameters...`

followed by `perf report`; it's not as useful to profile the Python side
of things, Johannes' method is the right one here, but in case you need
to know in which libc function or which kernel function you're stuck
most of the time: great tool!

Best regards,
Marcus

On 29/09/2021 14.04, Jameson Collins wrote:
> @Johannes, that's neat.  I'll give that a shot.
>
> @Marcus, I can't run GRC on the target as it doesn't have X.  I'm using
> grcc to generate the block, I should have mentioned that.  When you say
> IO-bound I'm guessing you mean because it's scanning the disk?  I
> haven't benchmarked this hardware yet, but the filesystem is a ram disk
> so I would expect it to be reasonably fast.  But this is something I can
> look into.
>
> Thanks
>
> On Wed, Sep 29, 2021 at 6:55 AM Marcus Müller <mmueller@gnuradio.org
> <mailto:mmueller@gnuradio.org>> wrote:
>
> But before going into too much depth, make sure the duration isn't just
> basically identical to clicking on the "reload block library" button,
> which is first IO-bound (which *can* take significant amount of CPU
> time
> on weaker ARMs) and then parsing-limited.
>
> Best Regards,
>
> Marcus
>
> On 9/29/21 11:21 AM, Johannes Demel wrote:
> > Hi,
> >
> > I used:
> > https://docs.python.org/3/library/profile.html#module-cProfile
> <https://docs.python.org/3/library/profile.html#module-cProfile>
> > in the past to locate the problematic lines of code.
> >
> > ```
> > import cProfile
> > import pstats
> >
> > with cProfile.Profile() as pr:
> >     run_the_problematic_function_etc()
> > stats = pstats.Stats(pr)
> > stats.sort_stats('cumtime').reverse_order()
> > stats.print_stats()
> > ```
> > You might want to adopt these lines for your use-case. I started at
> > the top-level of my application and then gradually moved the code
> to a
> > more fitting function.
> >
> > Cheers
> > Johannes
> >
> > On 28.09.21 23:40, Jameson Collins wrote:
> >> I have a completely blank flowgraph (well just the default
> 'Options'
> >> block).
> >>
> >> On my 8 core, 2 GHz, Intel based virtual machine this flowgraph
> >> generates in under a second.
> >>
> >> On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and
> >> completely maxes out 1 core while it's running.
> >>
> >> Why might cause this?  How might I troubleshoot it?
> >
>

Re: re-synchronize data transmission when parameter changes

Hi Wei,

it sounds to me like a bit of an "esoteric" use to adjust the number of
repetitions at runtime for a transmission, but that should not stop you!

Not all things can work, though:

> For example, by asking the two repeat blocks always
> process the same amount of samples,

No, that's not how GNU Radio works!

> or each time I change the
> parameters, the two file sources re-transmit the file from the beginning
> simultaneously?

That wouldn't solve the fact that the repetition factor of your two
"Repeat" blocks aren't set synchronously.

Instead:
If you want, you can:

Stream A -->|Streams to| |Vector to|--->
Stream B -->| Vector |--->|repeat|-->| Streams |--->

By far the most elegant way would be if you wrote your own C++ repeat
block that has an arbitrary number (instead of just 1) input (and the
same number of outputs). Then, you could avoid the "Streams to vector"
and "vector to streams" trickery.

Best regards,
Marcus

On 29/09/2021 18.10, Huang Wei wrote:
> Hello everyone,
>
> I am testing the transmission of the same signal in parallel through two
> repeat blocks (see attached flowgraph). The repeat times of both repeat
> blocks are set by the same GUI range from 2 to 10.
> When I start running the flowgraph, the two output signals are exactly
> the same as expected. But when I change the repeat times from the GUI
> range, the two signals are not synchronized anymore (see attached signal
> plot).
>
> I am wondering, is there a way to keep the two signals always
> synchronized? For example, by asking the two repeat blocks always
> process the same amount of samples, or each time I change the
> parameters, the two file sources re-transmit the file from the beginning
> simultaneously?
>
> I am doing this because I want to transmit the signals simultaneously
> through two synchronized USRPs, and I don't want the mis-match of the
> signals due to changing the parameter in the repeat blocks every time.
>
> Appreciate if someone could help me!
>
> Regards,
> Wei
>

re-synchronize data transmission when parameter changes

Hello everyone,

I am testing the transmission of the same signal in parallel through two repeat blocks (see attached flowgraph). The repeat times of both repeat blocks are set by the same GUI range from 2 to 10.

When I start running the flowgraph, the two output signals are exactly the same as expected. But when I change the repeat times from the GUI range, the two signals are not synchronized anymore (see attached signal plot).

I am wondering, is there a way to keep the two signals always synchronized? For example, by asking the two repeat blocks always process the same amount of samples, or each time I change the parameters, the two file sources re-transmit the file from the beginning simultaneously?

I am doing this because I want to transmit the signals simultaneously through two synchronized USRPs, and I don't want the mis-match of the signals due to changing the parameter in the repeat blocks every time.

Appreciate if someone could help me!

Regards,

Wei

Re: Completely blank flowgraph takes a minute to generate

@Johannes, that's neat.  I'll give that a shot.

@Marcus, I can't run GRC on the target as it doesn't have X.  I'm using grcc to generate the block, I should have mentioned that.  When you say IO-bound I'm guessing you mean because it's scanning the disk?  I haven't benchmarked this hardware yet, but the filesystem is a ram disk so I would expect it to be reasonably fast.  But this is something I can look into.

Thanks

On Wed, Sep 29, 2021 at 6:55 AM Marcus Müller <mmueller@gnuradio.org> wrote:

But before going into too much depth, make sure the duration isn't just
basically identical to clicking on the "reload block library" button,
which is first IO-bound (which *can* take significant amount of CPU time
on weaker ARMs) and then parsing-limited.

Best Regards,

Marcus

On 9/29/21 11:21 AM, Johannes Demel wrote:
> Hi,
>
> I used:
> https://docs.python.org/3/library/profile.html#module-cProfile
> in the past to locate the problematic lines of code.
>
> ```
> import cProfile
> import pstats
>
> with cProfile.Profile() as pr:
>     run_the_problematic_function_etc()
> stats = pstats.Stats(pr)
> stats.sort_stats('cumtime').reverse_order()
> stats.print_stats()
> ```
> You might want to adopt these lines for your use-case. I started at
> the top-level of my application and then gradually moved the code to a
> more fitting function.
>
> Cheers
> Johannes
>
> On 28.09.21 23:40, Jameson Collins wrote:
>> I have a completely blank flowgraph (well just the default 'Options'
>> block).
>>
>> On my 8 core, 2 GHz, Intel based virtual machine this flowgraph
>> generates in under a second.
>>
>> On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and
>> completely maxes out 1 core while it's running.
>>
>> Why might cause this?  How might I troubleshoot it?
>

Re: Completely blank flowgraph takes a minute to generate

But before going into too much depth, make sure the duration isn't just
basically identical to clicking on the "reload block library" button,
which is first IO-bound (which *can* take significant amount of CPU time
on weaker ARMs) and then parsing-limited.

Best Regards,

Marcus

On 9/29/21 11:21 AM, Johannes Demel wrote:
> Hi,
>
> I used:
> https://docs.python.org/3/library/profile.html#module-cProfile
> in the past to locate the problematic lines of code.
>
> ```
> import cProfile
> import pstats
>
> with cProfile.Profile() as pr:
>     run_the_problematic_function_etc()
> stats = pstats.Stats(pr)
> stats.sort_stats('cumtime').reverse_order()
> stats.print_stats()
> ```
> You might want to adopt these lines for your use-case. I started at
> the top-level of my application and then gradually moved the code to a
> more fitting function.
>
> Cheers
> Johannes
>
> On 28.09.21 23:40, Jameson Collins wrote:
>> I have a completely blank flowgraph (well just the default 'Options'
>> block).
>>
>> On my 8 core, 2 GHz, Intel based virtual machine this flowgraph
>> generates in under a second.
>>
>> On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and
>> completely maxes out 1 core while it's running.
>>
>> Why might cause this?  How might I troubleshoot it?
>

Re: Completely blank flowgraph takes a minute to generate

Hi,

I used:
https://docs.python.org/3/library/profile.html#module-cProfile
in the past to locate the problematic lines of code.

```
import cProfile
import pstats

with cProfile.Profile() as pr:
run_the_problematic_function_etc()
stats = pstats.Stats(pr)
stats.sort_stats('cumtime').reverse_order()
stats.print_stats()
```
You might want to adopt these lines for your use-case. I started at the
top-level of my application and then gradually moved the code to a more
fitting function.

Cheers
Johannes

On 28.09.21 23:40, Jameson Collins wrote:
> I have a completely blank flowgraph (well just the default 'Options' block).
>
> On my 8 core, 2 GHz, Intel based virtual machine this flowgraph
> generates in under a second.
>
> On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and
> completely maxes out 1 core while it's running.
>
> Why might cause this?  How might I troubleshoot it?

Completely blank flowgraph takes a minute to generate

I have a completely blank flowgraph (well just the default 'Options' block).

On my 8 core, 2 GHz, Intel based virtual machine this flowgraph generates in under a second.

On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and completely maxes out 1 core while it's running.

Why might cause this?  How might I troubleshoot it?

UHD 4.1.0.2 and 4.1.0.3 released!

Hello GNU Radio Community and friends of UHD,

In all the excitement of attending and presenting at last week's GNU Radio Conference 2021, I neglected to send out the announcement for these two releases. These releases have some late-breaking bugfixes for the NI Ettus USRP X410, USRP B2xx, and a few other friends/issues we met along the way.

UHD 4.1.0.3 Release
 * uhd
   - zbx: Prevent TX antenna config from disrupting RX

UHD 4.1.0.2 Release
 * b200
   - Fix overflow handling
 * fpga
   - Re-order error and data packets
   - Fix sc16 to sc12 converter
 * host
   - Add static_assert to prevent meta_range_t(0,0)
 * mpm
   - x4xx: update mboard_max_rev
 * mpmd
   - Add discoverable feature for trig i/o mode
 * sim
   - Update chdr_16sc_to_sc12 testbench
 * tests
   - Add recv(0) case to rx_streamer_test
 * uhd
   - transport: Avoid exceptions in disconnect_receiver()
   - streamer: Restore original recv(0) semantics
 * x4xx_bist
   - use get_mpm_client in gpio bist

With very best regards,
Aaron

[VOLK] Help us relicense VOLK under LGPLv3+

Dear contributors of VOLK,

we are writing to let you know that we are working towards a new major
release of VOLK. The possibly biggest change will be that we intend to
use a different license for this release: VOLK 3.0 shall be licensed
under the LGPL 3.0 (or later).
To do this effectively, we will need your help, should you agree. If you
are already aware of this effort and are in support, you can skip to
"What are you asking from contributors?" below, but we recommend you
read this letter in its entirety to make sure you understand our
intentions and process.


# Why are we doing this?

In retrospect, LGPL would probably have been the better choice for VOLK
from the get-go. The FSF recommendations on libraries states that "If
developers are already using an established alternative library released
under a nonfree license or a lax pushover license, then we recommend
using the GNU Lesser General Public License (LGPL)."
(https://www.gnu.org/licenses/license-recommendations.html).

We agree with this recommendation, and want to avoid VOLK being a SIMD
library exclusively used by GNU Radio (and a few others), while other
software packages rally behind other SIMD libraries, that are more
liberally licensed.

We could have chosen an even less restrictive license, but we are
believers in copyleft, and believe the LGPL strikes the right balance
between not restricting users in which types of software they may use
VOLK, and requiring users to continue upstreaming their modifications to
VOLK.


# How are we going to do this?

Relicensing codebases is a complex process, full of potential pitfalls.
To avoid any misconceptions, ambiguities, or legal issues, we have
decided to go for the nuclear option: We will delete all of VOLK, and
start from scratch, using the LGPL from the beginning of VOLK 3.0.
It would be a futile attempt to try and recreate the decades of work
that went into previous versions of VOLK without violating the VOLK 2.0
license. We are therefore asking all contributors to re-grant us
permission to include their code, previously submitted into VOLK
versions 1 and 2, into the newly licensed VOLK 3. The process for
contributors is simple (see below), but first, we want to explain how
this works.

For contributing to VOLK 2.0, most of you signed a CLA, granting the
copyright to the FSF. This CLA includes a paragraph stating that the FSF
grants back to the developer the rights to use their contributions as
they see fit.

We cannot copy code from VOLK 2.0, since that is GPL licensed. But we
can ask you to resubmit your contributions to VOLK 3.0, which is LGPL
licensed. And that's what we're asking you to do in this letter. The
process to do so is really simple and will be explained shortly.

Once your previous contributions are re-submitted, the copyright will
fall back onto the original authors.


# What's going to happen to VOLK 2? Will there be other changes in VOLK
3.0 other than the license change?

VOLK 2 will remain GPL-licensed. We may choose to continue supporting it
with bug fixes, but the main development focus will lie on VOLK 3 going
forward.

The roadmap for VOLK 3.0 is not yet fully laid out, but we are
considering making some API-breaking changes in VOLK 3 along with the
relicensing.
At the moment, we consider approaches to fix complex data type
incompatibilities between C and C++.


# What are you asking from contributors?

To grant us permission to use your contributions under the LGPL3 license
for VOLK 3.0, we ask that you sign the paragraph
[HERE](https://github.com/gnuradio/volk/blob/main/AUTHORS_RESUBMITTING_UNDER_LGPL_LICENSE.md).
You
can do this either by submitting a pull request against [THIS
FiLE](https://github.com/gnuradio/volk/blob/main/AUTHORS_RESUBMITTING_UNDER_LGPL_LICENSE.md).,
adding your name and email address as they appear in previous
commits. Alternatively, you can send us an email, in which you state
that you've read and understood the following paragraph, and we will add
your name on your behalf.

There is *no need to submit pull requests with your previous
submissions*. Once you have agreed to re-submit your code to VOLK 3, we
will pull your submissions out of git history and apply them to the VOLK
3 branch under the new license on your behalf.

Should you not wish to re-use your contributions for VOLK 3, we
understand and respect that, and will not include your code in future
versions of VOLK. For logistical purposes, it would be very helpful if
you still respond to this email and let us know about your decision, so
we can more easily track how many contributors are in agreement with
this change.


# Relicensing Agreement (this goes into the repo)
This statement goes into the commit message.

I, {contributor name}, hereby resubmit all my contributions to the VOLK
project and repository under the terms of the LGPL-3.0-or-later.
My GitHub handle is {github handle}.
My email addresses used for contributions are: {email address}, ... .

I hereby agree that contributions made by me in the past, to previous
versions of VOLK, may be re-used for inclusion in VOLK 3. I understand
that VOLK 3 will be relicensed under LGPL-3.0-or-later.

Thanks for your help and support!
Johannes

Re: CPFSK

El 22/9/21 a las 23:11, Andrew Thommesen escribió:
> Hi,
>
> CPFSK has been deprecated in latest gnuradio. What is the best approach to implement 4 level CPFSK using valid gnuradio blocks?

Hi,

Just a thought. What about using VCO (complex), feeding it as input the
appropriately scaled baseband waveform?

Best,

Daniel.

Re: Proper GMSK Decoding with the Viterbi Algorithm

Sylvain - I see a bunch of gr-gsm decoding blocks, which block were you referring to specifically? Thanks in advance

Patrick

> On Sep 18, 2021, at 5:19 PM, Sylvain Munaut <246tnt@gmail.com> wrote:
>
> Quick note that gr-gsm has a viterbi enabled GMSK demod block.
>
> Cheers,
>
> Sylvain

How to manipulate data with "channel model"？

,input,output
0,0j,(3.000007152557373+3.000007152557373j)
1,(1+1j),(4.000009536743164+4.000009536743164j)
2,(2+2j),(5.000011920928955+5.000011920928955j)
3,(3+3j),(6.000014305114746+6.000014305114746j)
4,(4+4j),(7.000016689300537+7.000016689300537j)
5,(5+5j),(8.000019073486328+8.000019073486328j)
6,(6+6j),(9.000020980834961+9.000020980834961j)
7,(7+7j),(10.00002384185791+10.00002384185791j)
8,(8+8j),(11.00002670288086+11.00002670288086j)
9,(9+9j),(12.000028610229492+12.000028610229492j)
10,(10+10j),(13.000030517578125+13.000030517578125j)
11,(11+11j),(14.000033378601074+14.000033378601074j)
12,(12+12j),(15.000036239624023+15.000036239624023j)
13,(13+13j),(16.000038146972656+16.000038146972656j)
14,(14+14j),(17.00004005432129+17.00004005432129j)
15,(15+15j),(18.000041961669922+18.000041961669922j)
16,(16+16j),(19.000045776367188+19.000045776367188j)
17,(17+17j),(20.00004768371582+20.00004768371582j)
18,(18+18j),(21.000049591064453+21.000049591064453j)
19,(19+19j),(22.00005340576172+22.00005340576172j)
20,(20+20j),(23.00005531311035+23.00005531311035j)
21,(21+21j),(24.000057220458984+24.000057220458984j)
22,(22+22j),(25.000059127807617+25.000059127807617j)
23,(23+23j),(26.00006103515625+26.00006103515625j)
24,(24+24j),(27.000064849853516+27.000064849853516j)
25,(25+25j),(28.00006675720215+28.00006675720215j)
26,(26+26j),(29.00006866455078+29.00006866455078j)
27,(27+27j),(30.000072479248047+30.000072479248047j)
28,(28+28j),(31.00007438659668+31.00007438659668j)
29,(29+29j),(32.00007629394531+32.00007629394531j)
30,(30+30j),(33.00008010864258+33.00008010864258j)
31,(31+31j),(34.00008010864258+34.00008010864258j)
32,(32+32j),(35.000083923339844+35.000083923339844j)
33,(33+33j),(36.000083923339844+36.000083923339844j)
34,(34+34j),(37.00008773803711+37.00008773803711j)
35,(35+35j),(38.000091552734375+38.000091552734375j)
36,(36+36j),(39.000091552734375+39.000091552734375j)
37,(37+37j),(40.00009536743164+40.00009536743164j)
38,(38+38j),(41.000099182128906+41.000099182128906j)
39,(39+39j),(42.000099182128906+42.000099182128906j)
40,(40+40j),(43.00010299682617+43.00010299682617j)
41,(41+41j),(44.00010681152344+44.00010681152344j)
42,(42+42j),(45.00010681152344+45.00010681152344j)
43,(43+43j),(46.0001106262207+46.0001106262207j)
44,(44+44j),(47.0001106262207+47.0001106262207j)
45,(45+45j),(48.00011444091797+48.00011444091797j)
46,(46+46j),(49.000118255615234+49.000118255615234j)
47,(47+47j),(50.000118255615234+50.000118255615234j)
48,(48+48j),(51.0001220703125+51.0001220703125j)
49,(49+49j),(52.0001220703125+52.0001220703125j)
50,(50+50j),(53.000125885009766+53.000125885009766j)
51,(51+51j),(54.00012969970703+54.00012969970703j)
52,(52+52j),(55.00012969970703+55.00012969970703j)
53,(53+53j),(56.0001335144043+56.0001335144043j)
54,(54+54j),(57.00013732910156+57.00013732910156j)
55,(55+55j),(58.00013732910156+58.00013732910156j)
56,(56+56j),(59.00014114379883+59.00014114379883j)
57,(57+57j),(60.000144958496094+60.000144958496094j)
58,(58+58j),(61.000144958496094+61.000144958496094j)
59,(59+59j),(62.00014877319336+62.00014877319336j)
60,(60+60j),(63.00014877319336+63.00014877319336j)
61,(61+61j),(64.00015258789062+64.00015258789062j)
62,(62+62j),(65.00015258789062+65.00015258789062j)
63,(63+63j),(66.00016021728516+66.00016021728516j)
64,(64+64j),(67.00016021728516+67.00016021728516j)
65,(65+65j),(68.00016021728516+68.00016021728516j)
66,(66+66j),(69.00016784667969+69.00016784667969j)
67,(67+67j),(70.00016784667969+70.00016784667969j)
68,(68+68j),(71.00016784667969+71.00016784667969j)
69,(69+69j),(72.00016784667969+72.00016784667969j)
70,(70+70j),(73.00017547607422+73.00017547607422j)
71,(71+71j),(74.00017547607422+74.00017547607422j)
72,(72+72j),(75.00017547607422+75.00017547607422j)
73,(73+73j),(76.00018310546875+76.00018310546875j)
74,(74+74j),(77.00018310546875+77.00018310546875j)
75,(75+75j),(78.00018310546875+78.00018310546875j)
76,(76+76j),(79.00019073486328+79.00019073486328j)
77,(77+77j),(80.00019073486328+80.00019073486328j)
78,(78+78j),(81.00019073486328+81.00019073486328j)
79,(79+79j),(82.00019836425781+82.00019836425781j)
80,(80+80j),(83.00019836425781+83.00019836425781j)
81,(81+81j),(84.00019836425781+84.00019836425781j)
82,(82+82j),(85.00020599365234+85.00020599365234j)
83,(83+83j),(86.00020599365234+86.00020599365234j)
84,(84+84j),(87.00020599365234+87.00020599365234j)
85,(85+85j),(88.00021362304688+88.00021362304688j)
86,(86+86j),(89.00021362304688+89.00021362304688j)
87,(87+87j),(90.00021362304688+90.00021362304688j)
88,(88+88j),(91.00021362304688+91.00021362304688j)
89,(89+89j),(92.0002212524414+92.0002212524414j)
90,(90+90j),(93.0002212524414+93.0002212524414j)
91,(91+91j),(94.0002212524414+94.0002212524414j)
92,(92+92j),(95.00022888183594+95.00022888183594j)
93,(93+93j),(96.00022888183594+96.00022888183594j)
94,(94+94j),(97.00022888183594+97.00022888183594j)
95,(95+95j),(98.00023651123047+98.00023651123047j)
96,(96+96j),(99.00023651123047+99.00023651123047j)
97,(97+97j),(100.00023651123047+100.00023651123047j)
98,(98+98j),(101.000244140625+101.000244140625j)
99,(99+99j),(102.000244140625+102.000244140625j)
100,(100+100j),(103.000244140625+103.000244140625j)
101,(101+101j),(104.000244140625+104.000244140625j)
102,(102+102j),(105.00025177001953+105.00025177001953j)
103,(103+103j),(106.00025177001953+106.00025177001953j)
104,(104+104j),(107.00025177001953+107.00025177001953j)
105,(105+105j),(108.00025939941406+108.00025939941406j)
106,(106+106j),(109.00025939941406+109.00025939941406j)
107,(107+107j),(110.00025939941406+110.00025939941406j)
108,(108+108j),(111.0002670288086+111.0002670288086j)
109,(109+109j),(112.0002670288086+112.0002670288086j)
110,(110+110j),(113.0002670288086+113.0002670288086j)
111,(111+111j),(114.00027465820312+114.00027465820312j)
112,(112+112j),(115.00027465820312+115.00027465820312j)
113,(113+113j),(116.00027465820312+116.00027465820312j)
114,(114+114j),(117.00028228759766+117.00028228759766j)
115,(115+115j),(118.00028228759766+118.00028228759766j)
116,(116+116j),(119.00028228759766+119.00028228759766j)
117,(117+117j),(120.00028991699219+120.00028991699219j)
118,(118+118j),(121.00028991699219+121.00028991699219j)
119,(119+119j),(122.00028991699219+122.00028991699219j)
120,(120+120j),(123.00028991699219+123.00028991699219j)
121,(121+121j),(124.00029754638672+124.00029754638672j)
122,(122+122j),(125.00029754638672+125.00029754638672j)
123,(123+123j),(126.00029754638672+126.00029754638672j)
124,(124+124j),(127.00030517578125+127.00030517578125j)
125,(125+125j),(128.00030517578125+128.00030517578125j)
126,(126+126j),(129.00030517578125+129.00030517578125j)
127,(127+127j),(130.00030517578125+130.00030517578125j)
128,(128+128j),(131.00030517578125+131.00030517578125j)
129,(129+129j),(132.0003204345703+132.0003204345703j)
130,(130+130j),(133.0003204345703+133.0003204345703j)
131,(131+131j),(134.0003204345703+134.0003204345703j)
132,(132+132j),(135.0003204345703+135.0003204345703j)
133,(133+133j),(136.0003204345703+136.0003204345703j)
134,(134+134j),(137.0003204345703+137.0003204345703j)
135,(135+135j),(138.00033569335938+138.00033569335938j)
136,(136+136j),(139.00033569335938+139.00033569335938j)
137,(137+137j),(140.00033569335938+140.00033569335938j)
138,(138+138j),(141.00033569335938+141.00033569335938j)
139,(139+139j),(142.00033569335938+142.00033569335938j)
140,(140+140j),(143.00033569335938+143.00033569335938j)
141,(141+141j),(144.00033569335938+144.00033569335938j)
142,(142+142j),(145.00035095214844+145.00035095214844j)
143,(143+143j),(146.00035095214844+146.00035095214844j)
144,(144+144j),(147.00035095214844+147.00035095214844j)
145,(145+145j),(148.00035095214844+148.00035095214844j)
146,(146+146j),(149.00035095214844+149.00035095214844j)
147,(147+147j),(150.00035095214844+150.00035095214844j)
148,(148+148j),(151.0003662109375+151.0003662109375j)
149,(149+149j),(152.0003662109375+152.0003662109375j)
150,(150+150j),(153.0003662109375+153.0003662109375j)
151,(151+151j),(154.0003662109375+154.0003662109375j)
152,(152+152j),(155.0003662109375+155.0003662109375j)
153,(153+153j),(156.0003662109375+156.0003662109375j)
154,(154+154j),(157.00038146972656+157.00038146972656j)
155,(155+155j),(158.00038146972656+158.00038146972656j)
156,(156+156j),(159.00038146972656+159.00038146972656j)
157,(157+157j),(160.00038146972656+160.00038146972656j)
158,(158+158j),(161.00038146972656+161.00038146972656j)
159,(159+159j),(162.00038146972656+162.00038146972656j)
160,(160+160j),(163.00038146972656+163.00038146972656j)
161,(161+161j),(164.00039672851562+164.00039672851562j)
162,(162+162j),(165.00039672851562+165.00039672851562j)
163,(163+163j),(166.00039672851562+166.00039672851562j)
164,(164+164j),(167.00039672851562+167.00039672851562j)
165,(165+165j),(168.00039672851562+168.00039672851562j)
166,(166+166j),(169.00039672851562+169.00039672851562j)
167,(167+167j),(170.0004119873047+170.0004119873047j)
168,(168+168j),(171.0004119873047+171.0004119873047j)
169,(169+169j),(172.0004119873047+172.0004119873047j)
170,(170+170j),(173.0004119873047+173.0004119873047j)
171,(171+171j),(174.0004119873047+174.0004119873047j)
172,(172+172j),(175.0004119873047+175.0004119873047j)
173,(173+173j),(176.00042724609375+176.00042724609375j)
174,(174+174j),(177.00042724609375+177.00042724609375j)
175,(175+175j),(178.00042724609375+178.00042724609375j)
176,(176+176j),(179.00042724609375+179.00042724609375j)
177,(177+177j),(180.00042724609375+180.00042724609375j)
178,(178+178j),(181.00042724609375+181.00042724609375j)
179,(179+179j),(182.00042724609375+182.00042724609375j)
180,(180+180j),(183.0004425048828+183.0004425048828j)
181,(181+181j),(184.0004425048828+184.0004425048828j)
182,(182+182j),(185.0004425048828+185.0004425048828j)
183,(183+183j),(186.0004425048828+186.0004425048828j)
184,(184+184j),(187.0004425048828+187.0004425048828j)
185,(185+185j),(188.0004425048828+188.0004425048828j)
186,(186+186j),(189.00045776367188+189.00045776367188j)
187,(187+187j),(190.00045776367188+190.00045776367188j)
188,(188+188j),(191.00045776367188+191.00045776367188j)
189,(189+189j),(192.00045776367188+192.00045776367188j)
190,(190+190j),(193.00045776367188+193.00045776367188j)
191,(191+191j),(194.00045776367188+194.00045776367188j)
192,(192+192j),0j
193,(193+193j),0j
194,(194+194j),0j
195,(195+195j),0j
196,(196+196j),0j
197,(197+197j),0j
198,(198+198j),0j
199,(199+199j),0j
200,0j,0j
201,0j,0j
202,0j,0j
203,0j,0j
204,0j,0j
205,0j,0j
206,0j,0j
207,0j,0j
208,0j,0j
209,0j,0j
210,0j,0j
211,0j,0j
212,0j,0j
213,0j,0j
214,0j,0j
215,0j,0j
216,0j,0j
217,0j,0j
218,0j,0j
219,0j,0j
220,0j,0j
221,0j,0j

Hi,guys!

I am testing the "channel model" module, and I have created the following flow diagram:

As shown in the flow diagram, I set up a signal source to input the "channel model" as (0,1,2,3,...,198,199), a total of two hundred numbers, but I check the "channel model" However, the output becomes a bunch of other numbers (3.00001+3.0000052i,...), a total of 192, which is 8 less than the input.（Please refer to attachment） I have some problems here:

First: The noise voltage, time offset, frequency offset, and multipath of my channel model do not exist (everything is the default). In theory, there is no noise at all, so why are the input and output signals different?

Second: Why is the number of inputs and outputs different? Does the "channel model" itself perform certain operations on the input?

Can someone explain it to me? thanks.

thirdly:How can I avoid this situation? Because I have to receive all these input signals to perform subsequent operations, and cannot discard any data（or delay）, I checked the previous mailing lists and found similar problems, but I did not find a good solution,maybe i should set taps?

Sincerely

CPFSK

Hi,

CPFSK has been deprecated in latest gnuradio. What is the best approach to implement 4 level CPFSK using valid gnuradio blocks?

Thanks,

John

CPFSK

Hi,

CPFSK has been deprecated in latest gnuradio. What is the best approach to implement 4 level CPFSK using valid gnuradio blocks?

Thanks,

John

Re: Can i some one explain what's appllication of subdev in UHD?

On 2021-09-22 9:01 a.m., sp h wrote:
> Can i some one explain what's appllication of subdev in UHD?
> How work i should with subdev....
> what's means in UHD?
> what's difference it with channel in UHD.........
>
> -- Using subdev spec 'A:AB A:BA B:0'.
> Jamming hardware initialized...
> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
> built-in sink types: uhd hackrf bladerf soapy redpitaya freesrp file
> -- Using subdev spec 'A:AB B:0'.
>
https://files.ettus.com/manual/page_configuration.html

version 3.8, ofdm, adalpm pluto data transfer

1- I couldn't transmit any data (text,picture or serial data) with gnuradio 3.8 version

2- If possible; How can I do it with OFDM modulation? 

I would be very grateful for any help 

p.s: 2 file example; how can i combine these two files

--

Özkan SEZER

Virus-free. www.avast.com

Can i some one explain what's appllication of subdev in UHD?

Can i some one explain what's appllication of subdev in UHD?
How work i should with subdev....
what's means in UHD?
what's difference it with channel in UHD.........

-- Using subdev spec 'A:AB A:BA B:0'.
Jamming hardware initialized...
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
built-in sink types: uhd hackrf bladerf soapy redpitaya freesrp file
-- Using subdev spec 'A:AB B:0'.

Re: RFNOC timeout error failure to create rfnoc_graph

On 2021-09-22 8:28 a.m., یک نفر wrote:
> When i used USRP x300 with sample rate 30M, some times i faced with
> below error...i want to know what's means this error in USRP...
>
> RFNOC timeout error failure to create rfnoc_graph
>
> thank in advance
>
Two points here:

30Msps is NOT a valid sample rate for the X300 series--it must be a
fraction of either of the two valid master clock rates--200MHz or 184.32MHz.

What version of UHD are you using?

RFNOC timeout error failure to create rfnoc_graph

When i used USRP x300 with sample rate 30M, some times i faced with
below error...i want to know what's means this error in USRP...

RFNOC timeout error failure to create rfnoc_graph

thank in advance

GRC C++ block parameter value can't be changed

Hello group,

I am very new in writing C++ blocks. I just followed GNU Radio tutorials to write a sync block. I simply used a parameter "double value", so the output = input * value.

The block works. However, if I use a GUI range to change the parameter "value" during running of GRC, the output doesn't change accordingly, the "value" remains the same as the default value in GUI range. Did I miss something in the block?

Please find the source code in the attached file, I appreciate it very much if you could help me figure out the problem.

Regards,

Wei

How to manipulate data with "channel model"？

Hi,guys!

I am testing the "channel model" module, and I have created the following flow diagram:

As shown in the flow diagram, I set up a signal source to input the "channel model" as (0,1,2,3,...,198,199), a total of two hundred numbers, but I check the "channel model" However, the output becomes a bunch of other numbers (3.00001+3.0000052i,...), a total of 192, which is 8 less than the input. I have two problems here:

First: The noise voltage, time offset, frequency offset, and multipath of my channel model do not exist (everything is the default). In theory, there is no noise at all, so why are the input and output signals different?

Second: Why is the number of inputs and outputs different? Does the "channel model" itself perform certain operations on the input?

Can someone explain it to me? thanks.

Sincerely

Re: why when i use gnuradio for USRP with UHD for high sample rate record file is not work

Ok, thank you. Guides are very useful.

On Tue, Sep 21, 2021 at 4:56 PM Jim Melton <jim.melton@sncorp.com> wrote:

The issue is that you can't write to disk as fast as your samples are coming in. This is a fundamental limitation of recording high rate data.

 

---

Jim Melton

Principal Software Engineer

 

From: Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> On Behalf Of ?? ???
Sent: Tuesday, September 21, 2021 07:40
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] why when i use gnuradio for USRP with UHD for high sample rate record file is not work

 

I use a USRP x300, when i want to use uhd and file sink in gnuradio , for high sample rate like 60M or 80M gnuradio can not record file.Gnuradio print some character on log: i want to record a sample not any other thing.
Is there any way that i can record with high sample rate in gnuradio?

my system is powerful:
Core i7
RAM 16
OOOOOOOOOOOOOO

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

Fwd: why when i use gnuradio for USRP with UHD for high sample rate record file is not work

Sorry, meant to send this to the list. 

@(^.^)@ Ed

Sent from my iPhone

Begin forwarded message:

From: Ed Criscuolo <ed@chessie.com>
Date: September 21, 2021 at 11:23:24 AM EDT
To: Marcus D Leech <patchvonbraun@gmail.com>
Subject: Re: why when i use gnuradio for USRP with UHD for high sample rate record file is not work

Since the X300 creates 16-bit samples, converting the complex float
samples into complex integer samples would reduce this to 4 bytes
per sample.  A 60 msps stream would then require only 240Mbyte/sec
disk write speed.   And if you can stand the loss in sampling
resolution,  going down to 8-bit samples by using complex short samples
would further reduce this to 120MBytes/sec.

@(^.^)@  Ed



On 9/21/21 10:45 AM, Marcus D Leech wrote:

Well if you're recording complex float samples, that's 8 bytes each. At

60msps that's 480Mbyte/second. Not too many disk subsystems can keep up

at that rate.

You might try short recordings into a RAM disk filesystem.

Sent from my iPhone

On Sep 21, 2021, at 10:42 AM, یک نفر <stackprogramer@gmail.com> wrote:



I use a USRP x300, when i want to use uhd and file sink in gnuradio ,

for high sample rate like 60M or 80M gnuradio can not record

file.Gnuradio print some character on log: i want to record a sample

not any other thing.

Is there any way that i can record with high sample rate in gnuradio?

my system is powerful:

Core i7

RAM 16

|OOOOOOOOOOOOOO|

RE: why when i use gnuradio for USRP with UHD for high sample rate record file is not work

The issue is that you can't write to disk as fast as your samples are coming in. This is a fundamental limitation of recording high rate data.

 

---

Jim Melton

Principal Software Engineer

 

From: Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> On Behalf Of ?? ???
Sent: Tuesday, September 21, 2021 07:40
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] why when i use gnuradio for USRP with UHD for high sample rate record file is not work

 

I use a USRP x300, when i want to use uhd and file sink in gnuradio , for high sample rate like 60M or 80M gnuradio can not record file.Gnuradio print some character on log: i want to record a sample not any other thing.
Is there any way that i can record with high sample rate in gnuradio?

my system is powerful:
Core i7
RAM 16
OOOOOOOOOOOOOO

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

Re: why when i use gnuradio for USRP with UHD for high sample rate record file is not work

Well if you're recording complex float samples, that's 8 bytes each. At 60msps that's 480Mbyte/second. Not too many disk subsystems can keep up at that rate. 

You might try short recordings into a RAM disk filesystem. 

Sent from my iPhone

On Sep 21, 2021, at 10:42 AM, یک نفر <stackprogramer@gmail.com> wrote:



I use a USRP x300, when i want to use uhd and file sink in gnuradio , for high sample rate like 60M or 80M gnuradio can not record file.Gnuradio print some character on log: i want to record a sample not any other thing.
Is there any way that i can record with high sample rate in gnuradio?

my system is powerful:
Core i7
RAM 16
OOOOOOOOOOOOOO

why when i use gnuradio for USRP with UHD for high sample rate record file is not work

I use a USRP x300, when i want to use uhd and file sink in gnuradio , for high sample rate like 60M or 80M gnuradio can not record file.Gnuradio print some character on log: i want to record a sample not any other thing.
Is there any way that i can record with high sample rate in gnuradio?

my system is powerful:
Core i7
RAM 16
OOOOOOOOOOOOOO

Re: Error when opening flowgraph unless a specific unused block is enabled

It's an error in grc. The block 'Modulate vector' is not proper
evaluated. Just open and close the block 'Modulate vector' in the
property editor then you get the error message :


Value "digital.modulate_vector_bc(mod.to_basic_block(), data, taps)"
cannot be evaluated:
'NoneType' object has no attribute 'to_basic_block'


I think there is an error in the digital_modulate_vector.block.yml
definition.
Probably line 16 in this file

value: ${ digital.modulate_vector_bc(mod.to_basic_block(), data, taps) }

should be removed.

-- Volker
Am 20.09.21 um 21:54 schrieb Jameson Collins:
> I am trying  to make my own version of packet_rx.grc.  I copied the
> flowgraph and began modifying it.  I found that at some point  I started
> getting this error when I open the flowgraph:
>
> ERROR:gnuradio.grc.core.FlowGraph:Failed to evaluate variable block
> modulated_sync_word
> Traceback (most recent call last):
>   File
> "/home/user/git/toolbox/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/grc/core/FlowGraph.py",
> line 268, in renew_namespace
>     value = eval(variable_block.value, namespace, variable_block.namespace)
>   File "<string>", line 1, in <module>
> AttributeError: 'NoneType' object has no attribute 'to_basic_block'
> ERROR:gnuradio.grc.core.FlowGraph:Failed to evaluate variable block
> modulated_sync_word
> Traceback (most recent call last):
>   File
> "/home/user/git/toolbox/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/grc/core/FlowGraph.py",
> line 268, in renew_namespace
>     value = eval(variable_block.value, namespace, variable_block.namespace)
>   File "<string>", line 1, in <module>
> AttributeError: 'NoneType' object has no attribute 'to_basic_block'
>
> I traced the problem back to whether or not the preamble variables are
> enabled in the flowgraph.  However, it doesn't matter whether these
> variables are actually used anywhere.  They simply need to exist
> otherwise this error occurs.
>
> Please see the attached grc file.  It has the minimum number of blocks
> to reproduce the error.  If the 3 disabled blocks are instead enabled
> then the error will not occur.

Error when opening flowgraph unless a specific unused block is enabled

I am trying  to make my own version of packet_rx.grc.  I copied the flowgraph and began modifying it.  I found that at some point  I started getting this error when I open the flowgraph:

ERROR:gnuradio.grc.core.FlowGraph:Failed to evaluate variable block modulated_sync_word
Traceback (most recent call last):
  File "/home/user/git/toolbox/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/grc/core/FlowGraph.py", line 268, in renew_namespace
    value = eval(variable_block.value, namespace, variable_block.namespace)
  File "<string>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'to_basic_block'
ERROR:gnuradio.grc.core.FlowGraph:Failed to evaluate variable block modulated_sync_word
Traceback (most recent call last):
  File "/home/user/git/toolbox/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/grc/core/FlowGraph.py", line 268, in renew_namespace
    value = eval(variable_block.value, namespace, variable_block.namespace)
  File "<string>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'to_basic_block'

I traced the problem back to whether or not the preamble variables are enabled in the flowgraph.  However, it doesn't matter whether these variables are actually used anywhere.  They simply need to exist otherwise this error occurs.

Please see the attached grc file.  It has the minimum number of blocks to reproduce the error.  If the 3 disabled blocks are instead enabled then the error will not occur.

Re: Generate flowgraphs from command line

Hi Jameson,

On 20/09/2021 16.09, Jameson Collins wrote:
> Excellent, thanks Vasil.
>
> Do you know if there is a way to get this tool to output a hierarchical
> block to the local folder? It seems they always get generated to
> ${HOME}/.grc_gnuradio/


Have you tried specifing `--output` and/or `--user-lib-dir` parameters?

-o DIR, --output DIR Output directory for compiled program [default=.]
-u, --user-lib-dir Output to default hier_block library (overwrites -o)

Which gnuradio version do you use?

Regards,
Vasil

Re: Generate flowgraphs from command line

Excellent, thanks Vasil.

Do you know if there is a way to get this tool to output a hierarchical block to the local folder?  It seems they always get generated to ${HOME}/.grc_gnuradio/

On Mon, Sep 20, 2021 at 8:32 AM Vasil Velichkov <vvvelichkov@gmail.com> wrote:

Hi Jameson,

On 20/09/2021 15.23, Jameson Collins wrote:
> Is there a command line method of converting .grc files to .py files?

You can use `grcc` to compile/convert flowgraphs fom the command line.

$ grcc --help
usage: grcc [-h] [-o DIR] [-u] [-r] GRC_FILE [GRC_FILE ...]

Compile a GRC file (.grc) into a GNU Radio Python program and run it.

positional arguments:
  GRC_FILE              .grc file to compile

optional arguments:
  -h, --help            show this help message and exit
  -o DIR, --output DIR  Output directory for compiled program [default=.]
  -u, --user-lib-dir    Output to default hier_block library (overwrites -o)
  -r, --run             Run the program after compiling [default=False]


Regards,
Vasil

Re: Sync Problem with 256-QAM with USRP B2xx in GRC

Hi Leonhard,

a really short reply because I'm stuck with a lot of other things, but:

256-QAM is indeed not trivial to phase synchronize, and you're right - your usual Costas
loop will have a hard time! Remember that the Costas loop tries to "lock onto" the limited
amount of phases that exist in the "correct" constellation. For BPSK, QPSK, that's simple.
For 256-QAM, there's 32 constellation points in each of the eight symmetric (0, pi/4],
(pi/4, pi/2]... sectors... you end up with 192 different phases (python code [1]).

Now, there's still some *adaptive blind phase estimation* algorithms that you could look
into, but in all honesty: Things are hard!

You typically go for some data/preamble-aided method with higher-order QAMs: For example,
just send a known preamble, and correlate against that. If you send the same L-length
preamble twice with a known distance D between their beginnings (often, just one right
after the first), you can employ a fixed-lag correlation (i.e. just a dot-product between
a vector of L samples with another vector of L samples, taken D later). The phase of that
will depend on how much the phase of the second preamble has rotated compared to the first
– and a phase rotation that always happens over a fixed time, that's a frequency, so you
got your frequency estimation done that way.

From the correlation of the received preamble with the known transmit preamble, you get an
absolute phase.

Note that in wireless communications, there's not that many cases where you have 256-QAM,
but not some external structure that needs synchronization, anyway. Most commonly (LTE,
WiFi, DTV, DSL, …) you'll find QAM within OFDM – and for OFDM, there's clever
synchronization. Schmidl&Cox is an all-time favorite ;)

Cheers,
Marcus



[1]
#!/usr/bin/env python
from fractions import Fraction as ratio
import itertools

# Number of bits in QAM, N = 8 -> 256-QAM
N = 8

# make the inphase points; sqrt(2**N) of them, centered on 0, spaced 2
inphase_component = range(-(2**(N//2))+1, 2**(N//2), 2)

#Make all combinations of inphase and quadrature components.
const_points = itertools.product(inphase_component, inphase_component)

# Fraction "auto-cancels",
# so that we get a deduplicated set of slopes, equivalent to angles
# Notice that {...} is Python's way of building a set from a generator
slopes = { ratio(*point) for point in const_points }

# Need to double the length, because (-3/-2) = (3/2), but these have
# different phases
print(f"Number of different angles in {2**N}-QAM: {2 * len(slopes)}")


On 20.09.21 09:10, Röpfl, Leonhard wrote:
> Dear GNU Radio Community,
>
>
> since a couple of months i try to get a 256-QAM Transmission over Air to work.
>
>
> Now i reached a dead point, because i could not get the receiver locked on the phase of
> the QAM.
>
>
> 4-QAM is not a Problem, it works fine like it is described in the Tutorial.
>
>
> I have tried Polyphase Clock Sync, Costas Loop ect. (what ever i found under
> Synchronizers) in quite various combination,
>
> but this leads to nothing. 
>
>
> My guess is that Costas Loop is not working for higher QAM anyway.
>
>
> I did not find any description, how this could be done right, neither in the
> Internet (Google, Youtube) nor in the library of our
>
> University.
>
>
> Helpful would be:
>
>
> - a generic description or example how this is done
>
>
> - a reference one a book or paper which describe that (even if this book is expensive)  
>
>
> - link to an online-resource 
>
>
> Thanks in advance
>
>
> Best regards
>
>
> Leonhard
>
>
>
>
>
>

Re: Generate flowgraphs from command line

Hi Jameson,

On 20/09/2021 15.23, Jameson Collins wrote:
> Is there a command line method of converting .grc files to .py files?

You can use `grcc` to compile/convert flowgraphs fom the command line.

$ grcc --help
usage: grcc [-h] [-o DIR] [-u] [-r] GRC_FILE [GRC_FILE ...]

Compile a GRC file (.grc) into a GNU Radio Python program and run it.

positional arguments:
GRC_FILE .grc file to compile

optional arguments:
-h, --help show this help message and exit
-o DIR, --output DIR Output directory for compiled program [default=.]
-u, --user-lib-dir Output to default hier_block library (overwrites -o)
-r, --run Run the program after compiling [default=False]


Regards,
Vasil

Generate flowgraphs from command line

Is there a command line method of converting .grc files to .py files?

Sync Problem with 256-QAM with USRP B2xx in GRC

Dear GNU Radio Community,

since a couple of months i try to get a 256-QAM Transmission over Air to work.

Now i reached a dead point, because i could not get the receiver locked on the phase of the QAM.

4-QAM is not a Problem, it works fine like it is described in the Tutorial.

I have tried Polyphase Clock Sync, Costas Loop ect. (what ever i found under Synchronizers) in quite various combination,

but this leads to nothing. 

My guess is that Costas Loop is not working for higher QAM anyway.

I did not find any description, how this could be done right, neither in the Internet (Google, Youtube) nor in the library of our

University.

Helpful would be:

- a generic description or example how this is done

- a reference one a book or paper which describe that (even if this book is expensive)  

- link to an online-resource 

Thanks in advance

Best regards

Leonhard

Re: Proper GMSK Decoding with the Viterbi Algorithm

Quick note that gr-gsm has a viterbi enabled GMSK demod block.

Cheers,

Sylvain

Re: Proper GMSK Decoding with the Viterbi Algorithm

There aren't blocks in Gnuradio to do this out of the box, at least not on real signals. Unless you're working with low SNR signals, or the GMSK BT product is very low (under 0.25, let's say), it will be of somewhat limited benefit to use Viterbi decoding. Synchronization also becomes a limiting factor at these low SNRs: if you are working with short packets (like, say, AIS) you will have to use a data-aided estimator which operates on an entire packet since a normal bit-by-bit estimator will not converge fast enough, or accurately enough, at low SNR.

That said, a basic GMSK demodulator (without equalization, frequency offset correction, or Viterbi decoding) would look like this: AGC -> Symbol sync (use the D'Andrea and Mengali Gen MSK TED) -> Quadrature demod -> Binary slicer. At this point you have bits, and you can do what you like with them.

Nick

On Fri, Sep 17, 2021 at 4:04 PM <pwhines2@verizon.net> wrote:

Hello all,

 

I've been messing around with GNU Radio for the past couple of months, and I'm struggling to come up with a way to properly decode GMSK using the Viterbi algorithm.  The GMSK Demod block works just fine, but since the packet decoder block is deprecated I can't think of another way to get data out of the transmissions.  Basically I'm just looking for guidance in which blocks to use and what order to use them in, and I can handle the rest myself.  I've made a couple of flowgraphs that seem to be on to something, but I'm not really sure.  Any help would be appreciated.

 

Thanks,

Patrick

Proper GMSK Decoding with the Viterbi Algorithm

Hello all,

 

I’ve been messing around with GNU Radio for the past couple of months, and I’m struggling to come up with a way to properly decode GMSK using the Viterbi algorithm.  The GMSK Demod block works just fine, but since the packet decoder block is deprecated I can’t think of another way to get data out of the transmissions.  Basically I’m just looking for guidance in which blocks to use and what order to use them in, and I can handle the rest myself.  I’ve made a couple of flowgraphs that seem to be on to something, but I’m not really sure.  Any help would be appreciated.

 

Thanks,

Patrick

RE: Re: Re: Why does this dump core?

For the sake of the archives, the issue was virtual inheritance. See https://www.cprogramming.com/tutorial/virtual_inheritance.html

 

One thing to be aware of is that if either transmitter or receiver attempted to invoke the storable constructor in their initialization lists, that call will be completely skipped when constructing a radio object! Be careful, as this could cause a subtle bug!

 

Because the interface class virtually inherited from gr::block, then the impl must explicitly invoke the gr::block ctor with the desired arguments. Because it didn't, the default gr::block ctor was invoked. That ctor demonstrably instantiates an object where message_port_register_out dumps core. Whether that is desired behavior or not is another matter. In my case, it was failure to properly initialize a virtual base class.

---

Jim Melton

 

From: Jim Melton
Sent: Wednesday, September 15, 2021 16:38
To: 'Jeff Long' <willcode4@gmail.com>; GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: RE: [EXTERNAL] Re: Re: Why does this dump core?

 

I can't explain it, but I found what's wrong. My failing Test class that derives from gr::block called the default ctor. That's bad. If instead, Test calls the "real" ctor, with io_signature and everything, it works. Note that the example that derives from gr::sync_block does call the "real" ctor; if I use the default gr::sync_block ctor, it still fails.

 

I didn't think I was calling the default ctor, but apparently I was.

 

The interface class:

class CYBERRADIO_API vita_udp_rx : virtual public gr::block

{

…

protected:

    using gr::block::block; // "inherit" base class ctor

};

 

Since this interface doesn't really do anything, I thought I could just pass-through to the gr::block constructor(s).

 

 

The impl class:

class vita_udp_rx_impl : public vita_udp_rx

{

    using Base = vita_udp_rx;

…

};

 

 

The impl ctor:

vita_udp_rx_impl::vita_udp_rx_impl(Cfg const& cfg)

    : Base("vita_udp_rx",

           gr::io_signature::make(0, 0, 0),

           gr::io_signature::make(1, 1, sizeof(gr_complex))),

…

{

…

}

 

What this should do is pass through to the gr::block constructor. But it doesn't appear to do so. If instead, I write

vita_udp_rx_impl::vita_udp_rx_impl(Cfg const& cfg)

    : gr::block("vita_udp_rx",

           gr::io_signature::make(0, 0, 0),

           gr::io_signature::make(1, 1, sizeof(gr_complex))),

…

{

…

}

 

Then it works.

 

---

Jim Melton

 

From: Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> On Behalf Of Jeff Long
Sent: Wednesday, September 15, 2021 16:23
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [EXTERNAL] Re: Re: Why does this dump core?

 

The Message Strobe block:

 

  gr-blocks/include/gnuradio/blocks/message_strobe.h

  gr-blocks/lib/message_strobe_impl.h

  gr-blocks/lib/message_strobe_impl.cc

 

looks like the simplest builtin block that has a message out port. It subclasses gr::block, so that should work.

 

Instantiating gr::block directly, and on the stack, is not something I've tried. Your longer bit of code shows you're using sptrs.

 

 

On Wed, Sep 15, 2021 at 5:57 PM Jim Melton <jim.melton@sncorp.com> wrote:

If I derived from a different block, it doesn't crash:

 

class Test : public gr::sync_block

{

public:

Test();

int work(int, gr_vector_const_void_star&, gr_vector_void_star&) override { return 0;};

};

 

Test::Test() : gr::sync_block("test",

           gr::io_signature::make(0, 0, 0),

           gr::io_signature::make(1, 1, sizeof(gr_complex)))

{

}

 

---

Jim Melton

 

From: Jim Melton
Sent: Wednesday, September 15, 2021 14:57
To: 'Jeff Long' <willcode4@gmail.com>
Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: RE: [EXTERNAL] Re: Why does this dump core?

 

Simpler example. This still dumps core. Please explain what is wrong with the argument:

 

class Test : public gr::block

{

public:

Test();

};

 

Test::Test() : gr::block() {

message_port_register_out(pmt::mp("test"));

}

 

int main(int argc, char** argv)

{

Test test; // dumps core

Return 0;

}

 ---

Jim Melton

 

From: Jeff Long <willcode4@gmail.com>
Sent: Tuesday, September 14, 2021 14:10
To: Jim Melton <jim.melton@sncorp.com>
Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [EXTERNAL] Re: Why does this dump core?

 

gr::CyberRadio::vita_udp_rx_impl::vita_udp_rx_impl() is calling gr::basic_block::message_port_register_out() with a bad argument most likely.

 

On Tue, Sep 14, 2021 at 2:40 PM Jim Melton <jim.melton@sncorp.com> wrote:

As briefly discussed on IRC last night,  I am trying to modify someone else's block to be more robust (detect or eliminate packet drops). In the ctor, I call message_port_register_out() and it dumps core. The offending call is here: https://github.com/jwmelto/gr-cyberradio/blob/7b048a14f76b140f5cd3edd7d8dfa533e1f892a7/gr-CyberRadio/lib/vita_udp_rx_impl.cc#L427

 

The stack trace from the core is

#0  0x00007ffff4b04973 in pmt::is_pair(boost::shared_ptr<pmt::pmt_base> const&) () from /usr/local/lib64/libgnuradio-pmt.so.3.8.2

#1  0x00007ffff4b07328 in pmt::assv(boost::shared_ptr<pmt::pmt_base>, boost::shared_ptr<pmt::pmt_base>) () from /usr/local/lib64/libgnuradio-pmt.so.3.8.2

#2  0x00007ffff4b075fd in pmt::dict_has_key(boost::shared_ptr<pmt::pmt_base> const&, boost::shared_ptr<pmt::pmt_base> const&) () from /usr/local/lib64/libgnuradio-pmt.so.3.8.2

#3  0x00007ffff73b72e2 in gr::basic_block::message_port_register_out(boost::shared_ptr<pmt::pmt_base>) () from /usr/local/lib64/libgnuradio-runtime.so.3.8.2

#4  0x00007ffff7b58d73 in gr::CyberRadio::vita_udp_rx_impl::vita_udp_rx_impl (this=0x622800, cfg=..., __in_chrg=<optimized out>, __vtt_parm=<optimized out>)

    at /tmp/gr-cyberradio/gr-CyberRadio/lib/vita_udp_rx_impl.cc:427

#5  0x00007ffff7b56cb3 in gr::CyberRadio::vita_udp_rx::make (cfg=...) at /tmp/gr-cyberradio/gr-CyberRadio/lib/vita_udp_rx_impl.cc:111

#6  0x000000000040c51d in main (argc=1, argv=0x7fffffffdf18) at /usr/src/project/main.cc:23

 

My minimal test program is here:

#include <CyberRadio/vita_udp_rx.h>

#include <gnuradio/top_block.h>

#include <gnuradio/blocks/file_sink.h>

 

int main(int argc, char** argv)

{

gr::CyberRadio::vita_udp_rx::Cfg cfg;

 

cfg.src_ip = "192.168.110.10";

cfg.port = 8010;

cfg.header_byte_offset = 48;

cfg.samples_per_packet = 1024;

cfg.bytes_per_packet = 4152;

cfg.swap_bytes = true;

cfg.swap_iq = false;

cfg.tag_packets = true;

cfg.uses_v49_1 = false;

 

cfg.debug = true;

 

auto v49 = gr::CyberRadio::vita_udp_rx::make(cfg); // core dump

auto sink = gr::blocks::file_sink::make(sizeof(gr_complex), "test.dat");

 

auto top = gr::make_top_block("Test");

top->connect(v49, 0, sink, 0);

 

return 0;

}

 

According to all that I know, this should work. It clearly does not. I would appreciate any pointers on how to get past this roadblock.

---

Jim Melton

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