Re: [USRP-users] UHD Comms Error

[Marcus D. Leech via USRP-users]

On 06/07/2019 12:29 PM, Mark Koenig via USRP-users wrote:


I am using a thunderbolt 3 interface, but only using it at 1Gig, 
standard 1500 MTU.  I am running at a sample rate of 25Msps.


If the problem is less-prevalent at lower sample rates, that suggests 
that your interface is dropping packets.


Keep mind that 1 Gig interface can support 25Msps at the absolute 
maximum at standard sample sizes.  So, you're
  right on the edge, and if the host interface is occasionally dropping 
frames during a control transaction, that will
  cause a failed transaction--the UHD protocol assumes an error-free 
channel, and has no provision for dealing with

  dropped packets.



Mark

*From: *Neel Pandeya 
*Date: *Thursday, June 6, 2019 at 2:00 PM
*To: *Mark Koenig 
*Cc: *"usrp-users@lists.ettus.com" 
*Subject: *Re: [USRP-users] UHD Comms Error

Hello Mark:

This may indicate a hardware problem.  What is specifically eliciting 
the error?  Does it occur with every time that there is a tune 
request?  Are you running your own program, or one the example 
programs, such as "rx_samples_to_file"?  Could you please try 
upgrading to UHD 3.14.0.0, and re-running your test, and let me know 
your results?


--Neel Pandeya

On Thu, 6 Jun 2019 at 12:47, Mark Koenig via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Please help, with the error I am seeing.

I am currently using an X310 with a UBX160 daughtercard and I get
the error below when changing the frequency parameters of the radio.

RuntimeError: EnvironmentError: IOError: Radio ctrl (A) packet
parse error - AssertionError: packet_info.packet_count ==
(seq_to_ack & 0xfff)

in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)

I am currently running UHD 3.9.7, but have also seen a similar
error with 3.10.2

Thanks

Mark

___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Marcus D. Leech via USRP-users]

On 06/07/2019 03:05 PM, Jason Matusiak via USRP-users wrote:


OK, this is actually an E310 problem.  The E310 always looks off 
device first. A coworker reminded me that we spent a couple days years 
back trying to figure out why the device was asking like it was 
working, but we weren't seeing any results.  It was because it was 
actually talking to an N2xx on the network even with the IP address arg.



We never found a solution (using both the 127 and 192 address as an 
argument still causes issues). So, it would be nice to clean this up 
on the E310 at some point, but for now I will try not to mix the E310 
and E320 on the same subnet.



For the case of running E310 apps *on* the E310, just use "type=e300", 
radio hardware on the E310 itself doesn't *have* an IP address, so using
  addr= will simply cause UHD to go down the wrong device path when 
you're running it ON the E31x itself.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Philip Balister via USRP-users]

On 06/07/2019 03:17 PM, Jason Matusiak via USRP-users wrote:
> OK, I will keep an eye on that.  No GR will kill us for now though.  I've 
> been playing with the build system for an E320 the last 2 weeks and have 
> learned to build //some// extra things in (including GR, but I haven't moved 
> that image onto a device yet), so I could probably take a swag at it, but it 
> probably would be easier for me to just wait.  The main issue with GR on the 
> E320 for me (which I assume will be an issue on the E310 as well) is that 
> scipy isn't built for it.  Lots of GR examples use it, and I am worried that 
> some of our internal OOT modules might, so I tried to build it in, but I went 
> down a 2 day rabbit hole trying to get python-scipy working (it seems to be 
> hard to do in oe based on other people in other projects struggling with it).
> 

I think some of the gnuradio scipy stuff was replaced with numpy
operations, which helps.

Yet another of my hobby projects is to collect all the fortran/scipy
stuff in a layer and try and get it built. I think it is possible, but
have no personal motivation to make it happen, and no one is willing to pay.

Philip

