[USRP-users] USRP-users Digest, Vol 22, Issue 26

mleech at ripnet.com mleech at ripnet.com
Tue Jun 26 13:10:31 EDT 2012


 

You need a faster computer. Really, there's no much tweaking that
can be done at the driver level to improve things when you're getting
consistent overrruns. 

And if your TX processing is complicated, you
may find it difficult even to keep up at 25Msps from even a fairly
"beefy" host computer. 

-Marcus 

On 26 Jun 2012 13:04, JAY PRAKASH
wrote: 

> Actually I am trying for 25Msps of sampling rate only but the
laptop command windows shows UUUUUUUUUU. 
> 
> so should I try at faster
laptop or there is some solution by changing some variables in UHD
driver to get the higher desired sample rate? 
> 
> Jay Prakash 
>
B.Tech Part III 
> Electronics Engineering 
> IIT BHU 
> VARANASI 
> 
>
On Wed, Jun 27, 2012 at 12:00 AM, <usrp-users-request at lists.ettus.com
[170]> wrote:
> 
>> Send USRP-users mailing list submissions to
>>
usrp-users at lists.ettus.com [1]
>> 
>> To subscribe or unsubscribe via
the World Wide Web, visit
>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[2]
>> or, via email, send a message with subject or body 'help' to
>>
usrp-users-request at lists.ettus.com [3]
>> 
>> You can reach the person
managing the list at
>> usrp-users-owner at lists.ettus.com [4]
>> 
>> When
replying, please edit your Subject line so it is more specific
>> than
"Re: Contents of USRP-users digest..."
>> 
>> Today's Topics:
>> 
>> 1.
Re: UDP Socket, SO_RCVBUF (Simon HB9DRV)
>> 2. Re: UDP Socket, SO_RCVBUF
(Simon HB9DRV)
>> 3. Re: UDP Socket, SO_RCVBUF (mleech at ripnet.com
[5])
>> 4. Does each antenna of USRP N210 can both transmit and
receive?
>> (Weixian Zhou)
>> 5. Re: Does each antenna of USRP N210 can
both transmit and
>> receive? (mleech at ripnet.com [6])
>> 6. Re: Does
each antenna of USRP N210 can both transmit and
>> receive? (Alex
Zhang)
>> 7. Re: Does each antenna of USRP N210 can both transmit and
>>
receive? (Nick Foster)
>> 8. Re: Does each antenna of USRP N210 can both
transmit and
>> receive? (Alex Zhang)
>> 9. using tune_request_t (Sanat
Gulvadi)
>> 10. Re: using tune_request_t (Josh Blum)
>> 11. Re: using
tune_request_t (Sanat Gulvadi)
>> 12. Re: Broken gpsdo or bad antenna?
(Dario Lombardo)
>> 13. Regarding the 112 decimation and 174 decimation
factors
>> (Birhane Alemayoh)
>> 14. MIMO Cable (Damien Serant)
>> 15.
Re: Broken gpsdo or bad antenna? (Nick Foster)
>> 16. Sampling rate for
usrp2 (JAY PRAKASH)
>> 17. Re: Sampling rate for usrp2
(mleech at ripnet.com [7])
>> 18. Re: Sequence Errors on USRP N200 (Jahshan
Bhatti)
>> 19. USRP2 synchronization (JAY PRAKASH)
>> 20. Re: Broken
gpsdo or bad antenna? (Dario Lombardo)
>> 
>>
----------------------------------------------------------------------
>>

>> Message: 1
>> Date: Mon, 25 Jun 2012 18:47:32 +0200
>> From: "Simon
HB9DRV" <simon at hb9drv.ch [8]>
>> To: <josh at ettus.com [9]>,
<usrp-users at lists.ettus.com [10]>
>> Subject: Re: [USRP-users] UDP
Socket, SO_RCVBUF
>> Message-ID:
<028901cd52f2$37d56e70$a7804b50$@hb9drv.ch [11]>
>> Content-Type:
text/plain; charset="us-ascii"
>> 
>> Josh,
>> 
>> If I'm using fc32 as
the sample type then am I correct in assuming that with
>> a 10MHz
sample rate the bandwidth is 10 * 2 (I+Q) * 4 (size of float) =
>>
80MS/s?
>> 
>> Simon Brown, HB9DRV
>> http://dit-dit-dit.com [12]
>> 
>>
You are standing at the end of a road before a small brick building.
Around
>> you is a forest.
>> A small stream flows out of the building
and down a gully. The sunspot count
>> is 285.
>> 
>> -----Original
Message-----
>> From: usrp-users-bounces at lists.ettus.com [13]
>>
[mailto:usrp-users-bounces at lists.ettus.com [14]] On Behalf Of Josh
Blum
>> 
>> The constructor takes arbitrary key/value pairs. One
possible key is the
>> "recv_buff_size". By default this is 50MB. See
docs here:
>>
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buf
[15]
>> fers
>> 
>> ------------------------------
>> 
>> Message: 2
>>
Date: Mon, 25 Jun 2012 19:01:27 +0200
>> From: "Simon HB9DRV"
<simon at hb9drv.ch [16]>
>> To: <usrp-users at lists.ettus.com [17]>
>>
Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
>> Message-ID:
<029101cd52f4$29196380$7b4c2a80$@hb9drv.ch [18]>
>> Content-Type:
text/plain; charset="us-ascii"
>> 
>> Crap, too much German beer :)
>>

>> If I'm using fc32 as the sample type then am I correct in assuming
that with
>> a 10 MS/s sample rate the bandwidth is 10 * 2 (I+Q) * 4
(size of float) = 80
>> MB/s?
>> 
>> Simon Brown, HB9DRV
>>
http://dit-dit-dit.com [19]
>> 
>> You are standing at the end of a road
before a small brick building. Around
>> you is a forest.
>> A small
stream flows out of the building and down a gully. The sunspot count
>>
is 285.
>> 
>> -----Original Message-----
>> From:
usrp-users-bounces at lists.ettus.com [20]
>>
[mailto:usrp-users-bounces at lists.ettus.com [21]] On Behalf Of Simon
HB9DRV
>> Sent: 25 June 2012 18:48
>> To: josh at ettus.com [22];
usrp-users at lists.ettus.com [23]
>> Subject: Re: [USRP-users] UDP Socket,
SO_RCVBUF
>> 
>> Josh,
>> 
>> If I'm using fc32 as the sample type then
am I correct in assuming that with
>> a 10MHz sample rate the bandwidth
is 10 * 2 (I+Q) * 4 (size of float) =
>> 80MS/s?
>> 
>> Simon Brown,
HB9DRV
>> http://dit-dit-dit.com [24]
>> 
>> You are standing at the end
of a road before a small brick building. Around
>> you is a forest.
>> A
small stream flows out of the building and down a gully. The sunspot
count
>> is 285.
>> 
>> -----Original Message-----
>> From:
usrp-users-bounces at lists.ettus.com [25]
>>
[mailto:usrp-users-bounces at lists.ettus.com [26]] On Behalf Of Josh
Blum
>> 
>> The constructor takes arbitrary key/value pairs. One
possible key is the
>> "recv_buff_size". By default this is 50MB. See
docs here:
>>
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buf
[27]
>> fers
>> 
>> _______________________________________________
>>
USRP-users mailing list
>> USRP-users at lists.ettus.com [28]
>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[29]
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date:
Mon, 25 Jun 2012 13:07:28 -0400
>> From: mleech at ripnet.com [30]
>> To:
<usrp-users at lists.ettus.com [31]>
>> Subject: Re: [USRP-users] UDP
Socket, SO_RCVBUF
>> Message-ID:
<d9e0726b7b88a7d9ad0771a5a9dbdd73 at ripnet.com [32]>
>> Content-Type:
text/plain; charset="utf-8"
>> 
>> On 25 Jun 2012 13:01, Simon HB9DRV
wrote:
>> 
>> > Crap, too much German
>> beer :)
>> >
>> > If I'm using
fc32 as the sample type then am I correct in
>> assuming that with
>> >
a 10 MS/s sample rate the bandwidth is 10 * 2 (I+Q)
>> * 4 (size of
float) = 80
>> > MB/s?
>> >
>> > Simon Brown, HB9DRV
>> >
>>
http://dit-dit-dit.com [33]
>> 
>> There are only two "wire format"
types: sc16 and
>> sc8
>> 
>> For sc16 (16-bit I 16-bit Q):
>> 
>>
10MS/s * 32-bits = 320Mbits/second
>> 
>> For sc8 (8-bit I 8-bit Q):
>>

