date:20190703

Re: [Discuss-gnuradio] Help getting accurate AWGN SNR values

2019-07-03 Thread Jonas Manthey

Hi,

Small addition: that’s why in the GNSS world (and others I guess) we use C/N0: 
https://en.wikipedia.org/wiki/Carrier-to-noise-density_ratio which is “normed” 
to 1Hz.

Kyeong’s video is a must watch if you are new to this field!

Cheers,
Jonas

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf Of 
Kyeong Su Shin
Sent: Mittwoch, 3. Juli 2019 03:43
To: Vladislav Fomitchev ; 
discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Help getting accurate AWGN SNR values


Hello Vladislav:



In my eyes, those plots look correct.



"For example, when I have a signal power ratio of 0db, I can still see my 
signal several db above the noise floor." -> That can totally happen; you must 
not forget that the bandwidth of the noise and the bandwidth of the signal that 
you are using for the SNR estimation are different (you are using 2 
samples/symbol for the PSK symbol generation).



OK, here is an example: Let's say that you are transmitting a CW-like tone (1 
Hz BW) with -160 dBm power, and the noise power of the receiver is -170 dBm/Hz. 
If you are observing 10 Hz of the BW, you are getting -160 dBm of noise power 
(0 dB SNR). If you observe 2 Hz instead, you get 7 dB SNR. But the spectrogram 
(or the PSD estimates) of the spectrum stays same - except that you are seeing  
a narrower range now.



Also, the power you are observing is the power of the PSK signals AND the power 
of the noise, so you do get a stronger RF power (per every FFT bin) when you 
increase the noise power. It is just that the power of the PSK signals is 
something that you want and the power of the noise is something that you do not 
want.



Also see: https://www.youtube.com/watch?v=PNMOwhEHE6w


[Image removed by sender.]
GRCon16 - Why Doesn't My Signal Look Like the Textbook?, Matt 
Ettus
www.youtube.com
All GRCon16 slides available here: http://gnuradio.org/grcon-2016/talks/ GNU 
Radio - the Free & Open-Source Toolkit for Software Radio http://gnuradio.org/




Regards,

Kyeong Su Shin




보낸 사람: Vladislav Fomitchev  대신 Discuss-gnuradio 

보낸 날짜: 2019년 7월 3일 수요일 오전 4:06:11
받는 사람: discuss-gnuradio@gnu.org
제목: [Discuss-gnuradio] Help getting accurate AWGN SNR values


Hello,

I have been trying to create a simulation with some basic PSK signals at 
varying SNR values by separately generating a signal and gaussian noise and 
adding them together. I am however having an issue at lower SNR’s where my 
measured SNR does not match what I observe in the waterfall or FFT. For 
example, when I have a signal power ratio of 0db, I can still see my signal 
several db above the noise floor. I used the gnuradio noise power example to 
setup my power measurements and noise generation, and it is fairly accurate 
until I get close to the noise floor. The specific issue seems to be that for 
some reason the amplitude of the noise also changes the peak amplitude of my 
psk signal. You can observe this in the following images where all I change is 
the noise power, yet the peak of my signal also moves. Data 0: is the spectral 
signal power, Data 1: is the spectral noise power, and Data 2: is the SNR or 
ratio of the signal and noise powers.
Top Left

Here is the same signal with a lower noise power. Note how the peak is ~4dB 
lower even though signal power is unchanged.
Top Middle

Here is a reference shot of a 10dB SNR signal to show that my measurements do 
work.
Right

I have attached a composite of the images and my flowgraph.

I would really appreciate any help with this. I feel I must be making a simple 
mistake somewhere since this is such an elementary task. As a note I have tried 
using the different channel model blocks, and different noise distributions 
which all had the same issue for me. Thanks in advance.

Vlad F.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ettus and GNU radio v3.8

2019-07-03 Thread Erik Heinz

I got a step further. The rfnoc domain for grc can be defined by a file 
rfnoc.domain.yml.

Now I can connect the module and generate a Python file from the flowgraph.


The connections still do not work at run time, though , see below.

I have defined 'connect:' and 'cpp_connect:' in rfnoc.domain.yml, but this 
definitions have no effect since this file is not read at run time and not 
included in

rfnoc_test1.py either.


Any suggestions?


Thanks and best regards,

Erik



Traceback (most recent call last):
  File "./rfnoc_test1.py", line 180, in 
main()
  File "./rfnoc_test1.py", line 158, in main
tb = top_block_cls()
  File "./rfnoc_test1.py", line 125, in __init__
self.connect((self.uhd_rfnoc_streamer_dma_fifo_0, 'out'), 
(self.qtgui_sink_x_0, 0))
  File "/usr/lib/python3.6/site-packages/gnuradio/gr/hier_block2.py", line 48, 
