Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock

[Tom Rondeau]

On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam <address@hidden> 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 <address@hidden>
> 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 <address@hidden> wrote:
>>>
>>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam
>>> <address@hidden> 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.
>