[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Working with GRC! Vector decimate
From: |
Glen I Langston |
Subject: |
Re: [Discuss-gnuradio] Working with GRC! Vector decimate |
Date: |
Sat, 17 Mar 2018 08:01:02 -0400 |
> 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
- Re: [Discuss-gnuradio] High Pass and Low Pass performance not inverse, (continued)