Re: Excess bandwidth in constellation modulator

[Md. Atiqur Rahman]

Thank you for your reply with the details.
I do already read from the GNU Radio tutorial but wasn't fully sure.
The equation now clear, just want to make sure one point from you.
After the modulation(e.g qpsk) signal upconverted to RF, then the signal
bandwidth still will be the same?

Thank you again.


On Wed, Feb 26, 2020 at 12:31 AM Moses Browne Mwakyanjala <
mbkit...@gmail.com> wrote:

> I saw your post on the gnuradio mailing list.
> The constellation modulator block uses a Square-Root Raised-Cosine filter
> with occupied bandwidth (double-sided a.k.a passband) given by BW = (1 +
> alpha)Rs, where Rs is the symbol rate. The bit rate for M-ary linear
> modulation is given by Bit Rate = Rs*Log(M)base2. Thus, for BPSK you will
> achieve Bit Rate = Rs, and for QPSK it will be Bit Rate = 2 * Rs.
> The transmission over-the-air is called passband, which for the SRRC
> filter is given as described above.
> You could read more on the SRRC filter from this Wikipedia article:
> https://en.wikipedia.org/wiki/Root-raised-cosine_filter
> You could get more information here:
> https://wiki.gnuradio.org/index.php/Tutorials
>
> Good luck.
>
>

-- 
Sincerely,
Md Atiqur Rahman

Re: gnuradio 3.8 errors with gr_modtool

[Laura Arjona]

just in case, I removed the only .pyc file I found under
/usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache
/usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache__$   sudo
rm *pyc

The same error occurs.

Thank you!

On Tue, Feb 25, 2020 at 2:17 PM Laura Arjona  wrote:

> Thank you Maitland.
> Is there a "safer" way of installing gnuradio 3.8?
>
> Matiland - there is not such a folder in /modtool/gr-newmod.
> I only have /usr/share/gnuradio/modtool/template
>
> On Tue, Feb 25, 2020 at 1:13 PM Maitland Bottoms  wrote:
>
>> Laura Arjona  writes:
>>
>> > 1 - Installed fresh Ubuntu 18.04.4 LTS
>> > 2- Installed git, cmake, swig, gnuradio.
>> > To install gnuradio, I used:
>> >   $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases
>> >$ sudo apt-get update
>> >$ sudo apt-get install gnuradio
>> >
>> At this point you have .pyc files where they do not belong, since as of
>> just now the ppa packages are still buggy.
>>
>> You can
>>  `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`
>> and get on with life.
>>
>> Hopefully the ppa packegs will be fixed soon...
>>
>> -Maitland
>>
>
>
> --
> *Laura Arjona *
> Washington Research Foundation Innovation Postdoctoral Fellow in
> Neuroengineering
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
>


-- 
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering

*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350

Re: gnuradio 3.8 errors with gr_modtool

[Laura Arjona]

Thank you Maitland.
Is there a "safer" way of installing gnuradio 3.8?

Matiland - there is not such a folder in /modtool/gr-newmod.
I only have /usr/share/gnuradio/modtool/template

On Tue, Feb 25, 2020 at 1:13 PM Maitland Bottoms  wrote:

> Laura Arjona  writes:
>
> > 1 - Installed fresh Ubuntu 18.04.4 LTS
> > 2- Installed git, cmake, swig, gnuradio.
> > To install gnuradio, I used:
> >   $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases
> >$ sudo apt-get update
> >$ sudo apt-get install gnuradio
> >
> At this point you have .pyc files where they do not belong, since as of
> just now the ppa packages are still buggy.
>
> You can
>  `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`
> and get on with life.
>
> Hopefully the ppa packegs will be fixed soon...
>
> -Maitland
>


-- 
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering

*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350

Re: gnuradio 3.8 errors with gr_modtool

[Maitland Bottoms]

Laura Arjona  writes:

> 1 - Installed fresh Ubuntu 18.04.4 LTS
> 2- Installed git, cmake, swig, gnuradio.
> To install gnuradio, I used:
>   $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases
>$ sudo apt-get update
>$ sudo apt-get install gnuradio
>
At this point you have .pyc files where they do not belong, since as of
just now the ppa packages are still buggy.

You can
 `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`
and get on with life.

Hopefully the ppa packegs will be fixed soon...

-Maitland

Re: gnuradio 3.8 errors with gr_modtool

[Laura Arjona]

Thank you all for your comments.

I re-installed Ubuntu, thinking that it was a problem with  my
installation, but I get the same errors again.

Marcus, I re-installed git, but I get the same error.
I have no idea what is happening. I followed this steps

1 - Installed fresh Ubuntu 18.04.4 LTS
2- Installed git, cmake, swig, gnuradio.
To install gnuradio, I used:
  $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases
   $ sudo apt-get update
   $ sudo apt-get install gnuradio


