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: USRP X310 Link Down with Intel X710-DA4 and Ubuntu
16.04.02 (Gilad Beeri (ApolloShield))
2. Re: b200_main.c (Jason Matusiak)
3. Re: b200_main.c (Ian Buckley)
4. Rfnoc - Accessing DMA FIFO Block Ctrl Class (Samuel Prager)
5. Re: b200_main.c (Jason Matusiak)
6. Re: b200_main.c (Jason Matusiak)
7. Re: b200_main.c (Ian Buckley)
8. Rfnoc siggen offset freq (Tobias Mitterer)
9. Expexted FPGA compatibility number 255.x, but got 14.0 (do ber)
10. Re: USRP X310 Link Down with Intel X710-DA4 and Ubuntu
16.04.02 (Neel Pandeya)
11. Re: Expexted FPGA compatibility number 255.x, but got 14.0
(Marcus M?ller)
12. Re: Rfnoc siggen offset freq (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Mar 2017 16:15:35 +0000
From: "Gilad Beeri (ApolloShield)" <[email protected]>
To: usrp-users <[email protected]>, Neel Pandeya
<[email protected]>, [email protected]
Subject: Re: [USRP-users] USRP X310 Link Down with Intel X710-DA4 and
Ubuntu 16.04.02
Message-ID:
<CAF4UVpAr=ubs4zoHhKTub5Sk=wldjjoqrr1+z_qsv4azqmg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Neel,
I'll try using NM and revert. I actually understood Marcus's comment the
opposite (as in "make sure you don't use NM").
I thought that Ettus advises the opposite - avoid using NM:
https://files.ettus.com/manual/page_usrp_x3x0_config.html#x3x0cfg_hostpc_netcfg_nwmgr
writes "Unfortunately, NetworkManager often tries to take control of a
connection and will disconnect the interface.
You should open your NetworkManager configuration and tell it to ignore the
network interface you are using."
---------- Forwarded message ----------
From: Neel Pandeya <[email protected]>
To: "Marcus M?ller" <[email protected]>
Cc: usrp-users <[email protected]>
Bcc:
Date: Sun, 12 Mar 2017 09:30:23 -0700
Subject: Re: [USRP-users] USRP X310 Link Down with Intel X710-DA4 and
Ubuntu 16.04.02
Hello Gilad:
Yeah, as Marcus said, set the IP address of the host via NetworkManager,
not from the command line. The default IP address of the X310 for 10 GbE is
192.168.40.2.
Are you using the latest version of the i40e driver? Did you get it from
the Intel website?
--Neel Pandeya
On Mon, Mar 13, 2017 at 4:25 PM Gilad Beeri (ApolloShield) <
[email protected]> wrote:
> Hi Marcus,
> I disabled NM for this NIC and configured static ip.
> See below /etc/NetworkManager/NetworkManager.conf and /etc/network
> interfaces (the unmanaged-devices key is actually redundant as NM won't
> manage an interface from /etc/network/interfaces given the managed=false in
> the ifupdown section).
>
> The NIC itself holds on to its static 192.168.40.1 IP well so I don't
> think it's an issue with NM. The IP seems to be configured well, the
> interface is up, but the state is DOWN. Not sure what the "state" in "ip
> addr show"'s output means but I think it's related to 2-sided links.
>
> When I put the SFP+/RJ45 adapter in USRP X Port 1, and connect it with a
> normal (not 10 GigE) Ethernet cable to my motherboard's Ethernet port
> (bypassing X710), stopping NM (sudo service NetworkManager stop),
> configuring the IP to the motherboard's NIC ("sudo ifconfig enp1s0f0 down"
> - avoid collisions - and then "sudo ip addr add 192.168.40.1/24 dev
> enp3s0"), verifying the IP is configured with the NIC, I still don't get
> pongs from the USRP, and Wireshark shows the USRP doesn't respond to ARP
> requests.
> BUT, in this case, "ip addr show" says the state is "UP" (maybe the OS
> treats differently links based on RJ45 vs. SFP+).
>
> I did a similar test with port 0 and IP 192.168.30.1/24 (I have the XG
> firmware installed), still no luck.
>
> I believe the above indicates the problem isn't with the X710 or its
> drivers, and probably also not with the SFP+ cables, but with the USRP
> itself, or its configuration in the host computer.
>
> The promised config files:
>
> /etc/NetworkManager/NetworkManager.conf:
> [main]
> plugins=ifupdown,keyfile,ofono
> dns=dnsmasq
>
> [ifupdown]
> managed=false
>
> [keyfile]
> unmanaged-devices=interface-name:enp1s0*
>
>
> /etc/network/interfaces:
> auto lo
> iface lo inet loopback
>
> auto enp1s0f0
> iface enp1s0f0 inet static
> address 192.168.40.1
> netmask 255.255.255.0
> gateway 0.0.0.0
>
> ---------- Forwarded message ---------
> From: <[email protected]>
> Date: Sun, Mar 12, 2017 at 8:57 PM
> Subject: USRP-users Digest, Vol 79, Issue 12
> To: <[email protected]>
>
>
>
> 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=
> [email protected]>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170313/4c15d9b6/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 13 Mar 2017 12:33:14 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200_main.c
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I just noticed the second to last check-in for that branch (back in
2015) talks about adding in logging that can be used on the "B200
side-channel utility (using UART or directly over USB)".
Digging around I see the utility in the src/uhd/host/utils directory. I
pip installed pyusb. I then did a uhd_usrp_probe to get the latest
firmware updated on the FPGA.
What I don't know, is how to I use the UART option. Is it a serial
connection over the USB, or is there a direct serial (which I could not
find in the schematics).
On 03/13/2017 11:31 AM, Jason Matusiak wrote:
> I was looking for something else and stumbled upon the b200_main.c
> file in the uhd/firmware/fx3/b200 folder. Looking into it, it seems
> to have the setup of the FX3 chip (which is what I thought it was
> doing based on the folder it is in), but it also prints out some debug
> messages.
>
> Based on my earlier B200mini MotoZ problem, I wouldn't mind seeing
> some of the debug (or adding some of my own) of what is really going
> on, but I am not sure where those messages would be printed out to.
> Are they just going out the JTAG port (which I don't have an adapter
> for)?
------------------------------
Message: 3
Date: Mon, 13 Mar 2017 10:44:18 -0700
From: Ian Buckley <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200_main.c
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Jason,
I wrote this a while ago so my memory might be a little hazy?.The UART path
passed the logging transactions over an I2C interface from FX3 to FPGA. In the
FPGA the I2C commands were briefly expanded to a parallel memory mapped bus
format where they drove a UART that put the logging on the J400 header at 1.8V
levels I think. You would need to build the FPGA with DEBUG_UART asserted to
have the UART enabled (These pins default to GPIO).
I forget how logging over USB might work.
-Ian
On Mar 13, 2017, at 9:33 AM, Jason Matusiak via USRP-users
<[email protected]> wrote:
> I just noticed the second to last check-in for that branch (back in 2015)
> talks about adding in logging that can be used on the "B200 side-channel
> utility (using UART or directly over USB)".
>
> Digging around I see the utility in the src/uhd/host/utils directory. I pip
> installed pyusb. I then did a uhd_usrp_probe to get the latest firmware
> updated on the FPGA.
>
> What I don't know, is how to I use the UART option. Is it a serial
> connection over the USB, or is there a direct serial (which I could not find
> in the schematics).
>
>
> On 03/13/2017 11:31 AM, Jason Matusiak wrote:
>> I was looking for something else and stumbled upon the b200_main.c file in
>> the uhd/firmware/fx3/b200 folder. Looking into it, it seems to have the
>> setup of the FX3 chip (which is what I thought it was doing based on the
>> folder it is in), but it also prints out some debug messages.
>>
>> Based on my earlier B200mini MotoZ problem, I wouldn't mind seeing some of
>> the debug (or adding some of my own) of what is really going on, but I am
>> not sure where those messages would be printed out to. Are they just going
>> out the JTAG port (which I don't have an adapter for)?
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Mon, 13 Mar 2017 11:47:13 -0700
From: Samuel Prager <[email protected]>
To: Ryan Marlow via USRP-users <[email protected]>
Subject: [USRP-users] Rfnoc - Accessing DMA FIFO Block Ctrl Class
Message-ID: <c40db8c8-2d02-4657-a5c2-acf3241ba410@Spark>
Content-Type: text/plain; charset="utf-8"
Hello,
I am interested in resizing the DMA fifo block, but see that the
"dma_fifo_block_ctrl.hpp" header file is not installed along with the rest of
the rfnoc component install headers. Is there a reason for this? What is the
maximum possible DMA fifo size for the x300?
I am using an underpowered host (microcontroller w/ 2 Gb ram) to receive a 4096
length sample burst at full rate 200msps. Ideally, these samples would all be
buffered into the DMA fifo and then offloaded as the host becomes ready.
Currently I am trying to receive a single 4096 sample burst. After ~1820
samples, however I begin to get receive errors: ERROR_CODE_TIMEOUT.
I would expect that with the default size of 32*1024*1024 the DMA fifo would
have no issue buffering all 4096 samples.
Could someone please provide guidance on how such performance might be achieved?
My current setup:
Radio rx -> fifo 1 -> DMA fifo -> fifo 2 -> host
Thank you,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170313/c772e5ff/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 13 Mar 2017 15:16:57 -0400
From: Jason Matusiak <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200_main.c
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Thank you for the info Ian. The I2C lines are tied to an EEPROM, so I
think that they are just for loading an image of some kind (or off-site
storage).
From the b200_main.h, it looks like these are the pins used to pass
data to the FPGA:
#define GPIO_FPGA_SB_SCL (uint32_t)(25) // CTL[8] --> K19 on
the FPGA
#define GPIO_FPGA_SB_SDA (uint32_t)(23) // CTL[6] --> H22 on
the FPGA
Looking at the .ucf for the B205 (b205.ucf) it appears that those are
called FX3_CTL6 and FX3_CTL8 in the project. And the only thing that
happens to them in b205.v is that they get passed to: the
gpif2_slave_fifo32 mopdule. Inside of there, nothing is done with those
two pins.
Do you think that the capabilities were maybe removed at some point?
~Jason
On 03/13/2017 01:44 PM, Ian Buckley wrote:
> Jason,
> I wrote this a while ago so my memory might be a little hazy?.The UART path
> passed the logging transactions over an I2C interface from FX3 to FPGA. In
> the FPGA the I2C commands were briefly expanded to a parallel memory mapped
> bus format where they drove a UART that put the logging on the J400 header
> at 1.8V levels I think. You would need to build the FPGA with DEBUG_UART
> asserted to have the UART enabled (These pins default to GPIO).
>
> I forget how logging over USB might work.
>
> -Ian
>
> On Mar 13, 2017, at 9:33 AM, Jason Matusiak via USRP-users
> <[email protected]> wrote:
>
>> I just noticed the second to last check-in for that branch (back in 2015)
>> talks about adding in logging that can be used on the "B200 side-channel
>> utility (using UART or directly over USB)".
>>
>> Digging around I see the utility in the src/uhd/host/utils directory. I pip
>> installed pyusb. I then did a uhd_usrp_probe to get the latest firmware
>> updated on the FPGA.
>>
>> What I don't know, is how to I use the UART option. Is it a serial
>> connection over the USB, or is there a direct serial (which I could not find
>> in the schematics).
>>
>>
>> On 03/13/2017 11:31 AM, Jason Matusiak wrote:
>>> I was looking for something else and stumbled upon the b200_main.c file in
>>> the uhd/firmware/fx3/b200 folder. Looking into it, it seems to have the
>>> setup of the FX3 chip (which is what I thought it was doing based on the
>>> folder it is in), but it also prints out some debug messages.
>>>
>>> Based on my earlier B200mini MotoZ problem, I wouldn't mind seeing some of
>>> the debug (or adding some of my own) of what is really going on, but I am
>>> not sure where those messages would be printed out to. Are they just going
>>> out the JTAG port (which I don't have an adapter for)?
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Mon, 13 Mar 2017 15:24:06 -0400
From: Jason Matusiak <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200_main.c
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
I just noticed, it looks like the b200.v has a #ifdef DEBUG_UART, but
that is nowhere to be found in the b205.v project.
So I think that it was never ported over to the B205 from the B2x0
line. I wonder if it is no longer usable given the current state of the
B205's firmware (assuming it is different for some reason)....
On 03/13/2017 03:16 PM, Jason Matusiak wrote:
> Thank you for the info Ian. The I2C lines are tied to an EEPROM, so I
> think that they are just for loading an image of some kind (or
> off-site storage).
>
> From the b200_main.h, it looks like these are the pins used to pass
> data to the FPGA:
> #define GPIO_FPGA_SB_SCL (uint32_t)(25) // CTL[8] --> K19
> on the FPGA
> #define GPIO_FPGA_SB_SDA (uint32_t)(23) // CTL[6] --> H22
> on the FPGA
>
> Looking at the .ucf for the B205 (b205.ucf) it appears that those are
> called FX3_CTL6 and FX3_CTL8 in the project. And the only thing that
> happens to them in b205.v is that they get passed to: the
> gpif2_slave_fifo32 mopdule. Inside of there, nothing is done with
> those two pins.
>
> Do you think that the capabilities were maybe removed at some point?
>
> ~Jason
>
> On 03/13/2017 01:44 PM, Ian Buckley wrote:
>> Jason,
>> I wrote this a while ago so my memory might be a little hazy?.The
>> UART path passed the logging transactions over an I2C interface from
>> FX3 to FPGA. In the FPGA the I2C commands were briefly expanded to a
>> parallel memory mapped bus format where they drove a UART that put
>> the logging on the J400 header at 1.8V levels I think. You would
>> need to build the FPGA with DEBUG_UART asserted to have the UART
>> enabled (These pins default to GPIO).
>>
>> I forget how logging over USB might work.
>>
>> -Ian
>>
>> On Mar 13, 2017, at 9:33 AM, Jason Matusiak via USRP-users
>> <[email protected]> wrote:
>>
>>> I just noticed the second to last check-in for that branch (back in
>>> 2015) talks about adding in logging that can be used on the "B200
>>> side-channel utility (using UART or directly over USB)".
>>>
>>> Digging around I see the utility in the src/uhd/host/utils
>>> directory. I pip installed pyusb. I then did a uhd_usrp_probe to
>>> get the latest firmware updated on the FPGA.
>>>
>>> What I don't know, is how to I use the UART option. Is it a serial
>>> connection over the USB, or is there a direct serial (which I could
>>> not find in the schematics).
>>>
>>>
>>> On 03/13/2017 11:31 AM, Jason Matusiak wrote:
>>>> I was looking for something else and stumbled upon the b200_main.c
>>>> file in the uhd/firmware/fx3/b200 folder. Looking into it, it
>>>> seems to have the setup of the FX3 chip (which is what I thought it
>>>> was doing based on the folder it is in), but it also prints out
>>>> some debug messages.
>>>>
>>>> Based on my earlier B200mini MotoZ problem, I wouldn't mind seeing
>>>> some of the debug (or adding some of my own) of what is really
>>>> going on, but I am not sure where those messages would be printed
>>>> out to. Are they just going out the JTAG port (which I don't have
>>>> an adapter for)?
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 7
Date: Mon, 13 Mar 2017 12:49:37 -0700
From: Ian Buckley <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200_main.c
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Jason,
I didn't realize that you were using B205. Yes, I didn't write the code in
B205.v but it's all based off the B2x0 code base. The FX3-CTL6 and FX3-CTL8
pins are still connected between FPGA and FX3 on B205 (though they use
different FPGA balls) and available for you to use. You would then steal a
couple of unused pins that go to B205 board headers and drop in this piece of
code from b200_core.v which de-serializes the bus transactions and instantiates
the UART. (BTW I spoke incorrectly, on reviewing this code I realize I used I2C
style signal names but the actual protocol coming from the FX3 is a serialized
version of Ettus's setting_bus thats being bit banged by software.).
====
/*******************************************************************
* Debug UART for FX3
******************************************************************/
wire debug_stb;
wire [31:0] debug_data;
wire [7:0] debug_addr;
wire [31:0] debug_serial;
serial_to_settings serial_to_settings_i1
(
.clk(bus_clk),
.reset(bus_rst),
.scl(debug_scl),
.sda(debug_sda),
.set_stb(debug_stb),
.set_addr(debug_addr),
.set_data(debug_data),
.debug(debug_serial)
);
// Nasty Hack to convert settings to wishbone crudely.
reg wb_stb;
wire wb_ack_o;
always @(posedge bus_clk)
wb_stb <= debug_stb ? 1 : ((wb_ack_o) ? 0 : wb_stb);
simple_uart debug_uart
(
.clk_i(bus_clk),
.rst_i(bus_rst),
.we_i(wb_stb),
.stb_i(wb_stb),
.cyc_i(wb_stb),
.ack_o(wb_ack_o),
.adr_i(debug_addr[2:0]),
.dat_i(debug_data[31:0]),
.dat_o(),
.rx_int_o(),
.tx_int_o(),
.tx_o(debug_txd),
.rx_i(debug_rxd),
.baud_o()
);
-Ian
On Mar 13, 2017, at 12:24 PM, Jason Matusiak <[email protected]>
wrote:
> I just noticed, it looks like the b200.v has a #ifdef DEBUG_UART, but that is
> nowhere to be found in the b205.v project.
>
> So I think that it was never ported over to the B205 from the B2x0 line. I
> wonder if it is no longer usable given the current state of the B205's
> firmware (assuming it is different for some reason)....
>
>
> On 03/13/2017 03:16 PM, Jason Matusiak wrote:
>> Thank you for the info Ian. The I2C lines are tied to an EEPROM, so I think
>> that they are just for loading an image of some kind (or off-site storage).
>>
>> From the b200_main.h, it looks like these are the pins used to pass data to
>> the FPGA:
>> #define GPIO_FPGA_SB_SCL (uint32_t)(25) // CTL[8] --> K19 on the
>> FPGA
>> #define GPIO_FPGA_SB_SDA (uint32_t)(23) // CTL[6] --> H22 on the
>> FPGA
>>
>> Looking at the .ucf for the B205 (b205.ucf) it appears that those are called
>> FX3_CTL6 and FX3_CTL8 in the project. And the only thing that happens to
>> them in b205.v is that they get passed to: the gpif2_slave_fifo32 mopdule.
>> Inside of there, nothing is done with those two pins.
>>
>> Do you think that the capabilities were maybe removed at some point?
>>
>> ~Jason
>>
>> On 03/13/2017 01:44 PM, Ian Buckley wrote:
>>> Jason,
>>> I wrote this a while ago so my memory might be a little hazy?.The UART path
>>> passed the logging transactions over an I2C interface from FX3 to FPGA. In
>>> the FPGA the I2C commands were briefly expanded to a parallel memory mapped
>>> bus format where they drove a UART that put the logging on the J400 header
>>> at 1.8V levels I think. You would need to build the FPGA with DEBUG_UART
>>> asserted to have the UART enabled (These pins default to GPIO).
>>>
>>> I forget how logging over USB might work.
>>>
>>> -Ian
>>>
>>> On Mar 13, 2017, at 9:33 AM, Jason Matusiak via USRP-users
>>> <[email protected]> wrote:
>>>
>>>> I just noticed the second to last check-in for that branch (back in 2015)
>>>> talks about adding in logging that can be used on the "B200 side-channel
>>>> utility (using UART or directly over USB)".
>>>>
>>>> Digging around I see the utility in the src/uhd/host/utils directory. I
>>>> pip installed pyusb. I then did a uhd_usrp_probe to get the latest
>>>> firmware updated on the FPGA.
>>>>
>>>> What I don't know, is how to I use the UART option. Is it a serial
>>>> connection over the USB, or is there a direct serial (which I could not
>>>> find in the schematics).
>>>>
>>>>
>>>> On 03/13/2017 11:31 AM, Jason Matusiak wrote:
>>>>> I was looking for something else and stumbled upon the b200_main.c file
>>>>> in the uhd/firmware/fx3/b200 folder. Looking into it, it seems to have
>>>>> the setup of the FX3 chip (which is what I thought it was doing based on
>>>>> the folder it is in), but it also prints out some debug messages.
>>>>>
>>>>> Based on my earlier B200mini MotoZ problem, I wouldn't mind seeing some
>>>>> of the debug (or adding some of my own) of what is really going on, but I
>>>>> am not sure where those messages would be printed out to. Are they just
>>>>> going out the JTAG port (which I don't have an adapter for)?
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
------------------------------
Message: 8
Date: Tue, 14 Mar 2017 13:30:07 +0100
From: Tobias Mitterer <[email protected]>
To: [email protected]
Subject: [USRP-users] Rfnoc siggen offset freq
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170314/039dcf1e/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 14 Mar 2017 15:57:50 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: [USRP-users] Expexted FPGA compatibility number 255.x, but
got 14.0
Message-ID:
<cabldf_ftgwz4-5xnayhgwldgkiabhvlyyhvjm8ngm5bz1g-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi to all,
I am currently working on E312. My final goal is to control an e312(if
possible multi e312 in the future) with GNURadio companion.
I installed SDK. I am following the steps written in here:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
I am in the "running the new UHD via sshfs section"
I am seeing and using newly compiled
UHD(/home/root/usr/bin/uhd_find_devices). So it is ok up to here.
When I wrote:
*~/usr/usr/lib/uhd/examples/benchmark_rate --tx_rate 1e6*
I got:
*Error: RuntimeError: Expexted FPGA compatibility number 255.x, but got
14.0: The FPGA build is not compatible with the host code build.*
What might be the problem? How can I solve this?
*Also, is there any example that I can download. I want an example GRC file
which is using e312? (I dont know how to control E312 with gnuradio
companion)*
Best,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170314/6bdfcdbc/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 14 Mar 2017 07:18:48 -0700
From: Neel Pandeya <[email protected]>
To: "Gilad Beeri (ApolloShield)" <[email protected]>
Cc: usrp-users <[email protected]>, Marcus M?ller
<[email protected]>
Subject: Re: [USRP-users] USRP X310 Link Down with Intel X710-DA4 and
Ubuntu 16.04.02
Message-ID:
<CACaXmv8dOq84O6eYSB1nceYjXmC67PJEcDMOhWzCFKao6ebJ=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Gilad:
I would actually suggest not using the command line, and using Network
Manager. It is possible to get Network Manager to ignore an interface so
that you can set the IP address from the command line, but it can be tricky
to configure, and it's probably easier to just set it from Network Manager.
--Neel Pandeya
On 13 March 2017 at 09:15, Gilad Beeri (ApolloShield) <
[email protected]> wrote:
> Hi Neel,
> I'll try using NM and revert. I actually understood Marcus's comment the
> opposite (as in "make sure you don't use NM").
>
> I thought that Ettus advises the opposite - avoid using NM:
> https://files.ettus.com/manual/page_usrp_x3x0_config.
> html#x3x0cfg_hostpc_netcfg_nwmgr
> writes "Unfortunately, NetworkManager often tries to take control of a
> connection and will disconnect the interface.
>
> You should open your NetworkManager configuration and tell it to ignore
> the network interface you are using."
>
>
>
> ---------- Forwarded message ----------
> From: Neel Pandeya <[email protected]>
> To: "Marcus M?ller" <[email protected]>
> Cc: usrp-users <[email protected]>
> Bcc:
> Date: Sun, 12 Mar 2017 09:30:23 -0700
> Subject: Re: [USRP-users] USRP X310 Link Down with Intel X710-DA4 and
> Ubuntu 16.04.02
> Hello Gilad:
>
> Yeah, as Marcus said, set the IP address of the host via NetworkManager,
> not from the command line. The default IP address of the X310 for 10 GbE is
> 192.168.40.2.
>
> Are you using the latest version of the i40e driver? Did you get it from
> the Intel website?
>
> --Neel Pandeya
>
> On Mon, Mar 13, 2017 at 4:25 PM Gilad Beeri (ApolloShield) <
> [email protected]> wrote:
>
>> Hi Marcus,
>> I disabled NM for this NIC and configured static ip.
>> See below /etc/NetworkManager/NetworkManager.conf and /etc/network
>> interfaces (the unmanaged-devices key is actually redundant as NM won't
>> manage an interface from /etc/network/interfaces given the managed=false in
>> the ifupdown section).
>>
>> The NIC itself holds on to its static 192.168.40.1 IP well so I don't
>> think it's an issue with NM. The IP seems to be configured well, the
>> interface is up, but the state is DOWN. Not sure what the "state" in "ip
>> addr show"'s output means but I think it's related to 2-sided links.
>>
>> When I put the SFP+/RJ45 adapter in USRP X Port 1, and connect it with a
>> normal (not 10 GigE) Ethernet cable to my motherboard's Ethernet port
>> (bypassing X710), stopping NM (sudo service NetworkManager stop),
>> configuring the IP to the motherboard's NIC ("sudo ifconfig enp1s0f0 down"
>> - avoid collisions - and then "sudo ip addr add 192.168.40.1/24 dev
>> enp3s0"), verifying the IP is configured with the NIC, I still don't get
>> pongs from the USRP, and Wireshark shows the USRP doesn't respond to ARP
>> requests.
>> BUT, in this case, "ip addr show" says the state is "UP" (maybe the OS
>> treats differently links based on RJ45 vs. SFP+).
>>
>> I did a similar test with port 0 and IP 192.168.30.1/24 (I have the XG
>> firmware installed), still no luck.
>>
>> I believe the above indicates the problem isn't with the X710 or its
>> drivers, and probably also not with the SFP+ cables, but with the USRP
>> itself, or its configuration in the host computer.
>>
>> The promised config files:
>>
>> /etc/NetworkManager/NetworkManager.conf:
>> [main]
>> plugins=ifupdown,keyfile,ofono
>> dns=dnsmasq
>>
>> [ifupdown]
>> managed=false
>>
>> [keyfile]
>> unmanaged-devices=interface-name:enp1s0*
>>
>>
>> /etc/network/interfaces:
>> auto lo
>> iface lo inet loopback
>>
>> auto enp1s0f0
>> iface enp1s0f0 inet static
>> address 192.168.40.1
>> netmask 255.255.255.0
>> gateway 0.0.0.0
>>
>> ---------- Forwarded message ---------
>> From: <[email protected]>
>> Date: Sun, Mar 12, 2017 at 8:57 PM
>> Subject: USRP-users Digest, Vol 79, Issue 12
>> To: <[email protected]>
>>
>>
>>
>> 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=
>> [email protected]>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170314/b8237ef4/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 14 Mar 2017 15:39:39 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Expexted FPGA compatibility number 255.x,
but got 14.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Ali,
I think you probably know that, but for future readers of this mailing list:
The E310/E312 *runs* the python code generated by GRC. Thus, everything
is happening on the E3xx itself ? aside from the flow graph design.
So, the FPGA compatibility mismatch means you're running a UHD on the
device which doesn't match the FPGA images that it loads. Is that
possible? Did you build UHD yourself, or are you running from a "plain"
Release-4 SD card image?
Best regards,
Marcus
On 14.03.2017 13:57, do ber via USRP-users wrote:
> Hi to all,
>
> I am currently working on E312. My final goal is to control an e312(if
> possible multi e312 in the future) with GNURadio companion.
>
> I installed SDK. I am following the steps written in here:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
> I am in the "running the new UHD via sshfs section"
>
> I am seeing and using newly compiled
> UHD(/home/root/usr/bin/uhd_find_devices). So it is ok up to here.
>
> When I wrote:
>
> *~/usr/usr/lib/uhd/examples/benchmark_rate --tx_rate 1e6*
>
> I got:
>
> */Error: RuntimeError: Expexted FPGA compatibility number 255.x, but
> got 14.0: The FPGA build is not compatible with the host code build./*
>
> What might be the problem? How can I solve this?
>
> _Also, is there any example that I can download. I want an example GRC
> file which is using e312? (I dont know how to control E312 with
> gnuradio companion)_
>
> Best,
> Ali
>
>
> _______________________________________________
> 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/20170314/721d0a7b/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 14 Mar 2017 15:41:04 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Rfnoc siggen offset freq
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Tobias,
so, I'm a bit confused here; where are you generating the sine? In the
FPGA, or the PC?
I think a block diagram of what happens where and what signal we're
analyzing would make this a little clearer :)
Best regards,
Marcus
On 14.03.2017 13:30, Tobias Mitterer via USRP-users wrote:
> Hello everyone,
>
> I don't know if I do sth wrong, but when I generate a 10kHz sine with
> a sample rate of 1MHz save this signal via a file sink, visualize its
> time and frequency domain, I get a peak at 10010Hz and see a
> modulation of the sine with 10Hz.
>
> Thanks in advance for your help.
>
>
> _______________________________________________
> 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/20170314/a85c537e/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 14
******************************************
