Re: [Discuss-gnuradio] Rational Resampler no output.

[Cor Legemaat]

https://github.com/gnuradio/gnuradio/issues/1348

Regards:
Cor

On Mon, 2017-06-26 at 14:11 +0200, Marcus Müller wrote:
> 
> That's mightily interesting! I feel like we should be doing bug
>   reports, but I'm not sure where.
> 
> 
> 
> 
> On 26.06.2017 06:42, Cor Legemaat
>   wrote:
> 
> 
> 
> >   Found it:
> > 
> >   
> > 
> >   
> > 
> >   Created an C++ app that called that function with the same
> > > > parameter values as with python for this flow graph. Witch
I was
> > able to debug normally.
> > 
> >   
> > 
> >   
> > 
> >   In window.cc line 265, with i = ntaps - 1, temp =
> > > > 1.002 that cause sqrt (0) witch return "-
nan" on
> > the next line and screw all the rest of the calculations.
> > 
> >   
> > 
> >   
> > 
> >   This only happens when compiled with "CFLAGS=-march=native
> > > > -O2", if I don't specify the march it's working correctly.
The
> > function is called on my system with taps=787 and beta = 7.
> > 
> >   
> > 
> >   
> > 
> >   Regards:
> > 
> >   Cor
> > 
> >   
> > 
> >   
> > 
> >   On Wed, 2017-06-21 at 15:13 +0200, Cor Legemaat wrote:
> > 
> > > Hi:
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Sorry for the late replay... The intel pc call
> > > > > >   filter.firdes.low_pass with the same values but return
768
> > > > > >   proper float values, not like the 's on the AMD
pc.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Tried to debug with "nemiver /usr/bin/python2.7 -u
> > >   /fm_receiver.py" and the breakpoint at firdes.cc
> > > > > >   line 100 witch get triggered and I can read the
function
> > > > > >   parameters but when I try to step true the function it
jumps
> > > > > >   to the assembly of pthread. If I put more breakpoints
in
> > >   firdes.cc I get back to the function but cant read any
> > >   variables any more. Also tried exporting "export
> > >   GR_SCHEDULER=STS" but the same symptoms.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Don't know if Ubuntu will trigger the bug it's probably
> > >   compiled more generic...
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Regards:
> > > 
> > > Cor
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Wed, 2017-06-07 at 04:26 -0400, Anon Lister wrote:
> > > 
> > > >   
> > > > > > > > I have an AMD system with the same chip running
Ubuntu
> > > > > > > >   16.xx. I can probably try to duplicate this
weekend, if
> > > >   Cor doesn't get to it, as another data point. 
> > > > 
> > > > 
> > > >   
> > > > 
> > > > On Jun 5, 2017 3:14 PM, "Marcus
> > > > > > > >   Müller" 
> > > >   wrote:
> > > > 
> > > >   
> > > > 
> > > >   Hi Cor,
> > > > 
> > > >   
> > > > > > > >   Excuse the language, but frk. Ok,
looks
> > > > > > > > like we have a bug in low_pass. Or in
GCC. Or
> > > > > > > > SWIG (which does the python-wrapping of
the code
> > > > in firdes.cc). yay.
> > > > > > > >   So, let's narrow this down: on intel and
amd64,
> > > > same number of taps, right?
> > > > > > > >   Then: If I asked you to use GDB to verify
the
> > > > C++ low_pass function in
> > > > > > > > gr::filter::firdes::low_pass actually
returned
> > > > > > > > the right float values, would you feel
that,
> > > > with a few hints, be able to do that?
> > > >   Best regards,
> > > >   Marcus
> > > > 
> > > >   
> > > >    
> > > > 
> > > > On
> > > >   01.06.2017 07:20, Cor Legemaat wrote:
> > > > 
> > > > 
> > > > 
> > > > >   Hi:
> > > > > 
> > > > > filter.firdes.low_pass get called with:
> > > > >  * fractional_bw = 0.4
> > > > >  * trans_width = 0.1
> > > > >  * mid_transition_band = 0.45
> > > > >  * interpolation = 24
> > > > > 
> > > > > But return: (nan, <788 times nan>)
> > > > > 
> > > > > Regards:
> > > > > Cor
> > > > > 
> > > > > On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote:
> > > > > 
> > > > > > Hi Cor,
> > > > > > 
> > > > > > > > > > > > > >    * When using 1 as 
> > > > > > > > > > > > > > "taps"
there is output.
> > > > > > > 
> > > > > >  Aha!!
> 

Re: [Discuss-gnuradio] Read and Write a PMT input/output GNURadio C++

[Cristian Rodríguez]

Hi.

Thanks a lot for your time to read.

I read the two links that you shared to me, Marcus. Thanks a lot for your
help. But i still have a problem.

I've implemented as follows:

   - I create, the output, input and the handler:

message_port_register_out(pmt::mp("out_threshold"));

message_port_register_in(pmt::mp("in_threshold"));
set_msg_handler(pmt::mp("in_threshold"),
boost::bind(_short_impl::set_msg, this, _1));

   - I create, the next function to handle the inputs

void set_msg(pmt::pmt_t msg) { d_msg= msg;
dout << "Nueva lectura : " << d_msg << " ninput: " << std::endl;
if (pmt::is_integer(d_msg)) {
d_threshold = (double) pmt::to_long(d_msg);
} else if (pmt::is_real(d_msg)) {
d_threshold = pmt::to_double(d_msg);
} else {
 // We really expected an integer or a double here, so we don't know what
to do
throw std::runtime_error("expected an integer!");
}

 }

   - In the block i linked the input and the output, just to check that the
   function set_msg(), works.


[image: Imágenes integradas 3]

   - I compile the c++ codes, etc... all that is necessary.
   - I write the output as follows (that's working, i checked that with a
   message debug):

