On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam <mnis...@winlab.rutgers.edu> wrote: > I got a partial answer to my previously posted question :). When I pass the > complex baseband I & Q with a costas loop block, the output indeed looks > like a square wave. > > Does it mean that external reference clock does not correct the > phase/carrier offset error? Does it only solve the timing error issue? > > Thanks, > > Nazmul
Glad that you are able to get far enough to recover it. As for the remaining 6 kHz offset, what's the RF frequency? What does 6 kHz translate into for a parts per million? While I would expect them to be the same with both locked to the same external clock, we are talking about reality here, so things aren't always that cooperative. I can't think what would cause this kind of an offset, though, as it seems rather large. Maybe someone with more hands-on hardware experience with precision equipment can jump in here. Tom > On Thu, Jun 7, 2012 at 12:00 PM, Nazmul Islam <mnis...@winlab.rutgers.edu> > wrote: >> >> Hi Tom, >> >> First of all, thanks a lot for your detailed reply. I appreciate it. I did >> as you told in the last email, i.e., I transmitted a square wave (switching >> between 0.5 to -0.5). The sqaure wave's period was 1 ms and the sampling >> rate was 1 MHz. I have attached the real part of the outputs with the >> email. >> >> The output shows a phase shift after every 500 samples, i.e., half period >> of the square wave with 1 MHz sampling rate. The sinusoidal nature of the >> output probably comes from frequency offset of the two USRP's. I expected >> this for an internal clock source. >> >> However, I see a 6 kHz frequency offset (3 sine period per 0.5 ms) even >> with the presence of an external clock. The external clock is driving both >> USRP's. The E LED is on. I am using a sine wave with 10 MHz frequency & 7 >> dBm amplitude as the external clock. I also put the clock source options in >> grc as external. Do I need to make any other changes in the GRC blocks to >> inform USRP about the external source? >> >> Any suggestions will be appreciated. Thanks for all of your help. >> >> Nazmul >> >> On Fri, May 25, 2012 at 1:40 PM, Tom Rondeau <t...@trondeau.com> wrote: >>> >>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam >>> <mnis...@winlab.rutgers.edu> wrote: >>> > Hello, >>> > >>> > I want to transmit a continuous stream of 1's or 0's (with bpsk >>> > modulation) >>> > and record the received I-Q stream. I am trying to use the >>> > 'digital_bert_tx.py' code for transmission and the uhd_rx_cfile code >>> > (gr-uhd/apps) for reception. Thereafter, I use the read_complex_binary >>> > code >>> > to read the data in Matlab. >>> > >>> > Surprisingly, I am receiving similar type of I-Q stream (around 0.3 + j >>> > 0.3) >>> > for both 1 and 0 transmission. I am using the following commands: >>> > >>> > self._bits = gr.vector_source_b([1,], True) (I >>> > either >>> > transmit infinite 1 or infinit 0's. When I transmit infinite 0's, I >>> > replace >>> > '1' by '0' in the command) >>> > >>> > ./digital_bert_naz_tx.py -r 5M -m bpsk -f 450M --gain 0.1 >>> > --non-differential (I am using non-differential since I want to see >>> > the >>> > different amplitude levels for '1's or 0's) >>> > >>> > ./uhd_rx_cfile -N 1000 -f 450M --samp-rate 5M file.dat (Since I am >>> > using >>> > bpsk, sample-rate should be equal to bit rate, I assume) >>> > >>> > Ideally, the I-Q stream of bpsk should show 180 degree phase shift for >>> > 1 and >>> > 0 transmission. I am getting the same value for both transmission. Can >>> > anyone suggest where I am making mistakes? >>> > >>> > >>> > Thanks, >>> > >>> > Nazmul >>> >>> >>> Nazmul, >>> Hard to say from this info. A few things to note on, though. First, >>> 1000 samples isn't that much. There are startup transients in >>> hardware, so you might just be seeing effects of those. I'd capture >>> ten thousand or a million and just read out the last 1000. >>> >>> Also, the transmitter and receiver are running on two different >>> clocks, so their frequency and phases aren't going to match, unless >>> you've locked them to the same source. It'd be hard to say what you'll >>> see, exactly, due to this. That's why we use recovery loops for all of >>> these things. >>> >>> What I would recommend is to create a transmitter that transmits a >>> long string of 1's followed by a long string of 0's (100 or 200 each). >>> When you plot the last 1000 samples, you should see something that >>> moves between two amplitudes. I wouldn't trust what you see from one >>> run to another, so just do it at the same time. >>> >>> Tom >> >> >> >> >> -- >> Muhammad Nazmul Islam >> >> Graduate Student >> Electrical & Computer Engineering >> Wireless Information & Networking Laboratory >> Rutgers, USA. >> > > > > -- > Muhammad Nazmul Islam > > Graduate Student > Electrical & Computer Engineering > Wireless Information & Networking Laboratory > Rutgers, USA. > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
