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: B210 Concurrent Process Access (Marcus M?ller)
2. USRP2 + XCVR2450 configuration (Virag Varga)
3. N210 - Detects 63 MB RAM in lieu of 512 MB (Brais Ares)
4. Re: N210 - Detects 63 MB RAM in lieu of 512 MB (Brais Ares)
5. Re: B210 Concurrent Process Access (Peter Witkowski)
6. E110 - Detects 63MB RAM in lieu of 512 MB (was: N210 -
Detects 63 MB RAM in lieu of 512 MB) (Marcus M?ller)
7. Re: N210 - Detects 63 MB RAM in lieu of 512 MB (Philip Balister)
8. Re: E110 - Detects 63MB RAM in lieu of 512 MB (was: N210 -
Detects 63 MB RAM in lieu of 512 MB) (Brais Ares)
9. B2xx fpga modification (Zhang, Yunfan Donald - 0666 - MITLL)
10. Re: B210 RF DC Offset Calibration Failure (Perelman, Nathan)
11. Re: B210 RF DC Offset Calibration Failure (Marcus D. Leech)
12. Re: B210 RF DC Offset Calibration Failure (Ian Buckley)
13. Re: B2xx fpga modification (Marcus M?ller)
14. Resolution of center frequency settings (mahaveer gupta)
15. Re: Resolution of center frequency settings (Marcus M?ller)
16. Re: E110 - Detects 63MB RAM in lieu of 512 MB (Marcus M?ller)
17. Re: [UHD 3.8.1] Release Announcement ([email protected])
18. Re: E110 - Detects 63MB RAM in lieu of 512 MB (Brais Ares)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Dec 2014 18:02:54 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 Concurrent Process Access
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello Peter,
the "shared" in shared pointer refers to the fact that the pointer can
be shared between different functional units in the same process, and
there's not a single instance which has to make sure the objects gets
destructed as soon as no one is using it anymore; sadly, that doesn't
work across processesg :/
So, no, only one process can own a B2x0 at a time; that would require
UHD to act like a server process, whereas in fact it's designed to act
more like a library. You'd need a central process to handle UHD and your
two DSP processes talking to that via IPC, or something of the like.
You can build something like that rather rapidly using GNU Radio and
gr-uhd, the UHD wrapper framework included with it; GNU Radio comes with
things like socket sinks/sources, and you can even do really cool IPC
using zeromq, for example; since a few months, the USRP blocks for GNU
Radio listen to asynchronous messages telling them to tune etc, so this
might reduce your coding efforts further.
Greetings,
Marcus
On 12/16/2014 05:53 PM, Peter Witkowski via USRP-users wrote:
> Hello,
>
> I have a quick question regarding how UHD handles concurrent processes
> accessing the same USRP.
>
> Say I have two applications (totally separate processes in Linux) and
> both want to talk to the same B210 (and use different channels on the
> B210). Can both processes communicate with the device concurrently?
> I noted that the make() call to multi_usrp returns a shared pointer,
> so I was wondering if (as a result) you can have multiple processes
> access the same physical device (with the same device arguments).
>
> Thanks in advance for the help.
>
> --
> Peter Witkowski
> [email protected] <mailto:[email protected]>
>
>
> _______________________________________________
> 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/20141216/3fb9d6ad/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 16 Dec 2014 12:15:54 +0100
From: Virag Varga <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP2 + XCVR2450 configuration
Message-ID:
<CABPEh2K1NA1EjjxFCVg7x=cs41xqqe6prclh08t157jcahf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
I'm quite new to the SDR world. I started with an USRP2 (r4) +
XCVR2450 dboard. I tried some examples with gnuradio, but I'm still
not sure, if everything is setup correctly (mostly it seems I'm only
getting noise)..
For start, I don't think I should get this output (no sign that my
daughterboard is recognized correctly) for uhd_usrp_probe (check down
below).
Do I miss some installation/configuration steps?
Thanks for any help!
Bests,
Virag
$ uhd_usrp_probe
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-release
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
_____________________________________________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: USRP2 r4
| | hardware: 1024
| | mac-addr: 00:50:c2:85:39:47
| | ip-addr: 255.255.255.255
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: 2375
| | FW Version: 12.4
| | FPGA Version: 10.0
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: mimo_locked, ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Unknown (0xffff) - 0
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: 0.000 to 0.000 MHz
| | | | Gain Elements: None
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ltc2284
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Unknown (0xffff) - 0
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: 0.000 to 0.000 MHz
| | | | Gain Elements: None
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9777
| | | | Gain Elements: None
------------------------------
Message: 3
Date: Tue, 16 Dec 2014 19:58:14 +0100
From: Brais Ares <[email protected]>
To: [email protected]
Subject: [USRP-users] N210 - Detects 63 MB RAM in lieu of 512 MB
Message-ID:
<cajcstagsjww_ax5ndfkafrygpvrhh_wg7dyvepdzy5979h2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm having trouble with one of my N210. It only detects 63 MB of RAM as you
can see in this pic, when this value ought to be 512 MB:
https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
The RAM that's still left is not even enough to compile a small program so
that gcc throws an error.
I moved the small PCB where the SD Card and processor are to a healthy
N210, and it's not healthy anymore, so the problem seems to be this small
PCB.
I would appreciate any advice about this.
Regards,
Brais.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141216/d31860b1/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 16 Dec 2014 20:05:27 +0100
From: Brais Ares <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 - Detects 63 MB RAM in lieu of 512 MB
Message-ID:
<CAJcStAgJwKaRkc3tSnSs5ggZL7zYZp-SsZ=cdthqds9a_vd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sorry,
All i said applied to USRPs E110.
2014-12-16 19:58 GMT+01:00 Brais Ares <[email protected]>:
>
> Hello,
>
> I'm having trouble with one of my N210. It only detects 63 MB of RAM as
> you can see in this pic, when this value ought to be 512 MB:
>
> https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
>
> The RAM that's still left is not even enough to compile a small program so
> that gcc throws an error.
>
> I moved the small PCB where the SD Card and processor are to a healthy
> N210, and it's not healthy anymore, so the problem seems to be this small
> PCB.
>
> I would appreciate any advice about this.
>
> Regards,
> Brais.
>
> --
>
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141216/2bb71d62/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 16 Dec 2014 14:17:11 -0500
From: Peter Witkowski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 Concurrent Process Access
Message-ID:
<can1qg3mzdyfyurxwj1vawudwybekzj6hs67el7ns_ndgspi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the help. That's what I figured, I just wanted to make sure
there wasn't anything else there.
On Tue, Dec 16, 2014 at 12:02 PM, Marcus M?ller <[email protected]>
wrote:
>
> Hello Peter,
>
> the "shared" in shared pointer refers to the fact that the pointer can be
> shared between different functional units in the same process, and there's
> not a single instance which has to make sure the objects gets destructed as
> soon as no one is using it anymore; sadly, that doesn't work across
> processesg :/
>
> So, no, only one process can own a B2x0 at a time; that would require UHD
> to act like a server process, whereas in fact it's designed to act more
> like a library. You'd need a central process to handle UHD and your two DSP
> processes talking to that via IPC, or something of the like.
>
> You can build something like that rather rapidly using GNU Radio and
> gr-uhd, the UHD wrapper framework included with it; GNU Radio comes with
> things like socket sinks/sources, and you can even do really cool IPC using
> zeromq, for example; since a few months, the USRP blocks for GNU Radio
> listen to asynchronous messages telling them to tune etc, so this might
> reduce your coding efforts further.
>
> Greetings,
> Marcus
>
>
>
> On 12/16/2014 05:53 PM, Peter Witkowski via USRP-users wrote:
>
> Hello,
>
> I have a quick question regarding how UHD handles concurrent processes
> accessing the same USRP.
>
> Say I have two applications (totally separate processes in Linux) and
> both want to talk to the same B210 (and use different channels on the
> B210). Can both processes communicate with the device concurrently? I
> noted that the make() call to multi_usrp returns a shared pointer, so I was
> wondering if (as a result) you can have multiple processes access the same
> physical device (with the same device arguments).
>
> Thanks in advance for the help.
>
> --
> Peter Witkowski
> [email protected]
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Peter Witkowski
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141216/c19d01b6/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 16 Dec 2014 20:19:05 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: [USRP-users] E110 - Detects 63MB RAM in lieu of 512 MB (was:
N210 - Detects 63 MB RAM in lieu of 512 MB)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello Brais,
have you tried putting a clean image on the SD card? This could also be
caused by something wrong with the way the operating system is loaded.
Greetings,
Marcus
On 12/16/2014 08:05 PM, Brais Ares via USRP-users wrote:
> Sorry,
>
> All i said applied to USRPs E110.
>
> 2014-12-16 19:58 GMT+01:00 Brais Ares <[email protected]
> <mailto:[email protected]>>:
>
> Hello,
>
> I'm having trouble with one of my N210. It only detects 63 MB of
> RAM as you can see in this pic, when this value ought to be 512 MB:
>
> https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
>
> The RAM that's still left is not even enough to compile a small
> program so that gcc throws an error.
>
> I moved the small PCB where the SD Card and processor are to a
> healthy N210, and it's not healthy anymore, so the problem seems
> to be this small PCB.
>
> I would appreciate any advice about this.
>
> Regards,
> Brais.
>
> --
>
>
>
> --
>
>
>
> _______________________________________________
> 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/20141216/74dd049e/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 16 Dec 2014 14:28:10 -0500
From: Philip Balister <[email protected]>
To: Brais Ares <[email protected]>, [email protected]
Subject: Re: [USRP-users] N210 - Detects 63 MB RAM in lieu of 512 MB
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 12/16/2014 01:58 PM, Brais Ares via USRP-users wrote:
> Hello,
>
> I'm having trouble with one of my N210. It only detects 63 MB of RAM as you
> can see in this pic, when this value ought to be 512 MB:
>
> https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
>
> The RAM that's still left is not even enough to compile a small program so
> that gcc throws an error.
>
> I moved the small PCB where the SD Card and processor are to a healthy
> N210, and it's not healthy anymore, so the problem seems to be this small
> PCB.
Can you see if the problem follows the SD card or the overo (the small
board is a gumstix Overo COM)?
Is it possible someone has reserved memory for the DSP by editting the
kernel command line?
Philip
>
> I would appreciate any advice about this.
>
> Regards,
> Brais.
>
> --
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Tue, 16 Dec 2014 23:39:30 +0100
From: Brais Ares <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E110 - Detects 63MB RAM in lieu of 512 MB
(was: N210 - Detects 63 MB RAM in lieu of 512 MB)
Message-ID:
<cajcstagxxtgbjozr4d4ivid0mvcfzsf8uahpyal-quuudcy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Marcus,
In order to discard that possibility, apart from switching Overo boards, I
also tried to only switch SD cards. I've got one SD Card working flawless
in the other E110, but putting it into the faulty usrp, RAM goes down to 61
MB as well.
Regards,
Brais.
2014-12-16 20:19 GMT+01:00 Marcus M?ller <[email protected]>:
>
> Hello Brais,
>
> have you tried putting a clean image on the SD card? This could also be
> caused by something wrong with the way the operating system is loaded.
>
> Greetings,
> Marcus
>
> On 12/16/2014 08:05 PM, Brais Ares via USRP-users wrote:
>
> Sorry,
>
> All i said applied to USRPs E110.
>
> 2014-12-16 19:58 GMT+01:00 Brais Ares <[email protected]>:
>>
>> Hello,
>>
>> I'm having trouble with one of my N210. It only detects 63 MB of RAM as
>> you can see in this pic, when this value ought to be 512 MB:
>>
>> https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
>>
>> The RAM that's still left is not even enough to compile a small program
>> so that gcc throws an error.
>>
>> I moved the small PCB where the SD Card and processor are to a healthy
>> N210, and it's not healthy anymore, so the problem seems to be this small
>> PCB.
>>
>> I would appreciate any advice about this.
>>
>> Regards,
>> Brais.
>>
>> --
>>
>>
>
> --
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20141216/e74c4489/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 16 Dec 2014 22:42:16 +0000
From: "Zhang, Yunfan Donald - 0666 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B2xx fpga modification
Message-ID:
<fd89003b729d7b4486041c3631beb92d18ad2...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
Hi List,
I am looking for resource to help me understand the current design of the
third generation FPGA (usrp3) and suggestions on where is a good place to
insert my custom fpga code. I know this is a very generalized question but
at this point I am just trying to understand the fpga code better. There
are a few words in the readme in the fpga repository on customizing the HDL
with gen 2 products, but nothing on gen 3.
Thanks
Donald Zhang
Electrical Engineer
MIT Lincoln Lab
244 Wood Street
Lexington, MA 02421
781-981-7698
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141216/cfb4caa0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5410 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141216/cfb4caa0/attachment-0001.p7s>
------------------------------
Message: 10
Date: Tue, 16 Dec 2014 22:58:41 +0000
From: "Perelman, Nathan" <[email protected]>
To: Ian Buckley <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
So is there no way to reliably sample at 61.44 MHz from a B210?
-Nathan
From: USRP-users [mailto:[email protected]] On Behalf Of
Perelman, Nathan via USRP-users
Sent: Monday, December 1, 2014 6:59 PM
To: Ian Buckley
Cc: [email protected]
Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
As advertised by the driver, the error does go away when I request a master
clock rate of 56 MHz. Other values between 56 and 61.44 MHz did not work (I
tried 57, 58, and 60). I was hoping to be able to sample at 61.44 MHz for my
application.
-Nathan
From: Ian Buckley [mailto:[email protected]]
Sent: Monday, December 1, 2014 6:16 PM
To: Perelman, Nathan
Cc: [email protected]
Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
This is a vague answer since I've never worked on this aspect of AD9361 and
someone may respond with a better response...
My recollection is that despite the actually radio being spec'ed to
61.44MHz, experience demonstrated that some of the internal algorithms that
perform calibrations start to have problems converging above 56MHz, which
generally results in larger elapsed times before the device is ready to by
used after configuration. Thus the origins of the warning message UHD gives
for rates >56MHz. I don't recall hearing a good reason "why" this should be
so from any ADI engineering folks.
So perhaps slow to converge manifests as failed to converge for some
possible configurations? What happens if you back it off a little from the
limit..say 61.0HMz?
-Ian
On Dec 1, 2014, at 1:58 PM, "Perelman, Nathan via USRP-users"
<[email protected]> wrote:
I'm seeing this error attempting to use a B210 with a master clock rate of
61.44 MHz. This is with UHD 3.8.0. I've been just trying to test it out with
the benchmark_rate application, but this is what happens:
$ ./benchmark_rate --rx_rate 61.44e6 --channels 0 --args
"master_clock_rate=61.44e6" --rx_cpu=sc16
linux; GNU C++ version 4.8.3 20140624 (Red Hat 4.8.3-1); Boost_105500;
UHD_003.008.000-0-unknown
Creating the usrp device with: master_clock_rate=61.44e6...
-- Operating over USB 3.
-- Detecting internal GPSDO.... Found an internal GPSDO
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 61.440000 MHz
UHD Warning:
The requested clock rate 61.440000 MHz may cause slow configuration.
The driver recommends a master clock rate less than 56.000000 MHz.
Error: RuntimeError: [ad9361_device_t] RF DC Offset Calibration Failure
I get the same error for other rates I've tried in excess of 56 MHz. Any
idea what causes this error and what I could do to resolve it? Thanks.
-Nathan
_______________________________________________
USRP-users mailing list
<mailto:[email protected]> [email protected]
<http://lists.ettus.com/mailman/listinfo/usrp-users_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/20141216/e66ab8da/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4327 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141216/e66ab8da/attachment-0001.p7s>
------------------------------
Message: 11
Date: Tue, 16 Dec 2014 18:20:26 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/16/2014 05:58 PM, Perelman, Nathan via USRP-users wrote:
>
> So is there no way to reliably sample at 61.44 MHz from a B210?
>
> -Nathan
>
The highest sample-rate on the B210 *when using both channels* is
30.72Msps, whereas in single-channel mode, it should be 61.44Msps,
provided you
make the master clock 61.44MHz--the default master clock if you don't
specify anything is 32MHz.
The AD9361 supports a maximum of 30.72Msps when you're streaming both
sides out of it, and that is a restriction on the way the clocking
works on that chip, not an arbitrary limitation based on FPGA policy
or anything like that, as far as I know.
Not sure why master clock above 56MHz doesn't work--it should, and
perhaps Balint or Ben or one of the other B2xx-involved R&D people could
comment. I know that I've set 61.44MHz master clock on my B210 in
the past, and that has worked OK, but perhaps this is a "chip by chip"
thing. There's no hint of that in the AD9361 data sheet.
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Perelman, Nathan via USRP-users
> *Sent:* Monday, December 1, 2014 6:59 PM
> *To:* Ian Buckley
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] B210 RF DC Offset Calibration Failure
>
> As advertised by the driver, the error does go away when I request a
> master clock rate of 56 MHz. Other values between 56 and 61.44 MHz did
> not work (I tried 57, 58, and 60). I was hoping to be able to sample
> at 61.44 MHz for my application.
>
> -Nathan
>
> *From:*Ian Buckley [mailto:[email protected]]
> *Sent:* Monday, December 1, 2014 6:16 PM
> *To:* Perelman, Nathan
> *Cc:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] B210 RF DC Offset Calibration Failure
>
> This is a vague answer since I've never worked on this aspect of
> AD9361 and someone may respond with a better response.....
>
> My recollection is that despite the actually radio being spec'ed to
> 61.44MHz, experience demonstrated that some of the internal algorithms
> that perform calibrations start to have problems converging above
> 56MHz, which generally results in larger elapsed times before the
> device is ready to by used after configuration. Thus the origins of
> the warning message UHD gives for rates >56MHz. I don't recall hearing
> a good reason "why" this should be so from any ADI engineering folks.
>
> So perhaps slow to converge manifests as failed to converge for some
> possible configurations? What happens if you back it off a little from
> the limit..say 61.0HMz?
>
> -Ian
>
> On Dec 1, 2014, at 1:58 PM, "Perelman, Nathan via USRP-users"
> <[email protected] <mailto:[email protected]>> wrote:
>
> I'm seeing this error attempting to use a B210 with a master clock
> rate of 61.44 MHz. This is with UHD 3.8.0. I've been just trying to
> test it out with the benchmark_rate application, but this is what happens:
>
> $ ./benchmark_rate --rx_rate 61.44e6 --channels 0 --args
> "master_clock_rate=61.44e6" --rx_cpu=sc16
>
> linux; GNU C++ version 4.8.3 20140624 (Red Hat 4.8.3-1); Boost_105500;
> UHD_003.008.000-0-unknown
>
> Creating the usrp device with: master_clock_rate=61.44e6...
>
> -- Operating over USB 3.
>
> -- Detecting internal GPSDO.... Found an internal GPSDO
>
> -- Initialize CODEC control...
>
> -- Initialize Radio control...
>
> -- Performing register loopback test... pass
>
> -- Performing register loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Asking for clock rate 61.440000 MHz
>
> UHD Warning:
>
> The requested clock rate 61.440000 MHz may cause slow configuration.
>
> The driver recommends a master clock rate less than 56.000000 MHz.
>
> Error: RuntimeError: [ad9361_device_t] RF DC Offset Calibration Failure
>
> I get the same error for other rates I've tried in excess of 56 MHz.
> Any idea what causes this error and what I could do to resolve it? Thanks.
>
> -Nathan
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
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/20141216/7cbf7af6/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 16 Dec 2014 15:56:47 -0800
From: Ian Buckley <[email protected]>
To: "Perelman, Nathan" <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Nathan,
I thing this is a perfectly reasonable question given that ADI specs the radio
as supporting this rate. I have filed a bug on this and I'll try to get someone
to work on it ASAP to get a definitive answer.
The bug is #649 incase you have a conversation with any Ettus support folks in
the future on this topic.
I, BTW see the same error message as you with current UHD and a B210.
-Ian
On Dec 16, 2014, at 2:58 PM, "Perelman, Nathan" <[email protected]>
wrote:
> So is there no way to reliably sample at 61.44 MHz from a B210?
> -Nathan
>
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Perelman, Nathan via USRP-users
> Sent: Monday, December 1, 2014 6:59 PM
> To: Ian Buckley
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
>
> As advertised by the driver, the error does go away when I request a master
> clock rate of 56 MHz. Other values between 56 and 61.44 MHz did not work (I
> tried 57, 58, and 60). I was hoping to be able to sample at 61.44 MHz for my
> application.
> -Nathan
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Monday, December 1, 2014 6:16 PM
> To: Perelman, Nathan
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 RF DC Offset Calibration Failure
>
> This is a vague answer since I've never worked on this aspect of AD9361 and
> someone may respond with a better response?..
>
> My recollection is that despite the actually radio being spec'ed to 61.44MHz,
> experience demonstrated that some of the internal algorithms that perform
> calibrations start to have problems converging above 56MHz, which generally
> results in larger elapsed times before the device is ready to by used after
> configuration. Thus the origins of the warning message UHD gives for rates
> >56MHz. I don't recall hearing a good reason "why" this should be so from any
> ADI engineering folks.
>
> So perhaps slow to converge manifests as failed to converge for some possible
> configurations? What happens if you back it off a little from the limit..say
> 61.0HMz?
>
> -Ian
>
>
> On Dec 1, 2014, at 1:58 PM, "Perelman, Nathan via USRP-users"
> <[email protected]> wrote:
>
>
> I?m seeing this error attempting to use a B210 with a master clock rate of
> 61.44 MHz. This is with UHD 3.8.0. I?ve been just trying to test it out with
> the benchmark_rate application, but this is what happens:
>
> $ ./benchmark_rate --rx_rate 61.44e6 --channels 0 --args
> "master_clock_rate=61.44e6" --rx_cpu=sc16
> linux; GNU C++ version 4.8.3 20140624 (Red Hat 4.8.3-1); Boost_105500;
> UHD_003.008.000-0-unknown
>
>
> Creating the usrp device with: master_clock_rate=61.44e6...
> -- Operating over USB 3.
> -- Detecting internal GPSDO.... Found an internal GPSDO
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 61.440000 MHz
>
> UHD Warning:
> The requested clock rate 61.440000 MHz may cause slow configuration.
> The driver recommends a master clock rate less than 56.000000 MHz.
> Error: RuntimeError: [ad9361_device_t] RF DC Offset Calibration Failure
>
>
> I get the same error for other rates I?ve tried in excess of 56 MHz. Any idea
> what causes this error and what I could do to resolve it? Thanks.
> -Nathan
> _______________________________________________
> 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/20141216/d383b653/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 17 Dec 2014 09:42:21 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B2xx fpga modification
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello Donald,
if inserting your own code is your goal, maybe the B2x0 is not the
optimal platform -- it offers little free ressources, as most of the
FPGA is used by the digital signal processing, data flow and control
necessary for operation.
Also, for the third generation, RFNoC (RF Network on Chip) is the
flexible new architecture, designed to allow you to easily define new
blocks of functionality and define how data flows in and out of these
[1]. Sadly, this requires features you can't get with the FPGA on the
B2x0 -- it works on the X series.
So if your question really was "how to modify third generation FPGA
images", the answer would be "go for RF NoC, it might make your life
sooo much easier"; if your question was in fact B2x0-centric, then the
answer is would be something like "it depends; assuming you want to do
DSP, maybe have a look into fpga-src/usrp3/top/b200/b200_radio.v to get
a bit of an overview on what happens with samples, and then have a look
at usrp3/lib/dsp/ddc_chain.v".
Greetings,
Marcus
[1] https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
On 12/16/2014 11:42 PM, Zhang, Yunfan Donald - 0666 - MITLL via
USRP-users wrote:
>
> Hi List,
>
>
>
> I am looking for resource to help me understand the current design of
> the third generation FPGA (usrp3) and suggestions on where is a good
> place to insert my custom fpga code. I know this is a very
> generalized question but at this point I am just trying to understand
> the fpga code better. There are a few words in the readme in the fpga
> repository on customizing the HDL with gen 2 products, but nothing on
> gen 3.
>
>
>
> Thanks
>
>
>
> Donald Zhang
>
> Electrical Engineer
>
> MIT Lincoln Lab
>
> 244 Wood Street
>
> Lexington, MA 02421
>
> 781-981-7698
>
>
>
>
>
> _______________________________________________
> 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/20141217/12f3c37d/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 17 Dec 2014 03:52:44 -0600
From: mahaveer gupta <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Resolution of center frequency settings
Message-ID:
<CAMhWHyZEGR=knpsqscbluwqjzdzx7a-y6ogz1_c1afiag1h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Could you please tell me the resolution at which I can vary the center
frequency settings in USRP N210.
For example, I can set the center frequency to be at 2.45 GHz. If I want to
increase the center frequency by 1 Hz, I could use 2.450000001 Hz. Not
sure, how accurate the small increment would be and if it would make any
difference at all.
I know 1 Hz is very small, but would like to know the step size at which
frequency increments would have effects
--
Thanks,
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141217/45d537ac/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 17 Dec 2014 11:21:32 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Resolution of center frequency settings
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hello Mahaveer,
tuning USRPs is a two-stage process:
1. the daughterboard has gets tuned.
2. the DSP logic performs digital frequency shifting.
1. Daughterboard tuning
-----------------------
The daughterboards have local oscillators (LO) which they use to mix
down the RF signal to baseband (or vice versa).
These LOs are generated from the motherboard reference clock, usually by
fractional interpolation; thus, the LO can only tune to a discrete set
of frequencies.
How many of these frequencies exists, and how they are distributed,
depends on the daughterboard.
2. DSP frequency shifting
-------------------------
RX side:
The FPGA has logic that generates a complex sine (it's actually a
12-stage CORDIC) and multiplies the ADC samples with it, before
anti-aliasing filtering and decimating the ADC samples (coming in at
100MS/s) to the user-requested sampling rate.
This allows the USRP to transparently tune to "any" real frequency in
the daughterboard's frequency range.
"any" is in parentheses, because this is where accuracy comes in: the
sine calculation of course happens with fixed point numbers, and so do
the multiplication and the rest of the DSP. Thus, everything is
quantisized (at 16bit, most of the time); this, by considering
quantization noise, will give a maximum SNR you can get. With that
maximum SNR you could calculate the maximum accuracy a given frequency
estimator could achieve. And that will be your lower boundary for
frequency resolution.
TX:
exactly the same, other way around.
Overall frequency accuracy considerations
-----------------------------------------
1Hz *is* very small. At 2.45GHz, that would be 0.4 parts per billion
accuracy. The accuracy of the reference clock is (I don't have exact
numbers in my head, just putting down something intuitively good) about
50 times worse. With other words: the variation you'll see because of
your reference clock should be expected to be 50 times as big as the
steps you want to do.
Even when driving the N210 at rather low user sampling rates, for
example 1MS/s, and considering the frequency shift in baseband, a
frequency accuracy of 1ppm is something that most receiving systems try
to autonomously correct by design.
This question comes up once or twice every year, and it's always
interesting to hear the motivation behind it, so would you mind
explaining why you want to tune so finely?
Best regards,
Marcus M?ller
On 12/17/2014 10:52 AM, mahaveer gupta via USRP-users wrote:
> Hello,
>
> Could you please tell me the resolution at which I can vary the center
> frequency settings in USRP N210.
>
> For example, I can set the center frequency to be at 2.45 GHz. If I
> want to increase the center frequency by 1 Hz, I could use 2.450000001
> Hz. Not sure, how accurate the small increment would be and if it
> would make any difference at all.
>
> I know 1 Hz is very small, but would like to know the step size at
> which frequency increments would have effects
>
> --
> Thanks,
> M
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 16
Date: Wed, 17 Dec 2014 16:06:09 +0100
From: Marcus M?ller <[email protected]>
To: Brais Ares <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E110 - Detects 63MB RAM in lieu of 512 MB
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Brais,
uh oh. I'd ask to do one more thing: can you connect a PC to the serial
console USB port [1] and boot the device, and give us the output (at
least the beginning)?
For that, you would run (assuming the serial converter in the E110
appears as /dev/ttyUSB0 on your PC)
screen -L /dev/ttyUSB0 115200,cs8,-ixon,-ixoff
and get the screenlog.* of that run in the folder that you ran screen
in. To exit screen, press ctrl+a, then k, then confirm.
Greetings,
Marcus
[1]http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-connect-through-the-console-port
On 12/16/2014 11:39 PM, Brais Ares wrote:
> Hello Marcus,
>
> In order to discard that possibility, apart from switching Overo
> boards, I also tried to only switch SD cards. I've got one SD Card
> working flawless in the other E110, but putting it into the faulty
> usrp, RAM goes down to 61 MB as well.
>
> Regards,
> Brais.
>
>
> 2014-12-16 20:19 GMT+01:00 Marcus M?ller <[email protected]
> <mailto:[email protected]>>:
>
> Hello Brais,
>
> have you tried putting a clean image on the SD card? This could
> also be caused by something wrong with the way the operating
> system is loaded.
>
> Greetings,
> Marcus
>
> On 12/16/2014 08:05 PM, Brais Ares via USRP-users wrote:
>> Sorry,
>>
>> All i said applied to USRPs E110.
>>
>> 2014-12-16 19:58 GMT+01:00 Brais Ares <[email protected]
>> <mailto:[email protected]>>:
>>
>> Hello,
>>
>> I'm having trouble with one of my N210. It only detects 63 MB
>> of RAM as you can see in this pic, when this value ought to
>> be 512 MB:
>>
>> https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
>>
>> The RAM that's still left is not even enough to compile a
>> small program so that gcc throws an error.
>>
>> I moved the small PCB where the SD Card and processor are to
>> a healthy N210, and it's not healthy anymore, so the problem
>> seems to be this small PCB.
>>
>> I would appreciate any advice about this.
>>
>> Regards,
>> Brais.
>>
>> --
>>
>>
>>
>> --
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20141217/626aa5c4/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 17 Dec 2014 15:42:16 +0000 (UTC)
From: [email protected]
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] [UHD 3.8.1] Release Announcement
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Upgrading from 3.7.1, Loving dev studio 2013 libraries being added, was going
to ask about that :)
?
In the past, you have included debug distros as well, but I did not see any of
those available.
Any chance of that continuing to happen?
?
I know with earlier versions, if you mixed debug and release libraries, bad
things happen and being able to run under the debugger as you know is
invaluable...
?
Thanks,
----- Original Message -----
From: "Martin Braun via USRP-users" <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Tuesday, December 16, 2014 6:59:34 AM
Subject: [USRP-users] [UHD 3.8.1] Release Announcement
Everyone,
we've just tagged and released our first bugfix release for the 3.8 UHD
series. This release also brings changes to the FPGA code and thus we've
bumped the compat number for X- and E3-Series devices' FPGA images. We
encourage everyone to update, in particular X-Series users because we
fixed some critical data integrity issues for those devices.
You can get this release by either pulling maint branch, or checking
out the release's tag:
https://github.com/EttusResearch/uhd/tree/release_003_008_001
Binary installers will be available through our usual channels soon.
Enjoy,
Martin
## 003.008.001 Changelog:
* B2x0: Fixed PLL settings, Fixed external ref selection, serialized
??streamer setup (thread-safety)
* X3x0: Fixed flow control issue, improved DAC ctrl + init logic,
??Fixed I/Q alignment issue
* Generation-3 devices: Fixed LED registers
* UHD: Improved tuning logic for manual tunes
* Tools: Multiple kitchen sink fixes, coloured output
* Examples: Multiple bugfixes (multi-channel ops)
* Docs/Manual: Multiple fixes, E310 panel images
_______________________________________________
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/20141217/c1e911e2/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 17 Dec 2014 16:56:51 +0100
From: Brais Ares <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E110 - Detects 63MB RAM in lieu of 512 MB
Message-ID:
<cajcstajighzn0eqjelj+el+f9qmykmrs9+naifv33vrnthp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Here you go, I used PuTTY instead:
https://dl.dropboxusercontent.com/u/2696878/bootlog.txt
It's weird because it seems to recognize the 512 MB DRAM when booting...
Thank you again.
Regards.
2014-12-17 16:06 GMT+01:00 Marcus M?ller <[email protected]>:
>
> Hello Brais,
>
> uh oh. I'd ask to do one more thing: can you connect a PC to the serial
> console USB port [1] and boot the device, and give us the output (at least
> the beginning)?
> For that, you would run (assuming the serial converter in the E110 appears
> as /dev/ttyUSB0 on your PC)
>
> screen -L /dev/ttyUSB0 115200,cs8,-ixon,-ixoff
>
> and get the screenlog.* of that run in the folder that you ran screen in.
> To exit screen, press ctrl+a, then k, then confirm.
>
>
> Greetings,
> Marcus
>
> [1]
> http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-connect-through-the-console-port
>
> On 12/16/2014 11:39 PM, Brais Ares wrote:
>
> Hello Marcus,
>
> In order to discard that possibility, apart from switching Overo boards,
> I also tried to only switch SD cards. I've got one SD Card working flawless
> in the other E110, but putting it into the faulty usrp, RAM goes down to 61
> MB as well.
>
> Regards,
> Brais.
>
>
> 2014-12-16 20:19 GMT+01:00 Marcus M?ller <[email protected]>:
>>
>> Hello Brais,
>>
>> have you tried putting a clean image on the SD card? This could also be
>> caused by something wrong with the way the operating system is loaded.
>>
>> Greetings,
>> Marcus
>>
>> On 12/16/2014 08:05 PM, Brais Ares via USRP-users wrote:
>>
>> Sorry,
>>
>> All i said applied to USRPs E110.
>>
>> 2014-12-16 19:58 GMT+01:00 Brais Ares <[email protected]>:
>>>
>>> Hello,
>>>
>>> I'm having trouble with one of my N210. It only detects 63 MB of RAM as
>>> you can see in this pic, when this value ought to be 512 MB:
>>>
>>> https://dl.dropboxusercontent.com/u/2696878/usrpram.jpg
>>>
>>> The RAM that's still left is not even enough to compile a small program
>>> so that gcc throws an error.
>>>
>>> I moved the small PCB where the SD Card and processor are to a healthy
>>> N210, and it's not healthy anymore, so the problem seems to be this small
>>> PCB.
>>>
>>> I would appreciate any advice about this.
>>>
>>> Regards,
>>> Brais.
>>>
>>> --
>>>
>>>
>>
>> --
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> 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/20141217/fabc21e7/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 52, Issue 19
******************************************
