It really does need to happen on one sample at a time - at least assuming I
use the same algorithm I'm using now. I am pretty much using the method
Sylvain suggests. The rotation is one operation of many inside a block -
ie. many rotations happen per call to work(), but one rotation per input
sam
On Thu, May 28, 2015 at 1:52 PM, Douglas Geiger
wrote:
> To follow-up on Sylvain's questions: is the restriction really on doing
> single-sample rotation (because of some intermediate calculation to generate
> the phase advance for the next sample), or on the alignment?
Based on available inform
On Tue, May 26, 2015 at 7:37 PM, John Malsbury wrote:
> I have a complex phase rotation function that uses a pre-generated
> sin/cos LUT and some basic multiple/adds.
>
> As it turns out, the rotation calc, which uses "straight" C/C++ math is
> still the bottleneck in a demod.
>
> I was wonderin
Hi John,
> I have a complex phase rotation function that uses a pre-generated sin/cos
> LUT and some basic multiple/adds.
>
> As it turns out, the rotation calc, which uses "straight" C/C++ math is
> still the bottleneck in a demod.
I don't quite get what you need ...
Rotating a single sample b
Traditionally this was a job for CORDIC. I don't know what the tradeoffs
look like on a modern processor, though. If a significant part of your
algorithm operates in phase/magnitude, might you consider a rect->polar
conversion?
John Malsbury [jmalsbury.perso...@gmail.com] wrote:
> I have a comp
I have a complex phase rotation function that uses a pre-generated sin/cos
LUT and some basic multiple/adds.
As it turns out, the rotation calc, which uses "straight" C/C++ math is
still the bottleneck in a demod.
I was wondering, is there some uber-efficient rotation block/class I should
be usi