in wrapped
func(self, src, src_port, dst, dst_port)
  File "/usr/lib/python3.6/site-packages/gnuradio/gr/hier_block2.py", line 111, 
in connect
self.primitive_connect(*args)
  File "/usr/lib/python3.6/site-packages/gnuradio/gr/runtime_swig.py", line 
3606, in primitive_connect
return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
TypeError: Wrong number or type of arguments for overloaded function 
'top_block_sptr_primitive_connect'.
  Possible C/C++ prototypes are:
gr::hier_block2::connect(gr::basic_block_sptr)
gr::hier_block2::connect(gr::basic_block_sptr,int,gr::basic_block_sptr,int)




Von: USRP-users  im Auftrag von Erik Heinz 
via USRP-users 
Gesendet: Freitag, 28. Juni 2019 18:12
An: discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com
Betreff: [USRP-users] gr-ettus and GNU radio v3.8


Have there been any efforts yet to port gr-ettus to the gnuradio master branch?

I made some trials today with gr-ettus under gnuradio-master and at least was 
able to compile and install it (except for fosphor which seems to need Qt4).
Automatic conversion of the grc xml files to the yml format was not possible, 
so I converted one by hand (uhd_rfnoc_dma_fifo).

I got so far that the block shows up in grc and most error messages went away.
There are still errors, however, about 'Domain key "rfnoc" is not registered' 
for the input and output ports. This is probably the reason as well why I 
cannot connect anything to this block (red arrows).

Any ideas? How do I register the rfnoc domain? Are there any serious reasons 
preventing the rfnoc blocks from working under v3.8?

Best regards,
Erik

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help getting accurate AWGN SNR values

2019-07-03 Thread Vladislav Fomitchev

Hello,
Thank you for these wonderfully helpful answers. I think I understand now
that my signal still appears above the noise floor because it is the noise
and signal power compounded in that bandwidth. That video is also
incredibly helpful, especially since I am working with physical SDR's.
Having said that, I think I have what I need, so thank you again.


On Wed, Jul 3, 2019, 4:09 AM Jonas Manthey  wrote:

> Hi,
>
>
>
> Small addition: that’s why in the GNSS world (and others I guess) we use
> C/N0: https://en.wikipedia.org/wiki/Carrier-to-noise-density_ratio which
> is “normed” to 1Hz.
>
>
>
> Kyeong’s video is a must watch if you are new to this field!
>
>
>
> Cheers,
>
> Jonas
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey=
> u-blox@gnu.org] *On Behalf Of *Kyeong Su Shin
> *Sent:* Mittwoch, 3. Juli 2019 03:43
> *To:* Vladislav Fomitchev ;
> discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Help getting accurate AWGN SNR values
>
>
>
> Hello Vladislav:
>
>
>
> In my eyes, those plots look correct.
>
>
>
> "For example, when I have a signal power ratio of 0db, I can still see my
> signal several db above the noise floor." -> That can totally happen; you
> must not forget that the bandwidth of the noise and the bandwidth of the
> signal that you are using for the SNR estimation are different (you are
> using 2 samples/symbol for the PSK symbol generation).
>
>
>
> OK, here is an example: Let's say that you are transmitting a CW-like tone
> (1 Hz BW) with -160 dBm power, and the noise power of the receiver is -170
> dBm/Hz. If you are observing 10 Hz of the BW, you are getting -160 dBm of
> noise power (0 dB SNR). If you observe 2 Hz instead, you get 7 dB SNR. But
> the spectrogram (or the PSD estimates) of the spectrum stays same - except
> that you are seeing  a narrower range now.
>
>
>
> Also, the power you are observing is the power of the PSK signals AND the
> power of the noise, so you do get a stronger RF power (per every
> FFT bin) when you increase the noise power. It is just that the power of
> the PSK signals is something that you want and the power of the noise is
> something that you do not want.
>
>
>
> Also see: https://www.youtube.com/watch?v=PNMOwhEHE6w
>
>
>
> [image: Image removed by sender.]
> 
>
> GRCon16 - Why Doesn't My Signal Look Like the Textbook?, Matt Ettus
> 
>
> www.youtube.com
>
> All GRCon16 slides available here: http://gnuradio.org/grcon-2016/talks/
> GNU Radio - the Free & Open-Source Toolkit for Software Radio
> http://gnuradio.org/
>
>
>
>
>
> Regards,
>
> Kyeong Su Shin
>
>
> --
>
> *보낸* *사람**:* Vladislav Fomitchev  대신
> Discuss-gnuradio 
> *보낸* *날짜**:* 2019년 7월 3일 수요일 오전 4:06:11
> *받는* *사람**:* discuss-gnuradio@gnu.org
> *제목**:* [Discuss-gnuradio] Help getting accurate AWGN SNR values
>
>
>
> Hello,
>
> I have been trying to create a simulation with some basic PSK signals at
> varying SNR values by separately generating a signal and gaussian noise and
> adding them together. I am however having an issue at lower SNR’s where my
> measured SNR does not match what I observe in the waterfall or FFT. For
> example, when I have a signal power ratio of 0db, I can still see my signal
> several db above the noise floor. I used the gnuradio noise power example
> to setup my power measurements and noise generation, and it is fairly
> accurate until I get close to the noise floor. The specific issue seems to
> be that for some reason the amplitude of the noise also changes the peak
> amplitude of my psk signal. You can observe this in the following images
> where all I change is the noise power, yet the peak of my signal also
> moves. Data 0: is the spectral signal power, Data 1: is the spectral noise
> power, and Data 2: is the SNR or ratio of the signal and noise powers.
> Top Left
>
> Here is the same signal with a lower noise power. Note how the peak is
> ~4dB lower even though signal power is unchanged.
> Top Middle
>
> Here is a reference shot of a 10dB SNR signal to show that my measurements
> do work.
> Right
>
> I have attached a composite of the images and my flowgraph.
>
> I would really appreciate any help with this. I feel I must be making a
> simple mistake somewhere since this is such an elementary task. As a note I
> have tried using the different channel model blocks, and different noise
> distributions which all had the same issue for me. Thanks in advance.
>
> Vlad F.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] fractional resampler weird behavior?

2019-07-03 Thread Achilleas Anastasopoulos

Hi all,

I have a 1KHz complex exponential sampled at 10Ksps going through a
fractional resampler with resampling ratio = 10
I display the output on a frequency sink (with sampling rate set to
100Ksps).
I expect to see a 1 KHz tone.
Instead I see only a DC component (see attached grc file)

When I repeat the experiment with the RATIONAL resampler with interpolation
10 and decimation 1 I get the expected result.

Can someone verify this behavior and if yes, am I missing something or is
this a bug?
(gnuradio 3.7.13.5)

thanks
Achilleas


test_resampler.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ettus and GNU radio v3.8

2019-07-03 Thread Håkon Vågsether

Hello Erik,

I haven't really looked at gr-ettus for the master branch yet, but have you
tried replacing 'out' with 0 on line 125 in rfnoc_test1.py?

It would also be helpful if you supplied a git branch or something to look
at, I might give it a try myself.

Best regards,
Håkon Vågsether

On Wed, Jul 3, 2019 at 12:22 PM Erik Heinz  wrote:

> I got a step further. The rfnoc domain for grc can be defined by a file
> rfnoc.domain.yml.
>
> Now I can connect the module and generate a Python file from the flowgraph.
>
>
> The connections still do not work at run time, though , see below.
>
> I have defined 'connect:' and 'cpp_connect:' in rfnoc.domain.yml, but this
> definitions have no effect since this file is not read at run time and not
> included in
>
> rfnoc_test1.py either.
>
>
> Any suggestions?
>
>
> Thanks and best regards,
>
> Erik
>
>
>
> Traceback (most recent call last):
>   File "./rfnoc_test1.py", line 180, in 
> main()
>   File "./rfnoc_test1.py", line 158, in main
> tb = top_block_cls()
>   File "./rfnoc_test1.py", line 125, in __init__
> self.connect((self.uhd_rfnoc_streamer_dma_fifo_0, 'out'),
> (self.qtgui_sink_x_0, 0))
>   File "/usr/lib/python3.6/site-packages/gnuradio/gr/hier_block2.py", line
> 48, in wrapped
> func(self, src, src_port, dst, dst_port)
>   File "/usr/lib/python3.6/site-packages/gnuradio/gr/hier_block2.py", line
> 111, in connect
> self.primitive_connect(*args)
>   File "/usr/lib/python3.6/site-packages/gnuradio/gr/runtime_swig.py",
> line 3606, in primitive_connect
> return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
> TypeError: Wrong number or type of arguments for overloaded function
> 'top_block_sptr_primitive_connect'.
>   Possible C/C++ prototypes are:
> gr::hier_block2::connect(gr::basic_block_sptr)
>
> gr::hier_block2::connect(gr::basic_block_sptr,int,gr::basic_block_sptr,int)
>
>
>
> --
> *Von:* USRP-users  im Auftrag von
> Erik Heinz via USRP-users 
> *Gesendet:* Freitag, 28. Juni 2019 18:12
> *An:* discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com
> *Betreff:* [USRP-users] gr-ettus and GNU radio v3.8
>
>
> Have there been any efforts yet to port gr-ettus to the gnuradio master
> branch?
>
> I made some trials today with gr-ettus under gnuradio-master and at least
> was able to compile and install it (except for fosphor which seems to need
> Qt4).
> Automatic conversion of the grc xml files to the yml format was not
> possible, so I converted one by hand (uhd_rfnoc_dma_fifo).
>
> I got so far that the block shows up in grc and most error messages went
> away.
> There are still errors, however, about 'Domain key "rfnoc" is not
> registered' for the input and output ports. This is probably the reason as
> well why I cannot connect anything to this block (red arrows).
>
> Any ideas? How do I register the rfnoc domain? Are there any serious
> reasons preventing the rfnoc blocks from working under v3.8?
>
> Best regards,
> Erik
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USB Audio Adapter as audio source

2019-07-03 Thread Barry Duggan

I am trying to use a C-Media USB Audio Device as the audio source in my 
flow graph. So far, I have not had any success with the device name.


I tried:
all variations of "C-Media Electronics Inc. USB Audio Device"
default (also an empty device name)
sysdefault
Device (there was a sym link)
hw:x,y with various numbers
plughw:x,y with various numbers
'PCM',x with various numbers
/proc/asound/card2 (which is the correct card from the list)

alsamixer shows the device as valid. There does not seem to be a 'mute' 
function.


Any suggestions?

Thanks
--
Barry Duggan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USB Audio Adapter as audio source

2019-07-03 Thread Kyeong Su Shin

Hello Barry:


Maybe it is not 'the proper way', but maybe you can leave the "Audio Source" 
as-is and set the input device using pavucontrol?


Regards,

Kyeong Su Shin



보낸 사람: Barry Duggan  대신 Discuss-gnuradio 

보낸 날짜: 2019년 7월 4일 목요일 오전 10:48:36
받는 사람: Discuss Gnuradio
제목: [Discuss-gnuradio] USB Audio Adapter as audio source

I am trying to use a C-Media USB Audio Device as the audio source in my
flow graph. So far, I have not had any success with the device name.

I tried:
all variations of "C-Media Electronics Inc. USB Audio Device"
default (also an empty device name)
sysdefault
Device (there was a sym link)
hw:x,y with various numbers
plughw:x,y with various numbers
'PCM',x with various numbers
/proc/asound/card2 (which is the correct card from the list)

alsamixer shows the device as valid. There does not seem to be a 'mute'
function.

Any suggestions?

Thanks
--
Barry Duggan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USB Audio Adapter as audio source

2019-07-03 Thread CEL

Hey Barry,

what I usually do is run "arecord -L" and pick one of the listed
things.

Best regards,
Marcus
On Wed, 2019-07-03 at 21:48 -0400, Barry Duggan wrote:
> I am trying to use a C-Media USB Audio Device as the audio source in
> my 
> flow graph. So far, I have not had any success with the device name.
> 
> I tried:
> all variations of "C-Media Electronics Inc. USB Audio Device"
> default (also an empty device name)
> sysdefault
> Device (there was a sym link)
> hw:x,y with various numbers
> plughw:x,y with various numbers
> 'PCM',x with various numbers
> /proc/asound/card2 (which is the correct card from the list)
> 
> alsamixer shows the device as valid. There does not seem to be a
> 'mute' 
> function.
> 
> Any suggestions?
> 
> Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] fractional resampler weird behavior?

2019-07-03 Thread CEL

Uh, yeah.

That thing always confuses me, too. The "resampling ratio" is the
inverse of what you'd expect, i.e. to interpolate by 10, set it to 0.1.

Note that for extreme resampling ratios (r << 1 or r >> 1), it might
make sense to split the resampling between a rational resampler and
this MMSE resampler, for both computational performance as well as
signal quality reasons.

Best regards,
Marcus

On Wed, 2019-07-03 at 14:40 -0400, Achilleas Anastasopoulos wrote:
> Hi all,
> 
> I have a 1KHz complex exponential sampled at 10Ksps going through a
> fractional resampler with resampling ratio = 10
> I display the output on a frequency sink (with sampling rate set to
> 100Ksps).
> I expect to see a 1 KHz tone.
> Instead I see only a DC component (see attached grc file)
> 
> When I repeat the experiment with the RATIONAL resampler with
> interpolation 10 and decimation 1 I get the expected result.
> 
> Can someone verify this behavior and if yes, am I missing something
> or is this a bug?
> (gnuradio 3.7.13.5)
> 
> thanks
> Achilleas
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help getting accurate AWGN SNR values

Re: [Discuss-gnuradio] gr-ettus and GNU radio v3.8

Re: [Discuss-gnuradio] Help getting accurate AWGN SNR values

[Discuss-gnuradio] fractional resampler weird behavior?

Re: [Discuss-gnuradio] gr-ettus and GNU radio v3.8

[Discuss-gnuradio] USB Audio Adapter as audio source

Re: [Discuss-gnuradio] USB Audio Adapter as audio source

Re: [Discuss-gnuradio] USB Audio Adapter as audio source

Re: [Discuss-gnuradio] fractional resampler weird behavior?

9 matches

Site Navigation

Mail list logo

Footer information