Bonjour Louis-Adrien - Cool experiment! Since we don't have access to your flowgraph, the following are just guesses. I believe that getting the signal gains "correct enough" is the key to what you're doing. 60 dB of attenuation is quite a bit! it's wise to protect the USRP Rx from signal overload though, but usually 30-40 dB is sufficient.
Pre-USRP TX Gain: the USRP Sink block takes in float values in the range [-1,+1] ... and ideally the max(abs()) of the signal is always < 1 ... and to be safe, even < 0.9. If the max(abs()) goes > 1 for very short bursts it's probably not an issue, but if the signal is regularly > 1 then the TX RF will look distorted since the USRP will clip the signal. Some versions of GR provide an API to normalize the constellation values to max(abs()) == 1 .. but this is not the default ... and if not, then I believe the max(abs()) grows with the QAM value. Thus, unless your flowgraph is normalizing the pre-USRP signal to be in the correct range, the signal max(abs()) will (eventually) end up being outside that range & the USRP TX RF will end up being distorted. Hope this is useful! - MLD On Wed, Feb 26, 2020 at 2:58 AM Louis-Adrien DUFRENE via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello everyone, > > > > I am using a USRP B210 with the Python (3.7.6) API with UHD 3.15 (from > conda-forge). > > > > RF setup is as follow: one USRP, one TX/RX connected with a SMA cable, 60 > dB attenuator, central freq is 1GHz, sampling rate is 1,6 MHz (oversampling > value is 4) and RX gain is fixed to 50 dB. > > I send burst of data composed of a zadoff-chu 256 followed by a payload > modulated with M-QAM and Gray mapping. This is a wideband transmission, > there is no additional filtering, nor OFDM modulation. > > > > I use a 1031-long ZC sequence to locate the frame. > > In reception, I use the 256-long ZC sequence to fine synch (select the > right sample version to go back to symbol rate), to estimate the channel > (1-tap) and more especially the phase shift, and to estimate the SNR. > > > > I could confirm the performance for 4-QAM and 16-QAM. BER vs SNR > performance curves obtained in experimentation follow perfectly the > theoretical curves for AWGN. > > > > However not in the case of the 64-QAM. Actually, I can’t obtain a SNR > above 22 / 23 dB, independently of the QAM order used. > > To increase the SNR and draw the performance curves, I simply increase the > TX gain. I start getting some problem from 45/50 dB. > > > > I observe a noise floor which looks like classic AWGN, but which is > increasing with the TX gain, since the estimated SNR is constant at 22.5 dB. > > > > I have also confirm the performances of the 4-QAM, 16-QAM and 64-QAM in > simulation on AWGN channel. > > > > At the moment I have no clue of what is happening. I have manually > activated dc offset and iq imbalance correction based on UHD API to be sure. > > > > What do I miss? I can provide more information if needed. > > > > Best regards, > > Louis-Adrien > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com