Re: FMCW GNU Radar Toolbox

[Alex Batts]

Okay, well best of luck with that. I hope the B200 has the necessary
capabilities to do what you need.

Here are the links to block writing, hope this helps.

https://wiki.gnuradio.org/index.php/OutOfTreeModules
https://wiki.gnuradio.org/index.php/BlocksCodingGuide

Thank you,

Alex

On Fri, Jul 9, 2021 at 3:35 AM Pham Van Dung  wrote:

> Yes, I use it for another project which is a pulse FMCW radar project
>
> In this project, we need an LFM with receiving time (dead-time) for
> testing the function of the radar (transmitter and receiver etc..)
>
> Do you have any tutorial to modify the block of GNU Radio? I am a hardware
> guy so it may take some time to implement this work so I would
> appreciate it if you can help me how to modify it
>
> Thank you very much
>
>
> On Thu, Jul 8, 2021, 18:07 Alex Batts  wrote:
>
>> What on the other device are you trying to measure? Are you simply
>> attempting to see if you can receive a signal, or are you trying to receive
>> information of some kind?
>>
>> Generating an LFM signal is no problem, and modifying the source code is
>> a good way to go if that's all you want to do. You are right though about
>> the 56 MHz bandwidth, and the sample rate may affect your chirp
>> repetition frequency.
>>
>> Thanks,
>>
>> Alex
>>
>> On Thu, Jul 8, 2021 at 11:20 AM Pham Van Dung 
>> wrote:
>>
>>> Thank Alex for your answer,
>>>
>>> For the second question, I will not design a pulse doppler radar with a
>>> linear FM pulse. But I wonder that I could generate an LFM signal (to
>>> measure another RF device at 1GHz) using Ettus B200?
>>>
>>> Due to the limit of the hardware capabilities, I think I can only
>>> generate an LFM with a maximum ~ 56 MHz sweep bandwidth (if possible).
>>>
>>> My approach is the modification of the source code of the FMCW block
>>> using OutOfTreeModules with gr_modtool,
>>>
>>> In which I will add the deadtime at the end of each FMCW pulse but I
>>> think I will not trade with my time to do this problem because I have
>>> already another solution :D
>>>
>>> Again, I appreciate your help and time in advance
>>>
>>> Vào Th 5, 8 thg 7, 2021 vào lúc 16:16 Alex Batts <
>>> battsale...@gmail.com> đã viết:
>>>
>>>> Hello,
>>>>
>>>> It has been a while since I used the FMCW block in the Radar toolbox,
>>>> but from what I can remember, the three samples sections are defining the
>>>> percentage of the signal you want distributed in each of those sections.
>>>> For example, if you want 50% of your signal to be CW, and 50% to be
>>>> up-chirp, put an equal number of samples in the Samples CW and Samples
>>>> up-chirp sections. The number of samples combined with your sample rate and
>>>> frequency sweep will determine the slope of the fm chirp.
>>>>
>>>> There is also a VCO block I'm pretty sure that you can use for more
>>>> customizable fmcw radar.
>>>>
>>>> For your second question, why do you want to add a dead time? My guess
>>>> would be because you are trying to do pulse doppler of some sort, but if
>>>> not please explain because I would definitely be interested in knowing what
>>>> you are attempting to do! If you are trying to do a pulse doppler radar
>>>> with a linear fm pulse compression, unfortunately, there isn't much
>>>> functionality within GNU Radio for that kind of thing, and SDRs aren't
>>>> great for pulse doppler right now. In a few years' time they will, but most
>>>> affordable SDRs just don't have the hardware capabilities necessary. FMCW
>>>> is the way to go for SDRs because of low peak power needed and because
>>>> timing is not as necessary for range disambiguation, which is nice because
>>>> of the low sample rates of most SDRs.
>>>>
>>>> I am not sure you can implement a dead-time within the FMCW signal
>>>> generator block, and am not sure that gr-radar has that capability.
>>>> However, if you still want to implement a dead-time, you could write a
>>>> custom block (GNU Radio has extensive tutorials on how to do this, and only
>>>> requires basic knowledge of yaml and c++). I would do something like,
>>>> generate a sine wave, and while the sine wave is above a certain threshold,
>>>> send the fmcw signal through, else, send a constant 0 through. You would
>>>> have to play around with the threshold to g

