Re: [USRP-users] X300: Can we use different TX sampling rates on RF A and RF B?

[Marcus D. Leech via USRP-users]

On 09/07/2018 07:01 PM, Serge Malo wrote:

Thanks for you quick answer Marcus:

I always thought it was impossible to create 2 multi_usrp objects 
which connects to the same X300 device. Is this really possible?

I can try that on my side later if you think its possible.


Best regards,
Serge
I would say try it.  But now that you mention it, it may not work. I'm 
not at my lab right now, or I'd try it myself






- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - -

*Meet us at ION GNSS+ 2018 in Miami! Sept 24-28 2018, booth 604.*
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com 
Twitter: @skydelsol 
Avis : Ce message est confidentiel et protégé par le secret 
professionnel. Si vous n'êtes pas le destinataire, veuillez informer 
l'expéditeur par courriel immédiatement et effacer ce message et en 
détruire toute copie. / Notice: This message is confidential and 
privileged. If you are not the addressee, please inform the sender by 
return e-mail immediately and delete this message and destroy all copies.


On 7 September 2018 at 16:35, Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 09/07/2018 04:32 PM, Serge Malo via USRP-users wrote:

Hi all,

I'm trying to use 2 different sampling rates the 2 TX channels of
a X300.
Basically, I create 2 different tx_streamers, and call
usrp->set_tx_rate() for each channel.

I'm getting this error from UHD:
Multiple sampling rates downstream of TX Terminator 0:
RuntimeError: Node 0/DUC_0 specifies 1.25e+07, node 0/DUC_1
specifies 2.5e+07.


I'm using UHD 3.10.3.0.
Can you tell me if this is expected, or should I be able to use 2
different sampling rates?

Thanks,
Serge

If you want different sample rates, you'll likely need to create
two independent multi_usrp objects to contain the streamers.






- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -
*Meet us at ION GNSS+ 2018 in Miami! Sept 24-28 2018, booth 604.*
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com 
Twitter: @skydelsol 
Avis : Ce message est confidentiel et protégé par le secret
professionnel. Si vous n'êtes pas le destinataire, veuillez
informer l'expéditeur par courriel immédiatement et effacer ce
message et en détruire toute copie. / Notice: This message is
confidential and privileged. If you are not the addressee, please
inform the sender by return e-mail immediately and delete this
message and destroy all copies.


___
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] X300: Can we use different TX sampling rates on RF A and RF B?

[Serge Malo via USRP-users]

Thanks for you quick answer Marcus:

I always thought it was impossible to create 2 multi_usrp objects which
connects to the same X300 device. Is this really possible?
I can try that on my side later if you think its possible.


Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - -
*Meet us at ION GNSS+ 2018 in Miami! Sept 24-28 2018, booth 604.*
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol 
Avis : Ce message est confidentiel et protégé par le secret professionnel.
Si vous n'êtes pas le destinataire, veuillez informer l'expéditeur par
courriel immédiatement et effacer ce message et en détruire toute copie. /
Notice: This message is confidential and privileged. If you are not the
addressee, please inform the sender by return e-mail immediately and delete
this message and destroy all copies.

On 7 September 2018 at 16:35, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 09/07/2018 04:32 PM, Serge Malo via USRP-users wrote:
>
> Hi all,
>
> I'm trying to use 2 different sampling rates the 2 TX channels of a X300.
> Basically, I create 2 different tx_streamers, and call usrp->set_tx_rate()
> for each channel.
>
> I'm getting this error from UHD:
> Multiple sampling rates downstream of TX Terminator 0: RuntimeError: Node
> 0/DUC_0 specifies 1.25e+07, node 0/DUC_1 specifies 2.5e+07.
>
>
> I'm using UHD 3.10.3.0.
> Can you tell me if this is expected, or should I be able to use 2
> different sampling rates?
>
> Thanks,
> Serge
>
> If you want different sample rates, you'll likely need to create two
> independent multi_usrp objects to contain the streamers.
>
>
>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - -
> *Meet us at ION GNSS+ 2018 in Miami! Sept 24-28 2018, booth 604.*
> *Serge Malo *
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017
> www.skydelsolutions.com
> Twitter: @skydelsol 
> Avis : Ce message est confidentiel et protégé par le secret professionnel.
> Si vous n'êtes pas le destinataire, veuillez informer l'expéditeur par
> courriel immédiatement et effacer ce message et en détruire toute copie. /
> Notice: This message is confidential and privileged. If you are not the
> addressee, please inform the sender by return e-mail immediately and delete
> this message and destroy all copies.
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] X300: Can we use different TX sampling rates on RF A and RF B?

[Marcus D. Leech via USRP-users]

On 09/07/2018 04:32 PM, Serge Malo via USRP-users wrote:

Hi all,

I'm trying to use 2 different sampling rates the 2 TX channels of a X300.
Basically, I create 2 different tx_streamers, and call 
usrp->set_tx_rate() for each channel.


I'm getting this error from UHD:
Multiple sampling rates downstream of TX Terminator 0: RuntimeError: 
Node 0/DUC_0 specifies 1.25e+07, node 0/DUC_1 specifies 2.5e+07.



I'm using UHD 3.10.3.0.
Can you tell me if this is expected, or should I be able to use 2 
different sampling rates?


Thanks,
Serge
If you want different sample rates, you'll likely need to create two 
independent multi_usrp objects to contain the streamers.







- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - -

*Meet us at ION GNSS+ 2018 in Miami! Sept 24-28 2018, booth 604.*
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com 
Twitter: @skydelsol 
Avis : Ce message est confidentiel et protégé par le secret 
professionnel. Si vous n'êtes pas le destinataire, veuillez informer 
l'expéditeur par courriel immédiatement et effacer ce message et en 
détruire toute copie. / Notice: This message is confidential and 
privileged. If you are not the addressee, please inform the sender by 
return e-mail immediately and delete this message and destroy all copies.



___
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] X300: Can we use different TX sampling rates on RF A and RF B?

[Serge Malo via USRP-users]

Hi all,

I'm trying to use 2 different sampling rates the 2 TX channels of a X300.
Basically, I create 2 different tx_streamers, and call usrp->set_tx_rate()
for each channel.

I'm getting this error from UHD:
Multiple sampling rates downstream of TX Terminator 0: RuntimeError: Node
0/DUC_0 specifies 1.25e+07, node 0/DUC_1 specifies 2.5e+07.


I'm using UHD 3.10.3.0.
Can you tell me if this is expected, or should I be able to use 2 different
sampling rates?

Thanks,
Serge



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - -
*Meet us at ION GNSS+ 2018 in Miami! Sept 24-28 2018, booth 604.*
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol 
Avis : Ce message est confidentiel et protégé par le secret professionnel.
Si vous n'êtes pas le destinataire, veuillez informer l'expéditeur par
courriel immédiatement et effacer ce message et en détruire toute copie. /
Notice: This message is confidential and privileged. If you are not the
addressee, please inform the sender by return e-mail immediately and delete
this message and destroy all copies.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister via USRP-users]

On 09/06/2018 02:52 PM, Philip Balister via USRP-users wrote:
> On 09/06/2018 08:52 AM, Jason Matusiak wrote:
>> Just finished running the second command just mentioned below, still died 
>> with the package "six" error.
> 
> I found the problem, will regenerate images and sdk tonight and update
> Dropbox in the morning. Thanks for testing this and finding I still had
> an issue with the E300 sdk.

Jason, give this a shot if you can:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Philip