3. Then when I use gr_modtool, I get the errors I reported in the first
message.

Any help would be greatly appreciate it, thanks!

On Fri, Feb 21, 2020 at 4:22 PM Maitland Bottoms  wrote:

> On Fri, 21 Feb 2020 10:58:18 -0800
> Laura Arjona  wrote:
>
> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position
> > 5: invalid continuation byte
>
> The problem comes from Python byte-compiled files used as templates.
>
> Perhaps the template processor is choking on a .pyc file?
>
> The solution is to remove all .pyc files found under
> /usr/share/gnuradio/modtool/gr-newmod
> (or whatever the correct path is for the modtool template directory
> in your installation.)
>
> If you have files like
> .../gnuradio/modtool/gr-newmod/python/build_utils_codes.pyc
> .../gnuradio/modtool/gr-newmod/python/build_utils.pyc
> .../gnuradio/modtool/gr-newmod/python/__init__.pyc
>
> then this is likely the trouble.
>
> In Debian, this bug is #946120
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946120
>
> It has been fixed in Debian's gnuradio 3.8 packages, so I am curious
> about how you might have ended up with this trouble.
>
> Hope that helps,
> -Maitland
>
>

-- 
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering

*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350

Re: SDR transceiver having independent mixer and ADC sampling clocks

[Brian Padalino]

On Tue, Feb 25, 2020 at 2:00 PM Heikki Laamanen 
wrote:

> Thanks Brian. You are right, there exists three VCOs and PLLs in the
> AD9361 which can be controlled independently.
>
>
>
> AD9361 Reference Manual UG-570 shows a more detailed diagram in Figure 7.
> on page 20. The baseband PLL comprises an N/N+1 divider controlled by a
> high-precision sigma-delta modulator. AD9361 Register Map Reference Manual
> UG-671 describes that the control word of the sigma-delta modulator
> consists of 29 bits giving a relative frequency resolution of 1.9 ppb
> (parts per billion).
>
>
>
> A brief description of the timing system.  The objective is a system for
> protecting or replacing GPS-based timing. In addition to navigation, the
> GPS system is used for generating an accurate clock which is in synchronism
> with the Coordinated Universal Time (UTC). A clock synchronized with the
> UTC, can be for example a 1 Hz physical clock signal whose rising edge goes
> up exactly at the start of an UTC second. The accuracy of an GPS-based
> timing system is about +-50 ns. Thus, we can say that the phase accuracy of
> GPS-based timing is about 50 ns.  The objective is to generate such clock
> by receiving a broadcast radio signal which is known to be in synchronism
> with the UTC.
>
>
>
> You mentioned that time is completely relative. If we think of the UTC, we
> could say that it gives an absolute time which is defined by several atomic
> clocks around the globe. A copy of the UTC can be generated, with a certain
> accuracy, by receiving the GPS or other similar satellite signal (Galileo,
> Glonass, Beidou) and synchronizing to it.
>

So you want to produce something like a stable 10MHz reference and  a 1PPS
which is synchronous to UTC using broadcast/terrestrial signals such as
DVB-T, ATSC, LTE, etc?  And your edges can be within +/-50ns of actual UTC?

I guess I'm still unsure if you do or do not believe the radios out there
allow for this to happen?  I'm not sure where you believe you have a
limitation.

Brian

RE: SDR transceiver having independent mixer and ADC sampling clocks

[Heikki Laamanen]

Thanks Brian. You are right, there exists three VCOs and PLLs in the AD9361 
which can be controlled independently.

 

AD9361 Reference Manual UG-570 shows a more detailed diagram in Figure 7. on 
page 20. The baseband PLL comprises an N/N+1 divider controlled by a 
high-precision sigma-delta modulator. AD9361 Register Map Reference Manual 
UG-671 describes that the control word of the sigma-delta modulator consists of 
29 bits giving a relative frequency resolution of 1.9 ppb (parts per billion).

 

A brief description of the timing system.  The objective is a system for 
protecting or replacing GPS-based timing. In addition to navigation, the GPS 
system is used for generating an accurate clock which is in synchronism with 
the Coordinated Universal Time (UTC). A clock synchronized with the UTC, can be 
for example a 1 Hz physical clock signal whose rising edge goes up exactly at 
the start of an UTC second. The accuracy of an GPS-based timing system is about 
+-50 ns. Thus, we can say that the phase accuracy of GPS-based timing is about 
50 ns.  The objective is to generate such clock by receiving a broadcast radio 
signal which is known to be in synchronism with the UTC.

 