message_port_pub(pmt::mp("out_threshold"), pmt::cons(pmt::PMT_NIL,
pmt::from_double(d_threshold)));

   - When i start the flowgraph, the block put in the output a PMT message,
   after that, as it is linked with the input, the message go to the input
   port. When it is recevied, the function set_msg is launched, but the type
   of the number in the PMT is not recognized as double. *Here is my
   problem, I don't understand why it is happening, because the PMT that I put
   in the output is build from a double, then it is supposed, the one that i
   received is too a double. What do you think?*

[image: Imágenes integradas 2]


Thanks in advance.


Best regards,


Cristian
2017-06-26 12:45 GMT-05:00 Marcus Müller :

> Hi Cristian,
>
> you need to subscribe a *handler* to the message port. See:
>
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_
> Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code
>
> It's absolutely up to you what kind of PMT you're publishing over a
> message port, but it's canonical to have a PMT dict that maps
>
> pmt::mp("propertyname") -> pmt::whateversuitsyourproperty.
>
> As an example, see what the gr-uhd blocks accept [1]
>
> Best regards,
>
> Marcus
>
> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
> On 06/26/2017 07:35 PM, Cristian Rodríguez wrote:
>
> Hi all,
>
> I'm not sure about how to read and write PMT ports from and to local
> variables. I'm going to expose what i'm doing, and if someone can help me i
> would be very greatful.
>
> I've created an input and an output of PMT type.
>
> message_port_register_in(pmt::pmt_t in_threshold)
> message_port_register_out(pmt::pmt_t out_threshold)
>
> Now i want to read the port, and save the data in a local variable, do
> operations with that variable, and later write it in the output,
>
> I create the variables,
>
> double d_threshold;
> pmt::pmt_t target;
>
>
>
> *I read it, I don't know how to do it. But I suppose: *
> message_port_sub(pmt::pmt_t
> 
> in_threshold,pmt::pmt_t
> 
> target);
> d_threshold= pmt::to_double
> 
> (target);
>
> And, I think i can write it as follows:
>
> msg=pmt::from_double
> 
> (d_threshold);
> message_port_pub(pmt::pmt_t
> 
> out_threshold,pmt::pmt_t
> 
> msg);
>
> What do you think, i've seen several examples, and they do this,
> message_port_pub(pmt::mp("symbols"), pmt::cons(pmt::make_dict(),
> pmt::init_c32vector(48, symbols)));
>
> But I don't understand why it is necessary to use pmt::make_dict().
>
> Thanks in advance.
>
> Best regards,
>
> Cristian
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dB or dBm

[lists]

  Yes my comment was for synchronous sampling. You need to window for a general purpose condition. A simpler explanation is that the DFT uses "periodic glasses." That is you take your sample and slap identical sequences on both sides. If there is a discontinuity at either edge, then an artifact is generated. Scahfer/Oppenheim‎ or Rabiner/Gold go into this ad nausem.Essentially the rectangular window is used when you don't window at all, and there will be fuzz at the spike. Longer sequences can reduce this effect since the discontinuity contributes less. Lab instruments that use the 10MHz reference on the back go for a premium because you can sync all your instruments, avoiding many sampling issues. From: Marcus MüllerSent: Monday, June 26, 2017 9:18 AMTo: discuss-gnuradio@gnu.orgSubject: Re: [Discuss-gnuradio] dB or dBm
  

  
  
Hi!
I fully agree with "for modulated signals, power estimates get
  more complicated"; I have the uncontrollable urge to be a
  smartass, however, about this:


A sine wave only has one bin.


Nope. That's true only for oscillations that fit exactly in
the number of samples observed by the DFT you're doing. For example:
Assume you do a 1024-FFT¹.
When your sine has a period of let's say 64, everything is fine. You
get an DFT that's all zeros but for one bin, because the oscillation
that repeats 16 times within one DFT correlates perfectly with that
(so you get one peak for the negative- and one peak for the
positive-frequency complex sinusoid).
But suppose you do a sine of periodicity 65! Now, there's no single
bin that correlates "perfectly", because 65 is not a factor of 1024.
But: Parseval's Theorem states that the energy can't disappear. In
fact, that energy ends up in neighboring bins.

Which, by the way, is the reason why it's dangerous to trust a
DFT-based spectrum estimate, unless you know that the signal
bandwidth is significantly larger than the bin spacing. You can only
achieve that through increasing the DFT (FFT) length, and that in
turn increases the observation time.

Best regards,
Marcus

¹NB: DFTs /FFTs do not have to be powers of two in length.
There's plenty of FFT implementations for length that can be
factorized to "small" prime factors, and you can do any (non-FFT)
DFT length, albeit at higher computational cost. So, a 1023-DFT is
perfectly possible to have.

On 26.06.2017 11:02,
  li...@lazygranch.com wrote:


  When
a signal is modulated, you need to use a FFT technique ‎to get
the power. My experience is all based on outmoded analog modem
design, but the idea is the same. The hardware FFT based
spectrum analyzer sums up the power in all the bins and gives
you a number.  
  
  
  A
sine wave only has one bin. So a modulated signal will always
have lower peaks than a sine wave for the same power. 
  
  
  I
have a HackRF and appreciate  this work. 
  
  
  

  

  
From: Ralph A. Schmid, dk5ras
Sent: Sunday, June 25, 2017 11:44 PM
To: 'Murat Aksu'; Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] dB or dBm
  

  

  
  
  





  Well, dBm is an absolute power, based on 0dBm
  = 1mW. The dB figures of your receiver are only relative
  values, they have no meaning. However those get
  interesting when something changes. You just need to
  understand that the input of -20dBm power has nothing to
  do with the resulting reading of -58dB. When you reduce
  the input power for another 10 dB (no matter if you turn
  it down or if you insert an additional 10dB attenuation,
  makes no difference), then your reading should change from
  -58dB to -68dB. 
   
  Then you have found a part of the linear
  range, where a direct relationship exists between the
  input power and the power reading. 
   
  AGCs may influence this, 

Re: [Discuss-gnuradio] Undefined reference gr::blocks::count_bits8

[Ron Economos]

You have to add BLOCKS in addition to RUNTIME. That is, change the 
existing line:


