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: RFNoC Signal Generator extension (Jonathon Pendlum)
2. " usrp_e310_fpga_sg3.bit" vs "usrp_e3xx_fpga_idle_sg3.bit"
for E312 (Xingjian Chen)
3. USRP X310 Link Down with Intel X710-DA4 and Ubuntu 16.04.02
(Gilad Beeri (ApolloShield))
4. Re: USRP X310 Link Down with Intel X710-DA4 and Ubuntu
16.04.02 (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Sat, 11 Mar 2017 15:27:33 -0600
From: Jonathon Pendlum <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Signal Generator extension
Message-ID:
<CAGdo0uQ=cv3oas8je4k9qwrqff6qtdoi2e-ks4yympqb4ot...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
Such a block does not exist yet. 100K samples would be on the order of
400KB of BRAM on the device. There is enough free BRAM on a X310 device to
fit that and using BRAM would be the easier approach versus using DRAM. To
fill the BRAM, you could either use a regular data stream or use control
packets. I would suggest using the data stream since you will be moving a
large amount of data.
Jonathon
On Wed, Mar 8, 2017 at 9:35 AM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Hi,
> I am looking to extend the RFNoC Signal Generator block or create a new
> block to provide capability for transmission of arbitrary I/Q data (finite
> length record which gets repeated) from the FPGA. Such a block would
> enable transmission of arbitrary data at 160 MHz bandwidth on both channels
> (X310/UBX160) which presently is not really possible (see other posts about
> transmitting at 200 MS/s even on one channel). Also, it would free up CPU
> cycles from having to send this finite block over and over.
>
> I am considering reserving a block of FPGA memory to hold the samples or
> alternatively using DRAM for this purpose. I am considering a ballpark
> sample depth of perhaps 100K samples. Before diving deeply into it, I am
> wondering if such a block already exists. If not, I am wondering if anyone
> has advice on the best way to implement this capability.
>
> Thanks.
> Rob
>
> _______________________________________________
> 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/20170311/c197cb38/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 11 Mar 2017 23:56:23 +0000
From: Xingjian Chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] " usrp_e310_fpga_sg3.bit" vs
"usrp_e3xx_fpga_idle_sg3.bit" for E312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am using E312 and going to play with its fpga scripts. I think there are two
.bit files generated for E312 after typing "make" in
uhd/fpga-src/usrp3/top/e300. They are " usrp_e310_fpga_sg3.bit" and
"usrp_e3xx_fpga_idle_sg3.bit". And my E312 loads "usrp_e310_fpga_sg3.bit" by
default. My question is what is the difference between the two .bit files? What
is idle mean? Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170311/42c325dd/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 12 Mar 2017 11:38:54 +0000
From: "Gilad Beeri (ApolloShield)" <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] USRP X310 Link Down with Intel X710-DA4 and
Ubuntu 16.04.02
Message-ID:
<CAF4UVpDAy-z737U0EFQsgrjcLagvd+Gv+kCgjW=jHb=zy0x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I have a USRP X310, Ubuntu 16.04.02 and an Intel X710-DA4 with Intel's SFP+
cables.
i40e version: 1.6.42
firmware-version (NIC): 5.05 0x8000289d 1.1568.0
The cable is connected to port 1 in the USRP, and the interface in Ubuntu
is configured statically with IP 192.168.40.1/24.
The problem: the link is seldom up.
"ip addr show enp1s0f0" says that the enp1s0f0 is UP (ifconfig says that
also), but "state DOWN", and that it is configured properly with the static
IP address
"dmesg | grep enp1s0f0" shows "IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is
not ready".
After some long random time, the link/state goes UP and everything is ok
(pings to USRP work), but not always, and only after I do an arbitrary set
of "ifconfig down/up" commands, incl. USRP/host reboots.
I tried 2 different cables (both new).
When connecting a SFP+/RJ45 adapter to the X710, and 1 GigE Ethernet cable
(other side connected to the wall - LAN), it works perfectly.
I don't have another 10 GigE device so I can't compare and connect it to
the NIC, to determine whether the problem is in the NIC when it tries to
work in 10 GigE mode (because in 1 GigE mode it worked - with the LAN), in
the USRP, or in the cables.
Any ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170312/ba309a03/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 12 Mar 2017 12:42:34 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP X310 Link Down with Intel X710-DA4 and
Ubuntu 16.04.02
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Gilad,
how exactly are you configuring the IP address of the interface?
NetworkManager has the tendency to override manually made user settings
if not made through the NetworkManager interface.
Best regards,
Marcus
On 12.03.2017 12:38, Gilad Beeri (ApolloShield) via USRP-users wrote:
> Hello,
> I have a USRP X310, Ubuntu 16.04.02 and an Intel X710-DA4 with Intel's
> SFP+ cables.
> i40e version: 1.6.42
> firmware-version (NIC): 5.05 0x8000289d 1.1568.0
> The cable is connected to port 1 in the USRP, and the interface in
> Ubuntu is configured statically with IP 192.168.40.1/24
> <http://192.168.40.1/24>.
>
> The problem: the link is seldom up.
> "ip addr show enp1s0f0" says that the enp1s0f0 is UP (ifconfig says
> that also), but "state DOWN", and that it is configured properly with
> the static IP address
>
> "dmesg | grep enp1s0f0" shows "IPv6: ADDRCONF(NETDEV_UP): enp1s0f0:
> link is not ready".
>
> After some long random time, the link/state goes UP and everything is
> ok (pings to USRP work), but not always, and only after I do an
> arbitrary set of "ifconfig down/up" commands, incl. USRP/host reboots.
>
> I tried 2 different cables (both new).
>
> When connecting a SFP+/RJ45 adapter to the X710, and 1 GigE Ethernet
> cable (other side connected to the wall - LAN), it works perfectly.
>
> I don't have another 10 GigE device so I can't compare and connect it
> to the NIC, to determine whether the problem is in the NIC when it
> tries to work in 10 GigE mode (because in 1 GigE mode it worked - with
> the LAN), in the USRP, or in the cables.
>
> Any ideas?
>
>
>
>
> _______________________________________________
> 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/20170312/232f461a/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 79, Issue 12
******************************************