Re: FMCW GNU Radar Toolbox

[Alex Batts]

What on the other device are you trying to measure? Are you simply
attempting to see if you can receive a signal, or are you trying to receive
information of some kind?

Generating an LFM signal is no problem, and modifying the source code is a
good way to go if that's all you want to do. You are right though about the
56 MHz bandwidth, and the sample rate may affect your chirp
repetition frequency.

Thanks,

Alex

On Thu, Jul 8, 2021 at 11:20 AM Pham Van Dung  wrote:

> Thank Alex for your answer,
>
> For the second question, I will not design a pulse doppler radar with a
> linear FM pulse. But I wonder that I could generate an LFM signal (to
> measure another RF device at 1GHz) using Ettus B200?
>
> Due to the limit of the hardware capabilities, I think I can only generate
> an LFM with a maximum ~ 56 MHz sweep bandwidth (if possible).
>
> My approach is the modification of the source code of the FMCW block using
> OutOfTreeModules with gr_modtool,
>
> In which I will add the deadtime at the end of each FMCW pulse but I think
> I will not trade with my time to do this problem because I have already
> another solution :D
>
> Again, I appreciate your help and time in advance
>
> Vào Th 5, 8 thg 7, 2021 vào lúc 16:16 Alex Batts 
> đã viết:
>
>> Hello,
>>
>> It has been a while since I used the FMCW block in the Radar toolbox, but
>> from what I can remember, the three samples sections are defining the
>> percentage of the signal you want distributed in each of those sections.
>> For example, if you want 50% of your signal to be CW, and 50% to be
>> up-chirp, put an equal number of samples in the Samples CW and Samples
>> up-chirp sections. The number of samples combined with your sample rate and
>> frequency sweep will determine the slope of the fm chirp.
>>
>> There is also a VCO block I'm pretty sure that you can use for more
>> customizable fmcw radar.
>>
>> For your second question, why do you want to add a dead time? My guess
>> would be because you are trying to do pulse doppler of some sort, but if
>> not please explain because I would definitely be interested in knowing what
>> you are attempting to do! If you are trying to do a pulse doppler radar
>> with a linear fm pulse compression, unfortunately, there isn't much
>> functionality within GNU Radio for that kind of thing, and SDRs aren't
>> great for pulse doppler right now. In a few years' time they will, but most
>> affordable SDRs just don't have the hardware capabilities necessary. FMCW
>> is the way to go for SDRs because of low peak power needed and because
>> timing is not as necessary for range disambiguation, which is nice because
>> of the low sample rates of most SDRs.
>>
>> I am not sure you can implement a dead-time within the FMCW signal
>> generator block, and am not sure that gr-radar has that capability.
>> However, if you still want to implement a dead-time, you could write a
>> custom block (GNU Radio has extensive tutorials on how to do this, and only
>> requires basic knowledge of yaml and c++). I would do something like,
>> generate a sine wave, and while the sine wave is above a certain threshold,
>> send the fmcw signal through, else, send a constant 0 through. You would
>> have to play around with the threshold to get the proper duty cycle and
>> play around with the frequency of the sine wave to make sure you are
>> staying in sync with the signal generator, but that is one idea on how I
>> would do it off the top of my head.
>>
>> Can you give me more information on the project and/or what your goals
>> are? It would help me give more specific advice as opposed to shooting
>> blindly.
>>
>> Thank you,
>>
>> Alex
>>
>> On Thu, Jul 8, 2021 at 5:44 AM Pham Van Dung  wrote:
>>
>>> Hello all,
>>> I want to make an FMCW signal generation with GNU Radar toolbox and
>>> Ettus B200
>>> I saw that you have several examples in
>>> https://github.com/kit-cel/gr-radar/tree/master/examples/simulation,
>>> but I do not understand the following parameters of the FMCW block
>>> - Samples CW
>>> - Samples up-chirp
>>> - Samples down-chirp
>>> - Frequency CW
>>> Second question, if I want to modify the block (I want to add dead-time
>>> at each pulse of FMCW), How can I do it?
>>> I appreciate your help and time
>>>
>>>
>
> --
> ---
> Van-Dung,PHAM
>
>

