Re: Is there anything about USRP blocks that breaks them within hier blocks?

[Marcus D. Leech]

On 12/03/2019 09:40 PM, Lukas Haase wrote:

Hi,

Am I not supposed to put USRP blocks within a hierarchichal block and if so, 
why?

Very strange minimal example (Ettus USRP X310, Windows 10, gnuradio 3.7.13.5):

https://paste.pics/8a1cf2b2661fab2bc71b760e369997b9

Works and with a spectrum analyzer I see the tone at 916 MHz.

Then I do nothing more than putting the Signal Source and USRP Sink into a hier 
block and using it:

https://paste.pics/8c7c200035a083e218625360defc8015

https://paste.pics/bcd7969f3299f54e56b0d3ca210d97af

It's hard to believe but true: The spectrum analyzer stays silent! It doesn't 
output anything.

All messages on the console are same as well: The FPGA image gets loaded onto 
the USRP and it starts.
For a brief moment at startup, the spectrum analyzer shows a small tone at 
916MHz which disappears again.


Thanks,
Luke



Your gain is 0, that might have some bearing.   Also, you should see the 
main tone at 915M, because your baseband signal is at -1M.

Is there anything about USRP blocks that breaks them within hier blocks?

[Lukas Haase]

Hi,

Am I not supposed to put USRP blocks within a hierarchichal block and if so, 
why?

Very strange minimal example (Ettus USRP X310, Windows 10, gnuradio 3.7.13.5):

https://paste.pics/8a1cf2b2661fab2bc71b760e369997b9

Works and with a spectrum analyzer I see the tone at 916 MHz.

Then I do nothing more than putting the Signal Source and USRP Sink into a hier 
block and using it:

https://paste.pics/8c7c200035a083e218625360defc8015

https://paste.pics/bcd7969f3299f54e56b0d3ca210d97af

It's hard to believe but true: The spectrum analyzer stays silent! It doesn't 
output anything.

All messages on the console are same as well: The FPGA image gets loaded onto 
the USRP and it starts.
For a brief moment at startup, the spectrum analyzer shows a small tone at 
916MHz which disappears again.


Thanks,
Luke

Re: Stream args on UHD USRP Sink

[Marcus D. Leech]

On 12/03/2019 11:26 AM, Müller, Marcus (CEL) wrote:

U that's an ancient version of GNU Radio. Do you use any other UHD-
linking software, or can you try our new PPA that would give you a
modern GNU Radio 3.8.0.0?
host_extra_scaling
https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases

Anyway, for most USRPs "fullscale" actually should do some scaling (if
you're so inclined, look for "_host_extra_scaling" in the UHD source
code).

What is the USRP you're using?

Best regards,
Marcus

I looked at the code, and the "fullscale" operand is ONLY ever applied 
for sc8 wire-format.  For sc16, both "host_extra_scaling" and

  "dsp_extra_scaling" are set to 1.0 in the setup code.

This is what I had recalled from years ago looking at this.

Re: Stream args on UHD USRP Sink

[Wheberth Damascena Dias]

Yeah, You are right,

My initial thougth was, UHD already needs to scale whatever comes in to the
DAC range. If it could take in account this extra scaling I could save the
constant multiplier block.

Best Regards.

Em ter, 3 de dez de 2019 15:24, Müller, Marcus (CEL) 
escreveu:

