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

> On Mar 16, 2018, at 8:16 PM, Marcus D. Leech <mleech@ripnet.com> 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
> 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