> 
> I'll keep an eye on the MPM and knowledge base updates, thanks.
> 
> 
> 
> From: Nate Temple 
> Sent: Friday, June 7, 2019 3:10 PM
> To: Jason Matusiak
> Cc: Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> Hi Jason,
> 
> You could try running the new 3.15 MPM based file system for the E310, but it 
> has some caveats, more details here: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html
> 
> 
> 
> Regards,
> Nate Temple
> 
> On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak 
> mailto:ja...@gardettoengineering.com>> wrote:
> 
> OK, this is actually an E310 problem.  The E310 always looks off device 
> first.  A coworker reminded me that we spent a couple days years back trying 
> to figure out why the device was asking like it was working, but we weren't 
> seeing any results.  It was because it was actually talking to an N2xx on the 
> network even with the IP address arg.
> 
> 
> We never found a solution (using both the 127 and 192 address as an argument 
> still causes issues).  So, it would be nice to clean this up on the E310 at 
> some point, but for now I will try not to mix the E310 and E320 on the same 
> subnet.
> 
> 
> 
> From: Jason Matusiak
> Sent: Friday, June 7, 2019 12:41 PM
> To: Nate Temple
> Cc: Marcus D Leech; Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> 
> OK, maybe based on my last email (which crossed yours I think).  The addr 
> flag doesn't seem to work at all with the uhd_usrp_probe on the E310 (at 
> least my version).
> 
> 
> From: Nate Temple mailto:nate.tem...@ettus.com>>
> Sent: Friday, June 7, 2019 12:37 PM
> To: Jason Matusiak
> Cc: Marcus D Leech; Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> Hi Jason,
> 
> For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 
> 3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the 
> same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into 
> the issue where probing in embedded mode would pickup the other device first, 
> but when providing a localhost addr, it worked as expected. I could use both 
> devices from a common host in network mode.
> 
> Trying the E320/E310 on different subnets would be worth a try.
> 
> I'll open an internal issue on our bug tracker for this, there is likely 
> improvements we can make to the device discovery.
> 
> 
> Regards,
> Nate Temple
> 
> On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
> mailto:ja...@gardettoengineering.com>> wrote:
> 
> Howdy.
> 
> 
> Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
> issue wasn't due to it, but it still acts the same.
> 
> 
> If I run: uhd_usrp_probe --args "addr=127.0.0.1"
> 
> root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; 
> UHD_3.11.0.1-0-unknown
> Error: i2c_zc_impl recv timeout
> 
> 
> 
> Reading up on the USRP2, they specifically say that you need to be on 
> different subnets if you are using more than on device.  I wonder if this is 
> the case here too?
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
> 
> 
> 
> From: Nate Temple mailto:nate.tem...@ettus.com>>
> Sent: Friday, June 7, 2019 12:17 PM
> To: Jason Matusiak
> Cc: Marcus D Leech; Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> Hi Jason,
> 
> On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
> expected?
> 
> uhd_usrp_probe --args "addr=127.0.0.1"
> 
> 
> Regards,
> Nate Temple
> 
> On Fri, Jun 7, 2019 at 9:10 AM Jason Ma

[USRP-users] A question of Frequency Offset

[Jiang, Fengyang via USRP-users]

Hi,

I'm transmitting a signal and receiving it using USRPs and want to estimate the 
frequency offset, but I'm getting something confusing.

I'm using 2.45GHz for the transmitting, and the sampling rate is 1MHz. The 
signal consists of 5 repeated preambles, and each of them has 100 data points 
(i.e. 100μs). Totally the signal has 500 data points (500μs), with a period of 
100μs.

After getting the received data, I can use a pair of data points whose distance 
is 100μs to calculate the frequency offset. However, if I use different pairs 
of data points, I will get different results. For example, if the received 
signal is [y1, y2, y3, ..., y101, y102, y103, ..., y499, y500], the frequency 
offset calculated by y101 and y1 is different from that calculted by y102 and 
y2, and that happens for all the pairs of data points. I should have got 
similar frequency offsets when using different pairs of data, but actually I 
got different results for each pair of the data.

