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. USRP1 control GPIOs on SBX boards (Nelson Pina)
2. Questions about the FPGA boot sequences in USRP N210? (Edmund Pan)
3. Re: Questions about the FPGA boot sequences in USRP N210?
(Nick Foster)
4. Re: GPSDO on N210 problem (Sam mite)
5. Re: Short-term accuracy and stability of the GPSDO (Sivan Toledo)
6. Iris Release 1.0.1 (Paul Sutton)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Apr 2013 19:06:52 +0100
From: Nelson Pina <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] USRP1 control GPIOs on SBX boards
Message-ID:
<CANFE8n4gcGc3gfU0UdWaO-CZoAz0yTuXM1U2Vtt424qXuqa2=a...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi everyone,
I have been trying to make a gnuradio out-of-the-tree block that is able to
control the four GPIOs, currently attached to LED's, of the SBX
daughter-boards working with an USRP motherboard.
I wonder if anyone can help me on this, making a functional draft code of
such a block:
1 integer input - that will define the state of the GPIOs
1 parameter - to define the motherboard serial number
I believe that for people with knowledge of C++, and Python this is a very
simple module, unfortunately that is not my area since I'm a hardware
engineer and I only work with C.
I tried some approaches, using the gr_modtool to create the module, but it
always fails with GRC running errors like:
**********************
Traceback (most recent call last):
File "/home/to-nelsonpina/Desktop/locus_gnuradio/GRC_files/top_block.py",
line 16, in <module>
import gpio
File "/usr/local/lib/python2.7/dist-packages/gpio/__init__.py", line 45,
in <module>
from gpio_swig import *
File "/usr/local/lib/python2.7/dist-packages/gpio/gpio_swig.py", line 26,
in <module>
_gpio_swig = swig_import_helper()
File "/usr/local/lib/python2.7/dist-packages/gpio/gpio_swig.py", line 22,
in swig_import_helper
_mod = imp.load_module('_gpio_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-gpio.so: undefined symbol:
_ZN3uhd4usrp10multi_usrp4makeERKNS_13device_addr_tE
*************************
I will appreciate all the help I can get from you guys.
Best regards,
__
*Nelson Pina*
Product Developer
Hardware
*[email protected]*
*T* +351 220 301 596 (PT)
*T* +44 114 213 2712 (UK)
*www.tomorrow-options.com
*Porto // Portugal
Sheffield // United Kingdom
<http://www.tomorrow-options.com/>
<http://www.linkedin.com/company/tomorrow-options>
<http://www.facebook.com/pages/Porto-Portugal/Tomorrow-Options/214846405104>
<http://twitter.com/TomorrowOptions>
<http://www.youtube.com/user/TomorrowOptionsTube>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130423/92a67f80/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 23 Apr 2013 12:35:33 -0700 (PDT)
From: Edmund Pan <[email protected]>
To: [email protected]
Subject: [USRP-users] Questions about the FPGA boot sequences in USRP
N210?
Message-ID:
<[email protected]>
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/20130423/70f6975e/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 23 Apr 2013 12:44:57 -0700
From: Nick Foster <[email protected]>
To: Edmund Pan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions about the FPGA boot sequences in
USRP N210?
Message-ID:
<CALALHJVhtY7iP3aBhaq4OqqGbuhAJhETKWCY+4TdPgFTF=k...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
M2M1M0 is 001, not 000. The pulldown on M0 is not populated and there are
internal pullups on that pin. The configuration is set up to boot from
Flash as a SPI Master.
--n
On Tue, Apr 23, 2013 at 12:35 PM, Edmund Pan <[email protected]> wrote:
> 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
> _______________________________________________
> 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/20130423/e267866c/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 24 Apr 2013 11:42:10 +0500
From: Sam mite <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO on N210 problem
Message-ID:
<caphw9tslnfyexsyho+rmicigsn0kxnjtgrzcf5gfpvdswmc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
> 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
>
Hi Marcus,
Yes, GPS antenna is working fine because I get this when I connect same
antenna to other GPSDO kit and USRP.
GPS lock status: locked
GPS_GPRMC: $GPRMC,081949.00,A,3342.8120,N,7301.4976,E,0.0,0.0,220413,,*0C
GPS_GPGGA:
$GPGGA,081949.00,3342.8120,N,7301.4976,E,2,11,0.9,591.0,M,-40.7,M,,*7C
It means, antenna is fine. right?
--
Best Regards,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130424/4cac6ebf/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 24 Apr 2013 11:02:03 +0300
From: Sivan Toledo <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Short-term accuracy and stability of the
GPSDO
Message-ID:
<caol_ruhkze32cw7cqr6dutxnhpzaikvewnorxsyrxyqn4eu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Matt. When you write that "You will also need to have self-surveyed
the position", is that some active procedure that we need to do, or just to
let the GPSDO run for a while and it will survey it's position?
On Tue, Apr 23, 2013 at 8:50 AM, Matt Ettus <[email protected]> wrote:
>
> 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/20130424/e0ee83e1/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 24 Apr 2013 16:49:14 +0100
From: Paul Sutton <[email protected]>
To: [email protected]
Subject: [USRP-users] Iris Release 1.0.1
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Release 1.0.1 of the Iris software radio architecture is now available:
https://github.com/softwareradiosystems/iris_core
https://github.com/softwareradiosystems/iris_modules
Contributors:
Paul Sutton <[email protected]>
Andre Puschmann <[email protected]>
Release 1.0.1 features two new stack components - TunTap and AlohaMac.
TunTap provides a connector between Iris and virtual network device drivers
TUN/TAP on Linux systems. AlohaMac provides a simple ALOHA medium access
control layer.
The release also provides performance improvements and bugfixes for
the OfdmModulator and OfdmDemodulator phy components.
Find out more:
- Redmine: http://www.softwareradiosystems.com/redmine/projects/iris
- Iris-discuss mailing list:
http://www.softwareradiosystems.com/mailman/listinfo/iris-discuss
- Iris blog: http://irissoftwareradio.wordpress.com
Enjoy!
Paul
------------------------------
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 19
******************************************