You mentioned that time is completely relative. If we think of the UTC, we 
could say that it gives an absolute time which is defined by several atomic 
clocks around the globe. A copy of the UTC can be generated, with a certain 
accuracy, by receiving the GPS or other similar satellite signal (Galileo, 
Glonass, Beidou) and synchronizing to it.

 

Heikki

 

From: Brian Padalino  
Sent: 24. helmikuutata 2020 18:11
To: Heikki Laamanen 
Cc: GNURadio Discussion List 
Subject: Re: SDR transceiver having independent mixer and ADC sampling clocks

 

On Mon, Feb 24, 2020 at 10:39 AM Heikki Laamanen mailto:heikki.laama...@dlc.fi> > wrote:

Hi experts in SDR RF transceivers,

 

I am working on a timing and synchronization system which generates a 
high-precision timing signal from a terrestrial broadcast signal.  I am looking 
for a suitable SDR HW-board providing independent clocks for the RF mixers and 
the ADC.

 

It seems that many SDR boards use transceiver chips having mixer and ADC clocks 
which are derived from a single clock. Thus, it is not feasible to control the 
ADC sampling clock frequency without affecting the mixer frequency. For 
example, some USRP products have Analog Devices AD9361 transceiver chips 
providing no option to have fully independent mixer and ADC clocks.

 

Is this assertion true?  According to this document:

 

  
https://ez.analog.com/wide-band-rf-transceivers/design-support/w/documents/10064/ad936x-local-oscillator-lo

 

There exists 3 VCO's in the AD9361.  One for TX, one for RX, and one for the 
baseband.  Why do you believe the clocks are not independent?  I agree the 
sampling clock might not be able to achieve the resolution you want, but I 
don't see why they are not fully independent already.

 

 

Why would I like to have independent mixer and ADC sampling clock?

 

The target is to generate a physical clock signal having small jitter and 
accurate phase. Hence, I need to control the frequency of some VCO based on the 
information the receiver signal processing gives. The most straightforward way 
to do this is to control the frequency of a VCO wherefrom the ADC sampling 
clock is derived.

 

You need to be more specific regarding your jitter and phase requirements.

 

Also remember that time is all completely relative.  Lastly, what does accurate 
phase mean to you?

 

Brian

Introduction for GSoC Participation

[Arpit Gupta]

Hi everyone,

I am Arpit Gupta, an Electronics and Communication undergraduate at the
Indian Institute of Technology, Roorkee. I have been in touch with GNU
Radio for about a year now. I successfully participated in *GSoC'19* with *GNU
Radio*, building a *Block Header Parsing Tool*. More details regarding my
project can be found here . The *complete
code* can be found here .
I'm very interested to contribute again in GNU Radio this year. I have gone
through the GSoC ideas list and the project I'm interested in working on
the most is *GRC: View Only Mode (Secure).*
The project has a very strong security implication on the GRC (GNU Radio
Companion) as it would stop or ask for user permission before executing
arbitrary python code. For example, *Python Module Block* allows you to run
arbitrary python code*. *The idea here is to add *persistent cache* to the
*eval* operations that would enable users to *view a flowgraph* without
being executed. Persistent cache means information is stored in "permanent"
memory, so data is not lost after a system restart or system crash as it
would be if it is stored in cache memory.
I would definitely like to work a lot more on this project, so it will be
very helpful if I can get further guidance. I will be highly obliged.

Thanks.

Regards,
Arpit Gupta
Indian Institute of Technology, Roorkee

Re: gr-fosphor on AMD RX 550

[Sylvain Munaut]

Hi,


> I attached the output of glxinfo and ran glmark2. The output is attached
> in this mail.

So from the GL info it looks like the OpenGL drivers you have are the
one from AMD and not the one from Mesa. I never used those.