Does anyone know what the case is, or any suggestions on the right way to 
calculate frequency offset? Thanks a lot!

Best,
Fengyang
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] offset tuning on the TwinRX

[Jason Matusiak via USRP-users]

A good write-up, thanks Sulvain.


I forgot all about how they functioned.  I worked on an SDR project a million 
years ago (before SDR was a thing) that did this.  I just used it and didn't 
realize that it was a super-het, and then I forgot all about it once I started 
using USRPs.


Thanks.



From: Sylvain Munaut <246...@gmail.com>
Sent: Wednesday, June 5, 2019 11:31 AM
To: Jason Matusiak
Cc: Robin Coxe; Ettus Mail List
Subject: Re: [USRP-users] offset tuning on the TwinRX



On Wed, Jun 5, 2019 at 4:41 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, thanks everyone.  I guess I have some superhet reading up to do 🙂.

In a nutshell, it's _always_ using LO offset :)

The RF path always brings the signal to some IF  (150 MHz IIRC), then the DDC 
blocks do the shift to baseband DC digitally.

So it's pretty much like if you had set the lo_offset = 150 MHz.

The finer points are :
 - It's not doing I/Q sampling, it uses one ADC for one channel and the other 
for the second one.
 - It's actually using band-pass sampling since the IF is higer than fs / 2.

But of course that means the hardware DDC blocks in the fpga are used already 
and that's why you can't (and there would be no point anyway) to apply some 
second level of lo_offset.


Cheers,

 Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

OK, I will keep an eye on that.  No GR will kill us for now though.  I've been 
playing with the build system for an E320 the last 2 weeks and have learned to 
build //some// extra things in (including GR, but I haven't moved that image 
onto a device yet), so I could probably take a swag at it, but it probably 
would be easier for me to just wait.  The main issue with GR on the E320 for me 
(which I assume will be an issue on the E310 as well) is that scipy isn't built 
for it.  Lots of GR examples use it, and I am worried that some of our internal 
OOT modules might, so I tried to build it in, but I went down a 2 day rabbit 
hole trying to get python-scipy working (it seems to be hard to do in oe based 
on other people in other projects struggling with it).


I'll keep an eye on the MPM and knowledge base updates, thanks.



From: Nate Temple 
Sent: Friday, June 7, 2019 3:10 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

You could try running the new 3.15 MPM based file system for the E310, but it 
has some caveats, more details here: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html



Regards,
Nate Temple

On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

OK, this is actually an E310 problem.  The E310 always looks off device first.  
A coworker reminded me that we spent a couple days years back trying to figure 
out why the device was asking like it was working, but we weren't seeing any 
results.  It was because it was actually talking to an N2xx on the network even 
with the IP address arg.


We never found a solution (using both the 127 and 192 address as an argument 
still causes issues).  So, it would be nice to clean this up on the E310 at 
some point, but for now I will try not to mix the E310 and E320 on the same 
subnet.



From: Jason Matusiak
Sent: Friday, June 7, 2019 12:41 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network


OK, maybe based on my last email (which crossed yours I think).  The addr flag 
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my 
version).


From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 3.11 
and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the same 
subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into the 
issue where probing in embedded mode would pickup the other device first, but 
when providing a localhost addr, it worked as expected. I could use both 
devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely 
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figur

Re: [USRP-users] E320 hogging the network

[Nate Temple via USRP-users]

Hi Jason,

You could try running the new 3.15 MPM based file system for the E310, but
it has some caveats, more details here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html



Regards,
Nate Temple