set(GR_REQUIRED_COMPONENTS RUNTIME)

to:

set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS)

Ron


On 06/26/2017 02:46 PM, Antonis Tzougkarakis wrote:


Hello Marcus,

I have added this in my main cmake: set(GR_REQUIRED_COMPONENTS 
BLOCKS). Although, when I tried to compile it I got the following message:


Swig source
/home/tzugarak/git/gr-ieee802_15_4g_testing/swig/ieee802_15_4g_testing_swig.i:5: 
Error: Unable to find 'gnuradio.i'
swig/CMakeFiles/ieee802_15_4g_testing_swig_swig_2d0df.dir/build.make:114: 
recipe for target 'swig/ieee802_15_4g_testing_swig_swig_2d0df' failed

make[2]: *** [swig/ieee802_15_4g_testing_swig_swig_2d0df] Error 1
make[2]: *** Deleting file 'swig/ieee802_15_4g_testing_swig_swig_2d0df'
CMakeFiles/Makefile2:345: recipe for target 
'swig/CMakeFiles/ieee802_15_4g_testing_swig_swig_2d0df.dir/all' failed
make[1]: *** 
[swig/CMakeFiles/ieee802_15_4g_testing_swig_swig_2d0df.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs
[ 60%] Linking CXX shared library 
libgnuradio-ieee802_15_4g_testing-1.0.0git.so

[ 60%] Built target gnuradio-ieee802_15_4g_testing
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I would also want to mention that before my addition of the function 
gr::blocks::count_bits8 I had no problem at all with the compile 
process. Do you have any idea on how to fix this?


Thanks again.
Antonis


On 06/26/2017 11:26 PM, Marcus Müller wrote:


Hello Tzougkarakis,

do you also /link/ against gr-blocks? It's probably sufficient to add 
"BLOCKS" to GR_REQUIRED_COMPONENTS in your OOT's main CMakeLists.txt.


Best regards,

Marcus


On 26.06.2017 21:21, Tzougkarakis Antonis wrote:

Hello,

I have an OOT module which I have created with gr_modtool and I want 
to use the function count_bits_8  and count_bits_16 from 
gnuradio/blocks/count_bits.h. I have included the library in my c++ 
file but when I try to compile it I get the following message:


[ 80%] Linking CXX executable test-ieee802_15_4g_testing
libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined 
reference to `gr::blocks::count_bits8(unsigned int)'
libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined 
reference to `gr::blocks::count_bits16(unsigned int)'

collect2: error: ld returned 1 exit status
lib/CMakeFiles/test-ieee802_15_4g_testing.dir/build.make:130: recipe 
for target 'lib/test-ieee802_15_4g_testing' failed

make[2]: *** [lib/test-ieee802_15_4g_testing] Error 1
CMakeFiles/Makefile2:137: recipe for target 
'lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all' failed
make[1]: *** [lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all] 
Error 2

make[1]: *** Waiting for unfinished jobs
[ 80%] Built target ieee802_15_4g_testing_swig_swig_2d0df
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I know that it is a link error but I don't know what addition I 
should do in order to fix the error. Any help would be appreciated.


Thank you.


___
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 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] Undefined reference gr::blocks::count_bits8

[Antonis Tzougkarakis]

Hello Marcus,

I have added this in my main cmake: set(GR_REQUIRED_COMPONENTS BLOCKS). 
Although, when I tried to compile it I got the following message:


Swig source
/home/tzugarak/git/gr-ieee802_15_4g_testing/swig/ieee802_15_4g_testing_swig.i:5: 
Error: Unable to find 'gnuradio.i'
swig/CMakeFiles/ieee802_15_4g_testing_swig_swig_2d0df.dir/build.make:114: 
recipe for target 'swig/ieee802_15_4g_testing_swig_swig_2d0df' failed

