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. Subnet Mask Change Error (Shaffer, Kevin C.)
2. Re: Subnet Mask Change Error (Josh Blum)
3. N200 FPGA-update fails (Michael Hartje)
4. TVRX2 AGC value (Juha Vierinen)
5. Re: TVRX2 AGC value (Jason Abele)
6. Re: N200 FPGA-update fails (Josh Blum)
7. error with latest version (Stephen)
8. Re: error with latest version (Stephen)
9. Re: error with latest version (Stephen)
10. Re: MIMO Reference Problem (Nick Foster)
11. Re: MIMO Reference Problem (Josh Blum)
12. GPSDO time is wrong (Nowlan, Sean)
13. Re: GPSDO time is wrong (Nick Foster)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Apr 2012 09:06:27 -0700
From: "Shaffer, Kevin C." <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Subnet Mask Change Error
Message-ID:
<ee2dba1391e1954ab1248c76f297639905249...@0461-its-exmb05.us.saic.com>
Content-Type: text/plain; charset="us-ascii"
I am trying to change the subnet mask on a USRP N210 using the following
command:
cd <install-path>/share/uhd/utils
./usrp_burn_mb_eeprom --args=<optional device args> --key=subnet
--val=255.255.255.0
But the error I get returned, says the EEPROM[subnet] value cannot be
found.
Has anyone had success changing the subnet on the USRP?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120430/319ced94/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 30 Apr 2012 09:57:44 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Subnet Mask Change Error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/30/2012 09:06 AM, Shaffer, Kevin C. wrote:
> I am trying to change the subnet mask on a USRP N210 using the following
> command:
>
>
>
> cd <install-path>/share/uhd/utils
>
> ./usrp_burn_mb_eeprom --args=<optional device args> --key=subnet
> --val=255.255.255.0
>
>
>
> But the error I get returned, says the EEPROM[subnet] value cannot be
> found.
>
>
Referring to:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination
This feature is not yet part of a release, you will have to use the
master branch/unstable build of UHD
-josh
------------------------------
Message: 3
Date: Mon, 30 Apr 2012 19:37:09 +0200
From: Michael Hartje <[email protected]>
To: [email protected]
Subject: [USRP-users] N200 FPGA-update fails
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15
I am using N200 r2 serial number EER1OZUN
on Ubuntu 11.10
since there were some problems to uhd_find_devices and to communicate
with the host I started an update of the firmware and FPGA to UHD
003.004.000-release images.
This gave some unwanted hanging situations:
1. with usrp_n2xx_net_burner_gui.py selecting the correct files it stops
with timeout error
2. with usrp_n2xx_net_burner.py
a) an update of the firmware was success
b) the update of the fpga gave:
# /host/utils/host/utils/usrp_n2xx_net_burner.py --addr=192.168.10.2
--fpga=images/usrp_n200_r2_fpga.bin
USRP-N2XX found.
Flash size: 4194304
Sector size: 65536
Begin FPGA write: this should take about 1 minute...
Erasing 1572864 bytes at 1572864
Writing image
Traceback (most recent call last):
File "./host/utils/usrp_n2xx_net_burner.py", line 522, in <module>
else: burner.burn_fw(fw=options.fw, fpga=options.fpga,
reset=options.reset, safe=options.overwrite_safe, check_rev=not
options.dont_check_rev)
File "./host/utils/usrp_n2xx_net_burner.py", line 311, in burn_fw
self.write_image(fpga_image, image_location)
File "./host/utils/usrp_n2xx_net_burner.py", line 353, in write_image
in_pkt = self.send_and_recv(out_pkt)
File "./host/utils/usrp_n2xx_net_burner.py", line 245, in send_and_recv
return self._sock.recv(UDP_MAX_XFER_BYTES)
socket.timeout: timed out
this is the end -- but when i want to access the n200 with
uhd_find_devices it gave me:
-- Opening a USRP2/N-Series device...
Error: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected protocol compatibility number [10 to 11], but got 9:
The firmware build is not compatible with the host code build.
any help is still needed!
Thanks for reading and thinking about it
M. Hartje
--
Prof. Dr.-Ing. Michael Hartje
Labor Hochspannungstechnik / Labor elektrische Messtechnik
Neustadtswall 30; D-28199 Bremen
Tel +49 421 5905-3444 FAX +49 421 5905-3476
------------------------------
Message: 4
Date: Mon, 30 Apr 2012 18:19:51 +0000
From: Juha Vierinen <[email protected]>
To: [email protected]
Subject: [USRP-users] TVRX2 AGC value
Message-ID:
<CAGbkif20b=CFY50SCWBDp2+5S1y8m=mjhn3errvkqmsamh1...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
Is it possible to read the AGC gain value in some way on the TVRX2?
juha
------------------------------
Message: 5
Date: Mon, 30 Apr 2012 11:52:11 -0700
From: Jason Abele <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] TVRX2 AGC value
Message-ID: <20120430185211.GF9892@nettles>
Content-Type: text/plain; charset=us-ascii
Juha,
On Mon, Apr 30, 2012 at 06:19:51PM +0000, Juha Vierinen wrote:
> Hi,
>
> Is it possible to read the AGC gain value in some way on the TVRX2?
Unfortunately, no, as far as we know, there is no readback for the
current gain state nor any way to halt the AGC, it is always on.
There is an RSSI sensor, which may help you
Jason
>
> juha
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Mon, 30 Apr 2012 12:04:56 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N200 FPGA-update fails
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/30/2012 10:37 AM, Michael Hartje wrote:
> I am using N200 r2 serial number EER1OZUN
> on Ubuntu 11.10
>
> since there were some problems to uhd_find_devices and to communicate
> with the host I started an update of the firmware and FPGA to UHD
> 003.004.000-release images.
>
> This gave some unwanted hanging situations:
>
This is definitely the sign of a packet drop. Can you try the burner app
on a different machine/ethernet card and see if the problem follows?
Any machine should be ok because the burner applications are just simple
python scripts.
-josh
------------------------------
Message: 7
Date: Mon, 30 Apr 2012 18:24:33 -0500
From: Stephen <[email protected]>
To: [email protected]
Subject: [USRP-users] error with latest version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hey,
I used the build gnuradio script to pull down the latest version of
gnuradio, uhd and the firmware. As far as I can see everything built
correctly. But when I try to run anything I get the following error
RuntimeError: RuntimeError: Expected FPGA compatibility number 9, but
got 10:
The FPGA build is not compatible with the host code build.
How do I fix this?
thanks,
Stephen
------------------------------
Message: 8
Date: Mon, 30 Apr 2012 18:27:39 -0500
From: Stephen <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] error with latest version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 4/30/2012 6:24 PM, Stephen wrote:
> Hey,
>
> I used the build gnuradio script to pull down the latest version of
> gnuradio, uhd and the firmware. As far as I can see everything built
> correctly. But when I try to run anything I get the following error
>
> RuntimeError: RuntimeError: Expected FPGA compatibility number 9, but
> got 10:
> The FPGA build is not compatible with the host code build.
>
> How do I fix this?
>
> thanks,
> Stephen
>
Forgot to mention I have a B100 usrp.
------------------------------
Message: 9
Date: Mon, 30 Apr 2012 18:37:14 -0500
From: Stephen <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] error with latest version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 4/30/2012 6:27 PM, Stephen wrote:
>
>
> On 4/30/2012 6:24 PM, Stephen wrote:
>> Hey,
>>
>> I used the build gnuradio script to pull down the latest version of
>> gnuradio, uhd and the firmware. As far as I can see everything built
>> correctly. But when I try to run anything I get the following error
>>
>> RuntimeError: RuntimeError: Expected FPGA compatibility number 9, but
>> got 10:
>> The FPGA build is not compatible with the host code build.
>>
>> How do I fix this?
>>
>> thanks,
>> Stephen
>>
>
> Forgot to mention I have a B100 usrp.
>
>
Nevermind. Something didn't work with the UHD fetch or build. I removed
all the UHD files and redid the fetch and build and everything is
working now.
------------------------------
Message: 10
Date: Mon, 30 Apr 2012 16:55:12 -0700
From: Nick Foster <[email protected]>
To: Brian Heilig <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] MIMO Reference Problem
Message-ID:
<calalhjxjnncg30gamzav5chtuvcidzkn+_smdbycgoph_-t...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Sat, Apr 28, 2012 at 1:30 PM, Brian Heilig <[email protected]>wrote:
> Dear List,
>
> I have a pair of USRP2 radios with RFX900 daughterboards. Both are HW rev
> 4. I'm having a very difficult time getting the two radios to synchronize
> to the same reference clock. I've tried both an external reference and the
> MIMO reference. I'm transmitting from USRP2 B and receiving from USRP2 A,
> and I'm (attempting to) lock B to A's reference. Unfortunately I'm seeing
> about a 10KHz difference in the received frequency at A.
>
> I've taken some pictures of what I believe to be the root of the problem.
> By the way I have my own FPGA and firmware images. The troubleshooting is
> pretty close to the hardware.
>
> In order to ensure the two radios were synchronized I used the 10 MHz
> output of A to trigger an oscilloscope. I then measured the various clocks
> on B. If the two clocks were synchronized we would see a nice clean signal
> without aliasing. But I don't...
>
> Here are some pictures of what I'm seeing.
>
> http://imgur.com/a/0rw3K
>
> The first image is of the 10 MHz signal from radio A, measured at the
> output of the clock switch U18 on radio B. This shows that a clean
> reference clock is arriving at the AD9510 U9 ref input. This measurement is
> triggered to itself.
>
> The next image is of the 100 Mhz output of the VCO of USRP2 B. It's also
> triggered to itself.
>
> The next image is of the 10 MHz from radio A used as a trigger, and 100
> Mhz output of the VCO from radio A. This is a sanity check, and shows what
> the display should look like if the two clocks are frequency aligned. Note
> that there is some interference on the 10 MHz signal from the 100 Mhz
> signal. This is because the probe measuring the 10 MHz signal is not the
> greatest.
>
> The last image is of the 10 MHz from radio A (same as image #1) used as a
> trigger, and 100 MHz output of the VCO from radio B. If the two clocks were
> synchronized I'd expect to see nice clean clocks. I don't, which indicates
> there is a (non-integer) frequency drift between them due to aliasing.
>
> Please help! I can't go any further until this is resolved.
>
Brian,
The USRP2/N210 do not have a reference output -- only a reference input.
Are you using the optional integrated GPSDO as your reference? If so, how
are you splitting it to both USRPs? We need some more information about
your setup.
Thanks,
--n
>
> Thanks,
> Brian
>
>
> _______________________________________________
> 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/20120430/b8d88852/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 30 Apr 2012 17:24:25 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] MIMO Reference Problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/28/2012 01:30 PM, Brian Heilig wrote:
> Dear List,
>
> I have a pair of USRP2 radios with RFX900 daughterboards. Both are HW rev
> 4. I'm having a very difficult time getting the two radios to synchronize
> to the same reference clock. I've tried both an external reference and the
> MIMO reference. I'm transmitting from USRP2 B and receiving from USRP2 A,
> and I'm (attempting to) lock B to A's reference. Unfortunately I'm seeing
> about a 10KHz difference in the received frequency at A.
>
Just to rule out something obvious. You are calling set_clock_source for
both channels?
If you have a shared 10MHz ref:
usrp->set_clock_source("external", 0);
usrp->set_clock_source("external", 1);
Or maybe the MIMO cable:
usrp->set_clock_source("mimo", 0);
//the other channel can be external or internal, your choosing
-josh
------------------------------
Message: 12
Date: Tue, 1 May 2012 04:14:24 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPSDO time is wrong
Message-ID: <195933287DC65748BA7AE867BA8E430B6218B9A3@apatlisdmbx02>
Content-Type: text/plain; charset="iso-8859-1"
I'm having an issue with the FPGA time register taking on a bad time value from
the GPSDO unit when it's not locked. Essentially I'm doing this:
while not usrp.get_mboard_sensor("gps_locked", 0).to_bool():
print "STILL waiting..."
sleep(4)
if usrp.get_mboard_sensor("gps_locked", 0).to_bool():
print "FINALLY LOCKED!"
usrp.get_time_last_pps(0)
>>> prints 1136074108, which is 2006-01-01 00:08:28
How do you force the GPSDO to give the correct time?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120501/dad6b43d/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 1 May 2012 08:16:45 -0700
From: Nick Foster <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO time is wrong
Message-ID:
<CALALHJX6M+PRZDhvph+=tBAegGg0h6QaGKB9Z1Gkk=+k7dx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Apr 30, 2012 at 9:14 PM, Nowlan, Sean
<[email protected]>wrote:
> I'm having an issue with the FPGA time register taking on a bad time
> value from the GPSDO unit when it's not locked. Essentially I'm doing this:
>
> while not usrp.get_mboard_sensor("gps_locked", 0).to_bool():
> print "STILL waiting..."
> sleep(4)
>
> if usrp.get_mboard_sensor("gps_locked", 0).to_bool():
> print "FINALLY LOCKED!"
>
> usrp.get_time_last_pps(0)
>
> >>> prints 1136074108, which is 2006-01-01 00:08:28
>
> How do you force the GPSDO to give the correct time?
>
The USRP PPS time and the GPSDO time aren't the same clock. You have to set
the time at next PPS to the gps_time sensor value, plus one second. It's
supposed to do this automatically at initialization time (see
usrp2_impl.cpp lines ~659-666), but if the GPSDO isn't locked when UHD
initializes it won't set a time (since the GPSDO time isn't known until GPS
lock). Either init after GPS is locked or duplicate that behavior in your
own program after lock.
If you don't care about the USRP PPS time (used for TX scheduling and RX
timestamping) but only care about GPSDO time at initialization (for, say,
coarse timestamping and logging) you can just fetch the GPS time from the
GPSDO with usrp.get_mboard_sensor("gpsdo_time", 0).to_int().
--n
>
> _______________________________________________
> 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/20120501/f433675a/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 21, Issue 1
*****************************************