On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> OK, this is actually an E310 problem.  The E310 always looks off device
> first.  A coworker reminded me that we spent a couple days years
> back trying to figure out why the device was asking like it was working,
> but we weren't seeing any results.  It was because it was actually talking
> to an N2xx on the network even with the IP address arg.
>
>
> We never found a solution (using both the 127 and 192 address as an
> argument still causes issues).  So, it would be nice to clean this up on
> the E310 at some point, but for now I will try not to mix the E310 and
> E320 on the same subnet.
>
>
> --
> *From:* Jason Matusiak
> *Sent:* Friday, June 7, 2019 12:41 PM
> *To:* Nate Temple
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
>
> OK, maybe based on my last email (which crossed yours I think).  The addr
> flag doesn't seem to work at all with the uhd_usrp_probe on the E310 (at
> least my version).
>
> --
> *From:* Nate Temple 
> *Sent:* Friday, June 7, 2019 12:37 PM
> *To:* Jason Matusiak
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Hi Jason,
>
> For what its worth, I haven't personally ran this exact combo (E310 w/ UHD
> 3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the
> same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into
> the issue where probing in embedded mode would pickup the other device
> first, but when providing a localhost addr, it worked as expected. I could
> use both devices from a common host in network mode.
>
> Trying the E320/E310 on different subnets would be worth a try.
>
> I'll open an internal issue on our bug tracker for this, there is likely
> improvements we can make to the device discovery.
>
>
> Regards,
> Nate Temple
>
> On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Howdy.
>
>
> Nope, but it fails in a weird way.  I disconnected the E320 to make sure
> this issue wasn't due to it, but it still acts the same.
>
>
> If I run: uhd_usrp_probe --args "addr=127.0.0.1"
>
> *root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1" *
> *[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400;
> UHD_3.11.0.1-0-unknown*
> *Error: i2c_zc_impl recv timeout*
>
>
> Reading up on the USRP2, they specifically say that you need to be on
> different subnets if you are using more than on device.  I wonder if this
> is the case here too?
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
>
>
> --
> *From:* Nate Temple 
> *Sent:* Friday, June 7, 2019 12:17 PM
> *To:* Jason Matusiak
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Hi Jason,
>
> On the E310, if you pass the device arg addr with 127.0.0.1 does it work
> as expected?
>
> uhd_usrp_probe --args "addr=127.0.0.1"
>
>
> Regards,
> Nate Temple
>
> On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Darn, I was hoping that was it, but I don't think so.
>
>
> Here is the result from my E310:
>
> eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46
>
> and now the E320:
>
> sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB
>
> If I ping each device on my host, then run arp, I see this (the mac
> addresses match up correctly):
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.10.45ether   00:80:2f:24:c2:fb   C
>  p4p1
> 192.168.10.95ether   00:80:2f:25:44:46   C
>  p4p1
>
> I figured that that would be fine though because I have the same issue
> when I am running commands ON my E310.  And if it was a routing issue, it
> would mean that both my machine and the E310 and the E320 were being
> screwed up.
>
>
>
> --
> *From:* Marcus D Leech 
> *Sent:* Friday, June 7, 2019 12:01 PM
> *To:* Jason Matusiak
> *Cc:* Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check the MAC addresses.
>
> I know that on some ARM platforms that has to be programmed in at boot and
> perhaps these system images have it set to the same value.
>
> Sent from my iPhone
>
> On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Philip,
>
>
> They have unique addresses (10.95 and 10.45).  It is really weird that
> when I am on the E310, and set the ip-addr to himself, that he would even
> look off the device
>
>
> Th

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

OK, this is actually an E310 problem.  The E310 always looks off device first.  
A coworker reminded me that we spent a couple days years back trying to figure 
out why the device was asking like it was working, but we weren't seeing any 
results.  It was because it was actually talking to an N2xx on the network even 
with the IP address arg.


We never found a solution (using both the 127 and 192 address as an argument 
still causes issues).  So, it would be nice to clean this up on the E310 at 
some point, but for now I will try not to mix the E310 and E320 on the same 
subnet.



From: Jason Matusiak
Sent: Friday, June 7, 2019 12:41 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network


OK, maybe based on my last email (which crossed yours I think).  The addr flag 
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my 
version).


