Re: [Discuss-gnuradio] Working with GRC! Vector decimate

[Glen I Langston]

> On Mar 16, 2018, at 8:16 PM, Marcus D. Leech <address@hidden> wrote:
> 
> On 03/16/2018 10:57 AM, Glen I Langston wrote:
>> Hi
>> 
>> Thanks for your help.  I know no-one else cares, but
>> I’ve finally figured out all the steps to get Vector decimation working with 
>> GRC.
>> 
>> A few notes:  I don’t think forecast() is ever called with a decimate block.
>> 
>> Multiple output vectors are possible, and care needs to be taken to count
>> all the outputs.
>> 
>> My initial QA only had one vector output, so worked fine.
>> GRC was generating multiple vectors as output and my vave code was chocking
>> on multiple outputs.
>> 
>> I’ve yet to figure out how to put this block in GitHub
>> 
> Glen:
> 
> First, congrats on getting your first custom block working.  I pop the 
> virtual champagne cork in your general direction.
> 

Hi Marcus,

Thanks!  I take great personal pride in getting this to work.  I was able to 
cascade several
of these average blocks.  After figuring out the average block, the median 
block only
took a few minutes.  

> Next, rough outline of getting your stuff on GitHub:
> 
> Create a GitHub account.  Create a project.
> 
> Do an initial git clone of the project, and move your "stuff" into there.
> 
> Git "add" all the pieces that should be under source control.
> 
> Git "commit -a"
> 
> Git push
> 
Thanks for the summary.  I’ll do that very soon.  I was going to take another
look at your installation for your odroid_ra and follow that example.
> There, you have an initial instance of your stuff.
> 
> Now, since this block just does the (rough) equivalent (at the moment) of a 
> single-pole-IIR filter followed by a keep-one-in-N, it would be useful to 
> compare
>  performance of your fused block.  I suspect that it will be poorer--because 
> it's written in Python.
> 

I was wondering about performance.   I would like to do the tests you 
identified.
The python code works only with vectors.   There are not single element sums or 
comparisons.  Hopefully
that may help performance.

> A fairer test would be to create a fused averager+decimator in C++,

If I get the strength I will try and create the C++ version.  The average
part is extremely simple.  The C++ overhead is very daunting to me however.

My next priority is getting the Radio Astronomy File-writing into custom vector 
blocks,
compatible with GRC.  I need my file format so I don’t have to write all the 
down
stream code.   Plus I like that an output file can be used to completely setup 
the next
observation.

I’m envisioning a block that sets up the input values for the observation and
a block that writes every vector it receives.   This write block would be 
proceeded by
a bunch of average blocks.

Somewhere along the average chain I’d add a standard QT GUI too.

> taking advantage of whatever SIMD tricks might be available.  The savings
>  on "fused" blocks are that they localize data-motion, but they may, for 
> significant-sized inputs, lose out due to the single-threaded nature of them.
> 
> Optimization is tricky, and it's not always obvious that any given approach 
> will "always work”.
Not Sure what SIMD tricks means, but I’ll google it!

Thanks again!

Cheers
Glen

> 

> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio