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: GPSDO on N210 problem (Marcus D. Leech)
2. USRP1 re-clocking with function generator (Kostas Tsalikis)
3. Re: USRP1 re-clocking with function generator (Marcus D. Leech)
4. Questions about the FPGA boot sequences in USRP N210? (Pan)
5. Short-term accuracy and stability of the GPSDO (Sivan Toledo)
6. Re: Short-term accuracy and stability of the GPSDO (Matt Ettus)
7. Re: USRP1 re-clocking with function generator
(Ralph A. Schmid, dk5ras)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Apr 2013 12:15:43 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO on N210 problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/22/2013 03:25 AM, Sam mite wrote:
>
>
> On 04/15/2013 12:28 AM, Sam mite wrote:
> > Hi,
> >
> > I am trying to setup GPS on my N210. The problem is that
> Detecting internal
> > GPSDO returns *"not found"* as shown below. Whereas it also says
> that *gpsdo:
> > internal. *What is wrong ? I am on ubnutu Gnuradio 3.6.3rc0. My UHD
> > version is UHD_003.005.000-26-gb65a3924
> >
>
> The gpsdo internal is just an entry in the device's eeprom to tell it
> that it should look for the GPSDO. So, I think you are looking at a
> communication issue. Double check that the power and serial cables
> appear to be plugged in correctly.
>
> -josh
>
>
> After checking the cable, and following the post installation
> instruction for N series, now the GPS has been detected. But now when
> I run following command
>
> /uhd_usrp_source= uhd.usrp_source(device_addr="addr=192.168.10.2",
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> ),
> )
> /
>
> /print uhd_usrp_source.get_mboard_sensor("gps_time").to_int()/
>
>
> I am getting the following error
>
> return _uhd_swig.uhd_usrp_source_sptr_get_mboard_sensor(self, *args,
> **kwargs)
> RuntimeError: LookupError: Path not found in tree:
> /mboards/0/sensors/gps_time
>
> Also sometime I get following:
>
> UHD Warning:
> get_time: ValueError: get_nmea(): no GPRMC message found
>
>
> what could be wrong ? Thanks for help
>
> --
>
> Best Regards,
>
> Sam
Just to eliminate "silly stuff", do you know that your GPS antenna is
working? Is it an active antenna?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130422/8b5fe9e4/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 22 Apr 2013 20:34:50 +0300
From: Kostas Tsalikis <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP1 re-clocking with function generator
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hi everyone,
I have to re-clock USRP1 for OpenBTS at 52MHz (as it is suggested in the
associated wiki) , and I'm going to use for this purpose a function
generator from my University's labs. Has anyone done this before or does
anyone have to give any tips, suggestions or notices, in general or
concerning any stability issues?
Thanks,
Tsalikis Kostas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130422/217553e3/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 22 Apr 2013 14:06:26 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP1 re-clocking with function generator
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> Hi everyone,
>
> I have to re-clock USRP1 for OpenBTS at 52MHz (as it is suggested in
> the associated wiki) , and I'm going to use for this purpose a
> function generator from my University's labs. Has anyone done this
> before or does anyone have to give any tips, suggestions or notices,
> in general or concerning any stability issues?
>
> Thanks,
> Tsalikis Kostas
What are the precision and stability specs of the function generator?
Some of them are really poor, some of them are excellent.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130422/34b1db27/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 22 Apr 2013 14:55:38 -0400
From: Pan <[email protected]>
To: [email protected]
Subject: [USRP-users] Questions about the FPGA boot sequences in USRP
N210?
Message-ID:
<CAM7k3FRO9tvcdF37qeH6wP4S+K=s3ao7er5p9rtrkp+kqi2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am trying to modifiy the FPGA code of the USRP N210. My question is where
I should store the FPGA configuration file? I just checked the N210
schematic, and saw that the board just has one 32Mbit flash(M25P32) and one
2K EEPROM(24Lc024). I assume that the FPGA configuration file is stored in
the flash. When the USRP N210 Device is powered on, the FPGA congiuration
file is loaded to FPGA. It this correct?
Howevrer, what I am confused is that I just check the FPGA boot pin
configuration status which is M2M1M0="000", that means when the FPGA is
power on, it should load frome some platform flash. But, actually, there is
no platform flash in the USRP N210 device at all. Is there anyone be kind
enough to explain what the FPGA boot sequence in USRP N210 is? Thank you so
much.
Best,
Edmund
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130422/21be8bfd/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 23 Apr 2013 07:31:03 +0300
From: Sivan Toledo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Short-term accuracy and stability of the GPSDO
Message-ID:
<CAOL_ruF-fX1A_u43DC46ux5tef7N=We6Y4FOVF=j2zew6hc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I tried to measure the short term accuracy and stability of the GPSDO. My
application requires high stability and the GPSDO seems to not perform very
well in that respect. I would like to check if others had similar
experiences.
What I did was to send a carrier from one USRP using tx_waveform at
434.6Mhz (using a WBX) and to receive 10s chunks in a second USRP, both of
which had a locked GPSDO. The FFTs of these samples were analyzed. I did
this for 10 minutes.
I discovered 3 interesting things. First, the signal has a bandwidth of
about 20Hz, which I think means that the entire TX and RX chains had
significant phase noise, at least when multiplied up to 434MHz.
Second, the signal was about 45Hz off from where it should have been, which
I think mean that the two GPSDOs where off by around 1hz (given that the
10MHz reference is multiplied by about 43).
Third, the signal wandered over about 40Hz within short time spans of about
a minute or less, again indicating frequency instability of about 0.5Hz per
GPSDO.
This is less than a 1e-7 error, which is huge over the long term average,
but perhaps not so large for the short term (say a few seconds or a minute).
Are these consistent with what others have seen (or what Ettus has measured
with these GPSDO units)?
Thanks, Sivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130423/59421cee/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 22 Apr 2013 22:50:44 -0700
From: Matt Ettus <[email protected]>
To: Sivan Toledo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Short-term accuracy and stability of the
GPSDO
Message-ID:
<CAN=1kn9-gp8ewb+usgq3qc_cctexlj-_7qfeg_nqmrw1y+r...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sivan,
The first thing to make sure is that both GPSDOs are locked, and that the
USRPs are locked to the GPSDOs. Also, the GPSDOs will take some time to
fully lock when first powered up. In general, these should be left on long
term for best results. You will also need to have self-surveyed the
position.
Matt
On Mon, Apr 22, 2013 at 9:31 PM, Sivan Toledo <[email protected]> wrote:
> I tried to measure the short term accuracy and stability of the GPSDO. My
> application requires high stability and the GPSDO seems to not perform very
> well in that respect. I would like to check if others had similar
> experiences.
>
> What I did was to send a carrier from one USRP using tx_waveform at
> 434.6Mhz (using a WBX) and to receive 10s chunks in a second USRP, both of
> which had a locked GPSDO. The FFTs of these samples were analyzed. I did
> this for 10 minutes.
>
> I discovered 3 interesting things. First, the signal has a bandwidth of
> about 20Hz, which I think means that the entire TX and RX chains had
> significant phase noise, at least when multiplied up to 434MHz.
>
> Second, the signal was about 45Hz off from where it should have been,
> which I think mean that the two GPSDOs where off by around 1hz (given that
> the 10MHz reference is multiplied by about 43).
>
> Third, the signal wandered over about 40Hz within short time spans of
> about a minute or less, again indicating frequency instability of about
> 0.5Hz per GPSDO.
>
> This is less than a 1e-7 error, which is huge over the long term average,
> but perhaps not so large for the short term (say a few seconds or a minute).
>
> Are these consistent with what others have seen (or what Ettus has
> measured with these GPSDO units)?
>
> Thanks, Sivan
>
> _______________________________________________
> 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/20130422/7c257016/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 23 Apr 2013 11:40:07 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] USRP1 re-clocking with function generator
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You should meet the frequency within a few ppm, otherwise phones may not
find your cell.
Ralph.
From: USRP-users [mailto:[email protected]] On Behalf Of
Kostas Tsalikis
Sent: Monday, April 22, 2013 7:35 PM
To: [email protected]
Subject: [USRP-users] USRP1 re-clocking with function generator
Hi everyone,
I have to re-clock USRP1 for OpenBTS at 52MHz (as it is suggested in the
associated wiki) , and I'm going to use for this purpose a function
generator from my University's labs. Has anyone done this before or does
anyone have to give any tips, suggestions or notices, in general or
concerning any stability issues?
Thanks,
Tsalikis Kostas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130423/39c5e441/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 32, Issue 18
******************************************
