subject:"\[Discuss\-gnuradio\] Moving average"

Re: [Discuss-gnuradio] Moving average

2019-01-23 Thread CEL

Basics of python types:
Phase * (float(SampleRate)/360)

(your own parentheses are actually mathematically irrelevant, and
numerically make the result less stable, so I' omit them, i.e. Phase *
float(SampleRate)/360)

Best regards,
Marcus
On Tue, 2019-01-22 at 06:30 -0700, david vanhorn wrote:
> So how would you represent this expression so that it evaluates as floating 
> point:
> As the "Delay" variable in a delay block:  Phase * (SampleRate/360)
> 
> 
> On Tue, Jan 22, 2019 at 5:59 AM david vanhorn  wrote:
> > Nope.
> > 
> > 1/Averaging evaluates to zero.
> > 1/Averaging. (trailing period) does not evaluate, either in the Moving 
> > Average parameters, or as a separate variable.
> > 
> > 
> > On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson  
> > wrote:
> > > 1/5 is zero using integer division in python.
> > > 
> > > Try using float division
> > > 
> > >  1/4000.
> > >  1/5.
> > > 
> > > -- Cinaed
> > > 
> > > 
> > > On 1/21/19 4:41 PM, david vanhorn wrote:
> > > > The docs say that I need to set Scale to the inverse of the Length.
> > > > Ok, I interpret that as Length = 4000 and Scale = 1/4000
> > > > The docs here:
> > > > https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> > > > says that Scale is a float.
> > > > 
> > > > The discussion here clearly shows Scale working for values <1 and >0
> > > > https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> > > > 
> > > > If I enter a scale value by hand, like 0.2, then I see 200m which is
> > > > what I expect.
> > > > If I enter a scale value as (1/5) then I see 0.
> > > > If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
> > > > field of the moving average, it evaluates to 0.
> > > > 
> > > > 
> > > > When I enter the values in the block, it looks like scale is an int,
> > > > which makes 1/4000 or indeed 1/(>1) problematic in that it always
> > > > evaluates to zero, which kinda breaks things.
> > > > When I enter 1/2 I get "0"
> > > > 
> > > > When I hover over the field to enter Scale, I get Type Real.
> > > > 
> > > > I have the input and output of my integrator connected to a QT GUI Time
> > > > Sink, and while the input waveform is what I expect, if I have any <1
> > > > Scale parameter, the output is 0.
> > > > 
> > > > 
> > > > Is something broken here, or is it me?
> > > > I've not had any problems using simple math in any of the other fields
> > > > where appropriate.
> > > > 
> > > > 
> > > > -- 
> > > > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> > > > 
> > > > ___
> > > > 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
> > 
> > 
> > -- 
> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average

2019-01-23 Thread Phil Frost

from __future__ import division

...in the script at the top or as a GRC block will also do the trick.

