Re: [announcement] master: SWIG -> Pybind11 (breaks OOT interface)

[Morman, Joshua]

Thank you Marcus for the merge, the introduction, and the warnings :)

For all the Ubuntu users - the GNU Radio Master PPA has been updated with 
builds pulled from the latest master, so it now includes the pybind11 bindings, 
and OOTs will need to start migrating to the new python binding structure.  
Only install from this PPA if you want to test the latest master branch and get 
your OOTs ready for 3.9 
(https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide). 
Otherwise, it is better to stay with the gnuradio-releases PPA.   Here is the 
PPA info for master:


sudo add-apt-repository ppa:gnuradio/gnuradio-master
sudo apt-get update
sudo apt-get install gnuradio

Fedora COPR is not yet up to date, but I will let everyone know when that 
supports the current master branch with pybind11.

Josh



From: Marcus Müller mailto:mmuel...@gnuradio.org>>
Date: Thu, Jun 18, 2020 at 2:59 PM
Subject: [announcement] master: SWIG -> Pybind11 (breaks OOT interface)
To: Gnuradio Mailing List 
mailto:discuss-gnuradio@gnu.org>>


Hello, most prolific SDR community to wander this wide globe,

TL;DR: brace yourself. If you're on master, we'll be breaking your OOT.
You don't have to worry about anything if you're using GNU Radio 3.8.

We're close to merging the pybind branch into master – and that means
we're improving things a lot.

Formerly, we used SWIG to generate Python bindings for GNU Radio's C++
classes – a decision made much more than a decade ago[1], when it still
wasn't clear that Python would be the only language we support (SWIG can
generate wrappers for *a lot* of languages).

In what it does, SWIG is pretty impressive: give it some C++ header, and
it will generate the correct binding for python, including generating of
some mapper types, transparent handling of pointers etc. And, we've
really been using it a lot and in a lot of complex usage scenarios. I
honestly think that, together with OpenCV and LLDB, we really might be
the healthiest and largest project to use SWIG in such a wide way. I'm
very thankful SWIG exists!

Now, having said that, SWIG was always kind of a pain to work into our
source tree. The promise of "throwing in unmodified C++ headers, getting
out perfect Python bindings", far too often, turned out to be "after
massaging these headers quite a bit, then adding a bit of SWIG
directives here and there in swig .i files that we have to keep updated
whenever we change header structure"; and every time something broke our
SWIG bindings, be it a bug on our side or an unexpected change in SWIG
semantics, or be it that SWIG stubbornly refuses to use the include
paths we specify on some platforms, we sunk literal working days into
getting things fixed.

So, as awesome as SWIG's automatism are, using it on such a type-diverse
code base, with such a platform-diverse user community, was kind of
liable for a lot of time not spent on developing a better SDR framework,
but fixing tooling.

Thus, Josh took it upon himself to get this sorted out – and replace
SWIG with Pybind11. Now, Pybind11 is pretty different from SWIG. It's
actually pure C++11 code, and just compiles with standard compilers. No
extra tooling required.

It does come at the expense of you having to declare your interface
yourself. That sounds like a regression, but honestly, there's been so
much work put into making this automateable by Josh, for most blocks
that don't do anything "special", you can just let the automatism take
over. If that doesn't work, you'll typically get a compiler error,
telling you exactly what's wrong. To illustrate, I'll attach the code
generated to wrap a simple block below[2].

However, what that means is that we're also changing the way OOTs need
to wrap their C++ to Python so that they can still can work with GNU
Radio C++ objects wrapped to Python. gr_modtool has been updated to have
new stubs, and the aforementioned automatism is available, too. Small
problem: unlike compilation, the code generation does need an extra bit
of tooling, pygccxml to be specific. This is really only necessary when
you wrap a block that's not been wrapped before, not when compiling any
existing module or the GNU Radio source tree.

In terms of compile time: according to my current level of overview, for
proper multicore machines, building the many smaller C++ files tends to
be a bit faster than first running SWIG to generate 100kLOC-files and
then compile these monsters. For single- or dualcore machines, the
opposite tends to be true. It's my duty to remind you that compiling on
a RaspberryPi itself might get even more cumbersome than it currently
is, and that you should prefer the cross-building toolchains of the
operating system you're running on the embedded platform rather than
building directly on it. Especially debian makes that pretty easy.

Best regards,
and the happiest of hacking,

Marcus

[1]

Re: [USRP-users] NEED HELP: RFNoC OOT tutorial

[Mohamed Yaaseen]

Hello Cherif,
  I followed the same tutorial, it is the same as in AN here:
https://kb.ettus.com/Getting_Started_with_RFNoC_Development
But, uhd 4.0 mentioned in there is the pybombs recipes, I am not sure which
source used to built these recipes, but I guess it should be uhd
rfnoc-devel branch
The UHD-3.15 branch of uhd repository is the current stable version and
master branch corresponds to UHD-4.0.0.


Regards,
Mohamed Yaaseen


On Fri, 26 Jun 2020 at 17:51, cherif chibane 
wrote:

> Hi Moahmmed,
>
> I am in the process going that RFOC tutorial in:
>
> https://www.youtube.com/watch?v=j-EfyPVpaJ8
>
> He seems to be using UHD 4.0.0 and yet  he uses XML for binding the RFNoC
> module he created. Am I missing something?
>
> Thanks,
> Cherif
>
>
>
> On Fri, Jun 26, 2020 at 11:14 AM Mohamed Yaaseen via USRP-users <
> usrp-us...@lists.ettus.com> wrote:
>
>> Hello Guys,
>>
>> I am following the rfnoc getting started tutorial, to develop a gain
>> block. I am using the following branches of UHD, gr-ettus, gnuradio.
>> UHD - 3.15 LTS
>> gr-ettus - maint-3.8
>> gnuradio - maint-3.8
>> All installed in a custom prefix without using pybombs:
>> ~/workspace/installs/stable
>>
>> I have created the gain oot module using rfnocmodtool with all the
>> testbench and also have created the FPGA image. Now to create a gnuradio
>> grc bindings, the tutorial uses the xml file.
>> Since I am using gnuradio 3.8, it requires a yaml file. But even though I
>> am using gr-ettus maint-3.8 branch it's rfnocmodtools is not updated to
>> have yaml files. So, I am  stuck with xml.
>> Yea, I can just convert xml to yaml file manually, But, I find many extra
>> parameter with the xml file
>> and I am also not sure  how  I should change the CMakeLists.txt so that
>> the yaml files get installed correctly, while installing the OOT module.
>> I need some help on how I can create a yaml file for rfnoc oot in a
>> proper way ?
>>
>> My second question is: Currently, I can see that in the master branch of
>> UHD, the entire RFNoC work flow is  changing. I couldn't find
>> uhd_image_builder.py and gr-ettus is going to be removed etc.
>> I will  be working with RFNoC for the next couple of months, so I would
>> like to know If I should be moving to UHD 4.0.0 before I begin developing
>> my actual rfnoc application. And if so, is there any guide or how-to page
>> for RFNoC getting started UHD - 4.0.0 ? The current AN seems pretty
>> outdated even for UHD-3.15-LTS version
>>
>> Looking forward to your suggestions, tips and answers ..!!
>>
>> Thanks, stay safe and healthy !!
>>
>> Regards,
>> Mohamed Yaaseen
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

Re: Calculating SNR of an incoming signal

[Johannes Demel]

Hi Alex,

your cut-off frequency needs to be lower than half your sampling rate.
If your sampling rate is 61.44MHz, your maximum cut-off frequency can be 
30.72MHz. And it should probably be a bit lower. You're working in 
baseband here. It is really important to understand the concepts of 
digital signal processing. That's also the reason I pointed out several 
resources.


SNR calculation itself is not always trivial. You need a way to 
distinguish samples that should only carry noise energy and those that 
should carry signal energy.
Often people distinguish between SNR estimation for AWGN channels and 
for fading channels. While your estimator will probably not distinguish 
between the two, some estimators just fail for fading channels especially.
For OFDM you might want to look into Schmidl preamble based SNR 
estimation. There might be an M2M4 estimator for symbol based SNR 
estimation.

What kind of system are you using?

Cheers
Johannes


On 26.06.20 15:49, Alex Batts wrote:
Right, because the filter cutoff frequency needs to be at least half the 
sampling rate, I figured I would not be able to use a filter since the 
bladeRF I will be using has a 61.44 MHz sampling rate and I will be 
operating in the GHz range.


What I will probably end up having to do is do a pre-run calibration 
where the tone is not playing, use a complex to mag^2 and average power 
combination, set that as a constant block, and then subtract the 
calibrated constant from the total power when the tone is on to get the 
most accurate possible signal power. While not ideal because it is not a 
truly live SNR calculation, it is the best workaround that avoids the 
filter I can think of.


