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 sample as the rotation is dependent on what happened with previous samples.
Still processing what Tom/Doug are suggesting otherwise. The mod is generally product by something that isnt on GNU Radio. When we recreate the mod in software we definitely use a form that is easily done in vector form. Haven't quite wrapped my head on how to do the same on the receiving end while achieving optimum detection... Got any good papers? Converting everything to phase might be a half-way reasonable approach. Imminently, I only need to make this ~22% faster. It's possible this might work on a faster processor. -John On Thu, May 28, 2015 at 2:50 PM, Tom Tsou <tom.t...@ettus.com> wrote: > On Thu, May 28, 2015 at 1:52 PM, Douglas Geiger > <doug.gei...@bioradiation.net> 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 information, I'm guessing the prior scenario with > something like a filtered sequence feeding a phase modulator to > generate GMSK or similar non-linear CPM signal. In cases like these, > is the phase modulator really necessary? > > Many non-linear digital modulations in use these days have some form > of linear representation that is more efficient to implement on > vector-capable hardware. One solution to the rotator inefficiency > might be to get rid of it entirely. > > -TT >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