On Tue, Jan 22, 2019, 17:42 Cinaed Simson  On 1/22/19 4:59 AM, david vanhorn wrote:
> > Nope.
> >
> > 1/Averaging evaluates to zero.
> > 1/Averaging. (trailing period) does not evaluate, either in the Moving
> > Average parameters, or as a separate variable.
>
> You can't put a "." after a variable.
>
> Use
>
>   1/float(Averaging)
>
> or
>
>   1./Averaging
>
> -- Cinaed
>
>
> >
> >
> > On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson  > > wrote:
> >
> > 1/5 is zero using integer division in python.
> >
> > Try using float division
> >
> >  1/4000.
> >  1/5.
> >
> > -- Cinaed
> >
> >
> > On 1/21/19 4:41 PM, david vanhorn wrote:
> > > The docs say that I need to set Scale to the inverse of the Length.
> > > Ok, I interpret that as Length = 4000 and Scale = 1/4000
> > > The docs here:
> > >
> >
> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> > > says that Scale is a float.
> > >
> > > The discussion here clearly shows Scale working for values <1 and
> >0
> > >
> >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> > >
> > > If I enter a scale value by hand, like 0.2, then I see 200m which
> is
> > > what I expect.
> > > If I enter a scale value as (1/5) then I see 0.
> > > If I set a variable called "Scale" = (1/) and enter "Scale" in the
> > Scale
> > > field of the moving average, it evaluates to 0.
> > >
> > >
> > > When I enter the values in the block, it looks like scale is an
> int,
> > > which makes 1/4000 or indeed 1/(>1) problematic in that it always
> > > evaluates to zero, which kinda breaks things.
> > > When I enter 1/2 I get "0"
> > >
> > > When I hover over the field to enter Scale, I get Type Real.
> > >
> > > I have the input and output of my integrator connected to a QT GUI
> > Time
> > > Sink, and while the input waveform is what I expect, if I have any
> <1
> > > Scale parameter, the output is 0.
> > >
> > >
> > > Is something broken here, or is it me?
> > > I've not had any problems using simple math in any of the other
> fields
> > > where appropriate.
> > >
> > >
> > > --
> > > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
>
>
> ___
> 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] Moving average

2019-01-22 Thread Cinaed Simson

On 1/22/19 4:59 AM, david vanhorn wrote:
> Nope.
> 
> 1/Averaging evaluates to zero.
> 1/Averaging. (trailing period) does not evaluate, either in the Moving
> Average parameters, or as a separate variable.

You can't put a "." after a variable.

Use

  1/float(Averaging)

or

  1./Averaging

-- Cinaed


> 
> 
> On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson  > wrote:
> 
> 1/5 is zero using integer division in python.
> 
> Try using float division
> 
>  1/4000.
>  1/5.
> 
> -- Cinaed
> 
> 
> On 1/21/19 4:41 PM, david vanhorn wrote:
> > The docs say that I need to set Scale to the inverse of the Length.
> > Ok, I interpret that as Length = 4000 and Scale = 1/4000
> > The docs here:
> >
> 
> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> > says that Scale is a float.
> >
> > The discussion here clearly shows Scale working for values <1 and >0
> >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> >
> > If I enter a scale value by hand, like 0.2, then I see 200m which is
> > what I expect.
> > If I enter a scale value as (1/5) then I see 0.
> > If I set a variable called "Scale" = (1/) and enter "Scale" in the
> Scale
> > field of the moving average, it evaluates to 0.
> >
> >
> > When I enter the values in the block, it looks like scale is an int,
> > which makes 1/4000 or indeed 1/(>1) problematic in that it always
> > evaluates to zero, which kinda breaks things.
> > When I enter 1/2 I get "0"
> >
> > When I hover over the field to enter Scale, I get Type Real.
> >
> > I have the input and output of my integrator connected to a QT GUI
> Time
> > Sink, and while the input waveform is what I expect, if I have any <1
> > Scale parameter, the output is 0.
> >
> >
> > Is something broken here, or is it me?
> > I've not had any problems using simple math in any of the other fields
> > where appropriate.
> >
> >
> > --
> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> >
> > ___
> > 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
> 
> 
> 
> -- 
> K1FZY (WA4TPW) SK  9/29/37-4/13/15


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

Re: [Discuss-gnuradio] Moving average

2019-01-22 Thread david vanhorn

So how would you represent this expression so that it evaluates as floating
point:
As the "Delay" variable in a delay block:  Phase * (SampleRate/360)


On Tue, Jan 22, 2019 at 5:59 AM david vanhorn  wrote:

