Hi Tom & Nick, Thanks for your replies. The function generator is producing a sine wave with 1 V (10 MHz). This is going to the ref clocks. The E light is ON and I have changed the clock source option to be external in gnuradio-companion environment. I tried with square wave, too. But the output did not change. The transmission is taking place at 450 MHz carrier frequency. I am using USRP2's with RFX400 & FLEX400 daughterboard.
In fact, I see a 6 kHz frequency offset even without the reference clock. Does it suggest that the external reference clock is somehow not going through? I don't know if I should change more options in gnuradio-companion toolbox to make the reference clock work. Thanks, Nazmul On Thu, Jun 7, 2012 at 11:31 PM, Nick Foster <n...@ettus.com> wrote: > On Thu, Jun 7, 2012 at 7:11 PM, Tom Rondeau <t...@trondeau.com> wrote: > >> 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 >> > > 6kHz is way too high. They should be cycle-locked. What is the amplitude > of the clock signal you're feeding into the USRP2? > > --n > > >> >> >> > 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 >> > > -- 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