From: Nate Temple 
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 3.11 
and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the same 
subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into the 
issue where probing in embedded mode would pickup the other device first, but 
when providing a localhost addr, it worked as expected. I could use both 
devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely 
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

OK, maybe based on my last email (which crossed yours I think).  The addr flag 
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my 
version).


From: Nate Temple 
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 3.11 
and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the same 
subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into the 
issue where probing in embedded mode would pickup the other device first, but 
when providing a localhost addr, it worked as expected. I could use both 
devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely 
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its w

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

I just realized that using the 127 and 102 addresses don't work with the probe 
on the E310. It only works when I don't use the arg flag.



From: Jason Matusiak
Sent: Friday, June 7, 2019 12:22 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network


Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple 
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
>
>
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
>
>
> So what am I missing here?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users Info Page - 
Ettus
lists.ettus.com
To see the collection of prior postings to the list, visit the USRP-users 
Archives.. Using USRP-users: 

Re: [USRP-users] E320 hogging the network

[Nate Temple via USRP-users]

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD
3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the
same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into
the issue where probing in embedded mode would pickup the other device
first, but when providing a localhost addr, it worked as expected. I could
use both devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
wrote:

> Howdy.
>
>
> Nope, but it fails in a weird way.  I disconnected the E320 to make sure
> this issue wasn't due to it, but it still acts the same.
>
>
> If I run: uhd_usrp_probe --args "addr=127.0.0.1"
>
> *root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1" *
> *[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400;
> UHD_3.11.0.1-0-unknown*
> *Error: i2c_zc_impl recv timeout*
>
>
> Reading up on the USRP2, they specifically say that you need to be on
> different subnets if you are using more than on device.  I wonder if this
> is the case here too?
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
>
>
> --
> *From:* Nate Temple 
> *Sent:* Friday, June 7, 2019 12:17 PM
> *To:* Jason Matusiak
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Hi Jason,
>
> On the E310, if you pass the device arg addr with 127.0.0.1 does it work
> as expected?
>
> uhd_usrp_probe --args "addr=127.0.0.1"
>
>
> Regards,
> Nate Temple
>
> On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Darn, I was hoping that was it, but I don't think so.
>
>
> Here is the result from my E310:
>
> eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46
>
> and now the E320:
>
> sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB
>
> If I ping each device on my host, then run arp, I see this (the mac
> addresses match up correctly):
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.10.45ether   00:80:2f:24:c2:fb   C
>  p4p1
> 192.168.10.95ether   00:80:2f:25:44:46   C
>  p4p1
>
> I figured that that would be fine though because I have the same issue
> when I am running commands ON my E310.  And if it was a routing issue, it
> would mean that both my machine and the E310 and the E320 were being
> screwed up.
>
>
>
> --
> *From:* Marcus D Leech 
> *Sent:* Friday, June 7, 2019 12:01 PM
> *To:* Jason Matusiak
> *Cc:* Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check the MAC addresses.
>
> I know that on some ARM platforms that has to be programmed in at boot and
> perhaps these system images have it set to the same value.
>
> Sent from my iPhone
>
> On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Philip,
>
>
> They have unique addresses (10.95 and 10.45).  It is really weird that
> when I am on the E310, and set the ip-addr to himself, that he would even
> look off the device
>
>
> They both have hostnames and they are not similar to each other at all.
>
>
>
> --
> *From:* Philip Balister 
> *Sent:* Friday, June 7, 2019 11:10 AM
> *To:* Jason Matusiak; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check each ones ip address, likely by running ifconfig. In the back of
> my mind, I recall something like this in the E100 days. Do they have the
> same hostname?
>
> Philip
>
> On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> > It looks like I am misunderstanding something with how the E320 handles
> the network.
> >
> >
> > I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of
> the default 10.2).  I can ssh into it and things seem to run fine in
> embedded mode.
> >
> >
> > Now, if I ssh onto an E312 that is on the same network (IP 10.95), it
> doesn't work right as long as the E320 is plugged in.  When I do a probe or
> run any other UHD-type commands on the E310, it seems to always talk to the
> E320 first and it screws everything up.  It doesn't matter if I put the
> E310's address into the command or not, the E320 responds.  I also remember
> seeing this occur when I was on my host machine running commands (the E320
> bullied its way into being the main attraction).
> >
> >
> > My current work-around is to unplug Ethernet from the E320, run my
> command on the E310, plug back into the E320, then run its command.  This
> seems to allow things to work as I intended, but is obviously not ideal and
> is fairly difficult to do when devices are remote.
> >
> >
> > So what am I missing here?
> >
> >
> >

Re: [USRP-users] UHD Comms Error

[Mark Koenig via USRP-users]

I am using a thunderbolt 3 interface, but only using it at 1Gig, standard 1500 
MTU.  I am running at a sample rate of 25Msps.

Mark

From: Neel Pandeya 
Date: Thursday, June 6, 2019 at 2:00 PM
To: Mark Koenig 
Cc: "usrp-users@lists.ettus.com" 
Subject: Re: [USRP-users] UHD Comms Error

Hello Mark:

This may indicate a hardware problem.  What is specifically eliciting the 
error?  Does it occur with every time that there is a tune request?  Are you 
running your own program, or one the example programs, such as 
"rx_samples_to_file"?  Could you please try upgrading to UHD 3.14.0.0, and 
re-running your test, and let me know your results?

--Neel Pandeya



On Thu, 6 Jun 2019 at 12:47, Mark Koenig via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Please help, with the error I am seeing.

I am currently using an X310 with a UBX160 daughtercard and I get the error 
below when changing the frequency parameters of the radio.

RuntimeError: EnvironmentError: IOError: Radio ctrl (A) packet parse error - 
AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
  in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)


I am currently running UHD 3.9.7, but have also seen a similar error with 3.10.2

Thanks

Mark
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

Howdy.


Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
issue wasn't due to it, but it still acts the same.


If I run: uhd_usrp_probe --args "addr=127.0.0.1"

root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown
Error: i2c_zc_impl recv timeout



Reading up on the USRP2, they specifically say that you need to be on different 
subnets if you are using more than on device.  I wonder if this is the case 
here too?
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev



From: Nate Temple 
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech mailto:patchvonbr...@gmail.com>>
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
>
>
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
>
>
> So what am I missing here?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users Info Page - 
Ettus
lists.ettus.com
To see the collection of prior postings to the list, visit the USRP-users 
Archives.. Using USRP-users: To post a message to all the list members, send 
email to usrp-users@lists.ettus.com. You can 
subscribe to the list, or change your existing subscription, in the sections 
below.


>
___
USRP-users mailing list
USRP-users@lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Nate Temple via USRP-users]

Hi Jason,

On the E310, if you pass the device arg addr with 127.0.0.1 does it work as
expected?