> Nope.
>
> 1/Averaging evaluates to zero.
> 1/Averaging. (trailing period) does not evaluate, either in the Moving
> Average parameters, or as a separate variable.
>
>
> On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson 
> wrote:
>
>> 1/5 is zero using integer division in python.
>>
>> Try using float division
>>
>>  1/4000.
>>  1/5.
>>
>> -- Cinaed
>>
>>
>> On 1/21/19 4:41 PM, david vanhorn wrote:
>> > The docs say that I need to set Scale to the inverse of the Length.
>> > Ok, I interpret that as Length = 4000 and Scale = 1/4000
>> > The docs here:
>> >
>> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
>> > says that Scale is a float.
>> >
>> > The discussion here clearly shows Scale working for values <1 and >0
>> >
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
>> >
>> > If I enter a scale value by hand, like 0.2, then I see 200m which is
>> > what I expect.
>> > If I enter a scale value as (1/5) then I see 0.
>> > If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
>> > field of the moving average, it evaluates to 0.
>> >
>> >
>> > When I enter the values in the block, it looks like scale is an int,
>> > which makes 1/4000 or indeed 1/(>1) problematic in that it always
>> > evaluates to zero, which kinda breaks things.
>> > When I enter 1/2 I get "0"
>> >
>> > When I hover over the field to enter Scale, I get Type Real.
>> >
>> > I have the input and output of my integrator connected to a QT GUI Time
>> > Sink, and while the input waveform is what I expect, if I have any <1
>> > Scale parameter, the output is 0.
>> >
>> >
>> > Is something broken here, or is it me?
>> > I've not had any problems using simple math in any of the other fields
>> > where appropriate.
>> >
>> >
>> > --
>> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
>> >
>> > ___
>> > 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
>>
>
>
> --
> K1FZY (WA4TPW) SK  9/29/37-4/13/15
>


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average

2019-01-22 Thread david vanhorn

Nope.

1/Averaging evaluates to zero.
1/Averaging. (trailing period) does not evaluate, either in the Moving
Average parameters, or as a separate variable.


On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson 
wrote:

> 1/5 is zero using integer division in python.
>
> Try using float division
>
>  1/4000.
>  1/5.
>
> -- Cinaed
>
>
> On 1/21/19 4:41 PM, david vanhorn wrote:
> > The docs say that I need to set Scale to the inverse of the Length.
> > Ok, I interpret that as Length = 4000 and Scale = 1/4000
> > The docs here:
> >
> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> > says that Scale is a float.
> >
> > The discussion here clearly shows Scale working for values <1 and >0
> >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> >
> > If I enter a scale value by hand, like 0.2, then I see 200m which is
> > what I expect.
> > If I enter a scale value as (1/5) then I see 0.
> > If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
> > field of the moving average, it evaluates to 0.
> >
> >
> > When I enter the values in the block, it looks like scale is an int,
> > which makes 1/4000 or indeed 1/(>1) problematic in that it always
> > evaluates to zero, which kinda breaks things.
> > When I enter 1/2 I get "0"
> >
> > When I hover over the field to enter Scale, I get Type Real.
> >
> > I have the input and output of my integrator connected to a QT GUI Time
> > Sink, and while the input waveform is what I expect, if I have any <1
> > Scale parameter, the output is 0.
> >
> >
> > Is something broken here, or is it me?
> > I've not had any problems using simple math in any of the other fields
> > where appropriate.
> >
> >
> > --
> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> >
> > ___
> > 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
>


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average

2019-01-21 Thread Cinaed Simson

1/5 is zero using integer division in python.

Try using float division

 1/4000.
 1/5.

-- Cinaed