> 
> Philip
> 
>>  
>>  
>> - Original Message - Subject: RE: Re: [USRP-users] Issues 
>> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
>> From: "Jason Matusiak" 
>> Date: 9/6/18 8:44 am
>> To: "Philip Balister" 
>> Cc: "USRP-users@lists.ettus.com" 
>>
>>  Thanks Philip, that will be very helpful.  Will the steps be the same as 
>> before? :
>>  
>> 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh
>> 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300
>>  
>> Or will something need to change there?
>>  
>> - Original Message - Subject: Re: [USRP-users] Issues 
>> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
>> From: "Philip Balister" 
>> Date: 9/5/18 3:35 pm
>> To: "Jason Matusiak" 
>> Cc: "USRP-users@lists.ettus.com" 
>>
>> On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
>>  > Philip, I know I am digging this up from early in the year, but I didn't 
>> see an answer. I am having the exact same issue with the six package. Were 
>> you ever able to fix this?
>>  
>>  Pretty sure the sdk from here is fixed:
>>  
>>  https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0
>>  
>>  These are newer images based of rocko I ended creating out of another
>>  job. Posted in case others find them useful.
>>  
>>  Philip
>>  
>>  > 
>>  > 
>>  > - Original Message - On 04/02/2018 06:58 PM, Marcus D. 
>> Leech wrote:
>>  > > On 04/02/2018 06:09 PM, Philip Balister wrote:
>>  > >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>>  > >>> I'm having issues with installing GNU radio using PYBOMBS. It
>>  > >>> successfully
>>  > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>>  > >>> missing python six message. I have been using this guide from Ettus 
>> for
>>  > >>> reference.
>>  > >>>
>>  > >>> 
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>>  > >>>
>>  > >>>
>>  > >>>
>>  > >>> -- Python checking for six - python 2 and 3 compatibility library - 
>> not
>>  > >>> found
>>  > >>> CMake Error at volk/CMakeLists.txt:93 (message):
>>  > >>> six - python 2 and 3 compatibility library required to build VOLK
>>  > >>>
>>  > >> Looks like the volk added a dependency on python-six and the E300 image
>>  > >> doesn't have it. Ettus needs to create a new file system image with 
>> that
>>  > >> package installed.
>>  > >>
>>  > >> Philip
>>  > > WHile that is actually, true, in this case the user is doing
>>  > > cross-builds on their PC host, and had installed python-six into their
>>  > > cross-build
>>  > > environment, and still no joy.
>>  > 
>>  > Adding python-six-native cleared up my build issue. Likely the real
>>  > solution is regenerate the sdk including the native-sdk version of
>>  > python-six.
>>  > 
>>  > I'll poke meta-sdr for this soon to cover other users.
>>  > 
>>  > Philip
>>  > 
>>  > >
>>  > >
>>  > >>
>>  > >>> -- Configuring incomplete, errors occurred!
>>  > >>>
>>  > >>>
>>  > >>> Someone also posted the same issue but I couldn't find a response to 
>> his
>>  > >>> question along with how to bypass this error. I've tried installing 
>> the
>>  > >>> lastest version of python six-1.11.0 onto my local computer still but
>>  > >>> having no luck. Any guidance or help is appreciated.
>>  > >>>
>>  > >>> 
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
>>  > >>>
>>  > >>>
>>  > >>>
>>  > >>>
>>  > >>> ___
>>  > >>> Discuss-gnuradio mailing list
>>  > >>> address@hidden
>>  > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>  > >>>
>>  > >> ___
>>  > >> Discuss-gnuradio mailing list
>>  > >> address@hidden
>>  > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>  > >
>>  > >
>>  > > ___
>>  > > Discuss-gnuradio mailing list
>>  > > address@hidden
>>  > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>  > >
>>  > 
>>  > 
>>  > 
>>  > ___
>>  > 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

[USRP-users] Can't change MTU on N310

[Mark Wagner via USRP-users]

Hi,

Right now I'm trying to change the MTU on eth0 to be 8000 as suggested by
the Hardware driver and USRP manual but I'm getting an error

I'll start my N310 with a 10Gbe connection, screen in as instructed, and
type

ifconfig eth0 mtu 8000

then get error message

eth0: Invalid MTU 8000 requested, hw max 1500

My understanding is that the N310 thinks it can't change the MTU past 1500,
but this seems wrong. Has anyone else had this problem?

-Mark

-- 
Mark Wagner
University of California San Diego
Electrical and Computer Engineering
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP Source Block caught rx error code: 15

[Harper, Andrew via USRP-users]

Set the MTU to 1500 and that fixed it, thanks for the help!


From: Marcus D. Leech [mailto:mle...@ripnet.com]
Sent: Friday, September 7, 2018 11:38 AM
To: Harper, Andrew ; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Source Block caught rx error code: 15

On 09/07/2018 09:48 AM, Harper, Andrew wrote:

Here is the output:
enp3s0Link encap:Ethernet  HWaddr 68:f7:28:42:64:6b
  inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0
  inet6 addr: fe80::c469:ffbe:558:1d0c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:5000  Metric:1
  RX packets:129757 errors:0 dropped:0 overruns:0 frame:0
  TX packets:146186 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:60283078 (60.2 MB)  TX bytes:63747906 (63.7 MB)
Did you set the MTU to 5000?

For 1GiGe, the default is 1500, and what I've found with RealTek ethernet 
controllers is that they're perfectly happy to accept a higher
  MTU *setting* but cannot actually deliver on it.




From: Marcus D. Leech 
Sent: Thursday, September 6, 2018 4:31:28 PM
To: Harper, Andrew; 
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Source Block caught rx error code: 15

On 09/06/2018 04:01 PM, Harper, Andrew wrote:

I'm running Xubuntu 16.04 on the hardware, i.e. not VM:
Distributor ID:Ubuntu
Description:Ubuntu 16.04.5 LTS
Release:16.04
Codename:xenial


Ethernet info:
description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet 
Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@:03:00.0
logical name: enp3s0
version: 10
serial: 68:f7:28:42:64:6b
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master cap_list 
ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd 
autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 
driverversion=2.3LK-NAPI duplex=full firmware=rtl8168g-3_0.0.1 04/23/13 
ip=192.168.10.1 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
resources: irq:27 ioport:3000(size=256) 
memory:f0d04000-f0d04fff memory:f0d0-f0d03fff

What is the frame error count on the interface?  (rx errors when using ifconfig)





From: USRP-users 
 
on behalf of Marcus D. Leech via USRP-users 

Sent: Thursday, September 6, 2018 3:43 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Source Block caught rx error code: 15

On 09/06/2018 03:29 PM, Harper, Andrew via USRP-users wrote:

Hi, I am having a troubling error from my x310 USRP whenever I try to pull 
samples using the USRP source block. The error message I am getting is:


[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: Bad CHDR or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet 
fragment
The most basic flowgraph that creates this error is a USRP Source connected 
directly to a QT Time plot. It also happens when I try to run: 1) 
uhd_cal_rx_iq_balance, 2)  uhd_fft, 3) uhd_cal_tx_dc_offset, My gnuradio 
version is 3.7.13.4, UHD version is UHD 3.14.0.0-88-g6013a511, and i have just 
reinstalled both to make sure it is not a software issue. I am able to 
successfully run uhd_find_devices and uhd_usrp_probe. I am also able to run a 
USRP sink block without error, if that helps identify the problem.



Anyone have a fix for this?

Andrew


What type of Ethernet interface do you have on your system?

Is this a VM, or a on-the-hardware system?

Is this on Windows or Linux?



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

Re: [USRP-users] USRP Source Block caught rx error code: 15

[Marcus D. Leech via USRP-users]

On 09/07/2018 09:48 AM, Harper, Andrew wrote:


Here is the output:

enp3s0Link encap:Ethernet  HWaddr 68:f7:28:42:64:6b
  inet addr:192.168.10.1  Bcast:192.168.10.255 Mask:255.255.255.0
  inet6 addr: fe80::c469:ffbe:558:1d0c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:5000  Metric:1
  RX packets:129757 errors:0 dropped:0 overruns:0 frame:0
  TX packets:146186 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:60283078 (60.2 MB)  TX bytes:63747906 (63.7 MB)


Did you set the MTU to 5000?

For 1GiGe, the default is 1500, and what I've found with RealTek 
ethernet controllers is that they're perfectly happy to accept a higher

  MTU *setting* but cannot actually deliver on it.




*From:* Marcus D. Leech 
*Sent:* Thursday, September 6, 2018 4:31:28 PM
*To:* Harper, Andrew; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP Source Block caught rx error code: 15
On 09/06/2018 04:01 PM, Harper, Andrew wrote:


I'm running Xubuntu 16.04 on the hardware, i.e. not VM:

Distributor ID:Ubuntu
Description:Ubuntu 16.04.5 LTS
Release:16.04
Codename:xenial

Ethernet info:

description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit 
Ethernet Controller

vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@:03:00.0
logical name: enp3s0
version: 10
serial: 68:f7:28:42:64:6b
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master 
cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 
1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes 
driver=r8169 driverversion=2.3LK-NAPI duplex=full 
firmware=rtl8168g-3_0.0.1 04/23/13 ip=192.168.10.1 latency=0 link=yes 
multicast=yes port=MII speed=1Gbit/s
resources: irq:27 ioport:3000(size=256) 
memory:f0d04000-f0d04fff memory:f0d0-f0d03fff



What is the frame error count on the interface?  (rx errors when using 
ifconfig)






*From:* USRP-users  on behalf of 
Marcus D. Leech via USRP-users 

