Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

[Bob McGwier]

Franks comments are right on median and ROM in this case.    I stayed up 
to 4 AM and went to work at  after having breakfast and a cup of coffee 
and arrived by 9.  It is showing.

The entire gist of my comments amount to nothing more than don't allow 
"aliasing" of the spectral changes as your traverse the compressed power 
spectrum to cause you to miss a peak that is ABOVE the detection threshold.


So,  pardon me but,  is this a pretty picture exercise or a real 
detection problem?  If it is a detection problem,  then you might as 
well just compress to the largest value in the bins to be pushed 
together so you assure that your threshold is exceeded when it should 
be.  If it is a pretty picture problem,  just prevent scalloping by any 
old heuristic, just make it as fleet of calculation feet as possible and 
throw in some pretty grassy stuff to make it look nice.

Bob



Marcus D. Leech wrote:
> Bob McGwier wrote:
>   
> > I suggest that the best algorithm for this would be the rank order
> > mean alternated with the max so long as you are going to insert
> > "heuristic grass".  So it would be max, ROM, max, ROM, .....
> >
> >
> > Let [B1, B2, B3, B4, ... BN]  be powers of five adjacent bins.
> >
> > Put them in rank order
> >
> > [R1, R2, R3, R4,  ... RN]
> >
> > If N is even,  the rank order mean is (R_(N/2) + R_/(N/2 +1)*0.5.
> > If N is odd,  the rank order mean is R_(N/2 +0.5)
> >
> > But I still see a problem:
> >
> > I suggest that in order to prevent "scalloping" of a swept tone across
> > this algorithm or any other like it,  that some "bin"  in the lossy
> > compression set of bins must ALWAYS be forced to take on the large of
> > the power spectrum otherwise your alternative min/max/min/max might
> > jump up and down as you sweep a tone through it.  Or did I miss
> > something?
> >
> > Bob
> >     
> I love that phrase, Bob.   "Heuristic grass".
>
> I think that the real answer is to "play with it, and see what best
> suits the application".   Ranking the bin might end up being
>   expensive.  I'd probably use qsort(),  but I can't remember what its
> computational complexity is. Just looked it up.  Worst case
>   is O(N**2), and best-case is O(NlogN).   For worst-case, that's rather
> brutal at 4M bins (and even worse at my maximum of
>   16M bins).
>
> This discussion has ended up being much more fascinating than I had
> predicted.   Keep it up everybody!
>
>   


--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn