BPSK to QPSK

hi everyone,

   I am using the programs of DIGITAL-BERT folder to see the bit 

error
rate pattern versus the SNR. The given programs are for BPSK scheme. I
tried
to change it for QPSK Scheme. But seems that I did not do it right. I am
giving the modified code in the programs . Please help me
out…Thanking
in advance…

1) transmit_path.py in /digital-bert/ folder.

self._bits = gr.vector_source_b([1,], True) # Infinite stream of
ones
self._scrambler = gr.scrambler_bb(0x8A, 0x7F, 7) # CCSDS 7-bit
scrambler

Map to constellation

self._constellation = [-1-1j,1-1j,-1+1j,1+1j]
self._mapper = gr.chunks_to_symbols_bc(self._constellation,2)

Create RRC with specified excess bandwidth

taps = gr.firdes.root_raised_cosine(spsamplitude, # Gain
sps, # Sampling rate
1.0, # Symbol rate
excess_bw, # Roll-off factor
11
sps) # Number of taps

self._rrc = gr.interp_fir_filter_ccf(sps, # Interpolation rate
taps) # FIR taps

    # Wire block inputs and outputs
    self.connect(self._bits, self._scrambler, self._mapper, 

self._rrc,
self)

2)receive_path. py in /digital-bert/ folder

self._agc = gr.agc_cc(1e-5, 1.0, 1.0, 1.0)

Create RRC with specified excess bandwidth

taps = gr.firdes.root_raised_cosine(1.0, # Gain
self._sps, # Sampling rate
1.0, # Symbol rate
excess_bw, # Roll-off factor
11*self._sps) # Number of taps

self._rrc = gr.fir_filter_ccf(1, taps)

    # Create a Costas loop frequency/phase recovery block

    print "Costas alpha:", costas_alpha
    print "Costas beta:", costas_beta
    print "Costas max:", costas_max

    self._costas = gr.costas_loop_cc(costas_alpha,  # PLL first 

order
gain
costas_beta, # PLL second
order
gain
costas_max, # Max frequency
offset rad/sample
-costas_max, # Min frequency
offset rad/sample
4) # QPSK

    # Create a M&M bit synchronization retiming block
    mm_mu = 0.5
    mm_omega = self._sps

    print "MM gain mu:", mm_gain_mu
    print "MM gain omega:", mm_gain_omega
    print "MM omega limit:", mm_omega_limit

    self._mm = gr.clock_recovery_mm_cc(mm_omega,       # Initial

samples/symbol
mm_gain_omega, # Second
order
gain
mm_mu, # Initial
symbol
phase
mm_gain_mu, # First order
gain
mm_omega_limit) # Maximum
timing
offset

    # Add an SNR probe on the demodulated constellation
    self._snr_probe = gr.probe_mpsk_snr_c(10.0/symbol_rate)
    self.connect(self._mm, self._snr_probe)


    self._c2r = gr.complex_to_real()
    self._slicer = gr.binary_slicer_fb()
    self._c2i = gr.complex_to_imag()
    self._inter = gr.interleave(gr.sizeof_float*1)
    # Descramble BERT sequence.  A channel error will create 3 

incorrect
bits
self._descrambler = gr.descrambler_bb(0x8A, 0x7F, 7) # CCSDS
7-bit
descrambler

    # Measure BER by the density of 0s in the stream
    self._ber = gr.probe_density_b(1.0/symbol_rate)

self.connect(self, self._agc, self._rrc, self._costas, self._mm)
self.connect(self._mm,self._c2r)
self.connect(self._mm,self._c2i)
self.connect(self._c2r,(self._inter,0))
self.connect(self._c2i,(self._inter,1))
self.connect(self._inter,self._slicer,self._descrambler,self._ber)

Please help me out.

Amarnath

amarnath alapati wrote:

hi everyone,

   I am using the programs of DIGITAL-BERT folder to see the bit