If there are any other suggestions to get a more live/real time SNR 
calculation I am open to that as well.


Thank you for the help,

Alex



On Fri, Jun 26, 2020 at 4:17 AM Johannes Demel > wrote:


Hi Alex,

"0 < fa <= sampling_rate/2" is correct and should always be
enforced. If
you try to set your filter cut-off frequency at >= samp_rate/2, you'll
experience aliasing.

After reading your mails, I get the impression you try to set your
filter cut-off frequency at your carrier frequency $f_c$ + bandwidth/2
$B/2$. Or something in that range. That won't work in baseband.
Effectively, your signal at $f_c$ goes through a mixer and is shifted
such that it would appear at $0$ in your baseband signal.

There's a lot of digital signal processing fundamentals involved. I
like
the explanations given in [0]. Though, of course there are well known
books such as the ones by Proakis or Sklar on the topic.

Cheers
Johannes

[0] https://dspillustrations.com/pages/index.html

On 25.06.20 22:22, Alex Batts wrote:
 > The effective noise bandwidth is part of the calculation. I'm
using the
 > radar range equation.
 >
 > My purpose for including the bandwidth in my response was that
any time
 > I try to use a filter with a frequency greater than my sampling
rate/2 I
 > get an error returned. I agree that ideally I would use a band-pass
 > filter with very narrow cutoffs to best capture the signal in its
 > entirety, however, I can't because the frequency I'm trying to
set my
 > filter at is more than half my sampling rate, giving me an error.
Maybe
 > there is something askew with that error and it's something else,
but it
 > returns saying 0 < fa <= sampling_rate/2
 >
 > On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller mailto:muel...@kit.edu>
 > >> wrote:
 >
 >     Hi Alex,
 >
 >     On 25/06/2020 21.00, Alex Batts wrote:
 >      > I'm sampling an incoming signal, but only around 2 MSps.
 >      >
 >
 >     and that's fine! that's the *equivalent* baseband, it has all
the same
 >     information as the RF signal.
 >
 >      > I need the signal power to noise power ratio at the
receiver as
 >     part of
 >      > my range calculation.
 >
 >     Yes, but you'd always want to do that "signal to noise" only
in the
 >     bandwidth that actually contains your tone; the rest will
just contain
 >     more noise, interferers... to make your measurement worse.
 >
 >      > So I would need to be able to distinguish between
 >      > the power of the tone vs the power of the surrounding
noise and use
 >      > those two numerical values in an equation to calculate the
range.
 >
 >     You need to define "surrounding"! Your signal doesn't get
worse by
 >     applying a filter that only selects your tone and as little
else as
 >     possible. So you should do that – it makes your SNR better.
Hence, your
 >     Signal power estimate gets more reliable (which you
definitely want).
 >
 >     (that 

NEED HELP: RFNoC OOT tutorial

[Mohamed Yaaseen]

Hello Guys,

I am following the rfnoc getting started tutorial, to develop a gain
block. I am using the following branches of UHD, gr-ettus, gnuradio.
UHD - 3.15 LTS
gr-ettus - maint-3.8
gnuradio - maint-3.8
All installed in a custom prefix without using pybombs:
~/workspace/installs/stable

I have created the gain oot module using rfnocmodtool with all the
testbench and also have created the FPGA image. Now to create a gnuradio
grc bindings, the tutorial uses the xml file.
Since I am using gnuradio 3.8, it requires a yaml file. But even though I
am using gr-ettus maint-3.8 branch it's rfnocmodtools is not updated to
have yaml files. So, I am  stuck with xml.
Yea, I can just convert xml to yaml file manually, But, I find many extra
parameter with the xml file
and I am also not sure  how  I should change the CMakeLists.txt so that the
yaml files get installed correctly, while installing the OOT module.
I need some help on how I can create a yaml file for rfnoc oot in a  proper
way ?

My second question is: Currently, I can see that in the master branch of
UHD, the entire RFNoC work flow is  changing. I couldn't find
uhd_image_builder.py and gr-ettus is going to be removed etc.
I will  be working with RFNoC for the next couple of months, so I would
like to know If I should be moving to UHD 4.0.0 before I begin developing
my actual rfnoc application. And if so, is there any guide or how-to page
for RFNoC getting started UHD - 4.0.0 ? The current AN seems pretty
outdated even for UHD-3.15-LTS version

Looking forward to your suggestions, tips and answers ..!!

Thanks, stay safe and healthy !!

Regards,
Mohamed Yaaseen

Starting and stopping a flowgraph via XMLRPC Server

[mehtap özkan]

Dear All,
 I use the XMLRPC Server to control several variables on the flowgraph
remotely.
What I don't know is how to start, stop the flowgraph. (The documentation
says its possible)
Which commands should I send to the server? tb.start, tb.stop ???
Many thanks in advance

Re: Calculating SNR of an incoming signal

[Alex Batts]

Right, because the filter cutoff frequency needs to be at least half the
sampling rate, I figured I would not be able to use a filter since the
bladeRF I will be using has a 61.44 MHz sampling rate and I will be
operating in the GHz range.

What I will probably end up having to do is do a pre-run calibration where
the tone is not playing, use a complex to mag^2 and average power
combination, set that as a constant block, and then subtract the calibrated
constant from the total power when the tone is on to get the most accurate
possible signal power. While not ideal because it is not a truly live SNR
calculation, it is the best workaround that avoids the filter I can think
of.

If there are any other suggestions to get a more live/real time SNR
calculation I am open to that as well.

Thank you for the help,

Alex



On Fri, Jun 26, 2020 at 4:17 AM Johannes Demel 
wrote:

> Hi Alex,
>
> "0 < fa <= sampling_rate/2" is correct and should always be enforced. If
> you try to set your filter cut-off frequency at >= samp_rate/2, you'll
> experience aliasing.
>
> After reading your mails, I get the impression you try to set your
> filter cut-off frequency at your carrier frequency $f_c$ + bandwidth/2
> $B/2$. Or something in that range. That won't work in baseband.
> Effectively, your signal at $f_c$ goes through a mixer and is shifted
> such that it would appear at $0$ in your baseband signal.
>
> There's a lot of digital signal processing fundamentals involved. I like
> the explanations given in [0]. Though, of course there are well known
> books such as the ones by Proakis or Sklar on the topic.
>
> Cheers
> Johannes
>
> [0] https://dspillustrations.com/pages/index.html
>
> On 25.06.20 22:22, Alex Batts wrote:
> > The effective noise bandwidth is part of the calculation. I'm using the
> > radar range equation.
> >
> > My purpose for including the bandwidth in my response was that any time
> > I try to use a filter with a frequency greater than my sampling rate/2 I
> > get an error returned. I agree that ideally I would use a band-pass
> > filter with very narrow cutoffs to best capture the signal in its
> > entirety, however, I can't because the frequency I'm trying to set my
> > filter at is more than half my sampling rate, giving me an error. Maybe
> > there is something askew with that error and it's something else, but it
> > returns saying 0 < fa <= sampling_rate/2
> >
> > On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller  > > wrote:
> >
> > Hi Alex,
> >
> > On 25/06/2020 21.00, Alex Batts wrote:
> >  > I'm sampling an incoming signal, but only around 2 MSps.
> >  >
> >
> > and that's fine! that's the *equivalent* baseband, it has all the
> same
> > information as the RF signal.
> >
> >  > I need the signal power to noise power ratio at the receiver as
> > part of
> >  > my range calculation.
> >
> > Yes, but you'd always want to do that "signal to noise" only in the
> > bandwidth that actually contains your tone; the rest will just
> contain
> > more noise, interferers... to make your measurement worse.
> >
> >  > So I would need to be able to distinguish between
> >  > the power of the tone vs the power of the surrounding noise and
> use
> >  > those two numerical values in an equation to calculate the range.
> >
> > You need to define "surrounding"! Your signal doesn't get worse by
> > applying a filter that only selects your tone and as little else as
> > possible. So you should do that – it makes your SNR better. Hence,
> your
> > Signal power estimate gets more reliable (which you definitely want).
> >
> > (that also highlights why I have a bit of doubt on your measurement
> > methodology – if your SNR depends on receiver bandwidth, then how
> much
> > does it actually tell you about the range, unless you specify the
> > bandwidth alongside with it?)
> >
> > Think about it: we typically assume noise to be white, i.e. to have
> > identical power spectral density all over the spectrum, e.g. -170
> > dBm/Hz.
> >
> > Now, if your receiver bandwidth is set to 2 MHz (because that's what
> > your SDR is probably configured to filter out if you ask for 2 MS/s),
> > then you get twice as much noise power than if you set the sampling
> > rate
> > to 1 MS/s.
> >
> > It's the same thing that I always let students figure out by
> themselves
> > the first time they use the lab spectrum analyzer:
> > Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
> > Set the resolution bandwidth of the spectrum analyzer to 1 MHz, and
> > tell
> > me what the SNR is. Now set the resolution bandwidth to 300 kHz and
> > tell
> > me again.
> > You get as much "N" in your SNR as you let through your system. In
> the
> > case of the spectrum analyzer, every point on the display is the
> power
> > in 1 MHz (or 300 kHz) of filter. In the case of 

