Why no phase ambiguity in digital-bert

Hi All

I have been studying up on the Costas loop, and have a couple of queries
as to the benchmark_tx.py and benchmark_rx.py as a result.

Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity
when using a Costas loop. Why does this not seem to occur with the
benchmark_rx.py example? Is this related somehow to the PN code
introduced by the scrambler.

Secondly, I came across another post in which it was mentioned the
Costas loop should only operate on a single sample per symbol. However,
as I read the source code, it seems as though it is actually passed sps
samples per symbol, where sps > 1. Have I misread something here?

Any help in these matters would be greatly appreciated.

Thanks

Ian.

On Mon, Apr 12, 2010 at 22:11, Ian H. [email protected]
wrote:

I have been studying up on the Costas loop, and have a couple of queries as
to the benchmark_tx.py and benchmark_rx.py as a result.

Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when
using a Costas loop. Why does this not seem to occur with the
benchmark_rx.py example? Is this related somehow to the PN code introduced
by the scrambler.

The digital-bert example uses a self-synchronizing scrambler to
generate a bit sequence that occupies the full baseband bandwidth of
the channel. The scrambler/descrambler pair is insensitive to the
phase ambiguity; however, this comes at the price of generating extra
bit errors on the descrambled sequence for every bit error in the
channel.

Secondly, I came across another post in which it was mentioned the Costas
loop should only operate on a single sample per symbol. However, as I read
the source code, it seems as though it is actually passed sps samples per
symbol, where sps > 1. Have I misread something here?

Not sure what post you are referring to. While a Costas loop can
indeed operate on a single sample per symbol, it can also operate on
more than that. Different strategies in a receiver chain places the
frequency/phase synchronization at different places.

Johnathan

Thanks Jonathon

This clears things up a bit.

By the way, the post I was referring to can be found at

http://osdir.com/ml/discuss-gnuradio-gnu/2010-02/msg00098.html

Maybe I misread the reply from Jason, but said reply seemed to suggest
to me that a single sample per symbol should be used. Anyway, your
response has cleared things up for me.

Best Regards

Ian.

Maybe I misread the reply from Jason, but said reply seemed to suggest
to me that a single sample per symbol should be used.

This where a specific distinction comes in to play. Mpsk_receiver is
not just a costas loop. There are two actions happening in
mpsk_receiver. First, the signal is being corrected for incorrect
sample timing, using an MM loop. Second, the phase offset is being
tracked with a costas loop (and corrected for).

The user in the linked post was not using a sampler prior to his
(standalone) costas loop. The benchmark_rx uses an MM sampler and
costas loop together (called mpsk_receiver). The MM loop finds the
appropriate place to sample the entire symbol, leaving us with one
complex value representative of the center of the symbol. The costas
loop then operates on this single sample to softly slice the symbol
and update the phase error for the next iteration of the loop. The
‘samples per symbol’ parameter is the number of samples /you/ want to
use, which is an input to the sampler, not the costas loop.

If you follow the flow in the mpsk_receiver block used in benchmark_rx
it will be much clearer:
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc.cc

Jason

On Wed, Apr 14, 2010 at 06:48, Tom R. [email protected]
wrote:

Another point of clarification for the way benchmark_rx works. We use
differential modulation to account for the phase ambiguity. For BPSK,
there would indeed be a 180 degree ambiguity, but we use DBPSK, which
is insensitive to that. For anyone wanting to use non-differential
BPSK, you would have to use information in the preamble to account for
that.

There seems to be confusion about which script the original poster is
referring to. Both the digital packet modem (“digital”) and the
digital bit error rate tester (“digital-bert”) have scripts called
benchmark_rx.py. The original question was how the digital-bert
example was avoiding phase ambiguity while using straight BPSK and not
differential BPSK. This is due to the use of a self-synchronizing
digital scrambler prior to modulation.