error rate pattern versus the SNR. The given programs are for BPSK
scheme. I tried to change it for QPSK Scheme. But seems that I did not
do it right. I am giving the modified code in the programs . Please
help me out…Thanking in advance…
I think that the Costas- and MM- blocks only work for differential
encoding… If anyone knows differently, speak now of forever hold your
peace ;p

//Mattias

On 3/3/2010 7:12 AM, Mattias K. wrote:

I think that the Costas- and MM- blocks only work for differential
encoding… If anyone knows differently, speak now of forever hold your
peace ;p

//Mattias

No, the synchronization schemes are not dependent on the type of
encoding. They will work for either differential or non-differential. In
fact, they are really overkill for differentially encoded
modulations…

Tom

Tom R. wrote:

do it right. I am giving the modified code in the programs . Please

No, the synchronization schemes are not dependent on the type of
encoding. They will work for either differential or non-differential. In
fact, they are really overkill for differentially encoded modulations…

Tom

Hum… I’m glad to hear that, although I thought that the pi- phase
ambiguity of Costas- loops made them unsuitable for QPSK-
constellations… But I guess there is something I’m missing in the code
then?

Come to think of it. As stated in “Practical Costas loop design, J
Feigin”, one can track the carrier, but there is a chance that the
carrier will come out of the loop “upside down”. Are there blocks that
check for this?

BR
//Mattias

Hum… I’m glad to hear that, although I thought that the pi- phase
ambiguity of Costas- loops made them unsuitable for QPSK-
constellations… But I guess there is something I’m missing in the code
then?

You aren’t missing anything, you just need to account for the possible
rotation.

The easy way to do this is with differential decoding, because the
instantaneous phase is irrelevant.

The harder-but-still-easy was is to transmit some know sequence at the
beginning to determine the phase offset and adjust your decoding
accordingly.

Jason

Jason

I think of synchronization as making sure the constellation is
aligned. The actual bit representations are the next step. Since we
put a 64-bit access code on the front of every packet, it should be
easy to add logic in the sink to determine what the rotation is, but
we haven’t done anything about that.

Tom

Maybe I should have taken a few minutes to think about what was really
going on, before I started to write interleaved pilot- symbols in the
data- stream, and correcting the data on them at the rx- side then…
Anyway I got some more experience thinking in “gnuradio c++”, and now a
new view upon things ;]

//Mattias

On Wed, Mar 3, 2010 at 03:36, amarnath alapati
[email protected] wrote:

   I am using the programs of DIGITAL-BERT folder to see the bit error

rate pattern versus the SNR. The given programs are for BPSK scheme. I tried
to change it for QPSK Scheme. But seems that I did not do it right. I am
giving the modified code in the programs . Please help me out…Thanking
in advance…

Two major issues:

  1. On the receiver, you are not demapping your received constellation
    into QPSK dibit symbols. The current script simply discards the Q
    channel and slices the I channel about zero to recover BPSK symbols;
    you never changed any of that.

  2. Even were you to do this, the phase ambiguity of QPSK demodulation
    means you can end up in one of four states on the receiver, so I and Q
    can be swapped or inverted. In real communication systems this is
    either handled with differential coding or known synchronization words
    that allow the receiver to detect the rotated phase lock. BPSK has
    this problem as well, though limited to correct or inverted
    demodulation. The original BPSK-based BERT scripts use a
    self-synchronizing differential bit scrambler and descrambler that is
    okay with inverted demodulation.

Johnathan

On Wed, Mar 3, 2010 at 10:51 AM, Jason U. [email protected] wrote:

The harder-but-still-easy was is to transmit some know sequence at the
beginning to determine the phase offset and adjust your decoding
accordingly.

Jason

Yes, what Jason said.

I think of synchronization as making sure the constellation is
aligned. The actual bit representations are the next step. Since we
put a 64-bit access code on the front of every packet, it should be
easy to add logic in the sink to determine what the rotation is, but
we haven’t done anything about 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