uhd_usrp_probe --args "addr=127.0.0.1"


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Darn, I was hoping that was it, but I don't think so.
>
>
> Here is the result from my E310:
>
> eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46
>
> and now the E320:
>
> sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB
>
> If I ping each device on my host, then run arp, I see this (the mac
> addresses match up correctly):
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.10.45ether   00:80:2f:24:c2:fb   C
>  p4p1
> 192.168.10.95ether   00:80:2f:25:44:46   C
>  p4p1
>
> I figured that that would be fine though because I have the same issue
> when I am running commands ON my E310.  And if it was a routing issue, it
> would mean that both my machine and the E310 and the E320 were being
> screwed up.
>
>
>
> --
> *From:* Marcus D Leech 
> *Sent:* Friday, June 7, 2019 12:01 PM
> *To:* Jason Matusiak
> *Cc:* Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check the MAC addresses.
>
> I know that on some ARM platforms that has to be programmed in at boot and
> perhaps these system images have it set to the same value.
>
> Sent from my iPhone
>
> On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Philip,
>
>
> They have unique addresses (10.95 and 10.45).  It is really weird that
> when I am on the E310, and set the ip-addr to himself, that he would even
> look off the device
>
>
> They both have hostnames and they are not similar to each other at all.
>
>
>
> --
> *From:* Philip Balister 
> *Sent:* Friday, June 7, 2019 11:10 AM
> *To:* Jason Matusiak; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check each ones ip address, likely by running ifconfig. In the back of
> my mind, I recall something like this in the E100 days. Do they have the
> same hostname?
>
> Philip
>
> On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> > It looks like I am misunderstanding something with how the E320 handles
> the network.
> >
> >
> > I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of
> the default 10.2).  I can ssh into it and things seem to run fine in
> embedded mode.
> >
> >
> > Now, if I ssh onto an E312 that is on the same network (IP 10.95), it
> doesn't work right as long as the E320 is plugged in.  When I do a probe or
> run any other UHD-type commands on the E310, it seems to always talk to the
> E320 first and it screws everything up.  It doesn't matter if I put the
> E310's address into the command or not, the E320 responds.  I also remember
> seeing this occur when I was on my host machine running commands (the E320
> bullied its way into being the main attraction).
> >
> >
> > My current work-around is to unplug Ethernet from the E320, run my
> command on the E310, plug back into the E320, then run its command.  This
> seems to allow things to work as I intended, but is obviously not ideal and
> is fairly difficult to do when devices are remote.
> >
> >
> > So what am I missing here?
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> USRP-users Info Page - Ettus
> 
> lists.ettus.com
> To see the collection of prior postings to the list, visit the USRP-users
> Archives.. Using USRP-users: To post a message to all the list members,
> send email to usrp-users@lists.ettus.com. You can subscribe to the list,
> or change your existing subscription, in the sections below.
>
>
> >
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

Darn, I was hoping that was it, but I don't think so.


Here is the result from my E310:

eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46

and now the E320:

sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB

If I ping each device on my host, then run arp, I see this (the mac addresses 
match up correctly):

Address  HWtype  HWaddress   Flags MaskIface
192.168.10.45ether   00:80:2f:24:c2:fb   C p4p1
192.168.10.95ether   00:80:2f:25:44:46   C p4p1

I figured that that would be fine though because I have the same issue when I 
am running commands ON my E310.  And if it was a routing issue, it would mean 
that both my machine and the E310 and the E320 were being screwed up.



From: Marcus D Leech 
Sent: Friday, June 7, 2019 12:01 PM
To: Jason Matusiak
Cc: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check the MAC addresses.

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value.

Sent from my iPhone

On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister mailto:phi...@balister.org>>
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
>
>
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
>
>
> So what am I missing here?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users Info Page - 
Ettus
lists.ettus.com
To see the collection of prior postings to the list, visit the USRP-users 
Archives.. Using USRP-users: To post a message to all the list members, send 
email to usrp-users@lists.ettus.com. You can 
subscribe to the list, or change your existing subscription, in the sections 
below.


>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Marcus D Leech via USRP-users]

Check the MAC addresses. 

I know that on some ARM platforms that has to be programmed in at boot and 
perhaps these system images have it set to the same value. 

Sent from my iPhone