As you point out above, the receive chain in the digital packet modem
is indeed using DBPSK to avoid the phase lock ambiguity, but that’s
not what the OP was referring to, unless I am mistaken. Either way
it’s important to distinguish between these two applications, as they
work differently.

Johnathan

Hi,
I need to help, I’m doing a transmitter and receiver BPSK, using USRP2
and a 20dB cable that link both 2 devices,

In TX

sps=8
interpolation=16
IF=100MHz/interpolation
Sample_rate=IF/sps

GLFSR source
(gr_glfsr_source)[degree:12,repeat:yes,mask:0,seed:1]–>chunks to
symbols(gr_chunks_to_symbols)[psk.costellation[2],dimension:1]–>Interpolating
FIR
Filter(gr_interp_fir_filter)[Interpolation:8,Taps:gr_firdes_root_raised_cosine(sps2000,sps,1,0.3,sps11)]–>USRP2_sink[interpolation:16,frequency:2.45Ghz,gain(dB):45]

In RX:

sps=8
interpolation=16
IF=100MHz/interpolation
Sample_rate=IF/sps

USRP_sink[interpolation:16,frequency:2.45Ghz,gain(dB):45]–>Feed Forward
AGC(gr_feedforward_agc_cc)[num samples:256,reference:1]–>costas
loop(gr_costas_loop)[alfa:0.8,beta:0.0025,max_freq:1,min_freq:-1,order:2]–>M&M
clock recovery(gr_clock_recovery_mm)[omega:sps,gain
omega:0.0025,mu:0.5,gain mu:0.1,omega relative
limit:0.005]–>costellation
decoder(gr_costellation_decoder)[symbolPosition:psk.costellation(2)],symbol
value out:range(2)]–>Unpack K bits(gr_unpack_K_bits)[K:1]

I have some questions:

  1. I want to send a 5MHz signal How can I do, which parameters do I have
    to change?
    2)If I see the costellation after M&M clock recovery I see the typical
    BPSK costellation but I don’t have 2 little point in -1,1 but a large
    smear in these 2 points, why?
    3)what do you thing about my project?is it good?

Thank you I’m sorry but I’m not a good gnuradio programmer
best regards
Claudio

Johnathan C. wrote in post #905054:

On Wed, Apr 14, 2010 at 06:48, Tom R. [email protected]
wrote:

Another point of clarification for the way benchmark_rx works. We use
differential modulation to account for the phase ambiguity. For BPSK,
there would indeed be a 180 degree ambiguity, but we use DBPSK, which
is insensitive to that. For anyone wanting to use non-differential
BPSK, you would have to use information in the preamble to account for
that.

There seems to be confusion about which script the original poster is
referring to. Both the digital packet modem (“digital”) and the
digital bit error rate tester (“digital-bert”) have scripts called
benchmark_rx.py. The original question was how the digital-bert
example was avoiding phase ambiguity while using straight BPSK and not
differential BPSK. This is due to the use of a self-synchronizing
digital scrambler prior to modulation.

As you point out above, the receive chain in the digital packet modem
is indeed using DBPSK to avoid the phase lock ambiguity, but that’s
not what the OP was referring to, unless I am mistaken. Either way
it’s important to distinguish between these two applications, as they
work differently.

Johnathan

On Tue, Apr 13, 2010 at 1:11 AM, Ian H.
[email protected] wrote:

Hi All

I have been studying up on the Costas loop, and have a couple of queries as
to the benchmark_tx.py and benchmark_rx.py as a result.

Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when
using a Costas loop. Why does this not seem to occur with the
benchmark_rx.py example? Is this related somehow to the PN code introduced
by the scrambler.

Another point of clarification for the way benchmark_rx works. We use
differential modulation to account for the phase ambiguity. For BPSK,
there would indeed be a 180 degree ambiguity, but we use DBPSK, which
is insensitive to that. For anyone wanting to use non-differential
BPSK, you would have to use information in the preamble to account for
that.

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs