discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Comparison test results: new "2" series dqpsk blo


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Comparison test results: new "2" series dqpsk blocks
Date: Fri, 20 Aug 2010 18:37:34 -0400

On Thu, Aug 12, 2010 at 1:47 PM, ikjtel <address@hidden> wrote:
> I've run a comparison test of
>  - the "old" GR dqpsk block
>  - the "new" one (dqpsk2)
>  - the "op25" cqpsk (Gardner/Costas) block
>
> The resulting constellation diagrams are viewable at 
> http://www.lightlink.com/mhp/qpsk2/
>
> The results are: Gardner is the winner, the old GR blocks take second, the 
> new ones are last
> (intriguingly as shown in the symbol plot, things seem to start off nicely 
> but then go awry)...
>
> The problem could be caused by dumb user error - D.U.E. (TM) or something 
> fixable by simple
> parameter tweakage?
>
> The input file used in all three cases is a complex capture taken from a 
> system using so-called
> "LSM/CQPSK".  Basically, that appears to mean something like: a) simulcast 
> distortion is added;
> b) PI/4 DQPSK is used; c) pulse shaping is stretched so as to fit the 
> bandwidth of the signal into
> a 12.5 KHz channel; d) a "non-standard" waveform is used which results in the 
> signal passing
> through the origin (0,0) point, introducing a rather severe AM component.
>
> There are two further wrinkles in this particular case which should be noted:
> 1) the complex file was captured using a "very poor man's USRP", *not* a real 
> USRP
>   [ see http://www.lightlink.com/mhp/iq/ ].  However the file formats are 
> fully compatible.
>   Further, a DBSRX capture exhibits all the same characteristics.
> 2) the receiving location is outside the designed coverage area of the system
>
> The results of all of this, plus the fact that the capture was made prior to 
> verifying that the
> hardware even was functional for LSM, makes for a very "difficult" specimen 
> (perfect for
> torture-testing RX codes)...
>
> Best Regards
>
> Max


That's a very interesting result. Theoretically, it makes sense for
the Gardner loop to perform better than the M&M, but the polyphase
filterbank approach will perform better than both. This suggests
either an error in the parameters you chose or a bug in the code.

When I'm fully setup with multiple USRPs to do over-the-air testing
again, I'll investigate farther.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]