> I'd recommend not overestimating the workload of scaling outside of UHD
> – UHD still has to do that multiplication! So, scaling e.g. your
> constellation or your pulse-shaping filter would make at least as much
> sense.
>
> On Tue, 2019-12-03 at 14:11 -0300, Wheberth Damascena Dias wrote:
> > Hi Marcus, I
> >
> > I am planning to give a try to the GnuRadio 3.8 PPA. We are developing
> some OOT blocks and some rework may be needed to do so.
> >
> > I will take a look at the code, but I am inclined to change my
> application to eliminate the need of scaling in real time (scalling the QAM
> symbols for example)
> >
> > Regarding the USRP I am using a pair of X310.
> >
> > Thank you very much.
> > Wheberth
> >
> >
> > Em ter, 3 de dez de 2019 13:26, Müller, Marcus (CEL) 
> escreveu:
> > > U that's an ancient version of GNU Radio. Do you use any other UHD-
> > > linking software, or can you try our new PPA that would give you a
> > > modern GNU Radio 3.8.0.0?
> > >
> > > https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases
> > >
> > > Anyway, for most USRPs "fullscale" actually should do some scaling (if
> > > you're so inclined, look for "_host_extra_scaling" in the UHD source
> > > code).
> > >
> > > What is the USRP you're using?
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:
> > > > Hi all, not sure if I should send this here or at USRP list.
> > > >
> > > > I am trying to set the "fullscale" as a stream parameter of the USRP
> Sink block, but it have no effect. The idea is to avoid the use aof one
> block to scale the samples to [-1.0, +1.0] range May I be missing something?
> > > >
> > > > For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All
> stock from Ubuntu 18.04).
> > > > Thank you very
> > > >
> > > >
> > > >
> > > > --
> > > > Wheberth Damascena Dias
> > > > ___ _ _ __ ___ __ _ _ _  _
> > > > http://www.linkedin.com/in/wheberth
> > > > e-mail:whebe...@gmail.com
> > > >
>

Re: Stream args on UHD USRP Sink

[Marcus D. Leech]

On 12/03/2019 01:24 PM, Müller, Marcus (CEL) wrote:

I'd recommend not overestimating the workload of scaling outside of UHD
– UHD still has to do that multiplication! So, scaling e.g. your
constellation or your pulse-shaping filter would make at least as much
sense.
Indeed, if your flow-graph is within a single multiply block of running 
out of CPU headroom, you need to reevaluate what

  you're doing.



On Tue, 2019-12-03 at 14:11 -0300, Wheberth Damascena Dias wrote:

Hi Marcus, I

I am planning to give a try to the GnuRadio 3.8 PPA. We are developing some OOT 
blocks and some rework may be needed to do so.

I will take a look at the code, but I am inclined to change my application to 
eliminate the need of scaling in real time (scalling the QAM symbols for 
example)

Regarding the USRP I am using a pair of X310.

Thank you very much.
Wheberth


Em ter, 3 de dez de 2019 13:26, Müller, Marcus (CEL)  escreveu:

U that's an ancient version of GNU Radio. Do you use any other UHD-
linking software, or can you try our new PPA that would give you a
modern GNU Radio 3.8.0.0?

https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases

Anyway, for most USRPs "fullscale" actually should do some scaling (if
you're so inclined, look for "_host_extra_scaling" in the UHD source
code).

What is the USRP you're using?

Best regards,
Marcus

On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:

Hi all, not sure if I should send this here or at USRP list.

I am trying to set the "fullscale" as a stream parameter of the USRP Sink 
block, but it have no effect. The idea is to avoid the use aof one block to scale the 
samples to [-1.0, +1.0] range May I be missing something?

For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from 
Ubuntu 18.04).
Thank you very



--
Wheberth Damascena Dias
___ _ _ __ ___ __ _ _ _  _
http://www.linkedin.com/in/wheberth
e-mail:whebe...@gmail.com

Re: Lunar Orbiting Platform Gateway

[Michelle Thompson]

Here are the slides from recent ARISS presentations at AMSAT Space
Symposium, and a paper presented at IAC about ARISS' view of amateur radio
on the Gateway project.

The IAC presentation can be downloaded from:
https://www.dropbox.com/s/73yhtpmo8nn5x46/IAC%20Gateway%2010-21-19%20Final.pptx?dl=0

Here are the slides about amateur radio for Gateway:

AMSAT BoD Presentation:
https://www.dropbox.com/s/tf65twlojkw4zce/ARISS-AMSAT%20BoD%202019.pptx?dl=0
Gateway Presentation given in the symposium:
https://www.dropbox.com/s/rkd6wfjeu5c4iie/Gateway-AREx%20AMSAT%20Symposium%202019.pptx?dl=0

Thank you to Frank Bauer for providing all of this content.

What can we do to support, extend, and enhance the effort to get open
source DSP framework content better represented in space through the
Gateway project?

-Michelle W5NYV



On Wed, Oct 30, 2019 at 11:57 AM John Malsbury 
wrote:

> And you mentioned something about amateur radio portions, Michelle?
>
> On Wed, Oct 30, 2019 at 11:52 AM Kevin K Gifford <
> kevin.giff...@colorado.edu> wrote:
>
>> Hi -
>>
>> I am involved in recommending the radio communications architecture for
>> Gateway which is baselined to utilize CCSDS (see cases.org) protocols.
>>
>> For long-haul RF links (Gateway to Earth) Unified Space Link Protocol
>> (USLP).
>>
>> For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS
>>
>> For proximity wireless networks (around Gateway and on lunar surface)
>> 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration.
>>
>> Please feel free to respond directly if additional information is needed
>> and I’ll strive to assist.
>>
>> Kevin
>> --
>> *From:* Discuss-gnuradio > colorado@gnu.org> on behalf of John Malsbury <
>> jmalsbury.perso...@gmail.com>
>> *Sent:* Wednesday, October 30, 2019 12:34 PM
>> *To:* Michelle Thompson 
>> *Cc:* discuss-gnuradio@gnu.org 
>> *Subject:* Re: Lunar Orbiting Platform Gateway
>>
>> It was a cheap joke on my part (and not at all commentary on the gateway
>> concept).  Disregard.
>>
>> I'd be down to collaborate on something open source.  Could you point to
>> publicly available documents that summarize the standards/specs?
>>
>> -John
>>
>> On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson <
>> mountain.miche...@gmail.com> wrote:
>>
>> I was hesitant to ask why, but I'm curious now.
>>
>> I know the Gateway is controversial. I understand there's a lot of doubt
>> it will actually happen. The heavy emphasis on commercial activity is
>> another aspect.
>>
>> However, I've been asked for help on a receiving station for the amateur
>> radio portions that might be included. There's a lot of overlap between
>> what I do and the type of communications proposed.
>>
>> Comment and critique would be very appreciated here.
>>
>> -Michelle W5NYV
>>
>>
>>
>>
>> On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) 
>> wrote:
>>
>> Hey John,
>>
>> > > Anyone working on…
>> > Definitely not
>>
>> Does that imply they're finished?
>>
>> Best regards,
>> Marcus
>>
>>

Re: gr_modtool crash

[CEL]

Yeah, packaging mishaps happen, and especially with Ubuntu/Canonical
mostly grazing uninvolvedly on Mait's effort in the debian space, they
sometimes slip by. I'm super thankful Mait is so agile when it comes to
fixing the debian packages! 

On Tue, 2019-12-03 at 17:55 +, César MR wrote:
> It worked!
>  
> Oddly, newmod didn’t work in a fresh Ubuntu minimal installation. Thank you!
>  
>  
>  
> De: Maitland Bottoms
> Enviado: martes, 3 de diciembre de 2019 17:16
> Para: César MR; discuss-gnuradio@gnu.org
> Asunto: Re: gr_modtool crash
>  
> César MR  writes:
> 
> > Hi! I'm trying to follow the tutorial about working with gnuradio in c++, 
> > which can be found in the wiki, but i when i try to run gr_modtool, it 
> > crash. At first i thought that it was because of my language, so i changed 
> > my linux mint language to UK english, but it didn't work.
> >
> > In addition i had to run gr_modtool with admin privileges in order to  get 
> > a crash report in /var/crash directory.
> >
> > You can download the whole crash log here: https://mega.nz/#!yLxRGaRI
> >
> > What do you think is the root of my problem? thank you
> 
> That is a Debian packaging of gnuradio bug that mint inherited.
> This is also found in Debian 10 "Buster" gnuradio 3.7.13.4-4.
> 
> The problem comes from Python byte-compiled files used as templates.
> 
> The solution is to remove all .pyc files found under
> /usr/share/gnuradio/modtool/gr-newmod
> especially:
> /usr/share/gnuradio/modtool/gr-newmod/python/build_utils_codes.pyc
> /usr/share/gnuradio/modtool/gr-newmod/python/build_utils.pyc
> /usr/share/gnuradio/modtool/gr-newmod/python/__init__.pyc
> 
> I missed these becasue they are not present in the .deb, but are
> generated when the package is installed.
> 
> Recent (gnuradio 3.8) Debian packages no longer byte-compile any Python
> under /usr/share/gnuradio/ - solving this problem.
> 
> Easiest fix is just
> `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`
> 
> Good luck,
> -Maitland
>  


