Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 ([email protected])
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? ([email protected])
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 ([email protected])
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" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
Message-ID: <[email protected]>
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: [email protected]
[mailto:[email protected]] 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" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
Message-ID: <[email protected]>
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: [email protected]
[mailto:[email protected]] On Behalf Of Simon HB9DRV
Sent: 25 June 2012 18:48
To: [email protected]; [email protected]
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: [email protected]
[mailto:[email protected]] 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
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Mon, 25 Jun 2012 13:07:28 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
Message-ID: <[email protected]>
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 <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Does each antenna of USRP N210 can both transmit
and receive?
Message-ID:
<caherwcqbf07rkrfeem+8mhu2m7v-4wrfqhhowcanhkstbuv...@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: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Does each antenna of USRP N210 can both
transmit and receive?
Message-ID: <[email protected]>
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 <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Does each antenna of USRP N210 can both
transmit and receive?
Message-ID:
<CA+FEAnfemYtaEgagbb57MSBh+X_J=uiOnFg1uWW8zs8F=j2...@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, <[email protected]> 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
> [email protected]
> 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 <[email protected]>
To: Alex Zhang <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Does each antenna of USRP N210 can both
transmit and receive?
Message-ID:
<calalhjv-qgnhgnc6m9fqk9swy7q-gmn3p5xmtubeequt1jd...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
On Mon, Jun 25, 2012 at 12:58 PM, Alex Zhang <[email protected]>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, <[email protected]> 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
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
>
> Alex,
> *Dreams can come true ? just believe.*
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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 <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Does each antenna of USRP N210 can both
transmit and receive?
Message-ID:
<ca+feancqaa6zqmwckcsfv_yajgq9wfvmpevb0nkf8t1-9um...@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 <[email protected]> wrote:
> On Mon, Jun 25, 2012 at 12:58 PM, Alex Zhang <[email protected]>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, <[email protected]> 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
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true ? just believe.*
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> 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 <[email protected]>
To: [email protected]
Subject: [USRP-users] using tune_request_t
Message-ID:
<cah12yltplhhzftzt847+csy0zfoxw+qjlukkp0sij02r8qj...@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 <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] using tune_request_t
Message-ID: <[email protected]>
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 <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] using tune_request_t
Message-ID:
<CAH12yLu7NpL+es2CMzASG=zaKAFdOw-hTeq2xmVA=inpujf...@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" <[email protected]> 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
> [email protected]
> 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 <[email protected]>
To: Nick Foster <[email protected]>, John Malsbury
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<CAOYJJfsfictpW4_ZiTeg=v_vuxecnkteavakrj12th7ozzn...@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 <[email protected]> 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 <[email protected]>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 <[email protected]>
>> wrote:
>> > Hi Josh
>> >
>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>
>> 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 <[email protected]>
>> 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 <[email protected]>
>> wrote:
>> > Hi Josh
>> >
>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>
>> 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 <[email protected]>
>> 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
>> [email protected]
>> 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 <[email protected]>
To: [email protected]
Subject: [USRP-users] Regarding the 112 decimation and 174 decimation
factors
Message-ID:
<capf4mow5hlbqsbpgek0ar3xfa+zmken1bu3ktufka7hzfsp...@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 <[email protected]>
To: [email protected]
Subject: [USRP-users] MIMO Cable
Message-ID:
<CAM=tnlncmr20qknjtewnfbwqp0e4eb91ts5os7nfpm35q4n...@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 <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<CALALHJUYW=k+06egmhrytfhdfemuauuotoudkoq_fsvayqw...@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 <
[email protected]> 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 <[email protected]> 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
>> <[email protected]>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 <[email protected]>
>>> wrote:
>>> > Hi Josh
>>> >
>>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
>>> [email protected]> 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 <
>>> [email protected]> 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 <[email protected]>
>>> wrote:
>>> > Hi Josh
>>> >
>>> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <
>>> [email protected]> 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 <
>>> [email protected]> 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
>>> [email protected]
>>> 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 <[email protected]>
To: [email protected]
Subject: [USRP-users] Sampling rate for usrp2
Message-ID:
<cadvr-4w2lur6xdf5vrmhikkexmz2hhzrocwhnnp_3ebn7wj...@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: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Sampling rate for usrp2
Message-ID: <[email protected]>
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 <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<cajome120hztws6lkgd6n8fpxjmyykuqnudmaaeqnx2f3zf5...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 24, 2012 at 8:26 PM, Jahshan Bhatti <[email protected]> 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 <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP2 synchronization
Message-ID:
<CADVr-4z1_y=hzD7XZKdvec=ckkzd37gfjyw_qjzjk+vphe5...@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 <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<caoyjjfv5edqqcc4xo8ebzlwkr-q3qf5kyestttwnkjsoplz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Jun 26, 2012 at 4:52 PM, Nick Foster <[email protected]> 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
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 26
******************************************
