Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
John, Thanks a lot for your email. My previous USRP2 modules had some old daughterboards. I am currently working with USRP N210. I am not sure even this one is getting the external reference, either. Couple of things: 1. I have the tools to probe the 10 MHz reference signal. But I did not find R523 :S. I can see R521, R522, R524, C523, etc. But I did not see R523 in USRO N210. 2. I have kept the J510 jumper at 1-2. Therefore, it should take signal from external reference clock instead of GPS. 3. When I use the "external" clock source option in UHD:USRP Sink block of gnuradio-companion, the E led turns off. On the other hand, if I transmit with "default" clock source option in UHD: USRP sink block, the E led turns on !!! It's very surprising ! 4. I did another experiment to check if the USRP is locked to the external reference. At first, I gave an input of 10 MHz sine wave as an external source and transmitted a signal at 700 MHz carrier frequency. The carrier frequency option was given at gnuradio-companion software. Thereafter, I varied the reference clock frequency slightly (from 10 to 10.3, 10.4 MHz, etc.). During this period, I observed the signal at my laboratory spectrum analyzer. If there was a fixed gain that converted the 10 MHz reference source to 700 MHz carrier frequency, the transmitted signal's center frequency would have shifted from 700 MHz because the fixed gain would multiply 10.1 instead of 10 now. However, the center frequency did not change. I suspect that my USRP is still locked to its internal clock source. Since this happened to two different USRP's, the issue might be in software. Has anyone used external clock source from a gnuradio-companion generated python code? I am changing the external clock reference source in GRC. Do I need to make any other change? Thanks a lot for your help. Nazmul On Fri, Jun 8, 2012 at 12:53 PM, John Malsbury wrote: > Nazmul, > > Do you have the tools(o-scope) and capacity to probe the 10 MHz reference > signal at various places? Looking at the schematic, it looks like R523 is > a good place to determine if the 10 MHz reference is a good place. If you > don't see the external reference across this resistor, there may be a > problem with the reference input or conditioning circuitry. If we > eliminate this as a possibility we can investigate some others... > > -John > > > > -- 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
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
On Fri, Jun 8, 2012 at 8:57 AM, Nazmul Islam wrote: > Thanks for your replies. The function generator is producing a sine wave > with 1 V (10 MHz). This is going to the ref clocks. > It's possible that a function generator output, when loaded down by two REF inputs in parallel, might not produce the amplitude necessary to reliably work, nor might it have the necessary rise time. You'll need to measure these to ensure they meet the REF in requirements. The symptoms you are seeing are an indication they do not. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
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 wrote: > On Thu, Jun 7, 2012 at 7:11 PM, Tom Rondeau wrote: > >> On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam >> 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 wrote: >> >>> >> >>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam >> >>> 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 th
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
On Thu, Jun 7, 2012 at 7:11 PM, Tom Rondeau wrote: > On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam > 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 wrote: > >>> > >>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam > >>> 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, s
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam 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 > 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 wrote: >>> >>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam >>> 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.or
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
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 On Thu, Jun 7, 2012 at 12:00 PM, Nazmul Islam 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 wrote: > >> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam >> 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