Re: FMCW GNU Radar Toolbox

[Alex Batts]

Hello,

It has been a while since I used the FMCW block in the Radar toolbox, but
from what I can remember, the three samples sections are defining the
percentage of the signal you want distributed in each of those sections.
For example, if you want 50% of your signal to be CW, and 50% to be
up-chirp, put an equal number of samples in the Samples CW and Samples
up-chirp sections. The number of samples combined with your sample rate and
frequency sweep will determine the slope of the fm chirp.

There is also a VCO block I'm pretty sure that you can use for more
customizable fmcw radar.

For your second question, why do you want to add a dead time? My guess
would be because you are trying to do pulse doppler of some sort, but if
not please explain because I would definitely be interested in knowing what
you are attempting to do! If you are trying to do a pulse doppler radar
with a linear fm pulse compression, unfortunately, there isn't much
functionality within GNU Radio for that kind of thing, and SDRs aren't
great for pulse doppler right now. In a few years' time they will, but most
affordable SDRs just don't have the hardware capabilities necessary. FMCW
is the way to go for SDRs because of low peak power needed and because
timing is not as necessary for range disambiguation, which is nice because
of the low sample rates of most SDRs.

I am not sure you can implement a dead-time within the FMCW signal
generator block, and am not sure that gr-radar has that capability.
However, if you still want to implement a dead-time, you could write a
custom block (GNU Radio has extensive tutorials on how to do this, and only
requires basic knowledge of yaml and c++). I would do something like,
generate a sine wave, and while the sine wave is above a certain threshold,
send the fmcw signal through, else, send a constant 0 through. You would
have to play around with the threshold to get the proper duty cycle and
play around with the frequency of the sine wave to make sure you are
staying in sync with the signal generator, but that is one idea on how I
would do it off the top of my head.

Can you give me more information on the project and/or what your goals are?
It would help me give more specific advice as opposed to shooting blindly.

Thank you,

Alex

On Thu, Jul 8, 2021 at 5:44 AM Pham Van Dung  wrote:

> Hello all,
> I want to make an FMCW signal generation with GNU Radar toolbox and Ettus
> B200
> I saw that you have several examples in
> https://github.com/kit-cel/gr-radar/tree/master/examples/simulation, but
> I do not understand the following parameters of the FMCW block
> - Samples CW
> - Samples up-chirp
> - Samples down-chirp
> - Frequency CW
> Second question, if I want to modify the block (I want to add dead-time at
> each pulse of FMCW), How can I do it?
> I appreciate your help and time
>
>

Re: Library libbladeRF for bladeRF 2.0 micro xA4

[Alex Batts]

I used gnuradio with a bladeRF 2.0 micro xA9 this summer with a raspberry
pi running ubuntu. Once I got everything figured out it worked great. You
just have to make sure you have all of the necessary dependencies
installed. You should also use Ubuntu 20.04. I got compilation errors for
Raspbian and older Ubuntu versions because they lacked the necessary
dependencies.

On Sun, Dec 6, 2020 at 3:49 PM Alvaro Pendas Recondo 
wrote:

> Hello,
>
> I am considering buying an SDR model bladeRF 2.0 micro xA4 that is
> supposed to be compatible with GNU Radio through the library libbladeRF.
> Does anyone have previous experience handling this model with GNU Radio or
> other models by Nuand? I have experience with USRP and UHD, witch
> integration with GNU Radio is great, but I do not if that would be the case
> with libbladeRF. Any input would be greatly appreciated.
>
> Thank you in advance!
>
> Alvaro
>

GR-Radar FMCW Detection

[Alex Batts]