On 1/21/19 4:41 PM, david vanhorn wrote:
> The docs say that I need to set Scale to the inverse of the Length.
> Ok, I interpret that as Length = 4000 and Scale = 1/4000
> The docs here:
> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> says that Scale is a float.
> 
> The discussion here clearly shows Scale working for values <1 and >0
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> 
> If I enter a scale value by hand, like 0.2, then I see 200m which is
> what I expect.
> If I enter a scale value as (1/5) then I see 0.
> If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
> field of the moving average, it evaluates to 0.
> 
> 
> When I enter the values in the block, it looks like scale is an int,
> which makes 1/4000 or indeed 1/(>1) problematic in that it always
> evaluates to zero, which kinda breaks things.
> When I enter 1/2 I get "0"
> 
> When I hover over the field to enter Scale, I get Type Real.
> 
> I have the input and output of my integrator connected to a QT GUI Time
> Sink, and while the input waveform is what I expect, if I have any <1
> Scale parameter, the output is 0.
> 
> 
> Is something broken here, or is it me?
> I've not had any problems using simple math in any of the other fields
> where appropriate.
> 
> 
> -- 
> K1FZY (WA4TPW) SK  9/29/37-4/13/15
> 
> ___
> 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] Moving average

2019-01-21 Thread david vanhorn

The docs say that I need to set Scale to the inverse of the Length.
Ok, I interpret that as Length = 4000 and Scale = 1/4000
The docs here:
https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
says that Scale is a float.

The discussion here clearly shows Scale working for values <1 and >0
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html

If I enter a scale value by hand, like 0.2, then I see 200m which is what I
expect.
If I enter a scale value as (1/5) then I see 0.
If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
field of the moving average, it evaluates to 0.


When I enter the values in the block, it looks like scale is an int, which
makes 1/4000 or indeed 1/(>1) problematic in that it always evaluates to
zero, which kinda breaks things.
When I enter 1/2 I get "0"

When I hover over the field to enter Scale, I get Type Real.

I have the input and output of my integrator connected to a QT GUI Time
Sink, and while the input waveform is what I expect, if I have any <1 Scale
parameter, the output is 0.


Is something broken here, or is it me?
I've not had any problems using simple math in any of the other fields
where appropriate.


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving Average Block

2016-01-12 Thread Marcus Müller

Hi Pedro,

$y[n]=\sum\limits_{i=n-N+1}^n {\left|x[i]\right|^2}$ is nothing but the
moving average over the squared magnitude.
Sadly, your formula
$T=\sum\limits_{n=0}^{N-1} {\left|Y[n]\right|^2}$ doesn't specify what T
signifies; is T used as a single sum over N samples' squared magnitudes,
or is it something running (i.e. you get as many Ts as you consider samples.

I just assume you really are looking for a moving average, in which case
your flow graph is correct.
> Timothée told me to use stream to vector, but if I pack them, each 100
> samples will become one single information, right? What I need is more
> like a controller that gives me 100 samples at a time.
Really, I'm not sure where the formula you attached came from, or what
you mean, or if what you mean is what you need...
Maybe you could just write down, explicitely, what *each* output sample
should be (which is why I wrote $y[n]$ rather than $y$).


Best regards,
Marcus


On 12.01.2016 17:27, Pedro Gabriel Adami wrote:
> Dear all,
>
> In addition to my previous response, I'm attaching an image that shows
> the formula I'm trying to build in gnuradio (using blocks). But
> instead of n = 0 and N-1, I need n = 1 and 100 (100 samples). The
> second picture shows how I tried to do in Gnuradio, but the moving
> average block does not get 100 samples the way I need (as we could see
> in the previous answers).
>
> Timothée told me to use stream to vector, but if I pack them, each 100
> samples will become one single information, right? What I need is more
> like a controller that gives me 100 samples at a time.
>
> Please, I appreciate if you could give me some tips.
>
> Thanks in advance.
>
> 2016-01-08 14:47 GMT-02:00 Timothée COCAULT
> mailto:timothee.coca...@gmail.com>>:
>
> Whoops, just noticed I didn't reply to all when I answered so my
> message and Pedro's response were not forwarded to the mailing list :
>
> Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami
>  > a écrit :
>>
>> Dear, Timothée,
>>
>> Thank you so much. I am doing some tests and I've realized that
>> the results are a little strange. That is why I asked.
>>
>> Let me ask you one more thing: Do you know some block that is
>> capable to retain N samples, so I can use them and after that, it
>> retains the next N samples? Like a variable where I can "save"
>> the information for a short period of time, but my Gnuradio does
>> not have a "variable sink".
>>
>> Thanks in advance.
>>
>> Em 07/01/2016 17:18, "Timothée COCAULT"
>> mailto:timothee.coca...@gmail.com>>
>> escreveu:
>>
>> Hi Pedro,
>>
>> When you're not sure, the best solution is often to look at
>> the code.
>> If you look at the work function in
>> gr-blocks/lib/moving_average_XX_impl.cc.t, you see that the
>> block first sums the history (of length 100 in your case).
>> For each additional input items, it adds the new item and
>> subtracts the n-100 item, and outputs the current sum.
>>
>> So it will first calculate 1+...+100, then 2+...+101 and so on.
>>
>> Regards,
>> Timothée. 
>>
>>  
>>
>>
>
> I don't understand exactly your question but you can use a stream
> to vector to group your items in packets of size N, and plug it
> into a probe signal
>
>
>
>
> -- 
> Atenciosamente,
> Pedro Gabriel Adami
> Graduando do 5º período de Engenharia de Controle e Automação no
> Instituto Nacional de Telecomunicações - Inatel
>
>
> ___
> 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] Moving Average Block

