Re: First tutorial

[Fabian Schwartau]

Hi Alexander,

I see exactly what is shown in the tutorial and I don't see any 
harmonics. There are a two "shoulders" left and right to the signal, 
which are caused by the window function, which is applied by the 
Frequency sink to reduce spectral leakage. When I increase the lower 
boundary of the Frequency sink I can also see a lot of "noise" around 
-180dB, which is caused by numerical instability. Everything as 
expected... or did I get your question wrong?


Best,
Fabian

Am 30.03.22 um 08:19 schrieb Alexander Plotnikov:

Greetings everyone!

Can anybody please explain to me why in this example 
(https://wiki.gnuradio.org/index.php?title=Your_First_Flowgraph) the 
spectrum graph shows a harmonic far below 0dB?


Thanks everyone in advance!
Alexander

Re: First tutorial

[Fabian Schwartau]

Hi Alexander,

that is obviously a "problem" in gnu radio ;)
It depends on the window chosen and if it is normalized or not. The 
problem with the window functions in an FFT is, that you spread the 
power of the signal over multiple bins (which also happens when you have 
spectral leakage). You can either normalize the window so that the peak 
power will be correct (what you would like to see) or that the total 
mount of power/energy in the complete spectrum is preserved (what gnu 
radio is probably doing).
You can choose a rectangular window, make the fft length an exact 
multiple of the signal period and you will get a perfect peak at a 
single bin with the correct amplitude. But rectangular windows suffer 
from a lot of spectral leakage.


Best,
Fabian

PS: Please always (also) respond to the mailing list, so that others can 
find the discussion as well :)


Am 30.03.22 um 09:47 schrieb Alexander Plotnikov:

Greetings Fabian!

Thank you very much for your response.
I was talking about the main harmonic - the one I am generating with sin 
source.

I have attached a screen to be more exact.

What I am expecting is to get the spectrum of a pure sin with the Qt 
Freq Sink,
For now the problem seems to be due to Qt Freq Sink small number of FFT 
points.


Maybe you can advice me with any other Gui spectrum block? As you have 
probably noticed - I am very new to GNU Radio.


Thanks in advance,

Alexander

On 30.03.2022 10:19, Fabian Schwartau wrote:

Hi Alexander,

I see exactly what is shown in the tutorial and I don't see any 
harmonics. There are a two "shoulders" left and right to the signal, 
which are caused by the window function, which is applied by the 
Frequency sink to reduce spectral leakage. When I increase the lower 
boundary of the Frequency sink I can also see a lot of "noise" around 
-180dB, which is caused by numerical instability. Everything as 
expected... or did I get your question wrong?


Best,
Fabian

Am 30.03.22 um 08:19 schrieb Alexander Plotnikov:

Greetings everyone!