*Sent:* Thursday, September 6, 2018 3:43 PM
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP Source Block caught rx error code: 15
On 09/06/2018 03:29 PM, Harper, Andrew via USRP-users wrote:


Hi, I am having a troubling error from my x310 USRP whenever I try 
to pull samples using the USRP source block. The error message I am 
getting is:



[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: Bad CHDR or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR 
or packet fragment


The most basic flowgraph that creates this error is a USRP Source 
connected directly to a QT Time plot. It also happens when I try to 
run: 1) uhd_cal_rx_iq_balance, 2)  uhd_fft, 3) uhd_cal_tx_dc_offset, 
My gnuradio version is 3.7.13.4, UHD version is UHD 
3.14.0.0-88-g6013a511, and i have just reinstalled both to make sure 
it is not a software issue. I am able to successfully run 
uhd_find_devices and uhd_usrp_probe. I am also able to run a USRP 
sink block without error, if that helps identify the problem.



Anyone have a fix for this?

Andrew




What type of Ethernet interface do you have on your system?

Is this a VM, or a on-the-hardware system?

Is this on Windows or Linux?






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

Re: [USRP-users] "No upstream blocks" Warning

[Sebastian Bräuer via USRP-users]

Okay, thanks for the advice. I added a FIFO in between the host and my
block. I had not thought of this, because I never really intended to
receive samples from this port. I just need a port to get the receive
chain started. Now I'm not a getting a warning anymore, which is good I
guess. But still no output or blinking lights.

This confuses me, because it works just fine on gnuradio (although on a
slightly lower rate). Just a question: Do I actually have to receive
samples from the block once I started the rx_streamer? As far as I
understood the FPGA doesnt care wether I receive the samples it sends or
not, there is no backpressure.

PS: (Sorry for the duplicate mail, messed up my mail accounts)

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

Re: [USRP-users] USRP Source Block caught rx error code: 15

[Harper, Andrew via USRP-users]

Here is the output:

enp3s0Link encap:Ethernet  HWaddr 68:f7:28:42:64:6b
  inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0
  inet6 addr: fe80::c469:ffbe:558:1d0c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:5000  Metric:1
  RX packets:129757 errors:0 dropped:0 overruns:0 frame:0
  TX packets:146186 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:60283078 (60.2 MB)  TX bytes:63747906 (63.7 MB)




From: Marcus D. Leech 
Sent: Thursday, September 6, 2018 4:31:28 PM
To: Harper, Andrew; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Source Block caught rx error code: 15

On 09/06/2018 04:01 PM, Harper, Andrew wrote:

I'm running Xubuntu 16.04 on the hardware, i.e. not VM:

Distributor ID:Ubuntu
Description:Ubuntu 16.04.5 LTS
Release:16.04
Codename:xenial


Ethernet info:

description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet 
Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@:03:00.0
logical name: enp3s0
version: 10
serial: 68:f7:28:42:64:6b
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master cap_list 
ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd 
autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 
driverversion=2.3LK-NAPI duplex=full firmware=rtl8168g-3_0.0.1 04/23/13 
ip=192.168.10.1 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
resources: irq:27 ioport:3000(size=256) 
memory:f0d04000-f0d04fff memory:f0d0-f0d03fff


What is the frame error count on the interface?  (rx errors when using ifconfig)




From: USRP-users 
 
on behalf of Marcus D. Leech via USRP-users 

Sent: Thursday, September 6, 2018 3:43 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP Source Block caught rx error code: 15

On 09/06/2018 03:29 PM, Harper, Andrew via USRP-users wrote:

Hi, I am having a troubling error from my x310 USRP whenever I try to pull 
samples using the USRP source block. The error message I am getting is:


[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: Bad CHDR or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet 
fragment

The most basic flowgraph that creates this error is a USRP Source connected 
directly to a QT Time plot. It also happens when I try to run: 1) 
uhd_cal_rx_iq_balance, 2)  uhd_fft, 3) uhd_cal_tx_dc_offset, My gnuradio 
version is 3.7.13.4, UHD version is UHD 3.14.0.0-88-g6013a511, and i have just 
reinstalled both to make sure it is not a software issue. I am able to 
successfully run uhd_find_devices and uhd_usrp_probe. I am also able to run a 
USRP sink block without error, if that helps identify the problem.


Anyone have a fix for this?

Andrew