2016-01-12 Thread Pedro Gabriel Adami

Dear all,

In addition to my previous response, I'm attaching an image that shows the
formula I'm trying to build in gnuradio (using blocks). But instead of n =
0 and N-1, I need n = 1 and 100 (100 samples). The second picture shows how
I tried to do in Gnuradio, but the moving average block does not get 100
samples the way I need (as we could see in the previous answers).

Timothée told me to use stream to vector, but if I pack them, each 100
samples will become one single information, right? What I need is more like
a controller that gives me 100 samples at a time.

Please, I appreciate if you could give me some tips.

Thanks in advance.

2016-01-08 14:47 GMT-02:00 Timothée COCAULT :

> Whoops, just noticed I didn't reply to all when I answered so my message
> and Pedro's response were not forwarded to the mailing list :
>
> Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami <
> pedrogabriel.ad...@gmail.com> a écrit :
>
> Dear, Timothée,
>
> Thank you so much. I am doing some tests and I've realized that the
> results are a little strange. That is why I asked.
>
> Let me ask you one more thing: Do you know some block that is capable to
> retain N samples, so I can use them and after that, it retains the next N
> samples? Like a variable where I can "save" the information for a short
> period of time, but my Gnuradio does not have a "variable sink".
>
> Thanks in advance.
> Em 07/01/2016 17:18, "Timothée COCAULT" 
> escreveu:
>
>> Hi Pedro,
>>
>> When you're not sure, the best solution is often to look at the code.
>> If you look at the work function in
>> gr-blocks/lib/moving_average_XX_impl.cc.t, you see that the block first
>> sums the history (of length 100 in your case).
>> For each additional input items, it adds the new item and subtracts the
>> n-100 item, and outputs the current sum.
>>
>> So it will first calculate 1+...+100, then 2+...+101 and so on.
>>
>> Regards,
>> Timothée.
>>
>
>>
>
>
> I don't understand exactly your question but you can use a stream to
> vector to group your items in packets of size N, and plug it into a probe
> signal
>



-- 
Atenciosamente,
Pedro Gabriel Adami
Graduando do 5º período de Engenharia de Controle e Automação no Instituto
Nacional de Telecomunicações - Inatel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving Average Block

2016-01-08 Thread Timothée COCAULT

Whoops, just noticed I didn't reply to all when I answered so my message
and Pedro's response were not forwarded to the mailing list :

Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami <
pedrogabriel.ad...@gmail.com> a écrit :

Dear, Timothée,

Thank you so much. I am doing some tests and I've realized that the results
are a little strange. That is why I asked.