Hello,

I am attempting to use gr-radar with an sdr to design a monostatic FMCW
ranging system. The FMCW detector has three messages it receives and sends
out one message. Has anybody been able to successfully integrate this with
the rest of the gr-radar blocks? If so, which blocks did you use to pass
the messages in?

Thank you,

Alex

Re: BladeRF 2.0 Micro - Using Bias Tees with GRC

[Alex Batts]

Awesome, thank you so much for the help! It did end up being
"bladerf=0,biastee=1" to enable it.

Thank you again!

Alex

On Mon, Aug 10, 2020 at 2:55 PM Marcus D. Leech 
wrote:

> On 08/10/2020 02:51 PM, Alex Batts wrote:
> > Okay, so adding "biastee=(something)" to the "Device Arguments"
> > section of the osmocom sink/source should theoretically enable it?
> >
> > If so, do you know what these options would be, or at least where I
> > can access the driver source code to examine it?
> >
> > Thank you,
> >
> > Alex
> >
> https://osmocom.org/projects/gr-osmosdr/wiki
>
> It looks like something like:
>
> bladerf=0,biastee
>
> Should do it.
>
>
>

Re: BladeRF 2.0 Micro - Using Bias Tees with GRC

[Alex Batts]

Okay, so adding "biastee=(something)" to the "Device Arguments" section of
the osmocom sink/source should theoretically enable it?

If so, do you know what these options would be, or at least where I can
access the driver source code to examine it?

Thank you,

Alex

On Mon, Aug 10, 2020 at 2:36 PM Marcus D. Leech 
wrote:

> On 08/10/2020 01:49 PM, Alex Batts wrote:
> > Hello all,
> >
> > I am wondering if anyone that has used the bladeRF 2.0 micro with the
> > bias tees was able to keep the bias tees enabled once executing a GRC
> > flowgraph. I am able to enable the bias tees with the bladeRF-cli
> > commands, but once I execute a GRC flowgraph they become disabled.
> >
> > Note: I recognize this is not exactly the best question for these
> > forums, but I have tried contacting Nuand four times over the last
> > week and a half, both through phone and email, and I have tried
> > posting to their forums (any forum post has to be approved by a
> > moderator), and I have had no luck with any of the attempts. So I was
> > wondering if anyone else on here has had a similar experience and
> > solved their issue.
> >
> > I'm running Ubuntu 20 on an RPi4 8GB.
> >
> > Thank you in advance,
> >
> > Alex
> Given that Gnu Radio creates a brand-new session with the device, it's
> not surprising to me that "device init" turns off the bias-T.
>
> But I'll note that the gr-osmosdr driver for BladeRF includes a
> "biastee" device argument, which if present turns on the bias tee.
>
>
>
>

BladeRF 2.0 Micro - Using Bias Tees with GRC

[Alex Batts]

Hello all,

I am wondering if anyone that has used the bladeRF 2.0 micro with the bias
tees was able to keep the bias tees enabled once executing a GRC flowgraph.
I am able to enable the bias tees with the bladeRF-cli commands, but once I
execute a GRC flowgraph they become disabled.

Note: I recognize this is not exactly the best question for these forums,
but I have tried contacting Nuand four times over the last week and a half,
both through phone and email, and I have tried posting to their forums (any
forum post has to be approved by a moderator), and I have had no luck with
any of the attempts. So I was wondering if anyone else on here has had a
similar experience and solved their issue.

I'm running Ubuntu 20 on an RPi4 8GB.

Thank you in advance,

Alex

Re: OOT - ValueError: invalid literal for int() with base 10: '...'

[Alex Batts]

UPDATE:

The previous error was because I had neglected to omit some parts of my
.yml file.

That error has been solved, and I can place the block into the flow graph.
However, when I generate and execute I get a new error:

*Traceback (most recent call last):*
*File "home/ubuntu/GRC/top_block.py", line 35, in *
* import trial*
*ModuleNotFoundError: No module named 'trial'*

*>>>Done (return code 1)*