What type of Ethernet interface do you have on your system?

Is this a VM, or a on-the-hardware system?

Is this on Windows or Linux?



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

Re: [USRP-users] "No upstream blocks" Warning

[Jason Matusiak via USRP-users]

The issue is on your output side.  It has been explained to me (I think it is 
somewhere on this mailing list due to an issue I and other have had), that you 
can't mix ports to be both host and rfnoc streams on the same side of the RFNoC 
block.  So it sounds like the input side has both inputs coming from the RFNoC 
stream, that is fine.  On the other side it sounds like one output stays in the 
RFNoC stream, and the other goes directly the the host.  I believe that that is 
a no-no.
 
They either both need to go to the host, or both stay in RFNoC land (it doesn't 
have to be the same domain as the input, just the same on that side of the 
block).  I would try throwing an RFNoC FIFO on your output that goes to the 
host domain.  See if that makes things work for you.
 
- Original Message - Subject: [USRP-users] "No upstream blocks" 
Warning
From: "Sebastian Bräuer via USRP-users" 
Date: 9/7/18 5:21 am
To: "usrp-users@lists.ettus.com" 

Hi,
 
 I am currently working on a custom rfnoc block that needs input from the
 DDC but also gets samples from the host and sends them to the radio via
 the DUC. The block works perfectly in simulation and even in gnuradio
 but for some reason I cant get it to work in pure UHD.  In my UHD code I
 always get a "No upstream blocks" warning from the DDC block and nothing
 happens.
 No reception and no transmission (No light on the panel) and the
 registers in my block indicate that no data is flowing but UHD happily
 transmits data to the FPGA.
 
 Some info about my setup:
 
 I am working on an X310 with the rate set to 184.32e6. My custom block
 has two inputs and two outputs. Input 0 is wired to the DmaFifo and
 Input 1 is connected to the DDC. Output 0 is connected to the DDC for
 transmission while output 1 streams to the host.
 
 I don't know if the warning is directly related to my problem but it is
 my only guess, since it works in gnuradio. Any help would be appreciated.
 
 The code below reproduces the warning (Unfortunately, I cant show you my
 actual code):
 
 > #include
 > #include
 > #include
 > #include
 >
 > int main(int argc, char *argv[]){
 > uhd::device3::sptr dev;
 > uhd::device_addr_t hint;
 >
 > hint["addr"] = "192.168.10.2";
 >
 > std::cout << "Opening USRP...\n";
 > dev = uhd::device3::make(hint);
 >
 > //Block Declaration
 > uhd::rfnoc::radio_ctrl::sptr radio0;
 > uhd::rfnoc::block_ctrl_base::sptr lbt;
 > uhd::rfnoc::source_block_ctrl_base::sptr ddc;
 > uhd::rfnoc::source_block_ctrl_base::sptr duc;
 > uhd::rfnoc::source_block_ctrl_base::sptr dmaFifo;
 >
 > uhd::rfnoc::block_id_t radio_id_0(0, "Radio", 0);
 > uhd::rfnoc::block_id_t lbt_id(0, "lbt", 0);
 > uhd::rfnoc::block_id_t duc_id(0, "DUC", 0);
 > uhd::rfnoc::block_id_t ddc_id(0, "DDC", 0);
 > uhd::rfnoc::block_id_t dmaFifo_id(0, "DmaFIFO", 0);
 >
 > radio0 = dev->get_block_ctrl(radio_id_0);
 > lbt = dev->get_block_ctrl(lbt_id);
 > ddc = dev->get_block_ctrl(ddc_id);
 > duc = dev->get_block_ctrl(duc_id);
 > dmaFifo =
 > dev->get_block_ctrl(dmaFifo_id);
 > 
 > dev->clear();
 > 
 > uhd::rfnoc::graph::sptr graph;
 > graph = dev->create_graph("lbt_test");
 >
 > graph->connect(radio_id_0,0, ddc_id,0);
 > graph->connect(duc_id,0, radio_id_0,0);
 > 
 > graph->connect(lbt_id,0,duc_id,0);
 >
 > graph->connect(ddc_id,0,lbt_id,1);
 > graph->connect(dmaFifo_id,0,lbt_id,0);
 >
 > uhd::stream_args_t tx_args("fc32","sc16");
 > tx_args.args["block_id"] = dmaFifo_id;
 >
 > uhd::stream_args_t rx_args("fc32","sc16");
 > rx_args.args["block_id"] = lbt_id;
 > rx_args.args["block_port"] = "1";
 >
 > radio0->set_rx_streamer(true, 0);
 > radio0->set_tx_streamer(true, 0);
 >
 > uhd::tx_streamer::sptr tx_stream = dev->get_tx_stream(tx_args);
 > uhd::rx_streamer::sptr rx_stream = dev->get_rx_stream(rx_args);
 >
 > uhd::stream_cmd_t
 > cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
 > rx_stream->issue_stream_cmd(cmd);
 > }
 
 
 ___
 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] "No upstream blocks" Warning