smime.p7s
Description: S/MIME cryptographic signature

Re: Stream args on UHD USRP Sink

[CEL]

I'd recommend not overestimating the workload of scaling outside of UHD
– UHD still has to do that multiplication! So, scaling e.g. your
constellation or your pulse-shaping filter would make at least as much
sense. 

On Tue, 2019-12-03 at 14:11 -0300, Wheberth Damascena Dias wrote:
> Hi Marcus, I
> 
> I am planning to give a try to the GnuRadio 3.8 PPA. We are developing some 
> OOT blocks and some rework may be needed to do so.
> 
> I will take a look at the code, but I am inclined to change my application to 
> eliminate the need of scaling in real time (scalling the QAM symbols for 
> example)
> 
> Regarding the USRP I am using a pair of X310.
> 
> Thank you very much.
> Wheberth
> 
> 
> Em ter, 3 de dez de 2019 13:26, Müller, Marcus (CEL)  
> escreveu:
> > U that's an ancient version of GNU Radio. Do you use any other UHD-
> > linking software, or can you try our new PPA that would give you a
> > modern GNU Radio 3.8.0.0?
> > 
> > https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases
> > 
> > Anyway, for most USRPs "fullscale" actually should do some scaling (if
> > you're so inclined, look for "_host_extra_scaling" in the UHD source
> > code).
> > 
> > What is the USRP you're using?
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:
> > > Hi all, not sure if I should send this here or at USRP list.
> > > 
> > > I am trying to set the "fullscale" as a stream parameter of the USRP Sink 
> > > block, but it have no effect. The idea is to avoid the use aof one block 
> > > to scale the samples to [-1.0, +1.0] range May I be missing something?
> > > 
> > > For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock 
> > > from Ubuntu 18.04).
> > > Thank you very 
> > > 
> > > 
> > > 
> > > -- 
> > > Wheberth Damascena Dias
> > > ___ _ _ __ ___ __ _ _ _  _ 
> > > http://www.linkedin.com/in/wheberth
> > > e-mail:whebe...@gmail.com
> > > 


smime.p7s
Description: S/MIME cryptographic signature

upgrading to 3.8 (was: Re: Stream args on UHD USRP Sink)

[CEL]

Hi Glen,

On Tue, 2019-12-03 at 12:20 -0500, Glen Langston wrote:
> Hi
> 
> This is a general question about upgrade to python 3 and gnu radio 3.8.
> 
> We’ve got some custom C++ and Python code that will need to be installed.
> The python ran in version 2.7.  This is working with gnuradio companion 
> 3.7.13.4
> 
> How difficult a task is upgrading?  A day/week/month?

Pretty much impossible to say, but if you say "some", I'd assume it's
in the range of single-digits hours.

See: 

https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide

Best regards, 
Marcus


smime.p7s
Description: S/MIME cryptographic signature

RE: gr_modtool crash

[César MR]

It worked!

Oddly, newmod didn’t work in a fresh Ubuntu minimal installation. Thank you!



De: Maitland Bottoms
Enviado: martes, 3 de diciembre de 2019 17:16
Para: César MR; 
discuss-gnuradio@gnu.org
Asunto: Re: gr_modtool crash

César MR  writes:

> Hi! I'm trying to follow the tutorial about working with gnuradio in c++, 
> which can be found in the wiki, but i when i try to run gr_modtool, it crash. 
> At first i thought that it was because of my language, so i changed my linux 
> mint language to UK english, but it didn't work.
>
> In addition i had to run gr_modtool with admin privileges in order to  get a 
> crash report in /var/crash directory.
>
> You can download the whole crash log here: https://mega.nz/#!yLxRGaRI
>
> What do you think is the root of my problem? thank you

