On air 16_QAM transmission problem with USRP N210

Hi all,
I am trying to build transmission on air by using USRPs N210. The
transmission is good with MPSK modulations but when i try to use 16_QAM
i
could not receive data (0 bytes at the reception). I tried to adapte
transmission power, gain at the tranmitter, gain at receiver, samp_rate
but
the reception file still always empty. This is my flow graph:
Tx: file source => packet encoder => QAM mod => mult constant = 0.4 =>
UHD
usrp sink
Rx : UHD usrp source => QAM demod => packet decoder => file sink
samp_rate= 2M
samples/symbol = 8
centre frequency=2.4G
Any proposition will be appreciate
Thanks to all


View this message in context:
http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871.html
Sent from the GnuRadio mailing list archive at Nabble.com.

You’ll have to attach the flowgraph.

On 29.04.2014 23:22, zielalaoui wrote:

samples/symbol = 8
centre frequency=2.4G
Any proposition will be appreciate
Thanks to all

There are lots of things that can go wrong. At 16-QAM, you’ll likely
have some bit error, and you have no FEC to compensate for that.

Martin

On Wed, Apr 30, 2014 at 3:22 AM, Martin B.
[email protected]wrote:

usrp sink

Martin

Also synchronization. That QAM Demod you have right after the USRP
source
block in your email suggests you aren’t doing proper timing, freq, and
phase recovery.

Tom

Hi all,
For synchronization I did not add blocks because the QAM.py calls
synchronization blocks from generic_mod file which already contains AGC,
fll, polyphase clock synk, … I thought that those bolcks are doing the
job. So i just think to add FEC block because it is not a part of my
flow-graph. Do you thinks that i should add synchronization block even
it
exists in QAM demod block? or just try to find the best parameters of
timing, frequency, and phase in de QAM_demo block?
Thanks a lot for help.


View this message in context:
http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871p47891.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi Tom,
Yes i’ve already done the simulation with 16 QAM and even 64 QAM by
following your example for MPSK. The simulation was very good even I add
noise in the channel model. I had only problem of power, if the
transmitting
power is high enough the transmission is perfect with no errors. On air,
I
tried to add timing, frequency, and phase correction block but after
running
transmitting flow graph the simulation at receiver . what do you think
about
that?


View this message in context:
http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871p47897.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Wed, Apr 30, 2014 at 10:58 AM, zielalaoui [email protected]
wrote:

Hi all,
For synchronization I did not add blocks because the QAM.py calls
synchronization blocks from generic_mod file which already contains AGC,
fll, polyphase clock synk, … I thought that those bolcks are doing the
job. So i just think to add FEC block because it is not a part of my
flow-graph. Do you thinks that i should add synchronization block even it
exists in QAM demod block? or just try to find the best parameters of
timing, frequency, and phase in de QAM_demo block?
Thanks a lot for help.

Yes, synchronization for QAM is difficult and not extremely well-tested
in
GNU Radio. Have you done this in simulation, yet? That is, make a GRC
example with the transmitter and receiver and the add a channel model
block
to see what happens? Definitely start there before getting ahead of
yourself and adding the complexities of the real world.

Tom

On Wed, Apr 30, 2014 at 12:04 PM, zielalaoui [email protected]
wrote:

that?

Did you try adjusting the timing and frequency offset in your
simulation?

Tom

On Wed, Apr 30, 2014 at 1:01 PM, zielalaoui [email protected]
wrote:

Yes I did, with channel model like that:
Noise voltage = 200m
frequency offset=50m
epsilon=900m
taps=1
seed=0
And I can receive data.

Ok. A couple of things. First, please keep the rest of the conversation
in
the mail and bottom post like this. It helps make sure that the thread
is
readable. Second, I’ve been trying to coax you into providing more
information. When I originally asked if you had simulated the
connection,
explaining that you have tested with these parameters then would have
saved
us a lot of time. Please be complete in your explanations.

Now that you’ve done this part and verified that everything is working
in
simulation, try and see what’s different about the incoming signal as
opposed to the simulation. Is the frequency offset maybe too large? Is
the
received amplitude correct? Try mapping these into your simulation and
see
where things start to fall apart. At this point, you seem to have the
basic
setup correct and just need to continue to experiment with the settings.

Tom

Yes I did, with channel model like that:
Noise voltage = 200m
frequency offset=50m
epsilon=900m
taps=1
seed=0
And I can receive data.


View this message in context:
http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871p47903.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On 02.05.2014 16:59, zielalaoui wrote:

Hi to all,
I resolved my problem and I want to share the solution
The problem was the amplitude in the QAM demod block input. I checked the
constellation in the transmitter directly before UHD usrp block for being
sure the the constellation points are good depending on the samples/symbol
value (8 worked good). After that i just try to adapte the amplitude signal
in reception by adding gain for to have the same signal which i had in my
QAM simulation. Like that the transmission worked good.
Zakaria

Zakaria,

generally, your equalizer should be taking care of that. Adjusting gain
is an unreliable method, since the actual attenuation of your signal
over-the-air is a function of many things.

But nice that your experiment is working!

Martin

On Fri, May 2, 2014 at 11:08 AM, Martin B.
[email protected]wrote:

QAM simulation. Like that the transmission worked good.

Martin

Zakaria,

First, great that you got it working!

Martin makes a good point in general. One reason I mentioned the
amplitude
in my post is because I know that our consetllation objects used in the
constellation_receiver has some strange slicing requirements. They
expect
the constellation to have the symbols at certain points in complex space
(instead of, for instance, estimating the maximum energy of the
constellation and scaling based on that). Using the LMS_DD equalzier
with
the same constellation object for the QAM modulation you’re using will
do
what Martin is suggesting.

Tom

Hi to all,
I resolved my problem and I want to share the solution
The problem was the amplitude in the QAM demod block input. I checked
the
constellation in the transmitter directly before UHD usrp block for
being
sure the the constellation points are good depending on the
samples/symbol
value (8 worked good). After that i just try to adapte the amplitude
signal
in reception by adding gain for to have the same signal which i had in
my
QAM simulation. Like that the transmission worked good.
Zakaria


View this message in context:
http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871p47924.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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