> On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users 
>  wrote:
> 
> Philip,
> 
> They have unique addresses (10.95 and 10.45).  It is really weird that when I 
> am on the E310, and set the ip-addr to himself, that he would even look off 
> the device
> 
> They both have hostnames and they are not similar to each other at all.
> 
> 
> From: Philip Balister 
> Sent: Friday, June 7, 2019 11:10 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
>  
> Check each ones ip address, likely by running ifconfig. In the back of
> my mind, I recall something like this in the E100 days. Do they have the
> same hostname?
> 
> Philip
> 
> On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> > It looks like I am misunderstanding something with how the E320 handles the 
> > network.
> > 
> > 
> > I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> > default 10.2).  I can ssh into it and things seem to run fine in embedded 
> > mode.
> > 
> > 
> > Now, if I ssh onto an E312 that is on the same network (IP 10.95), it 
> > doesn't work right as long as the E320 is plugged in.  When I do a probe or 
> > run any other UHD-type commands on the E310, it seems to always talk to the 
> > E320 first and it screws everything up.  It doesn't matter if I put the 
> > E310's address into the command or not, the E320 responds.  I also remember 
> > seeing this occur when I was on my host machine running commands (the E320 
> > bullied its way into being the main attraction).
> > 
> > 
> > My current work-around is to unplug Ethernet from the E320, run my command 
> > on the E310, plug back into the E320, then run its command.  This seems to 
> > allow things to work as I intended, but is obviously not ideal and is 
> > fairly difficult to do when devices are remote.
> > 
> > 
> > So what am I missing here?
> > 
> > 
> > 
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> USRP-users Info Page - Ettus
> lists.ettus.com
> To see the collection of prior postings to the list, visit the USRP-users 
> Archives.. Using USRP-users: To post a message to all the list members, send 
> email to usrp-users@lists.ettus.com. You can subscribe to the list, or change 
> your existing subscription, in the sections below.
> 
> 
> > 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

Philip,


They have unique addresses (10.95 and 10.45).  It is really weird that when I 
am on the E310, and set the ip-addr to himself, that he would even look off the 
device


They both have hostnames and they are not similar to each other at all.



From: Philip Balister 
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
>
>
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
>
>
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
>
>
> So what am I missing here?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
USRP-users Info Page - 
Ettus
lists.ettus.com
To see the collection of prior postings to the list, visit the USRP-users 
Archives.. Using USRP-users: To post a message to all the list members, send 
email to usrp-users@lists.ettus.com. You can subscribe to the list, or change 
your existing subscription, in the sections below.


>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Philip Balister via USRP-users]

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
> 
> 
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
> 
> 
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
> 
> 
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
> 
> 
> So what am I missing here?
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Issues streaming only one channel from LFRX in X310 using rx_samples_to_file

[Lapointe, Benjamin - 0333 - MITLL via USRP-users]

Hi,

 

I am trying to stream one, and only one, channel from a LFRX inside a X310
using the rx_samples_to_file example, but haven't been fully successful.
It seems to always stream data for the second channel as well.

 

The command I am running is:

rx_samples_to_file -file=/path_to_file/file.dat -type=short -ant="A"
-nsamps=5000 -rate=1e6 -freq=0e3

 

This gives me my data for antenna RXA, but it also streams zeros in the
place of antenna RXB.

If I change antenna to "AB", then I get data for both antennas RXA and RXB,
as I would expect.

 

I've also tried using the "channel" option, but that doesn't seem to make a
difference.

 

I've also tried using the "wirefmt" option, but that throws an error for
anything other than "sc16".  

 

Thanks,

-Ben

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] two E320 radios

[Jason Matusiak via USRP-users]

OK, another E320 question.  With my custom RFNoC image, only a Radio_0 shows 
up.  Shouldn't there be a Radio_1 as well?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E320 hogging the network

[Jason Matusiak via USRP-users]

It looks like I am misunderstanding something with how the E320 handles the 
network.


I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
default 10.2).  I can ssh into it and things seem to run fine in embedded mode.


Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
work right as long as the E320 is plugged in.  When I do a probe or run any 
other UHD-type commands on the E310, it seems to always talk to the E320 first 
and it screws everything up.  It doesn't matter if I put the E310's address 
into the command or not, the E320 responds.  I also remember seeing this occur 
when I was on my host machine running commands (the E320 bullied its way into 
being the main attraction).


My current work-around is to unplug Ethernet from the E320, run my command on 
the E310, plug back into the E320, then run its command.  This seems to allow 
things to work as I intended, but is obviously not ideal and is fairly 
difficult to do when devices are remote.


So what am I missing here?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com