That is a Debian packaging of gnuradio bug that mint inherited.
This is also found in Debian 10 "Buster" gnuradio 3.7.13.4-4.

The problem comes from Python byte-compiled files used as templates.

The solution is to remove all .pyc files found under
/usr/share/gnuradio/modtool/gr-newmod
especially:
/usr/share/gnuradio/modtool/gr-newmod/python/build_utils_codes.pyc
/usr/share/gnuradio/modtool/gr-newmod/python/build_utils.pyc
/usr/share/gnuradio/modtool/gr-newmod/python/__init__.pyc

I missed these becasue they are not present in the .deb, but are
generated when the package is installed.

Recent (gnuradio 3.8) Debian packages no longer byte-compile any Python
under /usr/share/gnuradio/ - solving this problem.

Easiest fix is just
`sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`

Good luck,
-Maitland

Re: Stream args on UHD USRP Sink

[Michael Dickens]

Hi Glen - GR38 provides compatibility with Py27, so your old code should
still work there ... once the GR37 specific parts are update to what GR38
requires. From a Python perspective, it should still work. We'd recommend
creating a "maint-3.7" branch (or something that makes it clear that the
branch is for GR37), and then moving "master" to use GR38. Of course, GR39
will remove Py27 compatibility, so we advise everyone doing GR development
to update to Py3 code ... Py36 would be good enough, Py37 would be better!
Py38 is a little too young still to recommend long term moving to it, but
as of yet it seems to work out of the box with GR and UHD and Volk and
related projects. Hope this is useful! - MLD

On Tue, Dec 3, 2019 at 12:31 PM Glen Langston 
wrote:

> Hi
>
> This is a general question about upgrade to python 3 and gnu radio 3.8.
>
> We’ve got some custom C++ and Python code that will need to be installed.
> The python ran in version 2.7.  This is working with gnuradio companion
> 3.7.13.4
>
> How difficult a task is upgrading?  A day/week/month?
>
> Thanks again for all your guidance and help,
>
> Glen
>
> The code is modest in size, I’d say.   Is there a way of keeping
> backward compatibility to 2.7?   Should I create a whole new
> archive for python 3?
>
> ie we’re using
>
> www.github.com/WVURAIL/gr-radio_astro
>
> so should I make
>
> gr-radio_astro3
>
> ?
>
-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: Stream args on UHD USRP Sink

[Wheberth Damascena Dias]

Hi Marcus, I

I am planning to give a try to the GnuRadio 3.8 PPA. We are developing some
OOT blocks and some rework may be needed to do so.

I will take a look at the code, but I am inclined to change my application
to eliminate the need of scaling in real time (scalling the QAM symbols for
example)

Regarding the USRP I am using a pair of X310.

Thank you very much.
Wheberth


Em ter, 3 de dez de 2019 13:26, Müller, Marcus (CEL) 
escreveu:

> U that's an ancient version of GNU Radio. Do you use any other UHD-
> linking software, or can you try our new PPA that would give you a
> modern GNU Radio 3.8.0.0?
>
> https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases
>
> Anyway, for most USRPs "fullscale" actually should do some scaling (if
> you're so inclined, look for "_host_extra_scaling" in the UHD source
> code).
>
> What is the USRP you're using?
>
> Best regards,
> Marcus
>
> On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:
> > Hi all, not sure if I should send this here or at USRP list.
> >
> > I am trying to set the "fullscale" as a stream parameter of the USRP
> Sink block, but it have no effect. The idea is to avoid the use aof one
> block to scale the samples to [-1.0, +1.0] range May I be missing something?
> >
> > For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock
> from Ubuntu 18.04).
> > Thank you very
> >
> >
> >
> > --
> > Wheberth Damascena Dias
> > ___ _ _ __ ___ __ _ _ _  _
> > http://www.linkedin.com/in/wheberth
> > e-mail:whebe...@gmail.com
> >
>

Re: Stream args on UHD USRP Sink