Re: Problems with the GNU WiFi and the USRP B210

[Alex Humberstone]

So I'll agree here, I would not have opened your docx file if Marcus had
not already opened it.

To everyone on the mailing list, please avoid attaching documents, but if
you must, please only use PDF.

And if you have lots of output or code or something, please use Pastebin or
something like that, please do not dump it into your email and send an
email that's like 200 lines long.


On Fri, 26 Jun 2020 at 03:15, Johannes Demel 
wrote:

> Hi Silvio,
>
> please do not send docx Files. After reading Marcus answer, I assume
> your file contains valid info. But I thought this was just a spam or
> phishing mail. I'd totally expect some malicious macro in such a file. I
> see such malicious attachments regularly going through my spam filter.
> Also, use pdf please.
>
> Since we are on a publicly archived mailing list, it is really
> preferable to describe your issue directly in your email and just
> reference illustrations. In the past, people were asked to upload files
> to a platform and just add a link to their email.
>
> Cheers
> Johannes
>
>
> On 26.06.20 01:21, Silvio Cardero wrote:
> > Please open and read the document
> >
> >
> >
> > signature_658765992
> >
> >
> >
> > Silvio Cardero
> >
> > Chief Scientist
> >
> > 520.247.7275 (cell)
> >
> > Web www.ed2corp.com 
> >
> > Email Silvio@ed2corp _.com_
> >
> > 7636 N. Oracle Road
> >
> > Tucson, Az. 85704
> >
>
>

-- 
Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University
Las Cruces, New Mexico

Re: .docx attachments (was Problems with the GNU WiFi and the USRP B210)

[Ed Criscuolo]

I too had the same immediate reaction, and did not look at the file.

For what its worth, I ran it through Jotti's Malware scanner, and
it found nothing suspicious.

@(^.^)@  Ed


On 6/26/20 4:12 AM, Johannes Demel wrote:

Hi Silvio,

please do not send docx Files. After reading Marcus answer, I assume
your file contains valid info. But I thought this was just a spam or
phishing mail. I'd totally expect some malicious macro in such a file. I
see such malicious attachments regularly going through my spam filter.
Also, use pdf please.

Since we are on a publicly archived mailing list, it is really
preferable to describe your issue directly in your email and just
reference illustrations. In the past, people were asked to upload files
to a platform and just add a link to their email.

Cheers
Johannes


On 26.06.20 01:21, Silvio Cardero wrote:

Please open and read the document

​

signature_658765992



Silvio Cardero

Chief Scientist

520.247.7275 (cell)

Web www.ed2corp.com 

Email Silvio@ed2corp _.com_

7636 N. Oracle Road

Tucson, Az. 85704

gr-satellites

[Vincenzo Mone]

Hi to the list,

Anybody on this group that uses Daniel Estevez  gr-satellites?

I need some advice please

 

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




  *

  **   GSM  +39 328 7110193  **

  * SMS  +39 328 7110193*

  *

 

Re: Calculating SNR of an incoming signal

[Johannes Demel]

Hi Alex,

"0 < fa <= sampling_rate/2" is correct and should always be enforced. If 
you try to set your filter cut-off frequency at >= samp_rate/2, you'll 
experience aliasing.


After reading your mails, I get the impression you try to set your 
filter cut-off frequency at your carrier frequency $f_c$ + bandwidth/2 
$B/2$. Or something in that range. That won't work in baseband.
Effectively, your signal at $f_c$ goes through a mixer and is shifted 
such that it would appear at $0$ in your baseband signal.


There's a lot of digital signal processing fundamentals involved. I like 
the explanations given in [0]. Though, of course there are well known 
books such as the ones by Proakis or Sklar on the topic.


Cheers
Johannes