My module I created was named 'trial'. I noticed in top_block.py, instead
of saying *import trial_swig as trial* it just says *import trial*. I don't
know if this is correct or not, but that is what is auto generated when I
execute my flow graph.

Again, any insight would be much appreciated,

Alex

On Wed, Jul 8, 2020 at 5:39 PM Alex Batts  wrote:

> Hello,
>
> Sorry if this seems a little spam-ish. However, I wanted to make this a
> new thread since this appears to be an unrelated problem from the previous
> thread I had posted.
>
> I successfully created an OOT module with a block, I successfully ran
> cmake, make, make test, and make install (and ldconfig) following the OOT
> tutorial. When I open up GRC and attempt to place the block, nothing
> happens, and in the terminal window it says:
>
> *File
> "/usr/lib/python3/dist-packages/gnuradio/grc/core/utils/descriptors/evaluated.py",
> line 73, in __set__*
> *attributes[self.name <http://self.name>] = type(self.default)(value)*
> *ValueError: invalid literal for int() with base 10: '...'*
>
> (Note: There is a lot of text prior to this, but they appear to all be
> file locations and function calls).
>
> If I am understanding correctly, gnu thinks I am passing '...' as an int.
> However, I don't understand where this would have come from.
>
> If necessary, I can paste my .cc .h and .py files (the ones that are
> referenced in the OOT tutorial) for reference.
>
> Any help would be much appreciated,
>
> Alex
>

OOT - ValueError: invalid literal for int() with base 10: '...'

[Alex Batts]

Hello,

Sorry if this seems a little spam-ish. However, I wanted to make this a new
thread since this appears to be an unrelated problem from the previous
thread I had posted.

I successfully created an OOT module with a block, I successfully ran
cmake, make, make test, and make install (and ldconfig) following the OOT
tutorial. When I open up GRC and attempt to place the block, nothing
happens, and in the terminal window it says:

*File
"/usr/lib/python3/dist-packages/gnuradio/grc/core/utils/descriptors/evaluated.py",
line 73, in __set__*
*attributes[self.name ] = type(self.default)(value)*
*ValueError: invalid literal for int() with base 10: '...'*

(Note: There is a lot of text prior to this, but they appear to all be file
locations and function calls).

If I am understanding correctly, gnu thinks I am passing '...' as an int.
However, I don't understand where this would have come from.

If necessary, I can paste my .cc .h and .py files (the ones that are
referenced in the OOT tutorial) for reference.

Any help would be much appreciated,

Alex

Re: AttributeError: module ‘math’ has no attribute ‘exponent_ff’

[Alex Batts]

Update:

I recreated the module. However, I am now running into an error I ran into
yesterday. The error is:

ValueError: invalid literal for int() with base 10: ‘...’

Initially, in my exponent_ff_impl.cc file, my code for the dsp in:

int
exponent_ff_impl::general_work

used to be:

for(int i = 0; i < noutput_items; i++){
  out[i] = pow(in[i], 0.25);
}

However, when I was still working in my gr-math module (which I am no
longer working in), all I had to do to solve the error was change the pow
function to powf. Yet in my new module, even when I do this and remake it,
the error is still there.

Any help would be much appreciated.

Thank you,

Alex

On Wed, Jul 8, 2020 at 1:11 PM Alex Batts  wrote:

> Okay, I did not realize that could be an issue. Is there a way to rename
> the module or should I create another one?
>
> Thank you,
>
> Alex
>
> On Wed, Jul 8, 2020 at 1:08 PM Marcus Müller  wrote:
>
>> That's cool, but I'd strongly recommend not calling your module "math",
>> because that name clashes with the existing Python "math" module.
>> I think that might be happening: something you import imports math, and
>> thus the native module, which overrides yours.
>>
>> Best regards,
>> Marcus
>>
>> On 08/07/2020 19.05, Alex Batts wrote:
>> > I created my own “Math” module. This is to distinguish from the built
>> in
>> > “Math Operators” module.
>> >
>> > On Wed, Jul 8, 2020 at 12:59 PM Marcus Müller > > <mailto:muel...@kit.edu>> wrote:
>> >
>> > Hi Alex,
>> >
>> > um, where's that line from? There's no "exponent_ff" in Python's
>> > "built-in" math module, so this is not surprising.
>> >
>> > Best regards,
>> > Marcus
>> >
>> > On 08/07/2020 18.57, Alex Batts wrote:
>> >  > Hello,
>> >  >
>> >  > I tried to create my own OOT module, one that can do exponents on
>> >  > floats. However, I keep running into this error:
>> >  >
>> >  > self.math_exponent_ff_0 = math.exponent_ff()
>> >  > AttributeError: module ‘math’ has no attribute ‘exponent_ff’
>> >  >
>> >  > I saw an earlier post on the forums that had a couple fixes, but
>> > I tried
>> >  > those and it did not work. Any help would be appreciated. If need
>> > be, I
>> >  > can post files as well to see code.
>> >  >
>> >  > Thank you,
>> >  >
>> >  > Alex
>> >
>>
>>

Re: AttributeError: module ‘math’ has no attribute ‘exponent_ff’

[Alex Batts]

Okay, I did not realize that could be an issue. Is there a way to rename
the module or should I create another one?

Thank you,

Alex

On Wed, Jul 8, 2020 at 1:08 PM Marcus Müller  wrote:

> That's cool, but I'd strongly recommend not calling your module "math",
> because that name clashes with the existing Python "math" module.
> I think that might be happening: something you import imports math, and
> thus the native module, which overrides yours.
>
> Best regards,
> Marcus
>
> On 08/07/2020 19.05, Alex Batts wrote:
> > I created my own “Math” module. This is to distinguish from the built in
> > “Math Operators” module.
> >
> > On Wed, Jul 8, 2020 at 12:59 PM Marcus Müller  > <mailto:muel...@kit.edu>> wrote:
> >
> > Hi Alex,
> >
> > um, where's that line from? There's no "exponent_ff" in Python's
> > "built-in" math module, so this is not surprising.
> >
> > Best regards,
> > Marcus
> >
> > On 08/07/2020 18.57, Alex Batts wrote:
> >  > Hello,
> >  >
> >  > I tried to create my own OOT module, one that can do exponents on
> >  > floats. However, I keep running into this error:
> >  >
> >  > self.math_exponent_ff_0 = math.exponent_ff()
> >  > AttributeError: module ‘math’ has no attribute ‘exponent_ff’
> >  >
> >  > I saw an earlier post on the forums that had a couple fixes, but
> > I tried
> >  > those and it did not work. Any help would be appreciated. If need
> > be, I
> >  > can post files as well to see code.
> >  >
> >  > Thank you,
> >  >
> >  > Alex
> >
>
>

Re: AttributeError: module ‘math’ has no attribute ‘exponent_ff’

[Alex Batts]

I created my own “Math” module. This is to distinguish from the built in
“Math Operators” module.

On Wed, Jul 8, 2020 at 12:59 PM Marcus Müller  wrote:

> Hi Alex,
>
> um, where's that line from? There's no "exponent_ff" in Python's
> "built-in" math module, so this is not surprising.
>
> Best regards,
> Marcus
>
> On 08/07/2020 18.57, Alex Batts wrote:
> > Hello,
> >
> > I tried to create my own OOT module, one that can do exponents on
> > floats. However, I keep running into this error:
> >
> > self.math_exponent_ff_0 = math.exponent_ff()
> > AttributeError: module ‘math’ has no attribute ‘exponent_ff’
> >
> > I saw an earlier post on the forums that had a couple fixes, but I tried
> > those and it did not work. Any help would be appreciated. If need be, I
> > can post files as well to see code.
> >
> > Thank you,
> >
> > Alex
>
>

AttributeError: module ‘math’ has no attribute ‘exponent_ff’

[Alex Batts]

Hello,

I tried to create my own OOT module, one that can do exponents on floats.
However, I keep running into this error:

self.math_exponent_ff_0 = math.exponent_ff()
AttributeError: module ‘math’ has no attribute ‘exponent_ff’

I saw an earlier post on the forums that had a couple fixes, but I tried
those and it did not work. Any help would be appreciated. If need be, I can
post files as well to see code.

Thank you,

Alex

Re: Calculating SNR of an incoming signal

[Alex Batts]

Sorry for the delayed response.

I do have info on the object I am tracking and can calculate the radar
cross section. It is a model rocket that can most likely be estimated as a
cylinder with small error between the two calculations.

The system as a whole will technically be active since we will also be
sending out the sine wave and directing it, but the receiving SDR will not
simultaneously be transmitting. It could technically be considered an
active bistatic system, but since the receiving SDR is the only influence
on range detection we were just going to consider it passive. We will be
using the BladeRF 2.0 Micro xA9.

Yes, EO is electro-optical/a camera system.

Right now I am struggling to set up the equation for the range detection in
gnuradio. There doesn't seem to be any support for inverse log functions or
fractional exponents (or taking the exponent of a non-complex number).
Since I am having to convert to mag^2 to calculate the power, I am working
with floats. Is there a workaround for this that you know of, or is there
an extension/add-on for gnuradio that extends it's mathematics capabilities?

Thank you,

Alex

On Mon, Jun 29, 2020 at 4:43 AM Johannes Demel 
wrote:

> Hi Alex,
>
> please keep this discussion on the mailing list. Thus, I included the
> mailing list in this reply again.
>
> Let's summarize your system
> carrier frequency 5.8GHz
> Radar ranging with reflection loss. Do you have any info on your
> reflecting object? An objects radar cross-section may heavily influence
> your results.
> You stated, you'd work on a passive RF ranging system. The setup you
> describe is active though. I'm curious how you'll convert this to a
> passive system.
>
> What's the signal structure you send? Is it just a sine? Is it random
> QPSK symbols? What's your frontend's carrier frequency? Which SDR
> frontend do you use? A USRP? A HackRF?
>
> As long as your bandwidth definition together with your SNR definition
> is sound, it might work to pre-calibrate your system. You might want to
> do this periodically in case you'll run it for a longer time.
>
> EO (Electro-Optical?)
>
> Cheers
> Johannes
>
> On 26.06.20 18:01, Alex Batts wrote:
> > Hello,
> >
> > Yes, I understand the Nyquist sampling theorem and my hardware
> > limitations. That is why I assumed filtering would not work although I
> > gave it a shot anyways. I am not trying to demodulate any baseband
> > signal, rather I am going to be receiving a reflected signal at around
> > 5.8 GHz and using that signal for range detection. The signal itself
> > will not contain any information, but the strength of the signal is the
> > information I need. However, I need a method for determining, or at
> > least estimating, SNR because that is the key variable that will change
> > throughout my experiment in the radar range equation and will ultimately
> > be the deciding factor to determine how far away the object is. That was
> > why I proposed doing a pre-trial calculation where my source is not
> > transmitting to get the average noise power, and then set that as a
> > constant block and subtract it in real time from my average total power
> > with noise and signal both included. The constant block would then be
> > updated prior to each run.
> >
> > A necessary part of the radar range equation is the transmit power from
> > the source as well as the directivity. The SNR I'll be looking for is at
> > the receiver. So the equation takes care of any signal attenuation.
> >
> > I'm building a passive RF range calculation system in conjunction with
> > an EO object tracking system.
> >
> > Thank you,
> >
> > Alex
> >
> >
> >
> > On Fri, Jun 26, 2020 at 11:14 AM Johannes Demel  > <mailto:de...@ant.uni-bremen.de>> wrote:
> >
> > 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 

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  > <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 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

Re: Calculating SNR of an incoming signal

[Alex Batts]

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,
> Marcus
>
>

Re: Calculating SNR of an incoming signal

[Alex Batts]

I'm sampling an incoming signal, but only around 2 MSps.

I need the signal power to noise power ratio at the receiver as part of my
range calculation. 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. 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.

On Thu, Jun 25, 2020 at 2:51 PM Marcus Müller  wrote:

> But you're sampling something, or else you couldn't process this in GNU
> Radio. So, I'm a bit confused about what you're actually doing.
>
>
> On 25/06/2020 20.48, Alex Batts wrote:
> > Sorry, I'm new to the mailing list as well.
> >
> > How would you recommend isolating the tone power? A band pass filter
> > wouldn't work at that frequency since there isn't an SDR that can sample
> > that high. Would that be where the Phase Locked Loop comes into play?
> >
> > Thank you for your help to this point,
> >
> > Alex
> >
> > On Thu, Jun 25, 2020 at 1:41 PM Marcus Müller  > <mailto:muel...@kit.edu>> wrote:
> >
> > Hi Alex,
> >
> > can you make sure to reply to the mailing list, not just me alone?
> > Others usually take interest in discussion, too :)
> >
> > Well, then it's easy.
> >
> > Total signal power is simply the average magnitude square of your
> > received signal
> > You just need to subtract the power of the tone (that's its squared
> > amplitude) and get the noise power.
> >
> > Divide these two, and you get SNR.
> >
> > However, since this is the description of a Radar that assumes its
> > targets are stationary, you'd probably use a PLL to remove the noise
> > bandwidth drastically, so not quite sure that kind of SNR
> > measurement is
> > extremely useful for realistic system comparison!
> >
> > Best regards,
> > Marcus
> > On 24/06/2020 16.58, Alex Batts wrote:
> >  > Hello,
> >  >
> >  > __ __
> >  >
> >  > The incoming signal is going to be a specific tone, probably
> > around 5.8
> >  > GHz. I am going to be using it for radar range detection. My SDR
> > will
> >  > just passively receive the reflected signal off of the object and
> > use
> >  > the SNR in the range calculation.
> >  >
> >  > __ __
> >  >
> >  > Thank you,
> >  >
> >  > __ __
> >  >
> >  > Alex
> >  >
> >  > __ __
> >  >
> >
>
>

