Using external clock references in GRC environment

Hello,

I am running two USRP2’s with a 10 MHz external clock. I am using
gnuradio-companion to transmit data between the USRP’s. I have changed
the clock
source
option as ‘external’ in the UHD:USRP Source & Sinc blocks. I
kept
the time source and clock rate block as default since I am not providing
any external pps.

Unfortunately, I am getting unexpected and wrong outputs. Do I need to
make
any other changes in the USRP Source & Sink options?

Thanks,

Nazmul


Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

I have attached a screenshot that shows that way I am using the USRP:UHD
Sink block. I am running both of my USRP’s with the same 10 MHz clock
signal. The clock signal is coming from a function generator. Therefore,
I
have changed the clock source option in the USRP Sink block to be
external.

Unfortunately, I am getting wrong/strange outputs due to this change. Do
I
need to make any other change in the flowgraph to make it work with
external clock source?

Thanks,

Nazmul

On Tue, Jun 5, 2012 at 4:31 PM, Nazmul I.
[email protected]wrote:

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.


Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

On 06/05/2012 04:53 PM, Nazmul I. wrote:

I have attached a screenshot that shows that way I am using the USRP:UHD
Sink block. I am running both of my USRP’s with the same 10 MHz clock
signal. The clock signal is coming from a function generator. Therefore, I
have changed the clock source option in the USRP Sink block to be external.

Unfortunately, I am getting wrong/strange outputs due to this change. Do I
need to make any other change in the flowgraph to make it work with
external clock source?

Please define “wrong/strange outputs”.

Is the device locked to the reference? ie, is the ref lock light on?
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds

Dear Josh,

Thanks for the reply. The USRP is locked to the function generator. The
E
LED light is on. It is not as bright as LED D & F light, though.

I am sorry for not clarifying on the “strange output” last time. In my
experiment, I am transmitting an LFSR PN sequence. Thereafter, I
correlate
the transmitted PN sequence with the received baseband complex I & Q. If
there were no timing error between the two USRP’s, then I would get high
correlation after every chip sequence period.

I get this high correlation for small chip sequence lengths, e.g. 31,
63,
etc. However, when I use high chip sequence lengths, e.g., 1023 or 4095,
the output correlation is smeared. I don’t see any high peaks. According
to
Jonathan, the timing slips by enough for longer chip sequences and
therefore it leads to reduced correlation.

I thought that an external function generator, connected to the
reference
clocks of Tx an Rx USRP’s, would solve this problem. Unfortunately, the
attached figure will tell you that it did not. I just changed the ‘Clock
Source’ option to ‘External’ in the Source & Sink GRC blocks. I don’t
know
if I need to make any other changes.

Thanks,

Nazmul

On Tue, Jun 5, 2012 at 9:45 PM, Josh B. [email protected] wrote:

Unfortunately, I am getting wrong/strange outputs due to this change. Do
Thanks,
the

Wireless Information & Networking Laboratory
Discuss-gnuradio Info Page


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

Hello Jonathan,

Thanks a lot for your email. I am actually using 1 Mega chip per second
in
my experiments. I am using different chip sequence periods (63, 127,
etc.)
to see how they work. I I just wanted to emphasize on the “external ref
clock source” option in the previous email and I forgot to correct the
sampling rate value before taking the screenshot. I am really sorry for
throwing you off. I have attached the screen shots of my transmitter and
receiver with the email.

In the receiver, I am just taking the baseband I&Q samples that is
stored
in “Input.dat”. I am taking the correlation between the chip sequence &
these samples. Thereafter, I am taking the magnitude of the real &
imaginary parts.

I also think that timing error is leading to the wrong correlation
values
for higher chip sequence. I thought that the timing error would vanish
if I
use an external reference clock. I did that and put the UHD:USRP clock
source options as “external”. I don’t know why the timing error still
exists, i.e., I keep getting undetectable peaks with an external source.

Thanks,

Nazmul

On Wed, Jun 6, 2012 at 12:41 PM, Johnathan C. <
[email protected]> wrote:

It looked like on your last email that your GRC flowgraph has the USRP
might try increasing this as CPU performance allows.

Johnathan


Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

On Wed, Jun 6, 2012 at 9:22 AM, Nazmul I.
[email protected]wrote:

I am sorry for not clarifying on the “strange output” last time. In my
experiment, I am transmitting an LFSR PN sequence. Thereafter, I correlate
the transmitted PN sequence with the received baseband complex I & Q. If
there were no timing error between the two USRP’s, then I would get high
correlation after every chip sequence period.

It looked like on your last email that your GRC flowgraph has the USRP
source sample rate set to 32Ksps. This is not a sample rate producible
by
the USRP; in fact, in the bottom portion of the GRC window, you should
see
an error message telling you what it actually set the sample rate to.
If
this is different from the transmitter, then you will get what you are
seeing (or worse.)

You should look at what the allowable sample rates are for your
transmitter
and receiver USRPs, then pick a common one and set that as the variable
‘samp_rate’ in your GRC flowgraph on both sides. For purposes of your
experiment, I’d choose the lowest sample rate possible; later, you might
try increasing this as CPU performance allows.

Johnathan