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. Building a custom RFNoC FPGA Image with the right compat
number (devin kelly)
2. Re: More B205 FPGA Acceleration Questions (Ian Buckley)
3. Re: More B205 FPGA Acceleration Questions (Martin Braun)
4. Re: Building a custom RFNoC FPGA Image with the right compat
number (Martin Braun)
5. X310 over PCIe Error enumerating NI-RIO devices
(El Ouni, Naceur (IntlAssoc))
6. loss of usb3 after trying usb2 (Samy CHBINOU)
7. Re: loss of usb3 after trying usb2 (Marcus D. Leech)
8. Re: X310 over PCIe Error enumerating NI-RIO devices
(James Humphries)
9. Re: Building a custom RFNoC FPGA Image with the right compat
number (devin kelly)
10. temp sensors and PLL lock on E310 (Jason Matusiak)
11. Re: Building a custom RFNoC FPGA Image with the right compat
number (devin kelly)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Jun 2016 14:57:52 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Building a custom RFNoC FPGA Image with the
right compat number
Message-ID:
<CAANLyuaQP5_mSdWeDEn1sARrOTEPBkFV8oHPRUaFh=wabus...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I've managed to build a custom FPGA from the rfnoc-radio-redo branch (well,
in part that branch).
I took the image I built, copied it onto my E310 and loaded it like so:
uhd_usrp_probe --args='fpga=e300.bit'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
-- Loading FPGA image: e300.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
Error: RuntimeError: Expected FPGA compatibility number 255.x, but got 16.0:
The FPGA build is not compatible with the host code build.
Please run:
....
Like the page below says to do (as an aside, why I am I using
uhd_usrp_probe on the E310 and uhd_image_loader on other USRPs?).
http://files.ettus.com/manual/page_usrp_e3x0.html
It seems the version of the FPGA image I've built doesn't match the version
of the UHD I have on my E310. I think this is because I did this:
$ git clone --recursive https://github.com/EttusResearch/uhd.git
$ cd uhd
$ git checkout -b rfnoc-radio-redo origin/rfnoc-radio-redo
instead of this:
git clone -b rfnoc-radio-redo --recursive https://
github.com/EttusResearch/uhd.git
So the version of my submodules didn't match the version of my main
module. I'm currently building the code from the second command. Since
building the FPGA image takes a while on my computer is there some way to
check what the compatibility number will be for my image before I build
it? The best I've been able to do is this:
$ pwd
/home/devin/uhd/fpga-src/usrp3/top/e300
$ find . -name '*.v' -exec grep -Hi compat {} \;
./e310_core.v: localparam RB32_CORE_COMPAT = 5'd2;
./e310_core.v: RB32_CORE_COMPAT : rb_data <= {8'hAC, 8'h0, 8'd16,
8'd0};
It's not totally clear to me if the "8'd16" in rb_data corresponds to the
16.0 compatibility number I get in my image. It seems that other USRPs
have clearer compatibility numbers, like the b200 at this link:
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b200/b200_core.v#L81
Thanks for the help,
Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160630/e567e57e/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 30 Jun 2016 13:51:00 -0700
From: Ian Buckley <[email protected]>
To: Mark Napier <[email protected]>
Cc: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] More B205 FPGA Acceleration Questions
Message-ID:
<CAM_0ocEEzbOxPEr=LNHyrmg3F=vJ0856LrspTh0T=-upeeb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
One thing in the UHD API you might both find useful is the one_packet
argument to recv, its nice for returning framed data disguised as a sample
stream.
http://files.ettus.com/manual/classuhd_1_1rx__streamer.html
On Thu, Jun 30, 2016 at 6:13 AM, Mark Napier via USRP-users <
[email protected]> wrote:
> Hey Austin,
>
> I'm working on a project using a B205 and very similar processing. I've
> tossed the idea of using any of the underlying framing from the UHD, its
> just too damn hard for me to figure out quickly and I have a tight
> schedule. I'm a hardware/DSP guy and the learning curve on this software
> stack is very steep.
>
> Instead I took Martin's advice and am working on something simple. Use
> everything the way it is. Put all our processing in the legacy radio
> block. Configure the the B205 using the UHD to get the radio clock rate
> and decimation rate we want. Do all the base band processing in hardware.
>
> At the end, the data I want to output even with all the status reporting
> is less than the configured sample rate from the B205 to the UHD. Great.
> Configure the "Over the Wire" and output data for raw fixed point 16-bit
> I/Q; that is 32-bits per sample. Make up my own frame just using the
> "samples" as a raw transport. I like a unique word followed by an
> incrementing counter and then a simple checksum at the end of the frame. A
> simple repetitive structure that is easy for software to lock onto and
> parse.
>
> Save anything harder for when I have more time (maybe never.)
>
> I would very much like to hear how you do your custom register writes and
> reads and how you wind up getting your data in and out.
>
> Cheers,
>
> Mark Napier
>
>
>
> ------------------------------
>>
>> Message: 2
>> Date: Tue, 28 Jun 2016 11:02:14 -0600
>> From: Austin Anderson <[email protected]>
>> To: "[email protected]" <[email protected]>
>> Subject: [USRP-users] More B205 FPGA Acceleration Questions
>> Message-ID:
>> <CAF30z8d6aZr9GwkMotEZRqGbkk4EnTnZKnMGgz8ky7csSPMG=
>> [email protected]>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi All,
>> I have a couple follow up questions about using the FPGA on the B205. I'm
>> planning on replacing the DUC/DDC with my own processing cores and using
>> the user setting registers for configuration/control.
>>
>> 1. I understand how to turn on the user registers and what values I'd need
>> to write where to do what I want. What I'm unclear on is how to access
>> this
>> from the host software. I can see in:
>>
>> uhd/host/lib/usrb/b200/b200_impl.cpp
>>
>> where peek/poke calls exist that I can use. I've been working with the
>> example at:
>>
>> uhd/host/examples/rx_samples_to_file.cpp
>>
>> If I add a new method to the b200_impl class, is there a straightforward
>> way to call that from the usrp object created in that example? Is adding a
>> new method the recommended approach?
>>
>> 2. The most basic processing I'd like to do is a fixed point FFT. I'd like
>> to synch up the framing of the FFT in the FPGA fabric with the framing of
>> the data on the host side. The FFT's framing can be synch'd up by pulsing
>> a
>> reset signal. Does the host-side pulse a reset to the FPGA fabric to start
>> a data transfer? If that's the case, syncing the framing should be pretty
>> easy.
>>
>> Thanks,
>> -Austin
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/e4ee6eff/attachment-0001.html
>> >
>>
>> ------------------------------
>
>
> _______________________________________________
> 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/20160630/4347c95d/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 30 Jun 2016 14:02:37 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] More B205 FPGA Acceleration Questions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/28/2016 10:02 AM, Austin Anderson via USRP-users wrote:
> Hi All,
> I have a couple follow up questions about using the FPGA on the B205.
> I'm planning on replacing the DUC/DDC with my own processing cores and
> using the user setting registers for configuration/control.
>
> 1. I understand how to turn on the user registers and what values I'd
> need to write where to do what I want. What I'm unclear on is how to
> access this from the host software. I can see in:
>
> uhd/host/lib/usrb/b200/b200_impl.cpp
>
> where peek/poke calls exist that I can use. I've been working with the
> example at:
>
> uhd/host/examples/rx_samples_to_file.cpp
>
> If I add a new method to the b200_impl class, is there a straightforward
> way to call that from the usrp object created in that example? Is adding
> a new method the recommended approach?
No, but you can add properties to the property tree. This is how we
export APIs to userland. Most properties end up being peeks/pokes in the
end.
> 2. The most basic processing I'd like to do is a fixed point FFT. I'd
> like to synch up the framing of the FFT in the FPGA fabric with the
> framing of the data on the host side. The FFT's framing can be synch'd
> up by pulsing a reset signal. Does the host-side pulse a reset to the
> FPGA fabric to start a data transfer? If that's the case, syncing the
> framing should be pretty easy.
Depending on where you want to put the FFT, there's different signals
you can use. There's a framer in the radio which outputs AXI stream
signals, which would make it trivial to hook it up to an FFT.
Cheers,
M
------------------------------
Message: 4
Date: Thu, 30 Jun 2016 14:08:06 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Building a custom RFNoC FPGA Image with the
right compat number
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/30/2016 11:57 AM, devin kelly via USRP-users wrote:
> Like the page below says to do (as an aside, why I am I using
> uhd_usrp_probe on the E310 and uhd_image_loader on other USRPs?).
Devin,
the E310 auto-loads the FPGA image every time a UHD session is
instantiated, so you don't need uhd_image_loader.
>
> http://files.ettus.com/manual/page_usrp_e3x0.html
>
> It seems the version of the FPGA image I've built doesn't match the
> version of the UHD I have on my E310. I think this is because I did this:
>
> |$ git clone --recursive https:||//github.com/EttusResearch/uhd.git
> <http://github.com/EttusResearch/uhd.git>
> |
> |$ cd uhd
> |
> |$ git checkout -b ||rfnoc-radio-redo origin/||rfnoc-radio-redo|
>
> instead of this:
>
> |git clone -b rfnoc-radio-redo --recursive
> https:||//github.com/EttusResearch/uhd.git
> <http://github.com/EttusResearch/uhd.git>
If you're using the submodule, are you running 'git submodulate update'?
Cheers,
M
>
> |
> So the version of my submodules didn't match the version of my main
> module. I'm currently building the code from the second command. Since
> building the FPGA image takes a while on my computer is there some way
> to check what the compatibility number will be for my image before I
> build it? The best I've been able to do is this:
>
> $ pwd
> /home/devin/uhd/fpga-src/usrp3/top/e300
> $ find . -name '*.v' -exec grep -Hi compat {} \;
> ./e310_core.v: localparam RB32_CORE_COMPAT = 5'd2;
> ./e310_core.v: RB32_CORE_COMPAT : rb_data <= {8'hAC, 8'h0, 8'd16,
> 8'd0};
>
> It's not totally clear to me if the "8'd16" in rb_data corresponds to
> the 16.0 compatibility number I get in my image. It seems that other
> USRPs have clearer compatibility numbers, like the b200 at this link:
>
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b200/b200_core.v#L81
>
> Thanks for the help,
> Devin
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Thu, 30 Jun 2016 22:18:59 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 over PCIe Error enumerating NI-RIO devices
Message-ID:
<sn1pr09mb092562381f09cefe989d922b9e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello all,
Today I wanted to connect to an X310 (initially an NI-2942R that I re-imaged to
be UHD-based and not LabVIEW ) through PCI Express cable.
The server from which I want to connect (Ubuntu 14.04) is ON and already had
the PCIe card connected to its motherboard.
I followed the guide in ettus's website: ("The USRP X3x0, NI USRP-294x and NI
USRP-295x devices cannot be hot-swapped when connected over PCI Express.
Unplugging the PCI Express connection or powering the device should be done
only after disabling the device or powering off the host computer.")
* X310 was OFF when I plugged the PCIe cable,
* niusrprio_pcie was on stop status prior to that.
* I plugged the cable into X310 then started the niusrprio_pcie
Next, on uhd_usrp_probe --args "resource=RIO0" I get: Device discovery error:
RuntimeError: x300_find_pcie: Error enumerating NI-RIO devices. Unknown error.
(Error code -52012)
and on uhd_image_loader --args="type=x300,resource=RIO0" I get: Error:
RuntimeError: x300_find_pcie: Error enumerating NI-RIO devices. Unknown error.
(Error code -52012)
Kernel version: 4.2.0-36-generic,
UHD version: UHD_003.010.git-202-g9e0861e1
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160630/f95e0622/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 1 Jul 2016 00:59:00 +0200
From: Samy CHBINOU <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] loss of usb3 after trying usb2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
I 've found a strange problem on my B205mini.
the uhd_usrp_probe worked fine on usb3, then I swithed to usb2 to try
with this port, it worked fine too but now when I try back with usb3 I
have the error... same after a reboot...
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
--
Best Regards - Cordialement
GreenFLOPS? EURL
Samy CHBINOU
Software Engineer - Managing Partner
T?l. 06.67.89.55.87 www.greenflops.com
------------------------------
Message: 7
Date: Thu, 30 Jun 2016 20:04:55 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] loss of usb3 after trying usb2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 06/30/2016 06:59 PM, Samy CHBINOU via USRP-users wrote:
> Hello,
>
> I 've found a strange problem on my B205mini.
>
> the uhd_usrp_probe worked fine on usb3, then I swithed to usb2 to try
> with this port, it worked fine too but now when I try back with usb3 I
> have the error... same after a reboot...
>
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
What does 'lsusb' report with the B205 plugged in? What kind of USB3
controller do you have? You can use:
lspci -v
To see what the XHCI controller type is.
------------------------------
Message: 8
Date: Thu, 30 Jun 2016 20:05:57 -0400
From: James Humphries <[email protected]>
To: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 over PCIe Error enumerating NI-RIO
devices
Message-ID:
<CAEwGFhU_HbrzNk9m0j_OW8ae1nGCYckVxx+6-9fS=-gf0qn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Naceur,
Have you tried powering on the X310 and letting it boot before you power on
the PC?
-Trip
On Thu, Jun 30, 2016 at 6:18 PM, El Ouni, Naceur (IntlAssoc) via USRP-users
<[email protected]> wrote:
> Hello all,
>
>
>
> Today I wanted to connect to an X310 (initially an NI-2942R that I
> re-imaged to be UHD-based and not LabVIEW ) through PCI Express cable.
>
> The server from which I want to connect (Ubuntu 14.04) is ON and already
> had the PCIe card connected to its motherboard.
>
>
>
> I followed the guide in ettus?s website: (?The USRP X3x0, NI USRP-294x and
> NI USRP-295x devices *cannot* be hot-swapped when connected over PCI
> Express. Unplugging the PCI Express connection or powering the device
> should be done only after disabling the device or powering off the host
> computer.?)
>
>
>
> ? X310 was OFF when I plugged the PCIe cable,
>
> ? niusrprio_pcie was on stop status prior to that.
>
> ? I plugged the cable into X310 then started the niusrprio_pcie
>
>
>
> Next, on *uhd_usrp_probe --args "resource=RIO0"* I get: Device discovery
> error: RuntimeError: x300_find_pcie: Error enumerating NI-RIO devices.
> Unknown error. (Error code -52012)
>
> and on *uhd_image_loader --args="type=x300,resource=RIO0"* I get: Error:
> RuntimeError: x300_find_pcie: Error enumerating NI-RIO devices. Unknown
> error. (Error code -52012)
>
>
>
> Kernel version: 4.2.0-36-generic,
>
> UHD version: UHD_003.010.git-202-g9e0861e1
>
>
>
> Thanks and Regards,
>
>
>
> Naceur El Ouni
>
> NIST - Wireless Networks Division (673)
>
> 100 Bureau Dr. Building 222-A218
>
> Gaithersburg, MD 20899
>
> (301) 975-3353
>
>
>
> _______________________________________________
> 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/20160630/3891e482/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 1 Jul 2016 08:56:56 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] Building a custom RFNoC FPGA Image with the
right compat number
Message-ID:
<caanlyuzawy+qqccmovfzjg9rpcclsgfmtcsrm7o9sz8sjmn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I made sure my submodules matched the branch of my main module repo and
that worked ok. I also checked e310_core.v and the third item was "8'd255"
which matches what I was looking for. However I now have a new problem
uhd_usrp_probe --args='fpga=e300.bit'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
-- Loading FPGA image: e300.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Setting up dest map for ep 0 to be stream 1
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_0/ports/out/0
-- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/A/connection == IQ
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/A/connection == IQ
-- Setting up dest map for ep 1 to be stream 4
-- Performing register loopback test... Error: EnvironmentError: IOError:
Radio ctrl (1) no response packet - AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at
/home/balister/fido-rfnoc-test/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.1.51-r0/git/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
A co-worker tells me he's had this problem before and the cause was the
FPGA code being further along than UHD C++ code. The FPGA code I'm
building is the latest rfnoc-radio-redo (b62d96c) and the E310 image I'm
using is this one:
# cat /etc/version-image
Timestamp: 201511241931
Release:
Image: gnuradio-dev-image
Which I'm pretty sure I got from here:
http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/
Do I need to use older FPGA sources? Is there any way of knowing how far
back I have to go?
Thanks again,
Devin
On Thu, Jun 30, 2016 at 5:08 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 06/30/2016 11:57 AM, devin kelly via USRP-users wrote:
> > Like the page below says to do (as an aside, why I am I using
> > uhd_usrp_probe on the E310 and uhd_image_loader on other USRPs?).
>
> Devin,
>
> the E310 auto-loads the FPGA image every time a UHD session is
> instantiated, so you don't need uhd_image_loader.
>
> >
> > http://files.ettus.com/manual/page_usrp_e3x0.html
> >
> > It seems the version of the FPGA image I've built doesn't match the
> > version of the UHD I have on my E310. I think this is because I did
> this:
> >
> > |$ git clone --recursive https:||//github.com/EttusResearch/uhd.git
> > <http://github.com/EttusResearch/uhd.git>
> > |
> > |$ cd uhd
> > |
> > |$ git checkout -b ||rfnoc-radio-redo origin/||rfnoc-radio-redo|
> >
> > instead of this:
> >
> > |git clone -b rfnoc-radio-redo --recursive
> > https:||//github.com/EttusResearch/uhd.git
> > <http://github.com/EttusResearch/uhd.git>
>
> If you're using the submodule, are you running 'git submodulate update'?
>
> Cheers,
> M
> >
> > |
> > So the version of my submodules didn't match the version of my main
> > module. I'm currently building the code from the second command. Since
> > building the FPGA image takes a while on my computer is there some way
> > to check what the compatibility number will be for my image before I
> > build it? The best I've been able to do is this:
> >
> > $ pwd
> > /home/devin/uhd/fpga-src/usrp3/top/e300
> > $ find . -name '*.v' -exec grep -Hi compat {} \;
> > ./e310_core.v: localparam RB32_CORE_COMPAT = 5'd2;
> > ./e310_core.v: RB32_CORE_COMPAT : rb_data <= {8'hAC, 8'h0, 8'd16,
> > 8'd0};
> >
> > It's not totally clear to me if the "8'd16" in rb_data corresponds to
> > the 16.0 compatibility number I get in my image. It seems that other
> > USRPs have clearer compatibility numbers, like the b200 at this link:
> >
> >
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b200/b200_core.v#L81
> >
> > Thanks for the help,
> > Devin
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [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/20160701/5dc41630/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 1 Jul 2016 09:22:20 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] temp sensors and PLL lock on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Talking with Ben yesterday, we realized that we probably need to be
monitoring the two temp sensors that UHD has access to on the E310 as
well as the digital PLL lock to try to narrow down some inconsistencies
we are seeing in our TDOA work that we can't figure out if it is on us
or a potential bug in the E310.
I've done a little research, but come up blank. What is the easiest way
to query the two temp sensors on the E310?
And is there a way to monitor the digital PLL to make sure it hasn't
lost lock for some reason?
TIA!!!
------------------------------
Message: 11
Date: Fri, 1 Jul 2016 09:22:35 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] Building a custom RFNoC FPGA Image with the
right compat number
Message-ID:
<caanlyua80_8hnx-esud+ohjdpdcpufrc2emwrzpssusubbk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
OK, I've tried building some more FPGA images and I'm still having problems:
root@ettus-e300:~# uhd_usrp_probe --args='fpga=usrp_e310_fpga_RFNOC.bit'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
-- Loading FPGA image: usrp_e310_fpga_RFNOC.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Setting up dest map for ep 0 to be stream 1
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_0/ports/out/0
-- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/A/connection == IQ
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/A/connection == IQ
-- Setting up dest map for ep 1 to be stream 4
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_1/ports/out/0
-- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_1] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/B/connection == IQ
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/B/connection == IQ
-- Performing CODEC loopback test... fail
Error: RuntimeError: CODEC loopback test failed.
root@ettus-e300:~# uhd_usrp_probe
--args='fpga=e300.bit'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
-- Loading FPGA image: e300.bit... done
Error: RuntimeError: [ad9361_device_t] BBPLL not locked
I suspect these are both related to having my UHD library and FPGA image
being out of sync. I noticed someone else having this issue (CODEC
loopback test failed) with their E310 on the mailing list earlier but there
wasn't a resolution.
Devin
On Fri, Jul 1, 2016 at 8:56 AM, devin kelly <[email protected]> wrote:
> I made sure my submodules matched the branch of my main module repo and
> that worked ok. I also checked e310_core.v and the third item was "8'd255"
> which matches what I was looking for. However I now have a new problem
>
> uhd_usrp_probe --args='fpga=e300.bit'
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-0-unknown
>
> -- Loading FPGA image: e300.bit... done
> -- Detecting internal GPSDO .... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Setting up dest map for ep 0 to be stream 1
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type =
> '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_0/ports/out/0
> -- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/A/connection == IQ
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/A/connection == IQ
> -- Setting up dest map for ep 1 to be stream 4
> -- Performing register loopback test... Error: EnvironmentError: IOError:
> Radio ctrl (1) no response packet - AssertionError: bool(buff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
> /home/balister/fido-rfnoc-test/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.1.51-r0/git/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>
> A co-worker tells me he's had this problem before and the cause was the
> FPGA code being further along than UHD C++ code. The FPGA code I'm
> building is the latest rfnoc-radio-redo (b62d96c) and the E310 image I'm
> using is this one:
>
> # cat /etc/version-image
> Timestamp: 201511241931
> Release:
> Image: gnuradio-dev-image
>
>
> Which I'm pretty sure I got from here:
> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/
>
> Do I need to use older FPGA sources? Is there any way of knowing how far
> back I have to go?
>
> Thanks again,
> Devin
>
>
> On Thu, Jun 30, 2016 at 5:08 PM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> On 06/30/2016 11:57 AM, devin kelly via USRP-users wrote:
>> > Like the page below says to do (as an aside, why I am I using
>> > uhd_usrp_probe on the E310 and uhd_image_loader on other USRPs?).
>>
>> Devin,
>>
>> the E310 auto-loads the FPGA image every time a UHD session is
>> instantiated, so you don't need uhd_image_loader.
>>
>> >
>> > http://files.ettus.com/manual/page_usrp_e3x0.html
>> >
>> > It seems the version of the FPGA image I've built doesn't match the
>> > version of the UHD I have on my E310. I think this is because I did
>> this:
>> >
>> > |$ git clone --recursive https:||//github.com/EttusResearch/uhd.git
>> > <http://github.com/EttusResearch/uhd.git>
>> > |
>> > |$ cd uhd
>> > |
>> > |$ git checkout -b ||rfnoc-radio-redo origin/||rfnoc-radio-redo|
>> >
>> > instead of this:
>> >
>> > |git clone -b rfnoc-radio-redo --recursive
>> > https:||//github.com/EttusResearch/uhd.git
>> > <http://github.com/EttusResearch/uhd.git>
>>
>> If you're using the submodule, are you running 'git submodulate update'?
>>
>> Cheers,
>> M
>> >
>> > |
>> > So the version of my submodules didn't match the version of my main
>> > module. I'm currently building the code from the second command. Since
>> > building the FPGA image takes a while on my computer is there some way
>> > to check what the compatibility number will be for my image before I
>> > build it? The best I've been able to do is this:
>> >
>> > $ pwd
>> > /home/devin/uhd/fpga-src/usrp3/top/e300
>> > $ find . -name '*.v' -exec grep -Hi compat {} \;
>> > ./e310_core.v: localparam RB32_CORE_COMPAT = 5'd2;
>> > ./e310_core.v: RB32_CORE_COMPAT : rb_data <= {8'hAC, 8'h0, 8'd16,
>> > 8'd0};
>> >
>> > It's not totally clear to me if the "8'd16" in rb_data corresponds to
>> > the 16.0 compatibility number I get in my image. It seems that other
>> > USRPs have clearer compatibility numbers, like the b200 at this link:
>> >
>> >
>> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b200/b200_core.v#L81
>> >
>> > Thanks for the help,
>> > Devin
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [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/20160701/e9111909/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 71, Issue 1
*****************************************