>> 10Msps * 16-bits = 160Mbits/second
>> 
>> Now,
>> if you're talking
about the host side and doing calculations for disk
>> writes or
something, then, fc32 is 32-bits I 32-bits Q:
>> 
>> 10Msps *
>> 64-bits
= 640Mbits/second
>> 
>> = 80Mbyte/second
>> 
>> -------------- next
part --------------
>> An HTML attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/75395faf/attachment-0001.html
[34]>
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date:
Mon, 25 Jun 2012 14:33:00 -0400
>> From: Weixian Zhou <ideazwx at gmail.com
[35]>
>> To: usrp-users <usrp-users at lists.ettus.com [36]>
>> Subject:
[USRP-users] Does each antenna of USRP N210 can both transmit
>> and
receive?
>> Message-ID:
>>
<CAHeRwcQbF07RkrFeEM+8Mhu2m7v-4wrFqhhOwCaNHkStBuVbhQ at mail.gmail.com
[37]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> I am
using USRP N210 and the daughter boards are XCVR2450. Does each
>>
antenna can both transmit and receive, or one antenna can only transmit
and
>> another can only receive?
>> 
>> --
>> Regards,
>> Weixian
Zhou
>> -------------- next part --------------
>> An HTML attachment
was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/408675fb/attachment-0001.html
[38]>
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date:
Mon, 25 Jun 2012 14:39:19 -0400
>> From: mleech at ripnet.com [39]
>> To:
<usrp-users at lists.ettus.com [40]>
>> Subject: Re: [USRP-users] Does each
antenna of USRP N210 can both
>> transmit and receive?
>> Message-ID:
<843d16888b1a8dd04f88d79788e3d91b at ripnet.com [41]>
>> Content-Type:
text/plain; charset="utf-8"
>> 
>> On 25 Jun 2012 14:33, Weixian Zhou
wrote:
>> 
>> > I am using USRP N210
>> and the daughter boards are
XCVR2450. Does each antenna can both
>> transmit and receive, or one
antenna can only transmit and another can
>> only receive?
>> > --
>>
>
>> > Regards, Weixian
>> Zhou
>> 
>>
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[42]
>> 
>> Either port can perform either function. But it's a
half-duplex
>> device, so you can't TX and RX at the same time.
>> 
>>
-------------- next part --------------
>> An HTML attachment was
scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/d47e38c3/attachment-0001.html
[43]>
>> 
>> ------------------------------
>> 
>> Message: 6
>> Date:
Mon, 25 Jun 2012 14:58:15 -0500
>> From: Alex Zhang
<cingular.alex at gmail.com [44]>
>> To: mleech at ripnet.com [45]
>> Cc:
usrp-users at lists.ettus.com [46]
>> Subject: Re: [USRP-users] Does each
antenna of USRP N210 can both
>> transmit and receive?
>> Message-ID:
>>
<CA+FEAnfemYtaEgagbb57MSBh+X_J=uiOnFg1uWW8zs8F=j259Q at mail.gmail.com
[47]>
>> Content-Type: text/plain; charset="windows-1252"
>> 
>> SBX
board claims to support full-duplex.
>> However, I still have problem in
using SBX board to carry out the
>> full-duplex communication.
>> 
>> On
Mon, Jun 25, 2012 at 1:39 PM, <mleech at ripnet.com [48]> wrote:
>> 
>> >
**
>> >
>> > On 25 Jun 2012 14:33, Weixian Zhou wrote:
>> >
>> > I am
using USRP N210 and the daughter boards are XCVR2450. Does each
>> >
antenna can both transmit and receive, or one antenna can only transmit
and
>> > another can only receive?
>> >
>> > --
>> > Regards,
>> >
Weixian Zhou
>> >
>> >
>> >
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[49]
>> >
>> > Either port can perform either function. But it's a
half-duplex device,
>> > so you can't TX and RX at the same time.
>>
>
>> >
>> >
>> >
>> >
>> >
>> >
_______________________________________________
>> > USRP-users mailing
list
>> > USRP-users at lists.ettus.com [50]
>> >
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[51]
>> >
>> >
>> 
>> --
>> 
>> Alex,
>> *Dreams can come true ? just
believe.*
>> -------------- next part --------------
>> An HTML
attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/60a4952b/attachment-0001.html
[52]>
>> 
>> ------------------------------
>> 
>> Message: 7
>> Date:
Mon, 25 Jun 2012 13:04:47 -0700
>> From: Nick Foster <nick at ettus.com
[53]>
>> To: Alex Zhang <cingular.alex at gmail.com [54]>
>> Cc:
usrp-users at lists.ettus.com [55]
>> Subject: Re: [USRP-users] Does each
antenna of USRP N210 can both
>> transmit and receive?
>> Message-ID:
>>
<CALALHJV-QgNhgnC6m9fQK9sWY7q-GMN3p5xmtuBEeqUt1jdjtA at mail.gmail.com
[56]>
>> Content-Type: text/plain; charset="windows-1252"
>> 
>> On Mon,
Jun 25, 2012 at 12:58 PM, Alex Zhang <cingular.alex at gmail.com
[57]>wrote:
>> 
>> > SBX board claims to support full-duplex.
>> >
However, I still have problem in using SBX board to carry out the
>> >
full-duplex communication.
>> >
>> 
>> Alex,
>> 
>> SBX is by design
full duplex. XCVR2450 is half-duplex by nature and was not
>> designed
for simultaneous TX/RX. Could you please elaborate on how SBX is
>> not
functioning in full duplex mode in your application?
>> 
>> --n
>> 
>>
>
>> > On Mon, Jun 25, 2012 at 1:39 PM, <mleech at ripnet.com [58]>
wrote:
>> >
>> >> **
>> >>
>> >> On 25 Jun 2012 14:33, Weixian Zhou
wrote:
>> >>
>> >> I am using USRP N210 and the daughter boards are
XCVR2450. Does each
>> >> antenna can both transmit and receive, or one
antenna can only transmit and
>> >> another can only receive?
>> >>
>>
>> --
>> >> Regards,
>> >> Weixian Zhou
>> >>
>> >>
>> >>
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[59]
>> >>
>> >> Either port can perform either function. But it's a
half-duplex device,
>> >> so you can't TX and RX at the same time.
>>
>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
_______________________________________________
>> >> USRP-users mailing
list
>> >> USRP-users at lists.ettus.com [60]
>> >>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[61]
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Alex,
>> > *Dreams can come
true ? just believe.*
>> >
>> >
>> >
_______________________________________________
>> > USRP-users mailing
list
>> > USRP-users at lists.ettus.com [62]
>> >
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[63]
>> >
>> >
>> -------------- next part --------------
>> An HTML
attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/627d526a/attachment-0001.html
[64]>
>> 
>> ------------------------------
>> 
>> Message: 8
>> Date:
Mon, 25 Jun 2012 15:33:56 -0500
>> From: Alex Zhang
<cingular.alex at gmail.com [65]>
>> To: Nick Foster <nick at ettus.com
[66]>
>> Cc: usrp-users at lists.ettus.com [67]
>> Subject: Re:
[USRP-users] Does each antenna of USRP N210 can both
>> transmit and
receive?
>> Message-ID:
>>
<CA+FEAncqAa6ZQmWckCSfv_YAJgQ9WfVMpEvb0nKF8T1-9um3Pg at mail.gmail.com
[68]>
>> Content-Type: text/plain; charset="windows-1252"
>> 
>> Maybe I
did not use the SBX correctly.
>> What I observed is that the if the my
USRP tries to receive something right
>> after it just complete a packet
transmission, it always fails in receiving
>> the correct data, even the
repsonder sends out the reply correctly. Thus I
>> add delay at the
responder before each reply is transmitting, as the other
>> side is
still in TX/RX switching.
>> 
>> Please see this link for my problem
description.
>>
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3964 [69]
>> 
>>
I have tried to set the TX and RX at different antennas, like the RX
is
>> RX2, TX is at TX/RX. But the problem still there, more like as
working in
>> half-duplex mode.
>> 
>> On Mon, Jun 25, 2012 at 3:04 PM,
Nick Foster <nick at ettus.com [70]> wrote:
>> 
>> > On Mon, Jun 25, 2012
at 12:58 PM, Alex Zhang <cingular.alex at gmail.com [71]>wrote:
>> >
>> >>
SBX board claims to support full-duplex.
>> >> However, I still have
problem in using SBX board to carry out the
>> >> full-duplex
communication.
>> >>
>> >
>> > Alex,
>> >
>> > SBX is by design full
duplex. XCVR2450 is half-duplex by nature and was
>> > not designed for
simultaneous TX/RX. Could you please elaborate on how SBX
>> > is not
functioning in full duplex mode in your application?
>> >
>> > --n
>>
>
>> >
>> >>
>> >> On Mon, Jun 25, 2012 at 1:39 PM, <mleech at ripnet.com
[72]> wrote:
>> >>
>> >>> **
>> >>>
>> >>> On 25 Jun 2012 14:33, Weixian
Zhou wrote:
>> >>>
>> >>> I am using USRP N210 and the daughter boards
are XCVR2450. Does each
>> >>> antenna can both transmit and receive, or
one antenna can only transmit and
>> >>> another can only receive?
>>
>>>
>> >>> --
>> >>> Regards,
>> >>> Weixian Zhou
>> >>>
>> >>>
>> >>>
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[73]
>> >>>
>> >>> Either port can perform either function. But it's a
half-duplex device,
>> >>> so you can't TX and RX at the same time.
>>
>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
_______________________________________________
>> >>> USRP-users
mailing list
>> >>> USRP-users at lists.ettus.com [74]
>> >>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[75]
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> Alex,
>> >> *Dreams
can come true ? just believe.*
>> >>
>> >>
>> >>
_______________________________________________
>> >> USRP-users mailing
list
>> >> USRP-users at lists.ettus.com [76]
>> >>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[77]
>> >>
>> >>
>> >
>> 
>> --
>> 
>> Alex,
>> *Dreams can come true ?
just believe.*
>> -------------- next part --------------
>> An HTML
attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/d3435681/attachment-0001.html
[78]>
>> 
>> ------------------------------
>> 
>> Message: 9
>> Date:
Tue, 26 Jun 2012 08:17:47 +0200
>> From: Sanat Gulvadi
<sanatgulvadi at gmail.com [79]>
>> To: usrp-users at lists.ettus.com [80]
>>
Subject: [USRP-users] using tune_request_t
>> Message-ID:
>>
<CAH12yLtPLHHzFTzT847+CSy0ZFOXW+QJLUkkp0Sij02r8qjrzw at mail.gmail.com
[81]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>>
Greetings,
>> 
>> I have a question about using the tune_request_t in my
application. I have
>> read from previous posts that there is an
inherent DC component at the
>> receiver which cannot be eliminated but
can be pushed so that it occurs
>> outside the band of interest.
>> When
I use usrp->set_rx_freq(uhd::tune_request_t(target_freq,lo_offset)) I
>>
am not sure what lo_offset is. I assume target_freq is the center freq
to
>> which I want the RF to tune to. Is lo_offset the offset by which I
want to *
>> push* the DC component so it ends up outside my band of
interest ?
>> So in this case, if I made lo_offset say, once or twice my
sampling rate,
>> should this be enough to accomplish this? Do I have to
additionally set the
>> tuning policy to POLICY_MANUAL ?
>> 
>> I
apologize if this question is too basic for this list.
>> 
>> Thanks and
Best Regards,
>> Sanat
>> -------------- next part --------------
>> An
HTML attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/ba952b76/attachment-0001.html
[82]>
>> 
>> ------------------------------
>> 
>> Message: 10
>> Date:
Mon, 25 Jun 2012 23:30:37 -0700
>> From: Josh Blum <josh at ettus.com
[83]>
>> To: usrp-users at lists.ettus.com [84]
>> Subject: Re:
[USRP-users] using tune_request_t
>> Message-ID:
<4FE9570D.3050508 at ettus.com [85]>
>> Content-Type: text/plain;
charset=ISO-8859-1
>> 
>> On 06/25/2012 11:17 PM, Sanat Gulvadi
wrote:
>> > Greetings,
>> >
>> > I have a question about using the
tune_request_t in my application. I have
>> > read from previous posts
that there is an inherent DC component at the
>> > receiver which cannot
be eliminated but can be pushed so that it occurs
>> > outside the band
of interest.
>> > When I use
usrp->set_rx_freq(uhd::tune_request_t(target_freq,lo_offset)) I
>> > am
not sure what lo_offset is. I assume target_freq is the center freq
to
>> > which I want the RF to tune to. Is lo_offset the offset by which
I want to *
>> > push* the DC component so it ends up outside my band of
interest ?
>> 
>> You might find helpful notes here:
>>
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
[86]
>> 
>>
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
[87]
>> 
>> > So in this case, if I made lo_offset say, once or twice
my sampling rate,
>> > should this be enough to accomplish this? Do I
have to additionally set the
>> > tuning policy to POLICY_MANUAL ?
>>
>
>> 
>> That constructor w/ the LO offset is simply a shortcut for
doing this.
>> 
>> -josh
>> 
>> ------------------------------
>> 
>>
Message: 11
>> Date: Tue, 26 Jun 2012 09:39:03 +0200
>> From: Sanat
Gulvadi <sanatgulvadi at gmail.com [88]>
>> To: josh at ettus.com [89]
>> Cc:
usrp-users at lists.ettus.com [90]
>> Subject: Re: [USRP-users] using
tune_request_t
>> Message-ID:
>>
<CAH12yLu7NpL+es2CMzASG=zaKAFdOw-hTeq2xmVA=inPUJFp_Q at mail.gmail.com
[91]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hi
Josh,
>> I actually read through those pages before I emailed the list.
Just want to
>> know if lo_offset is the variable that represents the
frequency offset by
>> which I have to push the dc or if it's the
frequency to which I want to set
>> the dc to.
>> Also is it necessary
to set the policy to manual first ?
>> Regards, Sanat
>> On Jun 26, 2012
8:30 AM, "Josh Blum" <josh at ettus.com [92]> wrote:
>> 
>> >
>> >
>> > On
06/25/2012 11:17 PM, Sanat Gulvadi wrote:
>> > > Greetings,
>> > >
>> >
> I have a question about using the tune_request_t in my application.
I
>> > have
>> > > read from previous posts that there is an inherent DC
component at the
>> > > receiver which cannot be eliminated but can be
pushed so that it occurs
>> > > outside the band of interest.
>> > >
When I use
usrp->set_rx_freq(uhd::tune_request_t(target_freq,lo_offset))
>> > I
>>
> > am not sure what lo_offset is. I assume target_freq is the center
freq to
>> > > which I want the RF to tune to. Is lo_offset the offset
by which I want
>> > to *
>> > > push* the DC component so it ends up
outside my band of interest ?
>> >
>> >
>> > You might find helpful
notes here:
>> >
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
[93]
>> >
>> >
>> >
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
[94]
>> >
>> > > So in this case, if I made lo_offset say, once or
twice my sampling rate,
>> > > should this be enough to accomplish this?
Do I have to additionally set
>> > the
>> > > tuning policy to
POLICY_MANUAL ?
>> > >
>> >
>> > That constructor w/ the LO offset is
simply a shortcut for doing this.
>> >
>> > -josh
>> >
>> >
_______________________________________________
>> > USRP-users mailing
list
>> > USRP-users at lists.ettus.com [95]
>> >
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[96]
>> >
>> -------------- next part --------------
>> An HTML
attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/ecbdd283/attachment-0001.html
[97]>
>> 
>> ------------------------------
>> 
>> Message: 12
>> Date:
Tue, 26 Jun 2012 09:41:21 +0200
>> From: Dario Lombardo
<dario.lombardo.ml at gmail.com [98]>
>> To: Nick Foster <nick at ettus.com
[99]>, John Malsbury
>> <john.malsbury at ettus.com [100]>
>> Cc:
"usrp-users at lists.ettus.com [101]" <usrp-users at lists.ettus.com [102]>
>>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
>> Message-ID:
>>
<CAOYJJfsfictpW4_ZiTeg=V_VuxEcnKTEAvAKrJ12TH7ozznQjQ at mail.gmail.com
[103]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> John,
Nick
>> Any other ideas, your side? Do you have debugging/test code to
check that
>> gpsdo is not broken?
>> I've tried everything and the only
possibily left is a broken gpsdo.
>> 
>> On Tue, Jun 19, 2012 at 4:53
PM, Nick Foster <nick at ettus.com [104]> wrote:
>> 
>> > Dario,
>> >
>> >
Also, please try configuring the USRP for "external" reference as you
did
>> > for the cesium test previously. Then connect the GPSDO to the
external
>> > reference input and see if kal gives reasonable error.
>>
>
>> > It does seem like you may have a faulty reference input.
>> >
>>
> --n
>> >
>> > On Tue, Jun 19, 2012 at 4:45 AM, John Malsbury
<john.malsbury at ettus.com [105]>wrote:
>> >
>> >> Just for grins, can you
remove the eeprom config that enables the
>> >> internal gpsdo? What
results do you see from kal when the internal tcxo on
>> >> the
motherboard is used?
>> >>
>> >> BTW, are you getting reasonable gga
strings that correlate to your known
>> >> position?
>> >>
>> >>
>> >>
John
>> >>
>> >> On Tuesday, June 19, 2012, Dario Lombardo
<dario.lombardo.ml at gmail.com [106]>
>> >> wrote:
>> >> > Hi Josh
>> >>
>
>> >> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury
<john.malsbury at ettus.com [107]>
>> >> wrote:
>> >> >>
>> >> >> Dario,
>>
>> >>
>> >> >> Forgive me if I am not able to see your previous posts as
I am
>> >> answering from my phone. Are you saying there is
>> >> >> 11
khz of error in the 10 mhz ref, or some frequency set to a
>> >>
daughterboard LO?
>> >> >
>> >> > I'm saying that error is the output of
kalibrate.
>> >> >
>> >> >>
>> >> >> You mention using an external
reference. I don't think you would
>> >> achieve lock if this were the
issue, but have you ensured the jumper is in
>> >> the proper
configuration?
>> >> >
>> >> > When using the front panel connectors, I
moved the jumper J510 to
>> >> select them. In this case I got 0 Hz of
error at my first try. To be sure,
>> >> I disconnected the gpsdo from
the mainboard.
>> >> >
>> >> >>
>> >> >> Are you selecting default or
external as the ref source in your
>> >> software?
>> >> >
>> >> > When
using the gpsdo, I moved the jumper J510, then configured the
>> >>
eeprom to "internal". In this case I suppose that the N210
automatically
>> >> selects the gpsdo. In fact every time I run
something I see
>> >> > -- Opening a USRP2/N-Series device...
>> >> > --
Current recv frame size: 1472 bytes
>> >> > -- Current send frame size:
1472 bytes
>> >> > -- Found a Jackson Labs GPS
>> >> > -- Setting
references to the internal GPSDO
>> >> > -- Initializing time to the
internal GPSDO
>> >> > no matter if any "external ref" is used or not.
In kal, I got that
>> >> error with and without the "-x" switch.
>> >>
>>
>> >> >> John
>> >> >>
>> >> >> On Tuesday, June 19, 2012, Dario
Lombardo <dario.lombardo.ml at gmail.com [108]>
>> >> wrote:
>> >> >> > Hi
all
>> >> >> > After many tries with my gpsdo, I still can't get a good
clock.
>> >> >> > I've written a sw that continuously polls the
gps_locked and the
>> >> ref_locked sensors. Both of them are always
locked, that means that my
>> >> antenna is getting a quite "clear" sky
view.
>> >> >> > I've connected the front panel connectors of my N210 to
a cesium
>> >> clock/pps generator, and I get 2 to 0 Hz of error with
kal. That should
>> >> mean that my usrp works fine and the kal commands
are good.hu [109]
>> >> >> > I've left the usrp turned on, with the gps
antenna connected, for
>> >> over 20 hours, but kal still gives me
around 11 kHz of error.
>> >> >> > I think that one of these 2 things is
happening:
>> >> >> > 1) my gpsdo card is broken. What can I do to
ensure that this is not
>> >> the case? And if this is the case, what
can I do?
>> >> >> > 2) my antenna can't give a signal that is clear
enough, so the gpsdo
>> >> isn't unable to give me the clock.
>> >> >> >
What do you think about the above cases?
>> >> >> > Any help
appreciated.
>> >> >> > Dario.
>> >>
>> >> Just for grins, can you
remove the eeprom config that enables the
>> >> internal gpsdo? What
results do you see from kal when the internal tcxo on
>> >> the
motherboard is used?
>> >>
>> >> Are you getting reasonable gga strings
that correlate to your known
>> >> position?
>> >>
>> >>
>> >> John
>>
>>
>> >> On Tuesday, June 19, 2012, Dario Lombardo
<dario.lombardo.ml at gmail.com [110]>
>> >> wrote:
>> >> > Hi Josh
>> >>
>
>> >> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury
<john.malsbury at ettus.com [111]>
>> >> wrote:
>> >> >>
>> >> >> Dario,
>>
>> >>
>> >> >> Forgive me if I am not able to see your previous posts as
I am
>> >> answering from my phone. Are you saying there is
>> >> >> 11
khz of error in the 10 mhz ref, or some frequency set to a
>> >>
daughterboard LO?
>> >> >
>> >> > I'm saying that error is the output of
kalibrate.
>> >> >
>> >> >>
>> >> >> You mention using an external
reference. I don't think you would
>> >> achieve lock if this were the
issue, but have you ensured the jumper is in
>> >> the proper
configuration?
>> >> >
>> >> > When using the front panel connectors, I
moved the jumper J510 to
>> >> select them. In this case I got 0 Hz of
error at my first try. To be sure,
>> >> I disconnected the gpsdo from
the mainboard.
>> >> >
>> >> >>
>> >> >> Are you selecting default or
external as the ref source in your
>> >> software?
>> >> >
>> >> > When
using the gpsdo, I moved the jumper J510, then configured the
>> >>
eeprom to "internal". In this case I suppose that the N210
automatically
>> >> selects the gpsdo. In fact every time I run
something I see
>> >> > -- Opening a USRP2/N-Series device...
>> >> > --
Current recv frame size: 1472 bytes
>> >> > -- Current send frame size:
1472 bytes
>> >> > -- Found a Jackson Labs GPS
>> >> > -- Setting
references to the internal GPSDO
>> >> > -- Initializing time to the
internal GPSDO
>> >> > no matter if any "external ref" is used or not.
In kal, I got that
>> >> error with and without the "-x" switch.
>> >>
>>
>> >> >> John
>> >> >>
>> >> >> On Tuesday, June 19, 2012, Dario
Lombardo <dario.lombardo.ml at gmail.com [112]>
>> >> wrote:
>> >> >> > Hi
all
>> >> >> > After many tries with my gpsdo, I still can't get a good
clock.
>> >> >> > I've written a sw that continuously polls the
gps_locked and the
>> >> ref_locked sensors. Both of them are always
locked, that means that my
>> >> antenna is getting a quite "clear" sky
view.
>> >> >> > I've connected the front panel connectors of my N210 to
a cesium
>> >> clock/pps generator, and I get 2 to 0 Hz of error with
kal. That should
>> >> mean that my usrp works fine and the kal commands
are good.hu [113]
>> >> >> > I've left the usrp turned on, with the gps
antenna connected, for
>> >> over 20 hours, but kal still gives me
around 11 kHz of error.
>> >> >> > I think that one of these 2 things is
happening:
>> >> >> > 1) my gpsdo card is broken. What can I do to
ensure that this is not
>> >> the case? And if this is the case, what
can I do?
>> >> >> > 2) my antenna can't give a signal that is clear
enough, so the gpsdo
>> >> isn't unable to give me the clock.
>> >> >> >
What do you think about the above cases?
>> >> >> > Any help
appreciated.
>> >> >> > Dario.
>> >> >
>> >>
>> >>
_______________________________________________
>> >> USRP-users mailing
list
>> >> USRP-users at lists.ettus.com [114]
>> >>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[115]
>> >>
>> >>
>> >
>> -------------- next part --------------
>> An
HTML attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/08012805/attachment-0001.html
[116]>
>> 
>> ------------------------------
>> 
>> Message: 13
>>
Date: Tue, 26 Jun 2012 14:10:00 +0300
>> From: Birhane Alemayoh
<birhanea at gmail.com [117]>
>> To: usrp-users at lists.ettus.com [118]
>>
Subject: [USRP-users] Regarding the 112 decimation and 174 decimation
>>
factors
>> Message-ID:
>>
<CAPF4MOw5HLbQsbPgEk0ar3Xfa+ZMKeN1bu3KtUFKA7HZfSprqQ at mail.gmail.com
[119]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hello
all
>> 
>> I understand the USB and gigiabit limitation when streaming
data to a host
>> PC. These RF bandwidth of the FPGA is decimated by a
decimation factor to
>> reduce the data rate to be streamed to the
PC.
>> 
>> For GSM applications, many litratures recommended to use
decimation factor
>> of 112 for USRP1 and 174 for USRP2, N2xxs to
capture one GSM channle. But
>> how can these decimation factors achieve
a bandwidth of one GSM channel.
>> One GSM channel has a bandwidth of
200 kHz. But for a USRP N200 with
>> 100MHz sampling rate for example;
if we use 174 decimation factor, we will
>> end up with 100/174 =
574.7KHz. This will be the input for our PC.
>> So what is the reason
behaind selecting 112 and 174?
>> Thank you!!
>> 
>> Birhane
>>
-------------- next part --------------
>> An HTML attachment was
scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/7283ccc0/attachment-0001.html
[120]>
>> 
>> ------------------------------
>> 
>> Message: 14
>>
Date: Tue, 26 Jun 2012 15:17:42 +0200
>> From: Damien Serant
<damien.serant at gmail.com [121]>
>> To: USRP-users at lists.ettus.com
[122]
>> Subject: [USRP-users] MIMO Cable
>> Message-ID:
>>
<CAM=tNLnCMr20qknJTewNfbwQP0e4Eb91Ts5os7nfPM35q4N31g at mail.gmail.com
[123]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hi
list,
>> 
>> Is the MIMO cable sold with the original USRP2 compatible
with the USRP
>> N200, because i don't manage to perform MIMO operation
("failed to
>> time-align" error) ?
>> 
>> Thanks,
>> 
>> Damien
>>
-------------- next part --------------
>> An HTML attachment was
scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/f30abfb4/attachment-0001.html
[124]>
>> 
>> ------------------------------
>> 
>> Message: 15
>>
Date: Tue, 26 Jun 2012 07:52:09 -0700
>> From: Nick Foster
<nick at ettus.com [125]>
>> To: Dario Lombardo
<dario.lombardo.ml at gmail.com [126]>
>> Cc: "usrp-users at lists.ettus.com
[127]" <usrp-users at lists.ettus.com [128]>
>> Subject: Re: [USRP-users]
Broken gpsdo or bad antenna?
>> Message-ID:
>>
<CALALHJUYW=K+06EgMHrytFhdfemuauuOtoUdkOQ_FSvayQw8Rw at mail.gmail.com
[129]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hi
Dario,
>> 
>> I'm out of ideas regarding your reference. To me, it seems
like *something*
>> is locking, but not to the proper device.
>> 
>> The
last possibility I can see before a hardware failure is the
possibility
>> that your local cell tower actually is off 20kHz.
Unlikely, but if it's
>> your only point of reference I suppose it's
possible.
>> 
>> Let me know if you want us to issue an RMA to retrieve
the USRP + GPSDO for
>> testing and repair.
>> 
>> --n
>> 
>> On Tue,
Jun 26, 2012 at 12:41 AM, Dario Lombardo <
>>
dario.lombardo.ml at gmail.com [130]> wrote:
>> 
>> > John, Nick
>> > Any
other ideas, your side? Do you have debugging/test code to check that
>>
> gpsdo is not broken?
>> > I've tried everything and the only possibily
left is a broken gpsdo.
>> >
>> > On Tue, Jun 19, 2012 at 4:53 PM, Nick
Foster <nick at ettus.com [131]> wrote:
>> >
>> >> Dario,
>> >>
>> >> Also,
please try configuring the USRP for "external" reference as you did
>>
>> for the cesium test previously. Then connect the GPSDO to the
external
>> >> reference input and see if kal gives reasonable error.
>>
>>
>> >> It does seem like you may have a faulty reference input.
>>
>>
>> >> --n
>> >>
>> >> On Tue, Jun 19, 2012 at 4:45 AM, John Malsbury
<john.malsbury at ettus.com [132]>wrote:
>> >>
>> >>> Just for grins, can
you remove the eeprom config that enables the
>> >>> internal gpsdo?
What results do you see from kal when the internal tcxo on
>> >>> the
motherboard is used?
>> >>>
>> >>> BTW, are you getting reasonable gga
strings that correlate to your known
>> >>> position?
>> >>>
>> >>>
>>
>>> John
>> >>>
>> >>> On Tuesday, June 19, 2012, Dario Lombardo
<dario.lombardo.ml at gmail.com [133]>
>> >>> wrote:
>> >>> > Hi Josh
>>
>>> >
>> >>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
>> >>>
john.malsbury at ettus.com [134]> wrote:
>> >>> >>
>> >>> >> Dario,
>> >>>
>>
>> >>> >> Forgive me if I am not able to see your previous posts as I
am
>> >>> answering from my phone. Are you saying there is
>> >>> >> 11
khz of error in the 10 mhz ref, or some frequency set to a
>> >>>
daughterboard LO?
>> >>> >
>> >>> > I'm saying that error is the output
of kalibrate.
>> >>> >
>> >>> >>
>> >>> >> You mention using an external
reference. I don't think you would
>> >>> achieve lock if this were the
issue, but have you ensured the jumper is in
>> >>> the proper
configuration?
>> >>> >
>> >>> > When using the front panel connectors,
I moved the jumper J510 to
>> >>> select them. In this case I got 0 Hz
of error at my first try. To be sure,
>> >>> I disconnected the gpsdo
from the mainboard.
>> >>> >
>> >>> >>
>> >>> >> Are you selecting
default or external as the ref source in your
>> >>> software?
>> >>>
>
>> >>> > When using the gpsdo, I moved the jumper J510, then
configured the
>> >>> eeprom to "internal". In this case I suppose that
the N210 automatically
>> >>> selects the gpsdo. In fact every time I
run something I see
>> >>> > -- Opening a USRP2/N-Series device...
>>
>>> > -- Current recv frame size: 1472 bytes
>> >>> > -- Current send
frame size: 1472 bytes
>> >>> > -- Found a Jackson Labs GPS
>> >>> > --
Setting references to the internal GPSDO
>> >>> > -- Initializing time
to the internal GPSDO
>> >>> > no matter if any "external ref" is used
or not. In kal, I got that
>> >>> error with and without the "-x"
switch.
>> >>> >>
>> >>> >> John
>> >>> >>
>> >>> >> On Tuesday, June
19, 2012, Dario Lombardo <
>> >>> dario.lombardo.ml at gmail.com [135]>
wrote:
>> >>> >> > Hi all
>> >>> >> > After many tries with my gpsdo, I
still can't get a good clock.
>> >>> >> > I've written a sw that
continuously polls the gps_locked and the
>> >>> ref_locked sensors.
Both of them are always locked, that means that my
>> >>> antenna is
getting a quite "clear" sky view.
>> >>> >> > I've connected the front
panel connectors of my N210 to a cesium
>> >>> clock/pps generator, and
I get 2 to 0 Hz of error with kal. That should
>> >>> mean that my usrp
works fine and the kal commands are good.hu [136]
>> >>> >> > I've left
the usrp turned on, with the gps antenna connected, for
>> >>> over 20
hours, but kal still gives me around 11 kHz of error.
>> >>> >> > I
think that one of these 2 things is happening:
>> >>> >> > 1) my gpsdo
card is broken. What can I do to ensure that this is
>> >>> not the
case? And if this is the case, what can I do?
>> >>> >> > 2) my antenna
can't give a signal that is clear enough, so the
>> >>> gpsdo isn't
unable to give me the clock.
>> >>> >> > What do you think about the
above cases?
>> >>> >> > Any help appreciated.
>> >>> >> > Dario.
>>
>>>
>> >>> Just for grins, can you remove the eeprom config that enables
the
>> >>> internal gpsdo? What results do you see from kal when the
internal tcxo on
>> >>> the motherboard is used?
>> >>>
>> >>> Are you
getting reasonable gga strings that correlate to your known
>> >>>
position?
>> >>>
>> >>>
>> >>> John
>> >>>
>> >>> On Tuesday, June 19,
2012, Dario Lombardo <dario.lombardo.ml at gmail.com [137]>
>> >>>
wrote:
>> >>> > Hi Josh
>> >>> >
>> >>> > On Tue, Jun 19, 2012 at 1:14
PM, John Malsbury <
>> >>> john.malsbury at ettus.com [138]> wrote:
>> >>>
>>
>> >>> >> Dario,
>> >>> >>
>> >>> >> Forgive me if I am not able to
see your previous posts as I am
>> >>> answering from my phone. Are you
saying there is
>> >>> >> 11 khz of error in the 10 mhz ref, or some
frequency set to a
>> >>> daughterboard LO?
>> >>> >
>> >>> > I'm saying
that error is the output of kalibrate.
>> >>> >
>> >>> >>
>> >>> >> You
mention using an external reference. I don't think you would
>> >>>
achieve lock if this were the issue, but have you ensured the jumper is
in
>> >>> the proper configuration?
>> >>> >
>> >>> > When using the
front panel connectors, I moved the jumper J510 to
>> >>> select them.
In this case I got 0 Hz of error at my first try. To be sure,
>> >>> I
disconnected the gpsdo from the mainboard.
>> >>> >
>> >>> >>
>> >>> >>
Are you selecting default or external as the ref source in your
>> >>>
software?
>> >>> >
>> >>> > When using the gpsdo, I moved the jumper
J510, then configured the
>> >>> eeprom to "internal". In this case I
suppose that the N210 automatically
>> >>> selects the gpsdo. In fact
every time I run something I see
>> >>> > -- Opening a USRP2/N-Series
device...
>> >>> > -- Current recv frame size: 1472 bytes
>> >>> > --
Current send frame size: 1472 bytes
>> >>> > -- Found a Jackson Labs
GPS
>> >>> > -- Setting references to the internal GPSDO
>> >>> > --
Initializing time to the internal GPSDO
>> >>> > no matter if any
"external ref" is used or not. In kal, I got that
>> >>> error with and
without the "-x" switch.
>> >>> >>
>> >>> >> John
>> >>> >>
>> >>> >> On
Tuesday, June 19, 2012, Dario Lombardo <
>> >>>
dario.lombardo.ml at gmail.com [139]> wrote:
>> >>> >> > Hi all
>> >>> >> >
After many tries with my gpsdo, I still can't get a good clock.
>> >>>
>> > I've written a sw that continuously polls the gps_locked and the
>>
>>> ref_locked sensors. Both of them are always locked, that means that
my
>> >>> antenna is getting a quite "clear" sky view.
>> >>> >> > I've
connected the front panel connectors of my N210 to a cesium
>> >>>
clock/pps generator, and I get 2 to 0 Hz of error with kal. That
should
>> >>> mean that my usrp works fine and the kal commands are
good.hu [140]
>> >>> >> > I've left the usrp turned on, with the gps
antenna connected, for
>> >>> over 20 hours, but kal still gives me
around 11 kHz of error.
>> >>> >> > I think that one of these 2 things
is happening:
>> >>> >> > 1) my gpsdo card is broken. What can I do to
ensure that this is
>> >>> not the case? And if this is the case, what
can I do?
>> >>> >> > 2) my antenna can't give a signal that is clear
enough, so the
>> >>> gpsdo isn't unable to give me the clock.
>> >>> >>
> What do you think about the above cases?
>> >>> >> > Any help
appreciated.
>> >>> >> > Dario.
>> >>> >
>> >>>
>> >>>
_______________________________________________
>> >>> USRP-users
mailing list
>> >>> USRP-users at lists.ettus.com [141]
>> >>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[142]
>> >>>
>> >>>
>> >>
>> >
>> -------------- next part
--------------
>> An HTML attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/d6d103be/attachment-0001.html
[143]>
>> 
>> ------------------------------
>> 
>> Message: 16
>>
Date: Tue, 26 Jun 2012 22:52:04 +0800
>> From: JAY PRAKASH
<jay.prakash.ece09 at itbhu.ac.in [144]>
>> To: usrp-users at lists.ettus.com
[145]
>> Subject: [USRP-users] Sampling rate for usrp2
>> Message-ID:
>>
<CADVr-4w2LUR6xDF5vrMhiKkExMz2hHZrocWHnNP_3Ebn7WJNVg at mail.gmail.com
[146]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> I am
working on channel sounding using USRP2, Considering the probable
>>
delays in indoor envronment I need sampling rate or say chip rate of
PN
>> sequence being transmitted to be around 25-32Mb/s.
>> 
>> But when
I go over 4 the screen of transmitter get full with"
>>
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU"
>> 
>> and when I see the
correlated data at receiver side its almost noise like
>> with very less
correlation.
>> 
>> Please help me out in increasing the sampling
rate.
>> 
>> I read somewhere to make changes in UHD driver based on
decimation
>> rates.But no proper description.
>> Jay Prakash
>> B.Tech
Part III
>> Electronics Engineering
>> IIT BHU
>> VARANASI
>>
-------------- next part --------------
>> An HTML attachment was
scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/50742ee8/attachment-0001.html
[147]>
>> 
>> ------------------------------
>> 
>> Message: 17
>>
Date: Tue, 26 Jun 2012 10:58:04 -0400
>> From: mleech at ripnet.com
[148]
>> To: <usrp-users at lists.ettus.com [149]>
>> Subject: Re:
[USRP-users] Sampling rate for usrp2
>> Message-ID:
<a6d416283991afd0ff55ac85d869cfd4 at ripnet.com [150]>
>> Content-Type:
text/plain; charset="utf-8"
>> 
>> On 26 Jun 2012 10:52, JAY PRAKASH
wrote:
>> 
>> > I am working on channel
>> sounding using USRP2,
Considering the probable delays in indoor
>> envronment I need sampling
rate or say chip rate of PN sequence being
>> transmitted to be around
25-32Mb/s.
>> >
>> > But when I go over 4 the
>> screen of transmitter
get full with"
>> UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU"
>> >
>> >
and when I see the
>> correlated data at receiver side its almost noise
like with very less
>> correlation.
>> >
>> > Please help me out in
increasing the sampling rate.
>> 
>> >
>> > I read somewhere to make
changes in UHD driver based on decimation
>> rates.But no proper
description.
>> >
>> > Jay Prakash
>> > B.Tech Part III
>> >
>>
Electronics Engineering
>> > IIT BHU
>> > VARANASI
>> 
>> USRP2 sample
rates are
>> constrained to be proper fractions of 100Msps. The "U"
means underrun,
>> which means your computer isn't keeping up with the
USRP2 data demand at
>> the chosen sample rate.
>> 
>> --------------
next part --------------
>> An HTML attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/35bed375/attachment-0001.html
[151]>
>> 
>> ------------------------------
>> 
>> Message: 18
>>
Date: Tue, 26 Jun 2012 10:07:06 -0500
>> From: Jahshan Bhatti
<jabhatti91 at gmail.com [152]>
>> To: josh at ettus.com [153]
>> Cc:
usrp-users at lists.ettus.com [154]
>> Subject: Re: [USRP-users] Sequence
Errors on USRP N200
>> Message-ID:
>>
<CAJOme120hZTWS6LKgd6N8fPxjMYYkUQnUdMAaEqNx2F3zF59-g at mail.gmail.com
[155]>
>> Content-Type: text/plain; charset=UTF-8
>> 
>> On Sun, Jun 24,
2012 at 8:26 PM, Jahshan Bhatti <jabhatti91 at gmail.com [156]> wrote:
>>
>
>> > Ok, instead of using the timing receivers, I simply
cross-correlated
>> > the signals with a MIMO set of USRP N200s. From
the cross-correlation,
>> > I can see that the delay is stable on
multiple runs but not exact.
>> > Here are my results:
>> >
>> > command
50 ms delay @ 5 MS/s results in error of -5.75 us
>> > command 50 ms
delay @ 4 MS/s results in error of -4.75 us
>> > command 100 ms delay @
5 MS/s results in error of -5.75 us
>> > command 100 ms delay @ 4 MS/s
results in error of -4.75 us
>> > command 200 ms delay @ 5 MS/s results
in error of 121.75 us
>> > command 200 ms delay @ 4 MS/s results in
error of 154.5 us
>> >
>> 
>> Does anyone know what the delays in
digitization and generation are in
>> the USRP N200? I bet the constant
microsecond delays at 50 and 100 ms
>> are due to samples getting
shifted in and out of buffers in the FPGA,
>> ADC, and DAC hardware. It
would be nice to have an explanation for
>> these delays so that way I
can safely calibrate them out.
>> 
>> ~Jahshan
>> 
>>
------------------------------
>> 
>> Message: 19
>> Date: Tue, 26 Jun
2012 23:46:40 +0800
>> From: JAY PRAKASH <jay.prakash.ece09 at itbhu.ac.in
[157]>
>> To: usrp-users at lists.ettus.com [158]
>> Subject: [USRP-users]
USRP2 synchronization
>> Message-ID:
>>
<CADVr-4z1_y=hzD7XZKdvec=CKKzD37GFJYW_QjzJK+VphE5iMg at mail.gmail.com
[159]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> I am
using digital_bert_tx.py for transmission of BPSK modulated
>> Bits
Sequences using GNURADIO.
>> 
>> But while at reception there are
synchronization issues.
>> How to synchronize the two USRP2's?
>> I read
about :-
>> 1)External function generator.
>> What preparation needs to
be done for it??
>> 
>> High frequency function generator of 10MGHZ
won't harm the device na?
>> 
>> Jay Prakash
>> B.Tech Part III
>>
Electronics Engineering
>> IIT BHU
>> VARANASI
>> -------------- next
part --------------
>> An HTML attachment was scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/525acd86/attachment-0001.html
[160]>
>> 
>> ------------------------------
>> 
>> Message: 20
>>
Date: Tue, 26 Jun 2012 17:58:46 +0200
>> From: Dario Lombardo
<dario.lombardo.ml at gmail.com [161]>
>> To: Nick Foster <nick at ettus.com
[162]>
>> Cc: "usrp-users at lists.ettus.com [163]"
<usrp-users at lists.ettus.com [164]>
>> Subject: Re: [USRP-users] Broken
gpsdo or bad antenna?
>> Message-ID:
>>
<CAOYJJfv5EDqqcc4Xo8EbzLWKr-q3qf5KYEsTTtwnkJSOPLZZvw at mail.gmail.com
[165]>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> On Tue,
Jun 26, 2012 at 4:52 PM, Nick Foster <nick at ettus.com [166]> wrote:
>>