Let me ask you one more thing: Do you know some block that is capable to
retain N samples, so I can use them and after that, it retains the next N
samples? Like a variable where I can "save" the information for a short
period of time, but my Gnuradio does not have a "variable sink".

Thanks in advance.
Em 07/01/2016 17:18, "Timothée COCAULT" 
escreveu:

> Hi Pedro,
>
> When you're not sure, the best solution is often to look at the code.
> If you look at the work function in
> gr-blocks/lib/moving_average_XX_impl.cc.t, you see that the block first
> sums the history (of length 100 in your case).
> For each additional input items, it adds the new item and subtracts the
> n-100 item, and outputs the current sum.
>
> So it will first calculate 1+...+100, then 2+...+101 and so on.
>
> Regards,
> Timothée.
>

>


I don't understand exactly your question but you can use a stream to vector
to group your items in packets of size N, and plug it into a probe signal
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving Average Block

2016-01-07 Thread West, Nathan

Chiming in that this is also a great opportunity to contribute improved
documentation after you've figured out your answer.

In addition to Marcus' comment, looking at the code helps (and in this case
is pretty easy):

   set_history(d_length);
  // skipping some stuff
  @I_TYPE@ sum = 0;
  int num_iter = (noutput_items>d_max_iter) ? d_max_iter :
noutput_items;
  for(int i = 0; i < d_length-1; i++) {
sum += in[i];
  }

  for(int i = 0; i < num_iter; i++) {
sum += in[i+d_length-1];
out[i] = sum * d_scale;
sum -= in[i];
  }

The first loop builds up an "initial" sum, the second loop does the grunt
work of generating output samples. You'll always get the sum of the last
n_length samples scaled by some factor (n_length for arithmetic mean).



On Thu, Jan 7, 2016 at 1:23 PM, Pedro Gabriel Adami <
pedrogabriel.ad...@gmail.com> wrote:

> Dear all,
>
> The documentation of the Moving Average block made me feel confuse about
> its functionality. It says: "output is the moving sum of the last N
> samples". If I need a sum of 100 samples, this block will sum the 100
> samples that I need and after that it will get another different samples?
> For example: 1+2+3+...+100 and 101+102+...200. Or it will do this:
> 1+2+...+100 and 2+3+...+101 and 3+4+...+102.
>
> I know it seems a little confuse, but I didn't find a better way to
> explain this, sorry.
>
> Thanks in advance.
>
> --
> Atenciosamente,
> Pedro Gabriel Adami
> Graduando do 5º período de Engenharia de Controle e Automação no Instituto
> Nacional de Telecomunicações - Inatel
>
> ___
> 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] Moving Average Block

2016-01-07 Thread Pedro Gabriel Adami

Dear all,

The documentation of the Moving Average block made me feel confuse about
its functionality. It says: "output is the moving sum of the last N
samples". If I need a sum of 100 samples, this block will sum the 100
samples that I need and after that it will get another different samples?
For example: 1+2+3+...+100 and 101+102+...200. Or it will do this:
1+2+...+100 and 2+3+...+101 and 3+4+...+102.

I know it seems a little confuse, but I didn't find a better way to explain
this, sorry.

Thanks in advance.

-- 
Atenciosamente,
Pedro Gabriel Adami
Graduando do 5º período de Engenharia de Controle e Automação no Instituto
Nacional de Telecomunicações - Inatel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average and history

2009-02-10 Thread Matt Ettus



Whoops,
forget about skipping the history(), of course it couldn't work.
However, by adding a state buffer to the class, the first for() loop
can be skipped. For long MAs, this would save some multiplications and
only increase memory usage by one item_size.


The reason we don't do that is that floating point numbers will have 
numerical errors.  If you add thousands of floats together, and then 
subtract them all out, you won't get zero.  This error will accumulate 
over time and become unstable.  That is why we start our accumulation 
over again periodically.


Matt


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

Re: [Discuss-gnuradio] Moving average and history

2009-02-10 Thread Martin Braun