Re: Calculating SNR of an incoming signal

[Alex Batts]

Sorry, I'm new to the mailing list as well.

How would you recommend isolating the tone power? A band pass filter
wouldn't work at that frequency since there isn't an SDR that can sample
that high. Would that be where the Phase Locked Loop comes into play?

Thank you for your help to this point,

Alex

On Thu, Jun 25, 2020 at 1:41 PM Marcus Müller  wrote:

> Hi Alex,
>
> can you make sure to reply to the mailing list, not just me alone?
> Others usually take interest in discussion, too :)
>
> Well, then it's easy.
>
> Total signal power is simply the average magnitude square of your
> received signal
> You just need to subtract the power of the tone (that's its squared
> amplitude) and get the noise power.
>
> Divide these two, and you get SNR.
>
> However, since this is the description of a Radar that assumes its
> targets are stationary, you'd probably use a PLL to remove the noise
> bandwidth drastically, so not quite sure that kind of SNR measurement is
> extremely useful for realistic system comparison!
>
> Best regards,
> Marcus
> On 24/06/2020 16.58, Alex Batts wrote:
> > Hello,
> >
> > __ __
> >
> > The incoming signal is going to be a specific tone, probably around 5.8
> > GHz. I am going to be using it for radar range detection. My SDR will
> > just passively receive the reflected signal off of the object and use
> > the SNR in the range calculation.
> >
> > __ __
> >
> > Thank you,
> >
> > __ __
> >
> > Alex
> >
> > __ __
> >
>
>

Calculating SNR of an incoming signal

[Alex Batts]

Hello,

I am relatively new to GNU Radio and I am trying to calculate the SNR of an
incoming signal. On the QT Gui frequency display it shows a red line and a
green line which I take to be the average noise power and average signal
power of the incoming signal (from my RTL SDR) respectively. Is there any
way I can utilize in real time the values of these two lines to calculate
an SNR? If not, is there a way to determine a value at a specific
frequency/average value over a range of frequencies for this calculation?

Thank you in advance,

Alex