# On air 16\_QAM transmission problem with USRP N210 **URL:** \ **Category:** GNU Radio\ **Created:** [April 29, 2014, 11:23pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769 "2014-04-29T23:23:42Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [April 29, 2014, 11:23pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/1 "2014-04-29T23:23:42Z")
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](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](http://Nabble.com). ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 1:52am UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/2 "2014-04-30T01:52:40Z")
You’ll have to attach the flowgraph. ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 9:24am UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/3 "2014-04-30T09:24:15Z")
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 ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 4:41pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/4 "2014-04-30T16:41:20Z")
On Wed, Apr 30, 2014 at 3:22 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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 ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 5:00pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/5 "2014-04-30T17:00:16Z")
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](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](http://Nabble.com). ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 6:05pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/6 "2014-04-30T18:05:33Z")
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](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](http://Nabble.com). ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 5:52pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/7 "2014-04-30T17:52:06Z")
On Wed, Apr 30, 2014 at 10:58 AM, zielalaoui [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 6:50pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/8 "2014-04-30T18:50:09Z")
On Wed, Apr 30, 2014 at 12:04 PM, zielalaoui [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > that? Did you try adjusting the timing and frequency offset in your simulation? Tom ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [May 1, 2014, 3:29pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/9 "2014-05-01T15:29:21Z")
On Wed, Apr 30, 2014 at 1:01 PM, zielalaoui [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [April 30, 2014, 7:02pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/10 "2014-04-30T19:02:57Z")
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](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](http://Nabble.com). ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [May 2, 2014, 5:09pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/11 "2014-05-02T17:09:30Z")
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 ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [May 2, 2014, 5:36pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/12 "2014-05-02T17:36:34Z")
On Fri, May 2, 2014 at 11:08 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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 ---
**Author:** ![zielalaoui](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/439d5e/32.png) [@zielalaoui](https://www.ruby-forum.com/u/zielalaoui)\ **Post date:** [May 2, 2014, 5:00pm UTC](https://www.ruby-forum.com/t/on-air-16-qam-transmission-problem-with-usrp-n210/240769/13 "2014-05-02T17:00:54Z")
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](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](http://Nabble.com).