make[2]: *** [swig/ieee802_15_4g_testing_swig_swig_2d0df] Error 1
make[2]: *** Deleting file 'swig/ieee802_15_4g_testing_swig_swig_2d0df'
CMakeFiles/Makefile2:345: recipe for target 
'swig/CMakeFiles/ieee802_15_4g_testing_swig_swig_2d0df.dir/all' failed
make[1]: *** 
[swig/CMakeFiles/ieee802_15_4g_testing_swig_swig_2d0df.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs
[ 60%] Linking CXX shared library 
libgnuradio-ieee802_15_4g_testing-1.0.0git.so

[ 60%] Built target gnuradio-ieee802_15_4g_testing
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I would also want to mention that before my addition of the function 
gr::blocks::count_bits8 I had no problem at all with the compile 
process. Do you have any idea on how to fix this?


Thanks again.
Antonis


On 06/26/2017 11:26 PM, Marcus Müller wrote:


Hello Tzougkarakis,

do you also /link/ against gr-blocks? It's probably sufficient to add 
"BLOCKS" to GR_REQUIRED_COMPONENTS in your OOT's main CMakeLists.txt.


Best regards,

Marcus


On 26.06.2017 21:21, Tzougkarakis Antonis wrote:

Hello,

I have an OOT module which I have created with gr_modtool and I want 
to use the function count_bits_8  and count_bits_16 from 
gnuradio/blocks/count_bits.h. I have included the library in my c++ 
file but when I try to compile it I get the following message:


[ 80%] Linking CXX executable test-ieee802_15_4g_testing
libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined 
reference to `gr::blocks::count_bits8(unsigned int)'
libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined 
reference to `gr::blocks::count_bits16(unsigned int)'

collect2: error: ld returned 1 exit status
lib/CMakeFiles/test-ieee802_15_4g_testing.dir/build.make:130: recipe 
for target 'lib/test-ieee802_15_4g_testing' failed

make[2]: *** [lib/test-ieee802_15_4g_testing] Error 1
CMakeFiles/Makefile2:137: recipe for target 
'lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all' failed

make[1]: *** [lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 80%] Built target ieee802_15_4g_testing_swig_swig_2d0df
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I know that it is a link error but I don't know what addition I 
should do in order to fix the error. Any help would be appreciated.


Thank you.


___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Undefined reference gr::blocks::count_bits8

[Marcus Müller]

Hello Tzougkarakis,

do you also /link/ against gr-blocks? It's probably sufficient to add
"BLOCKS" to GR_REQUIRED_COMPONENTS in your OOT's main CMakeLists.txt.

Best regards,

Marcus


On 26.06.2017 21:21, Tzougkarakis Antonis wrote:
> Hello,
>
> I have an OOT module which I have created with gr_modtool and I want
> to use the function count_bits_8  and count_bits_16 from
> gnuradio/blocks/count_bits.h. I have included the library in my c++
> file but when I try to compile it I get the following message:
>
> [ 80%] Linking CXX executable test-ieee802_15_4g_testing
> libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined
> reference to `gr::blocks::count_bits8(unsigned int)'
> libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined
> reference to `gr::blocks::count_bits16(unsigned int)'
> collect2: error: ld returned 1 exit status
> lib/CMakeFiles/test-ieee802_15_4g_testing.dir/build.make:130: recipe
> for target 'lib/test-ieee802_15_4g_testing' failed
> make[2]: *** [lib/test-ieee802_15_4g_testing] Error 1
> CMakeFiles/Makefile2:137: recipe for target
> 'lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all' failed
> make[1]: *** [lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> [ 80%] Built target ieee802_15_4g_testing_swig_swig_2d0df
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
>
> I know that it is a link error but I don't know what addition I should
> do in order to fix the error. Any help would be appreciated.
>
> Thank you.
>
>
> ___
> 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] Windows Binaries v1.3.0 posted

[Geof Nieboer]

All,

A new set of windows binaries are now posted.  A number of new packages
have been added.

http://www.gcndevelopment.com/gnuradio/downloads.htm

Changes:

   1. A complete debug version is now available, with the whole stack
   including all dependencies built in debug mode.  Symbols for Debug/Release
   are available as separate downloads.
   2. gr-fec features should now be operational.
   3. The following versions were updated:
  - GNURadio -> 3.7.11.1
  - gqrx -> 2.6.1
  - fftw -> 3.3.6-pl2
  - swig -> 3.0.12
  - libpng -> 1.6.29
   4. The following new OOT packages are now included:
  - gr-air-modes
  - gr-ais
  - gr-ax25
  - gr-burst (incl. bitarray)
  - gr-cdma
  - gr-display (incl. matplotlib)
  - gr-eventstream
  - gr-inspector (incl. tensorflow)
  - gr-lte
  - gr-mapper
  - gr-nacl
  - gr-paint (incl. PIL)
  - gr-radar
  - gr-rds
  - gr-specest
  - OpenLTE
   5. The build scripts received a tons of robustness upgrades, though
   again, end users are should use the installers, NOT build from source
   (that's not the windows way...)

There are examples for most of the OOT blocks in the /share directory tree.

While I have accomplished basic functional testing for most of the these
blocks, I could not accomplish the unit tests on many of them for a variety
of reasons (missing test data set etc.).
For the more complex blocks, (gr-lte, OpenLTE, gr-cdma), frankly I don't
have enough familiarity with these packages to know if they were acting as
intended.  SO, I'd appreciate any use reports on those blocks, even if it
is as simple as "worked as expected".

Known Issues:
-- gr-air-modes gui does not work, but the command line interface will

-- Switching a selector block with a UHD source will cause a crash

-- Switching between debug and release versions will cause intermittent
heap corruption issues.  Re-run application.

-- TCP Sink/Server are deprecated and do not function in the windows
version, use zeromq blocks

-- gr-newmod still does not work without a great deal of workarounds
(fixing that is the way ahead for 1.4.0)

-- agc3 block will run, but will adjust gain more slowly than on linux...
under investigation.

Enjoy!

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

[Discuss-gnuradio] Undefined reference gr::blocks::count_bits8

[Tzougkarakis Antonis]

Hello,

I have an OOT module which I have created with gr_modtool and I want to 
use the function count_bits_8  and count_bits_16 from 
gnuradio/blocks/count_bits.h. I have included the library in my c++ file 
but when I try to compile it I get the following message:


[ 80%] Linking CXX executable test-ieee802_15_4g_testing
libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined reference 
to `gr::blocks::count_bits8(unsigned int)'
libgnuradio-ieee802_15_4g_testing-1.0.0git.so.0.0.0: undefined reference 
to `gr::blocks::count_bits16(unsigned int)'

collect2: error: ld returned 1 exit status
lib/CMakeFiles/test-ieee802_15_4g_testing.dir/build.make:130: recipe for 
target 'lib/test-ieee802_15_4g_testing' failed

make[2]: *** [lib/test-ieee802_15_4g_testing] Error 1
CMakeFiles/Makefile2:137: recipe for target 
'lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all' failed

make[1]: *** [lib/CMakeFiles/test-ieee802_15_4g_testing.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 80%] Built target ieee802_15_4g_testing_swig_swig_2d0df
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I know that it is a link error but I don't know what addition I should 
do in order to fix the error. Any help would be appreciated.


Thank you.


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

Re: [Discuss-gnuradio] FM Modulation problem/question

[Phil Frost]

On Mon, Jun 26, 2017 at 1:50 PM Brashendeavours 
wrote:

> Thank you, Kevin. That is reassuring.
>
> My next question then, is since the deviation is affected by both
> amplitude and frequency, how would you recommend I empirically
> determine/set a peak deviation of 2400Hz for 1200Hz baseband?
> Is this experiment not possible to visualize/determine on a waterfall,
> simply?
>

 I think your confusion may be that deviation != occupied bandwidth.

If the sensitivity on the FM mod block is (2*pi*2400)/(48000), and the
sample rate is 48k, then the maximum deviation is 2.4kHz provided the
baseband signal does not exceed +/- 1. You can verify this by making the
baseband input a very low frequency sine wave, say 0.1 Hz. Viewed in the
waterfall you should then see the carrier move between -2.4 and +2.4kHz.

To determine the bandwidth occupied by the FM signal, you can use the
Carson bandwdith rule, which says the bandwidth required is the peak
deviation _plus the highest baseband frequency_, times two.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FM Modulation problem/question

[Kevin Reid]

On Mon, Jun 26, 2017 at 10:48 AM, Brashendeavours  wrote:

> My next question then, is since the deviation is affected by both
> amplitude and frequency, how would you recommend I empirically
> determine/set a peak deviation of 2400Hz for 1200Hz baseband?
>

The *deviation* is determined by the modulating signal and the modulator
sensitivity only. The overall *bandwidth*, which I assume is what you
actually want to control, is larger than that, and also depends on at what
point you consider a sideband too weak to care about (the sidebands
theoretically spread out across the entire spectrum, so you have to cut off
your counting — or apply a filter — at *some* point).

I'm afraid I'm not the person to explain how to do what you want in more
detail — I can spot some wrong notions but that's not the same as having
all the right ones. Perhaps someone else can comment.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Automating Transmit Gain

[Tellrell White]

Hello GuysI want to have the uhd sink block in my flow graph automatically 
cycle through a number of transmit gain values. I'm thinking of developing two 
blocks, one which will take in  a certain number of items and once it reaches a 
certain value a message will be sent to another block which will send a command 
to the uhd sink block to adjust the gain by a certain amount. I'm wondering if 
I could accomplish this task by just creating a single block similar to the 
"tagged stream to pdu" which takes in a stream of data and outputs a message. 
Any feedback would be greatly appreciated.
ThanksTellrell 

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

Re: [Discuss-gnuradio] FM Modulation problem/question

[Brashendeavours]

Thank you, Kevin. That is reassuring.

My next question then, is since the deviation is affected by both amplitude
and frequency, how would you recommend I empirically determine/set a peak
deviation of 2400Hz for 1200Hz baseband?
Is this experiment not possible to visualize/determine on a waterfall,
simply?

On Mon, Jun 26, 2017 at 1:26 PM, Kevin Reid  wrote:

> On Mon, Jun 26, 2017 at 10:07 AM, Brashendeavours <
> brashendeavo...@gmail.com> wrote:
>
>> Where my results differ from what I expect, is approximately above 100Hz.
>> Using an baseband of 1200Hz, I no longer get a signal sweeping from -ive to
>> +ive, I get [a constant frequency of 1200Hz on the waterfall](
>> http://imgur.com/BqGsRtK), and aliased multiples.
>>
>> I believe that my sample frequency of 48000 is sufficient as my mf is
>> 2400, and baseband is 1200.
>>
>> BW is (2 * (1200 + 2400)) = 7200Hz
>> Nyquist is 2*BW = 14400Hz
>>
>> So, what am I doing wrong?  Thanks in advance!
>>
>
> You're not doing anything wrong, and those are not aliases. They are the
> sidebands which result from frequency modulation.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Read and Write a PMT input/output GNURadio C++

[Marcus Müller]

Hi Cristian,

you need to subscribe a /handler/ to the message port. See:

https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.2_Adding_Message_Passing_to_the_Code

It's absolutely up to you what kind of PMT you're publishing over a
message port, but it's canonical to have a PMT dict that maps

pmt::mp("propertyname") -> pmt::whateversuitsyourproperty.

As an example, see what the gr-uhd blocks accept [1]

Best regards,

Marcus

[1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax

On 06/26/2017 07:35 PM, Cristian Rodríguez wrote:
> Hi all,
>
> I'm not sure about how to read and write PMT ports from and to local
> variables. I'm going to expose what i'm doing, and if someone can help
> me i would be very greatful.
>
> I've created an input and an output of PMT type.
>
> message_port_register_in(pmt::pmt_t in_threshold)
> message_port_register_out(pmt::pmt_t out_threshold)
>
> Now i want to read the port, and save the data in a local variable, do
> operations with that variable, and later write it in the output,
>
> I create the variables,
>
> double d_threshold;
> pmt::pmt_t target;
>
> *I read it, I don't know how to do it. But I suppose:
>
> *
> message_port_sub(pmt::pmt_t
> 
> in_threshold,pmt::pmt_t
> 
> target);
> d_threshold= pmt::to_double
> (target);
>
> And, I think i can write it as follows:
>
> msg=pmt::from_double
> (d_threshold);
> message_port_pub(pmt::pmt_t
> 
> out_threshold,pmt::pmt_t
> 
> msg);
>
> What do you think, i've seen several examples, and they do this,
> message_port_pub(pmt::mp("symbols"), pmt::cons(pmt::make_dict(),
> pmt::init_c32vector(48, symbols)));
>   
> But I don't understand why it is necessary to use pmt::make_dict().
>
> Thanks in advance.
>
> Best regards,
>
> Cristian
>
>
>
> ___
> 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] Read and Write a PMT input/output GNURadio C++

[Cristian Rodríguez]

Hi all,

I'm not sure about how to read and write PMT ports from and to local
variables. I'm going to expose what i'm doing, and if someone can help me i
would be very greatful.

I've created an input and an output of PMT type.

message_port_register_in(pmt::pmt_t in_threshold)
message_port_register_out(pmt::pmt_t out_threshold)

Now i want to read the port, and save the data in a local variable, do
operations with that variable, and later write it in the output,

I create the variables,

double d_threshold;
pmt::pmt_t target;



*I read it, I don't know how to do it. But I suppose:*
message_port_sub(pmt::pmt_t

in_threshold,pmt::pmt_t

target);
d_threshold= pmt::to_double

(target);

And, I think i can write it as follows:

msg=pmt::from_double

(d_threshold);
message_port_pub(pmt::pmt_t

out_threshold,pmt::pmt_t

msg);

What do you think, i've seen several examples, and they do this,
message_port_pub(pmt::mp("symbols"), pmt::cons(pmt::make_dict(),
pmt::init_c32vector(48, symbols)));

But I don't understand why it is necessary to use pmt::make_dict().

Thanks in advance.

Best regards,

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

Re: [Discuss-gnuradio] FM Modulation problem/question

[Kevin Reid]

On Mon, Jun 26, 2017 at 10:07 AM, Brashendeavours  wrote:

> Where my results differ from what I expect, is approximately above 100Hz.
> Using an baseband of 1200Hz, I no longer get a signal sweeping from -ive to
> +ive, I get [a constant frequency of 1200Hz on the waterfall](
> http://imgur.com/BqGsRtK), and aliased multiples.
>
> I believe that my sample frequency of 48000 is sufficient as my mf is
> 2400, and baseband is 1200.
>
> BW is (2 * (1200 + 2400)) = 7200Hz
> Nyquist is 2*BW = 14400Hz
>
> So, what am I doing wrong?  Thanks in advance!
>

You're not doing anything wrong, and those are not aliases. They are the
sidebands which result from frequency modulation.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FM Modulation problem/question

[Brashendeavours]

I am trying to wrap my head around FM modulation, and have setup some
experiments in GNU Radio to help, but they have only raised more questions.

I am trying to achieve a peak deviation of 2400Hz using a baseband signal
of 1200Hz. In my flowgraph [here](http://imgur.com/5pzSnsq), and [here](
http://imgur.com/uBDP3kF), you can see that I've set the fm block with a
sensitivity of (2*pi*2400)/(48000), and inversely for the gain of the
quadrature demodulation block.

Using a baseband of CONSTANT 1, I get the results as expected [here](
http://imgur.com/d5wxkwo).

Using a baseband of 15Hz, I also get results that I expect, (a signal
oscillating from ~-2400 to 2400Hz](http://imgur.com/VzG6bxx).

Where my results differ from what I expect, is approximately above 100Hz.
Using an baseband of 1200Hz, I no longer get a signal sweeping from -ive to
+ive, I get [a constant frequency of 1200Hz on the waterfall](
http://imgur.com/BqGsRtK), and aliased multiples.

I believe that my sample frequency of 48000 is sufficient as my mf is 2400,
and baseband is 1200.

BW is (2 * (1200 + 2400)) = 7200Hz
Nyquist is 2*BW = 14400Hz

So, what am I doing wrong?  Thanks in advance!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dB or dBm

[Marcus Müller]

Hi!

I fully agree with "for modulated signals, power estimates get more
complicated"; I have the uncontrollable urge to be a smartass, however,
about this:


> A sine wave only has one bin.

Nope. That's true only for oscillations that fit /exactly/ in the number
of samples observed by the DFT you're doing. For example:
Assume you do a 1024-FFT¹.
When your sine has a period of let's say 64, everything is fine. You get
an DFT that's all zeros but for one bin, because the oscillation that
repeats 16 times within one DFT correlates perfectly with that (so you
get one peak for the negative- and one peak for the positive-frequency
complex sinusoid).
But suppose you do a sine of periodicity 65! Now, there's no single bin
that correlates "perfectly", because 65 is not a factor of 1024. But:
Parseval's Theorem states that the energy can't disappear. In fact, that
energy ends up in neighboring bins.

Which, by the way, is the reason why it's dangerous to trust a DFT-based
spectrum estimate, unless you know that the signal bandwidth is
significantly larger than the bin spacing. You can only achieve that
through increasing the DFT (FFT) length, and that in turn increases the
observation time.

Best regards,
Marcus

¹NB: DFTs /FFTs do /not/ have to be powers of two in length. There's
plenty of FFT implementations for length that can be factorized to
"small" prime factors, and you can do any (non-FFT) DFT length, albeit
at higher computational cost. So, a 1023-DFT is perfectly possible to have.

On 26.06.2017 11:02, li...@lazygranch.com wrote:
> When a signal is modulated, you need to use a FFT technique ‎to get
> the power. My experience is all based on outmoded analog modem design,
> but the idea is the same. The hardware FFT based spectrum analyzer
> sums up the power in all the bins and gives you a number.  
>
> A sine wave only has one bin. So a modulated signal will always have
> lower peaks than a sine wave for the same power.
>
> I have a HackRF and appreciate  this work.
>
> *From: *Ralph A. Schmid, dk5ras
> *Sent: *Sunday, June 25, 2017 11:44 PM
> *To: *'Murat Aksu'; Discuss-gnuradio@gnu.org
> *Subject: *Re: [Discuss-gnuradio] dB or dBm
>
>
> Well, dBm is an absolute power, based on 0dBm = 1mW. The dB figures of
> your receiver are only relative values, they have no meaning. However
> those get interesting when something changes. You just need to
> understand that the input of -20dBm power has nothing to do with the
> resulting reading of -58dB. When you reduce the input power for
> another 10 dB (no matter if you turn it down or if you insert an
> additional 10dB attenuation, makes no difference), then your reading
> should change from -58dB to -68dB.
>
>  
>
> Then you have found a part of the linear range, where a direct
> relationship exists between the input power and the power reading.
>
>  
>
> AGCs may influence this, also nobody knows how accurate the peak power
> measuring works. As others already had mentioned, it could be useful
> to play with unmodulated carriers, just to get a feeling for this stuff.
>
>
> Ralph.
>
>  
>
> *From:*Murat Aksu [mailto:muratc...@hotmail.com]
> *Sent:* Thursday, June 22, 2017 4:58 PM
> *To:* Ralph A. Schmid, dk5ras
> *Subject:* Re: [Discuss-gnuradio] dB or dBm
>
>  
>
> Dear Ralph,
>
>  
>
> Thank you so much for your support. I really do not understand these
> dB values. When I inject 802.11g signal with -20 dBm power level and
> 20 dB attenuator which means -40 dBm going in the HackRF One, after
> running gr-scan command line or QSpectrumAnalyzer GUI, I am observing
> peak power values around -58 dB.
>
>  
>
> As you suggest, if I use 30 dB attenuator instead of 20 dB attenuator,
> I will still get some dB values and really don't know how they are
> related to power levels.
>
>  
>
> I would appreciate your guidance about this confusion.
>
>  
>
> Best,
>
> Murat
>
>  
>
> 
>
> *From:*Ralph A. Schmid, dk5ras  >
> *Sent:* Thursday, June 22, 2017 7:38 AM
> *To:* 'GNUBeginner'; Discuss-gnuradio@gnu.org
> 
> *Subject:* RE: [Discuss-gnuradio] dB or dBm
>
>  
>
> But still the dynamic range usually ends already quite below the maximum
> allowed level what is more a kind of hardware protection rule.
>
> Add some more attenuation and see if at least a 5dB change on your
> transmitter creates a 5dB change on your SDR. Then you are in the linear
> range and can start trying to calibrate the thingy for your frequency. And
> turn off AGC if this option is available.
>
> Ralph.
>
> > -Original Message-
> > From: Discuss-gnuradio [mailto:discuss-gnuradio-
> > bounces+ralph=schmid@gnu.org
> ] On Behalf Of GNUBeginner
> > Sent: Wednesday, June 21, 2017 10:48 PM
> > To: Discuss-gnuradio@gnu.org 
> > Subject: Re: [Discuss-gnuradio] dB or dBm
> >
> > 

Re: [Discuss-gnuradio] libqwt

[GNUBeginner]

Hello Sebastian,

Could you please show me how to build it from sources on Ubuntu 14.04?

Thanks



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/libqwt-tp64355p64370.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Rational Resampler no output.

[Marcus Müller]

That's mightily interesting! I feel like we should be doing bug reports,
but I'm not sure where.


On 26.06.2017 06:42, Cor Legemaat wrote:
> Found it:
>
> Created an C++ app that called that function with the same parameter
> values as with python for this flow graph. Witch I was able to debug
> normally.
>
> In window.cc line 265, with i = ntaps - 1, temp =
> 1.002 that cause sqrt (0) witch return "-nan" on the
> next line and screw all the rest of the calculations.
>
> This only happens when compiled with "CFLAGS=-march=native -O2", if I
> don't specify the march it's working correctly. The function is called
> on my system with taps=787 and beta = 7.
>
> Regards:
> Cor
>
> On Wed, 2017-06-21 at 15:13 +0200, Cor Legemaat wrote:
>> Hi:
>>
>> Sorry for the late replay... The intel pc call filter.firdes.low_pass
>> with the same values but return 768 proper float values, not like the
>> 's on the AMD pc.
>>
>> Tried to debug with "nemiver /usr/bin/python2.7 -u
>> /fm_receiver.py" and the breakpoint at firdes.cc line 100 witch
>> get triggered and I can read the function parameters but when I try
>> to step true the function it jumps to the assembly of pthread. If I
>> put more breakpoints in firdes.cc I get back to the function but cant
>> read any variables any more. Also tried exporting "export
>> GR_SCHEDULER=STS" but the same symptoms.
>>
>> Don't know if Ubuntu will trigger the bug it's probably compiled more
>> generic...
>>
>> Regards:
>> Cor
>>
>> On Wed, 2017-06-07 at 04:26 -0400, Anon Lister wrote:
>>> I have an AMD system with the same chip running Ubuntu 16.xx. I can
>>> probably try to duplicate this weekend, if Cor doesn't get to it, as
>>> another data point. 
>>>
>>> On Jun 5, 2017 3:14 PM, "Marcus Müller" >> > wrote:
>>>
>>> Hi Cor,
>>>
>>> Excuse the language, but frk. Ok, looks like we have a bug
>>> in low_pass. Or in GCC. Or SWIG (which does the python-wrapping
>>> of the code in firdes.cc). yay.
>>>
>>> So, let's narrow this down: on intel and amd64, same number of
>>> taps, right?
>>>
>>> Then: If I asked you to use GDB to verify the C++ low_pass
>>> function in gr::filter::firdes::low_pass actually returned the
>>> right float values, would you feel that, with a few hints, be
>>> able to do that?
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>>
>>> On 01.06.2017 07:20, Cor Legemaat wrote:
 Hi:

 filter.firdes.low_pass get called with:
  * fractional_bw = 0.4
  * trans_width = 0.1
  * mid_transition_band = 0.45
  * interpolation = 24

 But return: (nan, <788 times nan>)

 Regards:
 Cor

 On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote:
> Hi Cor,
>>  * When using 1 as "taps" there is output.
>  Aha!!
> So, here's the thing: something might be going wrong in the python
> code that sets up the taps automatically if you don't set them
> explicitly. 
> Maybe you can figure out where things go wrong; the interesting part
> (maybe add some `print`s here?) from [1]:
>
> # If we don't have user-provided taps, reduce the interp and
> # decim values by the GCD (if there is one) and then define
> # the taps from these new values.
> if taps is None:
> interpolation = interpolation // d
> decimation = decimation // d
> taps = design_filter(interpolation, decimation,
> fractional_bw)
>
> and
>
>
> def design_filter(interpolation, decimation, fractional_bw):
> """
> Given the interpolation rate, decimation rate and a fractional
> bandwidth,
> design a set of taps.
>
> Args:
> interpolation: interpolation factor (integer > 0)
> decimation: decimation factor (integer > 0)
> fractional_bw: fractional bandwidth in (0, 0.5)  0.4 works
> well. (float)
> Returns:
> : sequence of numbers
> """
>
> if fractional_bw >= 0.5 or fractional_bw <= 0:
> raise ValueError, "Invalid fractional_bandwidth, must be in
> (0, 0.5)"
>
> beta = 7.0
> halfband = 0.5
> rate = float(interpolation)/float(decimation)
> if(rate >= 1.0):
> trans_width = halfband - fractional_bw
> mid_transition_band = halfband - trans_width/2.0
> else:
> trans_width = rate*(halfband - fractional_bw)
> mid_transition_band = rate*halfband - trans_width/2.0
>
> taps = filter.firdes.low_pass(interpolation,
> # gain
> 

Re: [Discuss-gnuradio] dB or dBm

[lists]

  When a signal is modulated, you need to use a FFT technique ‎to get the power. My experience is all based on outmoded analog modem design, but the idea is the same. The hardware FFT based spectrum analyzer sums up the power in all the bins and gives you a number.  A sine wave only has one bin. So a modulated signal will always have lower peaks than a sine wave for the same power. I have a HackRF and appreciate  this work.From: Ralph A. Schmid, dk5rasSent: Sunday, June 25, 2017 11:44 PMTo: 'Murat Aksu'; Discuss-gnuradio@gnu.orgSubject: Re: [Discuss-gnuradio] dB or dBmWell, dBm is an absolute power, based on 0dBm = 1mW. The dB figures of your receiver are only relative values, they have no meaning. However those get interesting when something changes. You just need to understand that the input of -20dBm power has nothing to do with the resulting reading of -58dB. When you reduce the input power for another 10 dB (no matter if you turn it down or if you insert an additional 10dB attenuation, makes no difference), then your reading should change from -58dB to -68dB.  Then you have found a part of the linear range, where a direct relationship exists between the input power and the power reading.  AGCs may influence this, also nobody knows how accurate the peak power measuring works. As others already had mentioned, it could be useful to play with unmodulated carriers, just to get a feeling for this stuff.Ralph. From: Murat Aksu [mailto:muratc...@hotmail.com] Sent: Thursday, June 22, 2017 4:58 PMTo: Ralph A. Schmid, dk5rasSubject: Re: [Discuss-gnuradio] dB or dBm Dear Ralph, Thank you so much for your support. I really do not understand these dB values. When I inject 802.11g signal with -20 dBm power level and 20 dB attenuator which means -40 dBm going in the HackRF One, after running gr-scan command line or QSpectrumAnalyzer GUI, I am observing peak power values around -58 dB. As you suggest, if I use 30 dB attenuator instead of 20 dB attenuator, I will still get some dB values and really don't know how they are related to power levels. I would appreciate your guidance about this confusion. Best,Murat From: Ralph A. Schmid, dk5ras Sent: Thursday, June 22, 2017 7:38 AMTo: 'GNUBeginner'; Discuss-gnuradio@gnu.orgSubject: RE: [Discuss-gnuradio] dB or dBm  But still the dynamic range usually ends already quite below the maximumallowed level what is more a kind of hardware protection rule.Add some more attenuation and see if at least a 5dB change on yourtransmitter creates a 5dB change on your SDR. Then you are in the linearrange and can start trying to calibrate the thingy for your frequency. Andturn off AGC if this option is available.Ralph.> -Original Message-> From: Discuss-gnuradio [mailto:discuss-gnuradio-> bounces+ralph=schmid@gnu.org] On Behalf Of GNUBeginner> Sent: Wednesday, June 21, 2017 10:48 PM> To: Discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] dB or dBm> > I am already aware of what the maximum allowable receiver power which is-5> dBm. That is why I am starting from 0 dBm with 20 dB attenuator before> injecting it to the HackRF One.> > > > --> View this message in context: http://gnuradio.4.n7.nabble.com/dB-or-dBm-> tp64323p64335.html> Sent from the GnuRadio mailing list archive at Nabble.com.> > ___> 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] dB or dBm

[Ralph A. Schmid, dk5ras]

Well, dBm is an absolute power, based on 0dBm = 1mW. The dB figures of your
receiver are only relative values, they have no meaning. However those get
interesting when something changes. You just need to understand that the
input of -20dBm power has nothing to do with the resulting reading of -58dB.
When you reduce the input power for another 10 dB (no matter if you turn it
down or if you insert an additional 10dB attenuation, makes no difference),
then your reading should change from -58dB to -68dB. 

 

Then you have found a part of the linear range, where a direct relationship
exists between the input power and the power reading. 

 

AGCs may influence this, also nobody knows how accurate the peak power
measuring works. As others already had mentioned, it could be useful to play
with unmodulated carriers, just to get a feeling for this stuff.


Ralph.

 

From: Murat Aksu [mailto:muratc...@hotmail.com] 
Sent: Thursday, June 22, 2017 4:58 PM
To: Ralph A. Schmid, dk5ras
Subject: Re: [Discuss-gnuradio] dB or dBm

 

Dear Ralph,

 

Thank you so much for your support. I really do not understand these dB
values. When I inject 802.11g signal with -20 dBm power level and 20 dB
attenuator which means -40 dBm going in the HackRF One, after running
gr-scan command line or QSpectrumAnalyzer GUI, I am observing peak power
values around -58 dB.

 

As you suggest, if I use 30 dB attenuator instead of 20 dB attenuator, I
will still get some dB values and really don't know how they are related to
power levels.

 

I would appreciate your guidance about this confusion.

 

Best,

Murat

 

  _  

From: Ralph A. Schmid, dk5ras <  ra...@schmid.xxx>
Sent: Thursday, June 22, 2017 7:38 AM
To: 'GNUBeginner';  
Discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] dB or dBm 

 

But still the dynamic range usually ends already quite below the maximum
allowed level what is more a kind of hardware protection rule.

Add some more attenuation and see if at least a 5dB change on your
transmitter creates a 5dB change on your SDR. Then you are in the linear
range and can start trying to calibrate the thingy for your frequency. And
turn off AGC if this option is available.

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
>  
bounces+ralph=schmid@gnu.org] On Behalf Of GNUBeginner
> Sent: Wednesday, June 21, 2017 10:48 PM
> To:   Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dB or dBm
> 
> I am already aware of what the maximum allowable receiver power which is
-5
> dBm. That is why I am starting from 0 dBm with 20 dB attenuator before
> injecting it to the HackRF One.
> 
> 
> 
> --
> View this message in context:

http://gnuradio.4.n7.nabble.com/dB-or-dBm-
> tp64323p64335.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> 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