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

JAY PRAKASH jay.prakash.ece09 at itbhu.ac.in
Tue Jun 26 13:04:46 EDT 2012


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>wrote:

> Send USRP-users mailing list submissions to
>        usrp-users at lists.ettus.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> or, via email, send a message with subject or body 'help' to
>        usrp-users-request at lists.ettus.com
>
> You can reach the person managing the list at
>        usrp-users-owner at lists.ettus.com
>
> 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)
>   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. 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)
>  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>
> To: <josh at ettus.com>,   <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
> Message-ID: <028901cd52f2$37d56e70$a7804b50$@hb9drv.ch>
> 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
>
> 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
> [mailto:usrp-users-bounces at lists.ettus.com] 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
> fers
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 25 Jun 2012 19:01:27 +0200
> From: "Simon HB9DRV" <simon at hb9drv.ch>
> To: <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
> Message-ID: <029101cd52f4$29196380$7b4c2a80$@hb9drv.ch>
> 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
>
> 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
> [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of Simon HB9DRV
> Sent: 25 June 2012 18:48
> To: josh at ettus.com; usrp-users at lists.ettus.com
> 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
>
> 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
> [mailto:usrp-users-bounces at lists.ettus.com] 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
> fers
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 25 Jun 2012 13:07:28 -0400
> From: mleech at ripnet.com
> To: <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
> Message-ID: <d9e0726b7b88a7d9ad0771a5a9dbdd73 at ripnet.com>
> 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
>
> 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
> >
>
> ------------------------------
>
> Message: 4
> Date: Mon, 25 Jun 2012 14:33:00 -0400
> From: Weixian Zhou <ideazwx at gmail.com>
> To: usrp-users <usrp-users at lists.ettus.com>
> Subject: [USRP-users] Does each antenna of USRP N210 can both transmit
>        and     receive?
> Message-ID:
>        <CAHeRwcQbF07RkrFeEM+8Mhu2m7v-4wrFqhhOwCaNHkStBuVbhQ at mail.gmail.com
> >
> 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
> >
>
> ------------------------------
>
> Message: 5
> Date: Mon, 25 Jun 2012 14:39:19 -0400
> From: mleech at ripnet.com
> To: <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Does each antenna of USRP N210 can both
>        transmit and receive?
> Message-ID: <843d16888b1a8dd04f88d79788e3d91b at ripnet.com>
> 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
>
>
> 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
> >
>
> ------------------------------
>
> Message: 6
> Date: Mon, 25 Jun 2012 14:58:15 -0500
> From: Alex Zhang <cingular.alex at gmail.com>
> To: mleech at ripnet.com
> Cc: usrp-users at lists.ettus.com
> 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
> >
> 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> 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
> >
> > 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
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
>
>
> --
>
> 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
> >
>
> ------------------------------
>
> Message: 7
> Date: Mon, 25 Jun 2012 13:04:47 -0700
> From: Nick Foster <nick at ettus.com>
> To: Alex Zhang <cingular.alex at gmail.com>
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Does each antenna of USRP N210 can both
>        transmit        and receive?
> Message-ID:
>        <CALALHJV-QgNhgnC6m9fQK9sWY7q-GMN3p5xmtuBEeqUt1jdjtA at mail.gmail.com
> >
> Content-Type: text/plain; charset="windows-1252"
>
> On Mon, Jun 25, 2012 at 12:58 PM, Alex Zhang <cingular.alex at gmail.com
> >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> 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
> >>
> >> 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
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >
> >
> > --
> >
> > Alex,
> > *Dreams can come true ? just believe.*
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/627d526a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Mon, 25 Jun 2012 15:33:56 -0500
> From: Alex Zhang <cingular.alex at gmail.com>
> To: Nick Foster <nick at ettus.com>
> Cc: usrp-users at lists.ettus.com
> 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
> >
> 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
>
> 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> wrote:
>
> > On Mon, Jun 25, 2012 at 12:58 PM, Alex Zhang <cingular.alex at gmail.com
> >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> 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
> >>>
> >>> 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
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Alex,
> >> *Dreams can come true ? just believe.*
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> USRP-users at lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >
>
>
> --
>
> 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
> >
>
> ------------------------------
>
> Message: 9
> Date: Tue, 26 Jun 2012 08:17:47 +0200
> From: Sanat Gulvadi <sanatgulvadi at gmail.com>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] using tune_request_t
> Message-ID:
>        <CAH12yLtPLHHzFTzT847+CSy0ZFOXW+QJLUkkp0Sij02r8qjrzw at mail.gmail.com
> >
> 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
> >
>
> ------------------------------
>
> Message: 10
> Date: Mon, 25 Jun 2012 23:30:37 -0700
> From: Josh Blum <josh at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] using tune_request_t
> Message-ID: <4FE9570D.3050508 at ettus.com>
> 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
>
>
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
>
> > 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>
> To: josh at ettus.com
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] using tune_request_t
> Message-ID:
>        <CAH12yLu7NpL+es2CMzASG=zaKAFdOw-hTeq2xmVA=inPUJFp_Q at mail.gmail.com
> >
> 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> 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
> >
> >
> >
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
> >
> > > 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
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/ecbdd283/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Tue, 26 Jun 2012 09:41:21 +0200
> From: Dario Lombardo <dario.lombardo.ml at gmail.com>
> To: Nick Foster <nick at ettus.com>, John Malsbury
>        <john.malsbury at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
> Message-ID:
>        <CAOYJJfsfictpW4_ZiTeg=V_VuxEcnKTEAvAKrJ12TH7ozznQjQ at mail.gmail.com
> >
> 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> 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
> >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>
> >> wrote:
> >> > Hi Josh
> >> >
> >> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
> john.malsbury at ettus.com>
> >> 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>
> >> 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
> >> >> > 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>
> >> wrote:
> >> > Hi Josh
> >> >
> >> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
> john.malsbury at ettus.com>
> >> 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>
> >> 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
> >> >> > 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
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/08012805/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Tue, 26 Jun 2012 14:10:00 +0300
> From: Birhane Alemayoh <birhanea at gmail.com>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] Regarding the 112 decimation and 174 decimation
>        factors
> Message-ID:
>        <CAPF4MOw5HLbQsbPgEk0ar3Xfa+ZMKeN1bu3KtUFKA7HZfSprqQ at mail.gmail.com
> >
> 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
> >
>
> ------------------------------
>
> Message: 14
> Date: Tue, 26 Jun 2012 15:17:42 +0200
> From: Damien Serant <damien.serant at gmail.com>
> To: USRP-users at lists.ettus.com
> Subject: [USRP-users] MIMO Cable
> Message-ID:
>        <CAM=tNLnCMr20qknJTewNfbwQP0e4Eb91Ts5os7nfPM35q4N31g at mail.gmail.com
> >
> 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
> >
>
> ------------------------------
>
> Message: 15
> Date: Tue, 26 Jun 2012 07:52:09 -0700
> From: Nick Foster <nick at ettus.com>
> To: Dario Lombardo <dario.lombardo.ml at gmail.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
> Message-ID:
>        <CALALHJUYW=K+06EgMHrytFhdfemuauuOtoUdkOQ_FSvayQw8Rw at mail.gmail.com
> >
> 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> 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> 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
> >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
> >
> >>> wrote:
> >>> > Hi Josh
> >>> >
> >>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
> >>> john.malsbury at ettus.com> 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> 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
> >>> >> > 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
> >
> >>> wrote:
> >>> > Hi Josh
> >>> >
> >>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
> >>> john.malsbury at ettus.com> 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> 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
> >>> >> > 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
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120626/d6d103be/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 16
> Date: Tue, 26 Jun 2012 22:52:04 +0800
> From: JAY PRAKASH <jay.prakash.ece09 at itbhu.ac.in>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] Sampling rate for usrp2
> Message-ID:
>        <CADVr-4w2LUR6xDF5vrMhiKkExMz2hHZrocWHnNP_3Ebn7WJNVg at mail.gmail.com
> >
> 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
> >
>
> ------------------------------
>
> Message: 17
> Date: Tue, 26 Jun 2012 10:58:04 -0400
> From: mleech at ripnet.com
> To: <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Sampling rate for usrp2
> Message-ID: <a6d416283991afd0ff55ac85d869cfd4 at ripnet.com>
> 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
> >
>
> ------------------------------
>
> Message: 18
> Date: Tue, 26 Jun 2012 10:07:06 -0500
> From: Jahshan Bhatti <jabhatti91 at gmail.com>
> To: josh at ettus.com
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Sequence Errors on USRP N200
> Message-ID:
>        <CAJOme120hZTWS6LKgd6N8fPxjMYYkUQnUdMAaEqNx2F3zF59-g at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Jun 24, 2012 at 8:26 PM, Jahshan Bhatti <jabhatti91 at gmail.com>
> 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>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] USRP2 synchronization
> Message-ID:
>        <CADVr-4z1_y=hzD7XZKdvec=CKKzD37GFJYW_QjzJK+VphE5iMg at mail.gmail.com
> >
> 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
> >
>
> ------------------------------
>
> Message: 20
> Date: Tue, 26 Jun 2012 17:58:46 +0200
> From: Dario Lombardo <dario.lombardo.ml at gmail.com>
> To: Nick Foster <nick at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
> Message-ID:
>        <CAOYJJfv5EDqqcc4Xo8EbzLWKr-q3qf5KYEsTTtwnkJSOPLZZvw at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Jun 26, 2012 at 4:52 PM, Nick Foster <nick at ettus.com> 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
> >
>
> ------------------------------
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> End of USRP-users Digest, Vol 22, Issue 26
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120627/7ae7264e/attachment-0002.html>


More information about the USRP-users mailing list