On Mon, Feb 09, 2009 at 01:43:41PM +0100, Martin Braun wrote:
> [code]
> 
> Here's what I don't understand: the state for the MA (as for all
> filters) is saved implicitly in the history. However, in this special
> case, the state is simply one scalar value (saved in 'sum'). The way
> this is implemented, that state has to be recalculated every time work()
> is called. So, why bother with history() and not simply make 'sum' a
> class property? Would that screw up the scheduling?
> 
> The reason I ask is if I write a MA block for vectors, using history()
> means keeping vector_length x MA_length samples in some buffer and
> running as many extra multiplications every time work() is called. Of
> course, I'd prefer to solve this the GNU Radio way, but in this case it
> would seem a waste of memory and CPU cycles.

Whoops,
forget about skipping the history(), of course it couldn't work.
However, by adding a state buffer to the class, the first for() loop
can be skipped. For long MAs, this would save some multiplications and
only increase memory usage by one item_size.

Next time I'll think about it twice :)

Martin

-- 
Dipl.-Ing. Martin Braun   Phone: +49-(0)721-608 3790
Institut fuer Nachrichtentechnik  Fax:   +49-(0)721-608 6071
Universitaet Karlsruhe (TH)   http://www.int.uni-karlsruhe.de/


pgptWi7aVSo9n.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Moving average and history

2009-02-09 Thread Martin Braun

Hi,

I was about to write a block which calculates the moving average over a
whole vector, when I stumbled upon the way the current moving average
blocks handle the history.

Here's the code for the float version:

int
gr_moving_average_ff::work (int noutput_items,
  gr_vector_const_void_star &input_items,
  gr_vector_void_star &output_items)
{
  const float *in = (const float *) input_items[0];
  float *out = (float *) output_items[0];

  float sum = 0;
  int num_iter = (noutput_items>d_max_iter) ? d_max_iter :\
noutput_items;
  for (int i = 0; i < d_length-1 ; i++) {
sum += in[i];
  }

  for (int i = 0; i < num_iter; i++) {
sum += in[i+d_length-1];
out[i] = sum * d_scale;
sum -= in[i];
  }

  return num_iter;
}


Here's what I don't understand: the state for the MA (as for all
filters) is saved implicitly in the history. However, in this special
case, the state is simply one scalar value (saved in 'sum'). The way
this is implemented, that state has to be recalculated every time work()
is called. So, why bother with history() and not simply make 'sum' a
class property? Would that screw up the scheduling?

The reason I ask is if I write a MA block for vectors, using history()
means keeping vector_length x MA_length samples in some buffer and
running as many extra multiplications every time work() is called. Of
course, I'd prefer to solve this the GNU Radio way, but in this case it
would seem a waste of memory and CPU cycles.

Thanks for any insight,
Martin

-- 
Dipl.-Ing. Martin Braun   Phone: +49-(0)721-608 3790
Institut fuer Nachrichtentechnik  Fax:   +49-(0)721-608 6071
Universitaet Karlsruhe (TH)   http://www.int.uni-karlsruhe.de/


unnamed.sig
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average

Re: [Discuss-gnuradio] Moving average

Re: [Discuss-gnuradio] Moving average

Re: [Discuss-gnuradio] Moving average

Re: [Discuss-gnuradio] Moving average

Re: [Discuss-gnuradio] Moving average

[Discuss-gnuradio] Moving average

Re: [Discuss-gnuradio] Moving Average Block

Re: [Discuss-gnuradio] Moving Average Block

Re: [Discuss-gnuradio] Moving Average Block

Re: [Discuss-gnuradio] Moving Average Block

[Discuss-gnuradio] Moving Average Block

Re: [Discuss-gnuradio] Moving average and history

Re: [Discuss-gnuradio] Moving average and history

[Discuss-gnuradio] Moving average and history

15 matches

Site Navigation

Mail list logo

Footer information