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

Reply via email to