Re: [Discuss-gnuradio] cross correlation in the time domain and through Fourier tranform ?

[jmfriedt]

as a followup to my own post, some simulation with a smaller FFT size
and synthetic data (as opposed to records from the sound card) do yield
the expected behavior of an FFT analyzer used in cross-correlation
mode: jmfriedt.sequanux.org/test_vector.grc generates a
cross-correlation peak every N samples, here with N=256. At 10 kHz,
that makes for a cross correation peak every 25.6 ms.

JM 

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

Re: [Discuss-gnuradio] Python and C++ codes of the blocks IEEE 802.11

[Bastian Bloessl]

Hi Christian,

> On 24. Jun 2017, at 22:50, Cristian Rodríguez 
>  wrote:
> 
> This parameter is no global, I mean, when I use the wifi_phy_hier.grc in the 
> transceiver.grc or tx.grc, etc, If I modify the parameter before launch the 
> simulation it is ok, the change has effect in the flowgraph, but if i add a 
> QT GUI Range, and I modify it after the beginning of the simulation it 
> doesn't have effect. Then I think the "set" of the parameter is no global 
> (thinking in OOP).

Currently, the sensitivity is only through the constructor of the Sync Short 
block. That means it’s set when the block is instantiated and cannot be changed 
afterwards.

If you want to change the parameter while the flow graph is running (through a 
slider in the GUI, for example), you will have to extend the Sync Short block 
with a callback.
You could have a look at the Frame Equalizer block, for example. It allows 
changing the algorithm during run-time.

To extend Sync Short you have to:
- add the callback function to the XML description of the block:  (see here 
https://github.com/bastibl/gr-ieee802-11/blob/next/grc/ieee802_11_frame_equalizer.xml#L9)
- implement the callback for the block (note that the callback is a public 
function that has also to be added to the definition in /include/, and the use 
of a mutex since ‘work’ and the callback are called in different thread 
contexts).

If you implement this, please make a pull-request :-)

> 
> Besides, this parameter is used in the WiFi Sync Short, and i want to modify 
> this block to set that parameter as an input, and create another block in 
> which i'm going to include a fuzzy system to set the parameter depending on 
> other parameters.

For that use-case, I would extend the Sync Short block with an async message 
input (the gray ports in GRC) and let your fuzzy system send PMTs with the 
updated sensitivity values.

Best,
Bastian




> But at the very first, I need to be able to modify the parameter Threshold 
> (sensitivity) globally.
> 
> 
> 
> Thanks a lot for your time Marcus.
> 
> Best regards,
> 
> Cristian.
> 
>  
> 
> Best regards,
> 
> Marcus
> 
> 
> On 06/24/2017 11:17 PM, Cristian Rodríguez wrote:
>> Hi all,
>> 
>> I hope all is going well.
>> 
>> I was trying to modify the code of some blocks, where is usually the code of 
>> an specific block or flowgraph?
>> 
>> Specifically, I want to modify the number of inputs in the 
>> wifi_phy_hier.grc, and put the variable Sensitivity as global, I mean, that 
>> i can modify it while the code is running, as rx_gain or tx_gain. 
>> 
>> But in general, where can i find the codes? Are there some predefined 
>> folders?
>> 
>> 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] Python and C++ codes of the blocks IEEE 802.11

[Cristian Rodríguez]

2017-06-25 5:23 GMT-05:00 Bastian Bloessl :

> Hi Christian,
>
> > On 24. Jun 2017, at 22:50, Cristian Rodríguez <
> cristian.rodriguez...@gmail.com> wrote:
> >
> > This parameter is no global, I mean, when I use the wifi_phy_hier.grc in
> the transceiver.grc or tx.grc, etc, If I modify the parameter before launch
> the simulation it is ok, the change has effect in the flowgraph, but if i
> add a QT GUI Range, and I modify it after the beginning of the simulation
> it doesn't have effect. Then I think the "set" of the parameter is no
> global (thinking in OOP).
>
> Currently, the sensitivity is only through the constructor of the Sync
> Short block. That means it’s set when the block is instantiated and cannot
> be changed afterwards.
>
> If you want to change the parameter while the flow graph is running
> (through a slider in the GUI, for example), you will have to extend the
> Sync Short block with a callback.
> You could have a look at the Frame Equalizer block, for example. It allows
> changing the algorithm during run-time.
>
> To extend Sync Short you have to:
> - add the callback function to the XML description of the block:  (see
> here https://github.com/bastibl/gr-ieee802-11/blob/next/grc/
> ieee802_11_frame_equalizer.xml#L9)
> - implement the callback for the block (note that the callback is a public
> function that has also to be added to the definition in /include/, and the
> use of a mutex since ‘work’ and the callback are called in different thread
> contexts).
>
> If you implement this, please make a pull-request :-)
>
> Thanks a lot for your answer Bastian.

I'll implement this and after i write again.


> >
> > Besides, this parameter is used in the WiFi Sync Short, and i want to
> modify this block to set that parameter as an input, and create another
> block in which i'm going to include a fuzzy system to set the parameter
> depending on other parameters.
>
> For that use-case, I would extend the Sync Short block with an async
> message input (the gray ports in GRC) and let your fuzzy system send PMTs
> with the updated sensitivity values.
>
>
First i'll do the change in the xml, and when it is working i will
introduce the other block.

Thanks for your time to read.

Best regards,

Cristian


> Best,
> Bastian
>
>
>
>
> > But at the very first, I need to be able to modify the parameter
> Threshold (sensitivity) globally.
> >
> > 
> >
> > Thanks a lot for your time Marcus.
> >
> > Best regards,
> >
> > Cristian.
> >
> >
> >
> > Best regards,
> >
> > Marcus
> >
> >
> > On 06/24/2017 11:17 PM, Cristian Rodríguez wrote:
> >> Hi all,
> >>
> >> I hope all is going well.
> >>
> >> I was trying to modify the code of some blocks, where is usually the
> code of an specific block or flowgraph?
> >>
> >> Specifically, I want to modify the number of inputs in the
> wifi_phy_hier.grc, and put the variable Sensitivity as global, I mean, that
> i can modify it while the code is running, as rx_gain or tx_gain.
> >>
> >> But in general, where can i find the codes? Are there some predefined
> folders?
> >>
> >> Thanks in advance.
> >>
> >> Best regards,
> >>
> >> Cristian
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC 2017] gr-sigmf: Weekly update

[Kostis Triantafyllakis]

Hello,

There is an example flowgraph under the /examples directory of the 
gr-sigmf module, that demonstrates the functionality of sigmf sink block.
Please take a look at the gr-sigmf repo 
.
Also, you can find a video in the latest post at my blog 
.


Thanks!

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

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

[Cor Legemaat]

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
> > > > > > > >  
interpolation,
> > > > # Fs
> > > > > > > >    

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