Hi Nicholas, Thanks a lot for your explanations! I tried to increase the sampling rate at the receiver - the sine changed itself again and I still have the same amplitude differences (attached below). Another problem that I observed is that it works fine only at 433MHz. When I tried to set 868MHz/915MHz it became even less readable. At 2.4GHz and 5GHz it was looked like noise...
So... Try a few different scenarios, (locked clock, unlocked clock, under sampled, oversampled, etc.) and observe how it changes. ---> May you please tell me a bit more about those locked and unlocked clocks? Thanks again, Varban On Mon, Mar 9, 2020 at 9:16 AM Linnenkamp, Nicholas < [email protected]> wrote: > V. > > > > I could be wrong… > > > > It appears that you are under sampling on the receive USRP. This is > probably due to the transmitter and the receiver not sharing the same clock > and the receiver is drifting (slower). You can have the two USRPs share > the same 10Mhz clock to remove this problem but it is present in every QAM > communication system. Distributed systems don’t have the benefit of common > clock even with GPS so it is something that everyone deals with eventually. > > > > This is a good picture of when you under sample and get aliasing. > > > > > https://dsp.stackexchange.com/questions/31899/how-do-you-simultaneously-undersample-and-oversample > > > > This is one of the best treatments of QAM signals that I have ever read. > > > > > https://mriquestions.com/uploads/3/4/5/7/34572113/quad_signals_tutorial-lyons.pdf > > > > The real part of the signal is getting shifted from the In Phase to the > Quadrature and back again over time. If you were to zero out the Q and > plot the I you would get this aliasing. If you were to zero out the I and > plot the Q, you would also get this aliasing. If you add them together, > the real parts make the whole sine wave. It just shifts, like water, back > and forth from the I and Q, periodically, directly proportional to the > under sampling. > > > > Try a few different scenarios, (locked clock, unlocked clock, under > sampled, oversampled, etc.) and observe how it changes. > > > > In QAM signals the first thing you need to do is estimate clock drift and > then de-rotate your signal. You do these things periodically so that you > can track and properly sample the incoming signal. > > > > Best of luck! > > > Thanks, > Nicholas > > > > > > *From:* USRP-users *On Behalf Of *Varban Metodiev via USRP-users > *Sent:* Monday, March 09, 2020 7:14 AM > *To:* usrp-users <[email protected]> > *Subject:* [EXTERNAL] [USRP-users] B205mini: Setting Q signal component > to zero distorts the I component > > > > Dear all, > > > > I have two B205mini devices. One of those is my transmitting side and the > other one is the receiver. Both are connected via a cable (and an > attenuator, of course). > > > > Here is what I execute on the receiver: > > *rx_samples_to_file --freq 433e6 --rate 2e6 --bw 1e6 --gain 0 --nsamps 0 > --spb 200* > > > > And on the transmitter: > > *tx_waveforms --rate 1e6 --freq 433e6 --ampl 0.6 --gain 70 --bw 1e6 > --wave-type SINE --wave-freq 10e3 --spb 100 --otw sc16* > > > > The results are being read in GNU Octave: > > *samples_file=fopen('/home/vmetodiev/Development/SDR/uhd/host/build/examples/usrp_samples.dat', > 'rb');* > *data=fread(samples_file, 'int16');* > > > > So... when both I/Q channels carry the sines that are generated by the > wave_table function, the results looks fine - attachment "iq.png". > > > > However, I need to work only with the I channel and force the Q to > *disappear*, that is why I added the following lines in the > *tx_waveforms.cpp* code to zero it: > > > > // Zero the Q component > > for (size_t n = 0; n < buff.size(); n++) { > > buff[n] = std::complex<float>( buff[n].real(), *0 *); > > } > > > > And the result is a strangely distorted I-component sine - attachment > "i_only.png". > > > > May you please advise if it is possible to avoid this, because I am doing > something a bit strange that is not related to the normal I/Q modulations? > > > > Thanks in advance, > > V. > > > > > > > > > > >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