[Wheberth Damascena Dias]

Hi Mr. Leech,

Thank you for the information. I will look for another route.
My aplication currently generates samples with gaussian distribution and
unitary variance, fitting pretty much in the {-4.0, 4.0} range. This is why
I need the scaling.

Regards,
Wheberth




Em ter, 3 de dez de 2019 13:28, Marcus D Leech 
escreveu:

> My recollection is that full_scale applies only for sc8 samples.
>
> Gnuradio already scales into {-1.0,+1.0}
>
> Sent from my iPhone
>
> On Dec 3, 2019, at 6:47 AM, Wheberth Damascena Dias 
> wrote:
>
> 
> Hi all, not sure if I should send this here or at USRP list.
>
> I am trying to set the "fullscale" as a stream parameter of the USRP Sink
> block, but it have no effect. The idea is to avoid the use aof one block to
> scale the samples to [-1.0, +1.0] range May I be missing something?
>
> For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock
> from Ubuntu 18.04).
> Thank you very
>
>
> 
>
> --
> *Wheberth Damascena Dias*
> ___ _ _ __ ___ __ _ _ _  _
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com
>
>

Re: Stream args on UHD USRP Sink

[Glen Langston]

Hi

This is a general question about upgrade to python 3 and gnu radio 3.8.

We’ve got some custom C++ and Python code that will need to be installed.
The python ran in version 2.7.  This is working with gnuradio companion 3.7.13.4

How difficult a task is upgrading?  A day/week/month?

Thanks again for all your guidance and help,

Glen

The code is modest in size, I’d say.   Is there a way of keeping
backward compatibility to 2.7?   Should I create a whole new
archive for python 3?

ie we’re using 

www.github.com/WVURAIL/gr-radio_astro

so should I make 

gr-radio_astro3

?


> On Dec 3, 2019, at 11:26 AM, Müller, Marcus (CEL)  wrote:
> 
> U that's an ancient version of GNU Radio. Do you use any other UHD-
> linking software, or can you try our new PPA that would give you a
> modern GNU Radio 3.8.0.0?
> 
> https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases
> 
> Anyway, for most USRPs "fullscale" actually should do some scaling (if
> you're so inclined, look for "_host_extra_scaling" in the UHD source
> code).
> 
> What is the USRP you're using?
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:
>> Hi all, not sure if I should send this here or at USRP list.
>> 
>> I am trying to set the "fullscale" as a stream parameter of the USRP Sink 
>> block, but it have no effect. The idea is to avoid the use aof one block to 
>> scale the samples to [-1.0, +1.0] range May I be missing something?
>> 
>> For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from 
>> Ubuntu 18.04).
>> Thank you very 
>> 
>> 
>> 
>> -- 
>> Wheberth Damascena Dias
>> ___ _ _ __ ___ __ _ _ _  _ 
>> http://www.linkedin.com/in/wheberth
>> e-mail:whebe...@gmail.com
>> 

Re: Stream args on UHD USRP Sink

[Marcus D Leech]

My recollection is that full_scale applies only for sc8 samples. 

Gnuradio already scales into {-1.0,+1.0}

Sent from my iPhone

> On Dec 3, 2019, at 6:47 AM, Wheberth Damascena Dias  
> wrote:
> 
> 
> Hi all, not sure if I should send this here or at USRP list.
> 
> I am trying to set the "fullscale" as a stream parameter of the USRP Sink 
> block, but it have no effect. The idea is to avoid the use aof one block to 
> scale the samples to [-1.0, +1.0] range May I be missing something?
> 
> For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from 
> Ubuntu 18.04).
> Thank you very 
> 
> 
> 
> 
> -- 
> Wheberth Damascena Dias
> ___ _ _ __ ___ __ _ _ _  _ 
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com
> 

Re: Stream args on UHD USRP Sink

[CEL]

U that's an ancient version of GNU Radio. Do you use any other UHD-
linking software, or can you try our new PPA that would give you a
modern GNU Radio 3.8.0.0?

https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases

Anyway, for most USRPs "fullscale" actually should do some scaling (if
you're so inclined, look for "_host_extra_scaling" in the UHD source
code).