[0] https://dspillustrations.com/pages/index.html

On 25.06.20 22:22, Alex Batts wrote:
The effective noise bandwidth is part of the calculation. I'm using the 
radar range equation.


My purpose for including the bandwidth in my response was that any time 
I try to use a filter with a frequency greater than my sampling rate/2 I 
get an error returned. I agree that ideally I would use a band-pass 
filter with very narrow cutoffs to best capture the signal in its 
entirety, however, I can't because the frequency I'm trying to set my 
filter at is more than half my sampling rate, giving me an error. Maybe 
there is something askew with that error and it's something else, but it 
returns saying 0 < fa <= sampling_rate/2


On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller > wrote:


Hi Alex,

On 25/06/2020 21.00, Alex Batts wrote:
 > I'm sampling an incoming signal, but only around 2 MSps.
 >

and that's fine! that's the *equivalent* baseband, it has all the same
information as the RF signal.

 > I need the signal power to noise power ratio at the receiver as
part of
 > my range calculation.

Yes, but you'd always want to do that "signal to noise" only in the
bandwidth that actually contains your tone; the rest will just contain
more noise, interferers... to make your measurement worse.

 > So I would need to be able to distinguish between
 > the power of the tone vs the power of the surrounding noise and use
 > those two numerical values in an equation to calculate the range.

You need to define "surrounding"! Your signal doesn't get worse by
applying a filter that only selects your tone and as little else as
possible. So you should do that – it makes your SNR better. Hence, your
Signal power estimate gets more reliable (which you definitely want).

(that also highlights why I have a bit of doubt on your measurement
methodology – if your SNR depends on receiver bandwidth, then how much
does it actually tell you about the range, unless you specify the
bandwidth alongside with it?)

Think about it: we typically assume noise to be white, i.e. to have
identical power spectral density all over the spectrum, e.g. -170
dBm/Hz.

Now, if your receiver bandwidth is set to 2 MHz (because that's what
your SDR is probably configured to filter out if you ask for 2 MS/s),
then you get twice as much noise power than if you set the sampling
rate
to 1 MS/s.

It's the same thing that I always let students figure out by themselves
the first time they use the lab spectrum analyzer:
Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
Set the resolution bandwidth of the spectrum analyzer to 1 MHz, and
tell
me what the SNR is. Now set the resolution bandwidth to 300 kHz and
tell
me again.
You get as much "N" in your SNR as you let through your system. In the
case of the spectrum analyzer, every point on the display is the power
in 1 MHz (or 300 kHz) of filter. In the case of your Qt plot, it's the
power in a FFT bin. There's (f_sample)/(FFT length) bandwidth to each
bin; so your graphical analysis hinges on the setting of sample rate
and
FFT length (also, on window choice and labeling, and software
convention). Proportionally!

It's really hard to define "SNR" for 0-bandwidth, i.e. a single tone
(having a single tone, actually, gets tricky physically, but there's a
lot of people who could tell you more about oscillators than I could).

If you'd be fair, the only choice for the noise filter bandwidth would
be 0 Hz, because if you chose any wider, you always get more noise. But
in 0 Hz, there's actually 0 noise power! So, that doesn't work.

Instead, you need to define SNR exactly on the bandwidth your detection
system will have to use. That's a design parameter you haven't
mentioned
so far!

 > This
 > is why I referenced the green and red lines on the qt gui freq.
display,
 > this would seem to give me signal strength in dB.

Hopefully, above explained how much these lines depend on your
configuration and aren't "SNR".

Cheers,

Re: Problems with the GNU WiFi and the USRP B210

[Johannes Demel]

Hi Silvio,

please do not send docx Files. After reading Marcus answer, I assume 
your file contains valid info. But I thought this was just a spam or 
phishing mail. I'd totally expect some malicious macro in such a file. I 
see such malicious attachments regularly going through my spam filter.

Also, use pdf please.

Since we are on a publicly archived mailing list, it is really 
preferable to describe your issue directly in your email and just 
reference illustrations. In the past, people were asked to upload files 
to a platform and just add a link to their email.


Cheers
Johannes


On 26.06.20 01:21, Silvio Cardero wrote:

Please open and read the document

​

signature_658765992



Silvio Cardero

Chief Scientist

520.247.7275 (cell)

Web www.ed2corp.com 

Email Silvio@ed2corp _.com_

7636 N. Oracle Road

Tucson, Az. 85704