Can anybody please explain to me why in this example 
(https://wiki.gnuradio.org/index.php?title=Your_First_Flowgraph) the 
spectrum graph shows a harmonic far below 0dB?


Thanks everyone in advance!
Alexander

Removing Python Bindings from 3.9 OOT

[Brandon Smith]

Hello,

I am porting our GNURadio OOT from 3.8 to 3.9, and I have a block that we
utilize only in C++ and do not expose in GRC/Python. What would be the
correct method for removing it from the pybind process? I am hesitant to
start removing it from the new bindings dir for fear of breaking the build.
but from what I can gather:
1. remove block_python.cc
2. Remove block_python.cc from bindings/CMakeLists.txt
3. Remove mentions from python_bindings.cc

Any other tips?

Thank you!

- Brandon Smith

RE: Removing Python Bindings from 3.9 OOT

[Jim Melton]

As you have probably figured out by now, I don’t have experience with GRC. Your 
best answer will be to ask in the Matrix channel (or IRC if you are old-school).

I’m guessing your question is related to the change in how the Python bindings 
are done? I think that was 3.9 and not 3.10…

In the next few months I’m looking to upgrade my GNU Radio version, so I’m glad 
you are on top of this :P


---
Jim Melton
Sr Principal Software Engineer
Sierra Nevada Corporation
303.566.9582 (o) | 303.862.2459 (m)
jim.mel...@sncorp.com | 
sncorp.com

[cid:image002.jpg@01D8441B.D07F0260]



From: Discuss-gnuradio  
On Behalf Of Brandon Smith
Sent: Wednesday, March 30, 2022 07:26
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Removing Python Bindings from 3.9 OOT

Hello,

I am porting our GNURadio OOT from 3.8 to 3.9, and I have a block that we 
utilize only in C++ and do not expose in GRC/Python. What would be the correct 
method for removing it from the pybind process? I am hesitant to start removing 
it from the new bindings dir for fear of breaking the build. but from what I 
can gather:
1. remove block_python.cc
2. Remove block_python.cc from bindings/CMakeLists.txt
3. Remove mentions from python_bindings.cc

Any other tips?

Thank you!

- Brandon Smith

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: Removing Python Bindings from 3.9 OOT

[Brandon Smith]

I figured you'd be asking that's why I am working on it. idk if I can
access IRC from the office. Time to check!

- Brandon Smith


On Wed, Mar 30, 2022 at 11:52 AM Jim Melton  wrote:

> As you have probably figured out by now, I don’t have experience with GRC.
> Your best answer will be to ask in the Matrix channel (or IRC if you are
> old-school).
>
>
>
> I’m guessing your question is related to the change in how the Python
> bindings are done? I think that was 3.9 and not 3.10…
>
>
>
> In the next few months I’m looking to upgrade my GNU Radio version, so I’m
> glad you are on top of this :P
>
>
>
>
>
> ---
>
> *Jim Melton*
>
> Sr Principal Software Engineer
>
> Sierra Nevada Corporation
>
> 303.566.9582 (o) | 303.862.2459 (m)
>
> jim.mel...@sncorp.com | sncorp.com 
>
>
>
>
>
>
>
> *From:* Discuss-gnuradio  sncorp@gnu.org> *On Behalf Of *Brandon Smith
> *Sent:* Wednesday, March 30, 2022 07:26
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [EXTERNAL] Removing Python Bindings from 3.9 OOT
>
>
>
> Hello,
>
>
>
> I am porting our GNURadio OOT from 3.8 to 3.9, and I have a block that we
> utilize only in C++ and do not expose in GRC/Python. What would be the
> correct method for removing it from the pybind process? I am hesitant to
> start removing it from the new bindings dir for fear of breaking the build.
> but from what I can gather:
> 1. remove block_python.cc
> 2. Remove block_python.cc from bindings/CMakeLists.txt
> 3. Remove mentions from python_bindings.cc
>
>
>
> Any other tips?
>
>
>
> Thank you!
>
>
>
> - Brandon Smith
> 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.
>

Finding the GPS seconds time from GPSDO

[isaac mario tupac davila]

Hello

I'm Isaac. As it is said in this web:
https://files.ettus.com/manual/page_gpsdo.html ,
get_mboard_sensor("gps_time") gives us the seconds since January 1, 1970
(so UTC seconds).

What I'm looking for is that GNU Radio gives me the GPS seconds directly
(GPS time is ahead 18 seconds from UTC). Is there a method that gives us
the GPS seconds?

Regards
Isaac T.

Conda package for gr-sdrplay3 OOT module for Windows

[Franco VENTURI]

Good news - with Ryan's help a few days ago I was able to create a recipe and a 
conda package for the gr-sdrplay3 OOT module for Windows.

For those not familiar with it, the gr-sdrplay3 OOT module adds support for the 
SDRplay RSP devices as native GNU Radio sources, using directly the SDRplay 
APIs (i.e. without going through SoapySDR).
Up to now it was only available on Linux (and probably Mac), but with this 
conda package it is possible to run it on Windows (it requires the most current 
GNU Radio installation using conda - see here: 
https://wiki.gnuradio.org/index.php/CondaInstall).

For those interested in trying it out, this is the link to the conda package on 
my Google Drive: 
https://drive.google.com/file/d/1ZTUeYyOpms0rx7yU2Q5fOqElKIKgyJwK/view?usp=sharing
 (the conda recipe is in the package).

One important notice - conda's Python on Windows loads any dependent DLL from a 
limited set of folders (i.e. it does not use the %PATH% environment variable to 
search for dependent DLLs, as I think most of the other Windows applications 
do).
This means that the proprietary DLL for the SDRplay API 'sdrplay_api.dll' 
(which is typically installed under 'C:\Program Files\SDRplay\API\x64\') needs 
to be copied to one of these folders for things to work:

- %CONDA_PREFIX%\Lib\site-packages\gnuradio\sdrplay3
- %CONDA_PREFIX%
- %CONDA_PREFIX%\Library\mingw-w64\bin
- %CONDA_PREFIX%\Library\bin
- %CONDA_PREFIX%\Scripts
- C:\Windows\System32

Alternatively setting the environment variable 
CONDA_DLL_SEARCH_MODIFICATION_ENABLE to '1' makes conda Python look into all 
the folders listed in %PATH%, and it should work too.

If conda Python is not able to find the 'sdrplay_api.dll' file, it will throw 
an 'ImportError' exception for the line 'from gnuradio import sdrplay3'.

I am not sure of the best way to distribute this package after this initial 
'beta' version, since it is not straightforward to build it automatically on 
conda-forge because of its dependence on SDRplay proprietary DLL and include 
files.
I am open to ideas and suggestions on how to find a good long-term solution 
(also, if this is not the best forum to discuss this specific conda related 
topic, please let me know, and we can continue this conversation elsewhere).

Franco