[Sebastian Bräuer via USRP-users]

Hi,

I am currently working on a custom rfnoc block that needs input from the
DDC but also gets samples from the host and sends them to the radio via
the DUC. The block works perfectly in simulation and even in gnuradio
but for some reason I cant get it to work in pure UHD.  In my UHD code I
always get a "No upstream blocks" warning from the DDC block and nothing
happens.
No reception and no transmission (No light on the panel) and the
registers in my block indicate that no data is flowing but UHD happily
transmits data to the FPGA.

Some info about my setup:

I am working on an X310 with the rate set to 184.32e6. My custom block
has two inputs and two outputs. Input 0 is wired to the DmaFifo and
Input 1 is connected to the DDC. Output 0 is connected to the DDC for
transmission while output 1 streams to the host.

I don't know if the warning is directly related to my problem but it is
my only guess, since it works in gnuradio. Any help would be appreciated.

The code below reproduces the warning (Unfortunately, I cant show you my
actual code):

> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[]){
>     uhd::device3::sptr dev;
>     uhd::device_addr_t hint;
>
>     hint["addr"] = "192.168.10.2";
>
>     std::cout << "Opening USRP...\n";
>     dev = uhd::device3::make(hint);
>
>     //Block Declaration
>     uhd::rfnoc::radio_ctrl::sptr radio0;
>     uhd::rfnoc::block_ctrl_base::sptr lbt;
>     uhd::rfnoc::source_block_ctrl_base::sptr ddc;
>     uhd::rfnoc::source_block_ctrl_base::sptr duc;
>     uhd::rfnoc::source_block_ctrl_base::sptr dmaFifo;
>
>     uhd::rfnoc::block_id_t radio_id_0(0, "Radio", 0);
>     uhd::rfnoc::block_id_t lbt_id(0, "lbt", 0);
>     uhd::rfnoc::block_id_t duc_id(0, "DUC", 0);
>     uhd::rfnoc::block_id_t ddc_id(0, "DDC", 0);
>     uhd::rfnoc::block_id_t dmaFifo_id(0, "DmaFIFO", 0);
>
>     radio0 = dev->get_block_ctrl(radio_id_0);
>     lbt = dev->get_block_ctrl(lbt_id);
>     ddc = dev->get_block_ctrl(ddc_id);
>     duc = dev->get_block_ctrl(duc_id);
>     dmaFifo =
> dev->get_block_ctrl(dmaFifo_id);
>     
>     dev->clear();
>         
>     uhd::rfnoc::graph::sptr graph;
>     graph = dev->create_graph("lbt_test");
>
>     graph->connect(radio_id_0,0, ddc_id,0);
>     graph->connect(duc_id,0, radio_id_0,0);
>     
>     graph->connect(lbt_id,0,duc_id,0);
>
>     graph->connect(ddc_id,0,lbt_id,1);
>     graph->connect(dmaFifo_id,0,lbt_id,0);    
>
>     uhd::stream_args_t tx_args("fc32","sc16");
>     tx_args.args["block_id"] = dmaFifo_id;
>
>     uhd::stream_args_t rx_args("fc32","sc16");
>     rx_args.args["block_id"] = lbt_id;
>     rx_args.args["block_port"] = "1";
>
>     radio0->set_rx_streamer(true, 0);
>     radio0->set_tx_streamer(true, 0);
>
>     uhd::tx_streamer::sptr tx_stream = dev->get_tx_stream(tx_args);    
>     uhd::rx_streamer::sptr rx_stream = dev->get_rx_stream(rx_args);    
>
>     uhd::stream_cmd_t
> cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>     rx_stream->issue_stream_cmd(cmd);
> }


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