What is the USRP you're using?

Best regards,
Marcus

On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote:
> Hi all, not sure if I should send this here or at USRP list.
> 
> I am trying to set the "fullscale" as a stream parameter of the USRP Sink 
> block, but it have no effect. The idea is to avoid the use aof one block to 
> scale the samples to [-1.0, +1.0] range May I be missing something?
> 
> For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from 
> Ubuntu 18.04).
> Thank you very 
> 
> 
> 
> -- 
> Wheberth Damascena Dias
> ___ _ _ __ ___ __ _ _ _  _ 
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: gr_modtool crash

[Maitland Bottoms]

César MR  writes:

> Hi! I'm trying to follow the tutorial about working with gnuradio in c++, 
> which can be found in the wiki, but i when i try to run gr_modtool, it crash. 
> At first i thought that it was because of my language, so i changed my linux 
> mint language to UK english, but it didn't work.
>
> In addition i had to run gr_modtool with admin privileges in order to  get a 
> crash report in /var/crash directory.
>
> You can download the whole crash log here: https://mega.nz/#!yLxRGaRI
>
> What do you think is the root of my problem? thank you

That is a Debian packaging of gnuradio bug that mint inherited.
This is also found in Debian 10 "Buster" gnuradio 3.7.13.4-4.

The problem comes from Python byte-compiled files used as templates.

The solution is to remove all .pyc files found under
/usr/share/gnuradio/modtool/gr-newmod
especially:
/usr/share/gnuradio/modtool/gr-newmod/python/build_utils_codes.pyc
/usr/share/gnuradio/modtool/gr-newmod/python/build_utils.pyc
/usr/share/gnuradio/modtool/gr-newmod/python/__init__.pyc

I missed these becasue they are not present in the .deb, but are
generated when the package is installed.

Recent (gnuradio 3.8) Debian packages no longer byte-compile any Python
under /usr/share/gnuradio/ - solving this problem.

Easiest fix is just
`sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`

Good luck,
-Maitland

Re: Question about phase synchronization with X310 and two UBX 40

[Neel Pandeya]

Hello Masatetsu Wake-san:

I'm excited to hear that you are working with some USRP and GNU Radio users
in Japan!

Since we're both internal to National Instruments (I'm based in Austin,
Texas, USA), let's discuss this question directly, and go from there.

--Neel Pandeya



On Tue, 3 Dec 2019 at 01:14, Masatetsu Wake  wrote:

> Hello all,
>
>
>
> My customer is using X310 with two UBX 40 daugther boards and would like
> to know how he can synchronize the phase.
>
> Below is the some of the steps he is trying:
>
> 1.
> I add "dboard_clock_rate=20e6" to the "device arguments" field of
> the property for the UHD Source block, as the following URL
> shows.
> < 
> >>
> 2.
> Octoclock is connected to all of the four receivers (X310),
> and "clock_source" and "time_source" are "external" in the
> UHD Source block.
> 3.
> Each channel adds phase bias (value is random) everytime the program
> starts.
>
> He would like the phase bias to be constant.
>
> My customer can not share his code since he needs approvl to send program
> outside of the company.
>
> It is possible to share sample code (e.g. grc file) for phase
> synchronization.
>
>
>
> Thank you,
>
>
>
> Masatetsu Wake
>
> Account Manager
>
> National Instruments Japan
>
> M +81.80.5174.9003
>
> masatetsu.w...@ni.com
>
>
>

Stream args on UHD USRP Sink

[Wheberth Damascena Dias]

Hi all, not sure if I should send this here or at USRP list.

I am trying to set the "fullscale" as a stream parameter of the USRP Sink
block, but it have no effect. The idea is to avoid the use aof one block to
scale the samples to [-1.0, +1.0] range May I be missing something?

For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from
Ubuntu 18.04).
Thank you very


[image: image.png]
-- 
*Wheberth Damascena Dias*
___ _ _ __ ___ __ _ _ _  _
http://www.linkedin.com/in/wheberth
e-mail:whebe...@gmail.com