>> > Hi Dario,
>> >
>> > I'm out of ideas regarding your reference. To
me, it seems like
>> > *something* is locking, but not to the proper
device.
>> >
>> > The last possibility I can see before a hardware
failure is the
>> > possibility that your local cell tower actually is
off 20kHz. Unlikely, but
>> > if it's your only point of reference I
suppose it's possible.
>> >
>> 
>> No, it's not. I've run kal in scan
mode and the result is more or less the
>> same.
>> 
>> $ ./kal -s 900
-x
>> linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4);
Boost_104400;
>> UHD_003.004.002-152-gdb8f128e
>> 
>> -- Opening a
USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> --
Current send frame size: 1472 bytes
>> -- Detecting internal GPSDO....
Found a Jackson Labs GPS
>> -- found
>> -- Setting references to the
internal GPSDO
>> -- Initializing time to the internal GPSDO
>> 
>> UHD
Warning:
>> The hardware does not support the requested RX sample
rate:
>> Target sample rate: 0.270833 MSps
>> Actual sample rate:
0.271739 MSps
>> kal: Scanning for GSM-900 base stations.
>> chan: 8
(936.6MHz - 12.533kHz) power: 8062.48
>> 
>> chan: 11 (937.2MHz -
12.430kHz) power: 13724.73
>> 
>> chan: 37 (942.4MHz - 12.116kHz) power:
13138.43
>> 
>> chan: 85 (952.0MHz - 10.961kHz) power: 22605.52
>> 
>>
chan: 92 (953.4MHz - 10.885kHz) power: 44800.99
>> 
>> chan: 112
(957.4MHz - 10.786kHz) power: 31025.00
>> 
>> Today I've conducted a
test with a counter. GPSDO is completely isolated
>> from the mainboard
except for the power supply, sma pps is floating and
>> clock is
connected to counter. Counter gives me around 10.000.200 Hz. That
>>
confuses me totally...
>> Why kal gives me 10 kHz of error??
>> Why
gpsdo has a so bad clock? It is not enough for GSM :(...
>> 
>> I want
to go on a roof to have a clear signal.
>> Updates will follow.
>>
-------------- next part --------------
>> An HTML attachment was
scrubbed...
>> URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/192597d8/attachment-0001.html
[167]>
>> 
>> ------------------------------
>> 
>>
_______________________________________________
>> USRP-users mailing
list
>> USRP-users at lists.ettus.com [168]
>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[169]
>> 
>> End of USRP-users Digest, Vol 22, Issue 26
>>
******************************************

 

Links:
------
[1]
mailto:usrp-users at lists.ettus.com
[2]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[3]
mailto:usrp-users-request at lists.ettus.com
[4]
mailto:usrp-users-owner at lists.ettus.com
[5] mailto:mleech at ripnet.com
[6]
mailto:mleech at ripnet.com
[7] mailto:mleech at ripnet.com
[8]
mailto:simon at hb9drv.ch
[9] mailto:josh at ettus.com
[10]
mailto:usrp-users at lists.ettus.com
[11] http://hb9drv.ch
[12]
http://dit-dit-dit.com
[13]
mailto:usrp-users-bounces at lists.ettus.com
[14]
mailto:usrp-users-bounces at lists.ettus.com
[15]
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buf
[16]
mailto:simon at hb9drv.ch
[17] mailto:usrp-users at lists.ettus.com
[18]
http://hb9drv.ch
[19] http://dit-dit-dit.com
[20]
mailto:usrp-users-bounces at lists.ettus.com
[21]
mailto:usrp-users-bounces at lists.ettus.com
[22]
mailto:josh at ettus.com
[23] mailto:usrp-users at lists.ettus.com
[24]
http://dit-dit-dit.com
[25]
mailto:usrp-users-bounces at lists.ettus.com
[26]
mailto:usrp-users-bounces at lists.ettus.com
[27]
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buf
[28]
mailto:USRP-users at lists.ettus.com
[29]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[30]
mailto:mleech at ripnet.com
[31] mailto:usrp-users at lists.ettus.com
[32]
mailto:d9e0726b7b88a7d9ad0771a5a9dbdd73 at ripnet.com
[33]
http://dit-dit-dit.com
[34]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/75395faf/attachment-0001.html
[35]
mailto:ideazwx at gmail.com
[36] mailto:usrp-users at lists.ettus.com
[37]
mailto:CAHeRwcQbF07RkrFeEM%2B8Mhu2m7v-4wrFqhhOwCaNHkStBuVbhQ at mail.gmail.com
[38]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/408675fb/attachment-0001.html
[39]
mailto:mleech at ripnet.com
[40] mailto:usrp-users at lists.ettus.com
[41]
mailto:843d16888b1a8dd04f88d79788e3d91b at ripnet.com
[42]
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[43]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/d47e38c3/attachment-0001.html
[44]
mailto:cingular.alex at gmail.com
[45] mailto:mleech at ripnet.com
[46]
mailto:usrp-users at lists.ettus.com
[47] mailto:j259Q at mail.gmail.com
[48]
mailto:mleech at ripnet.com
[49]
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[50]
mailto:USRP-users at lists.ettus.com
[51]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[52]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/60a4952b/attachment-0001.html
[53]
mailto:nick at ettus.com
[54] mailto:cingular.alex at gmail.com
[55]
mailto:usrp-users at lists.ettus.com
[56]
mailto:CALALHJV-QgNhgnC6m9fQK9sWY7q-GMN3p5xmtuBEeqUt1jdjtA at mail.gmail.com
[57]
mailto:cingular.alex at gmail.com
[58] mailto:mleech at ripnet.com
[59]
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[60]
mailto:USRP-users at lists.ettus.com
[61]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[62]
mailto:USRP-users at lists.ettus.com
[63]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[64]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/627d526a/attachment-0001.html
[65]
mailto:cingular.alex at gmail.com
[66] mailto:nick at ettus.com
[67]
mailto:usrp-users at lists.ettus.com
[68]
mailto:CA%2BFEAncqAa6ZQmWckCSfv_YAJgQ9WfVMpEvb0nKF8T1-9um3Pg at mail.gmail.com
[69]
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3964
[70]
mailto:nick at ettus.com
[71] mailto:cingular.alex at gmail.com
[72]
mailto:mleech at ripnet.com
[73]
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450
[74]
mailto:USRP-users at lists.ettus.com
[75]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[76]
mailto:USRP-users at lists.ettus.com
[77]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[78]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/d3435681/attachment-0001.html
[79]
mailto:sanatgulvadi at gmail.com
[80]
mailto:usrp-users at lists.ettus.com
[81]
mailto:CAH12yLtPLHHzFTzT847%2BCSy0ZFOXW%2BQJLUkkp0Sij02r8qjrzw at mail.gmail.com
[82]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/ba952b76/attachment-0001.html
[83]
mailto:josh at ettus.com
[84] mailto:usrp-users at lists.ettus.com
[85]
mailto:4FE9570D.3050508 at ettus.com
[86]
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
[87]
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
[88]
mailto:sanatgulvadi at gmail.com
[89] mailto:josh at ettus.com
[90]
mailto:usrp-users at lists.ettus.com
[91]
mailto:inPUJFp_Q at mail.gmail.com
[92] mailto:josh at ettus.com
[93]
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
[94]
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
[95]
mailto:USRP-users at lists.ettus.com
[96]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[97]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/ecbdd283/attachment-0001.html
[98]
mailto:dario.lombardo.ml at gmail.com
[99] mailto:nick at ettus.com
[100]
mailto:john.malsbury at ettus.com
[101]
mailto:usrp-users at lists.ettus.com
[102]
mailto:usrp-users at lists.ettus.com
[103]
mailto:V_VuxEcnKTEAvAKrJ12TH7ozznQjQ at mail.gmail.com
[104]
mailto:nick at ettus.com
[105] mailto:john.malsbury at ettus.com
[106]
mailto:dario.lombardo.ml at gmail.com
[107]
mailto:john.malsbury at ettus.com
[108]
mailto:dario.lombardo.ml at gmail.com
[109] http://good.hu
[110]
mailto:dario.lombardo.ml at gmail.com
[111]
mailto:john.malsbury at ettus.com
[112]
mailto:dario.lombardo.ml at gmail.com
[113] http://good.hu
[114]
mailto:USRP-users at lists.ettus.com
[115]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[116]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/08012805/attachment-0001.html
[117]
mailto:birhanea at gmail.com
[118] mailto:usrp-users at lists.ettus.com
[119]
mailto:CAPF4MOw5HLbQsbPgEk0ar3Xfa%2BZMKeN1bu3KtUFKA7HZfSprqQ at mail.gmail.com
[120]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/7283ccc0/attachment-0001.html
[121]
mailto:damien.serant at gmail.com
[122]
mailto:USRP-users at lists.ettus.com
[123]
mailto:tNLnCMr20qknJTewNfbwQP0e4Eb91Ts5os7nfPM35q4N31g at mail.gmail.com
[124]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/f30abfb4/attachment-0001.html
[125]
mailto:nick at ettus.com
[126] mailto:dario.lombardo.ml at gmail.com
[127]
mailto:usrp-users at lists.ettus.com
[128]
mailto:usrp-users at lists.ettus.com
[129]
mailto:K%2B06EgMHrytFhdfemuauuOtoUdkOQ_FSvayQw8Rw at mail.gmail.com
[130]
mailto:dario.lombardo.ml at gmail.com
[131] mailto:nick at ettus.com
[132]
mailto:john.malsbury at ettus.com
[133]
mailto:dario.lombardo.ml at gmail.com
[134]
mailto:john.malsbury at ettus.com
[135]
mailto:dario.lombardo.ml at gmail.com
[136] http://good.hu
[137]
mailto:dario.lombardo.ml at gmail.com
[138]
mailto:john.malsbury at ettus.com
[139]
mailto:dario.lombardo.ml at gmail.com
[140] http://good.hu
[141]
mailto:USRP-users at lists.ettus.com
[142]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[143]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/d6d103be/attachment-0001.html
[144]
mailto:jay.prakash.ece09 at itbhu.ac.in
[145]
mailto:usrp-users at lists.ettus.com
[146]
mailto:CADVr-4w2LUR6xDF5vrMhiKkExMz2hHZrocWHnNP_3Ebn7WJNVg at mail.gmail.com
[147]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/50742ee8/attachment-0001.html
[148]
mailto:mleech at ripnet.com
[149] mailto:usrp-users at lists.ettus.com
[150]
mailto:a6d416283991afd0ff55ac85d869cfd4 at ripnet.com
[151]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/35bed375/attachment-0001.html
[152]
mailto:jabhatti91 at gmail.com
[153] mailto:josh at ettus.com
[154]
mailto:usrp-users at lists.ettus.com
[155]
mailto:CAJOme120hZTWS6LKgd6N8fPxjMYYkUQnUdMAaEqNx2F3zF59-g at mail.gmail.com
[156]
mailto:jabhatti91 at gmail.com
[157]
mailto:jay.prakash.ece09 at itbhu.ac.in
[158]
mailto:usrp-users at lists.ettus.com
[159]
mailto:CKKzD37GFJYW_QjzJK%2BVphE5iMg at mail.gmail.com
[160]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/525acd86/attachment-0001.html
[161]
mailto:dario.lombardo.ml at gmail.com
[162] mailto:nick at ettus.com
[163]
mailto:usrp-users at lists.ettus.com
[164]
mailto:usrp-users at lists.ettus.com
[165]
mailto:CAOYJJfv5EDqqcc4Xo8EbzLWKr-q3qf5KYEsTTtwnkJSOPLZZvw at mail.gmail.com
[166]
mailto:nick at ettus.com
[167]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/192597d8/attachment-0001.html
[168]
mailto:USRP-users at lists.ettus.com
[169]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[170]
mailto:usrp-users-request at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/7266766e/attachment-0002.html>


More information about the USRP-users mailing list