Unfortunately, since they don't actually _report_ any error, I don't
have any clue what to do or how to debug that remotely ...
(and I checked the code by putting an error in the shader on my
machine, here I do correctly get the error message printed out, so
it's relly the AMD driver screwing up here)

You can try the standalone 'main' test (you can build by going to the
lib/fosphor subdir of the source tree and type make) and then run it
by giving it a .cfile as argument. This might give some clue (because
it's not tangled in the whole thread mess of Qt and gnuradio) as to
what's going on.


> Currently, I'm stuck with a 5.0 kernel because the system won't boot
> with newer kernels due to some MCS checks.

Is that the issue with Ryzen 7 ?  I know I had to use a kernel from a
PPA for my machine because the one from the official 19.10 wouldn't
boot either.


Cheers,

   Sylvain

AW: gr-fosphor on AMD RX 550

[Johannes Demel]

Hi Sylvain,

I attached the output of glxinfo and ran glmark2. The output is attached 
in this mail. I'm glad that this is supposed to run on my machine.
Currently, I'm stuck with a 5.0 kernel because the system won't boot 
with newer kernels due to some MCS checks. I'm confident this is fixed 
in kernel 5.5 and thus I'll migrate to Ubuntu 20.04 as soon as it's 
available. I hope that'll make it easier as well.


Cheers
Johannes


Von: Sylvain Munaut <246...@gmail.com>
Gesendet: Montag, 24. Februar 2020 23:47
An: Johannes Demel
Cc: discuss-gnuradio@gnu.org
Betreff: Re: gr-fosphor on AMD RX 550

Hi Johannes,

First off the RX550 should work just fine. I have a RX570 and run
fosphor on it with no issues.
I am using Ubuntu 19.10 though which is much newer kernel and newer Mesa.

The OpenCL procedure looks fine and if it gets to that point, that
also worked fine. For some reason the shader fail ... but it's
supposed to print the error message which it's obviously not doing :/

Can you provide the full output of glxinfo and also try some open gl
application / benchmark (like glmark) see if they run fine ?

Cheers,

 Sylvain



$ glmark2
===
glmark2 2014.03+git20150611.fa71af2d
===
OpenGL Information
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER:   Radeon RX 550 Series
GL_VERSION:4.6.13581 Compatibility Profile Context 19.50
===
[build] use-vbo=false: FPS: 4433 FrameTime: 0.226 ms
[build] use-vbo=true: FPS: 7157 FrameTime: 0.140 ms
[texture] texture-filter=nearest: FPS: 6887 FrameTime: 0.145 ms
[texture] texture-filter=linear: FPS: 6761 FrameTime: 0.148 ms
[texture] texture-filter=mipmap: FPS: 6860 FrameTime: 0.146 ms
[shading] shading=gouraud: FPS: 6629 FrameTime: 0.151 ms
[shading] shading=blinn-phong-inf: FPS: 6572 FrameTime: 0.152 ms
[shading] shading=phong: FPS: 6373 FrameTime: 0.157 ms
[shading] shading=cel: FPS: 6317 FrameTime: 0.158 ms
[bump] bump-render=high-poly: FPS: 4981 FrameTime: 0.201 ms
[bump] bump-render=normals: FPS: 7201 FrameTime: 0.139 ms
[bump] bump-render=height: FPS: 7020 FrameTime: 0.142 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 6108 FrameTime: 0.164 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 3650 FrameTime: 
0.274 ms

[pulsar] light=false:quads=5:texture=false: FPS: 6707 FrameTime: 0.149 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: 
FPS: 2857 FrameTime: 0.350 ms

[desktop] effect=shadow:windows=4: FPS: 5108 FrameTime: 0.196 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 1094 FrameTime: 0.914 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: 
FPS: 2714 FrameTime: 0.368 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 1320 FrameTime: 0.758 ms

[ideas] speed=duration: FPS: 5700 FrameTime: 0.175 ms
[jellyfish] : FPS: 5068 FrameTime: 0.197 ms
[terrain] : FPS: 569 FrameTime: 1.757 ms
[shadow] : FPS: 5056 FrameTime: 0.198 ms
[refract] : FPS: 1280 FrameTime: 0.781 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 7313 FrameTime: 
0.137 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 7263 FrameTime: 
0.138 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 7299 FrameTime: 
0.137 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 7295 
FrameTime: 0.137 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 7299 
FrameTime: 0.137 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 7260 
FrameTime: 0.138 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 7266 
FrameTime: 0.138 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 7244 
FrameTime: 0.138 ms

===
  glmark2 Score: 5535 
===



name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: AMD
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: AMD
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robust

Re: GSOC 2020

[Sebastian Koslowski]

Hi Narayanan,

welcome here and thanks for your interest in GNU Radio and gr-radar. To get
started with Python I'd use one the countless resources you find on the
web. After that you would probably want to study the code of gr-radar
itself (the tests usually use Python). For a general introduction to
gr-radar there is also this blog https://grradar.wordpress.com/ and a bunch
of videos on YouTube.

For a GSoC project that you'll be working on full-time for three months,
I'd select some radar algorithm/method that really interests you and that
you are confident you can implement in that time frame. Also, consider,
that it is usually required to have access to suitable RF hardware for the
duration of the summer (maybe at your school).

Sebastian


On Mon, Feb 24, 2020 at 7:12 PM Narayanan Vinod <
narayananvinod2...@gmail.com> wrote:

> Hi , My name is Narayanan and I am a second year ECE student at REC
> ,Chennai , India . I am interested in doing this project named "Extending
> and Updating gr-radar" through GSOC 2020 Program. As per the skills
> required I have basic knowledge in signal processing and radars. Also i am
> familiar with c++,python which i could code better with some guidance . I
> would like to know how to start working for this project .Can there be a
> guidance for me?
>
>
>
>
> Sincerely ,
>
>
> Narayanan Vinod
>