date:20191024

Re: [USRP-users] [Discuss-gnuradio] Not able to find USRP N310 in host mode

2019-10-24 Thread Marcus D. Leech via USRP-users


On 10/24/2019 08:38 PM, Karthik Vasudeva wrote:

I tried, did not work.

kvasude2@veneno:~$ uhd_usrp_probe --args 
mgmt_addr=192.168.1.103,addr=192.168.10.2,type=n3xx
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
UHD_3.14.1.HEAD-0-g0347a6d8

Error: LookupError: KeyError: No devices found for ->
Device Address:
mgmt_addr: 192.168.1.103
addr: 192.168.10.2
type: n3xx

Karthik

OK, so, can you ping both of these addresses?

Is port UDP port 49152 port open on your host?




On Thu, Oct 24, 2019 at 7:26 PM Marcus D. Leech 
mailto:patchvonbr...@gmail.com>> wrote:


On 10/24/2019 03:44 PM, Karthik Vasudeva wrote:

I just tried with that address but still the same problem. Please
find the below error message

kvasude2@veneno:~$ uhd_usrp_probe --args
mgmt_addr=192.168.1.103,addr=192.168.10.2
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.14.1.HEAD-0-g0347a6d8
Error: LookupError: KeyError: No devices found for ->
Device Address:
mgmt_addr: 192.168.1.103
addr: 192.168.10.2

you'll also need to add:

type=n3xx

to the device args.




I am not sure whether my way of configuring the RJ45 port to
static is correct. Please provide pointers for the static
configuration of RJ45 port.

Karthik

On Thu, Oct 24, 2019 at 2:51 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:

Use the 192.168.1.103 address

127.0.0.1 is the address that’s used when running on the
embedded platform within the N310.



Sent from my iPhone


On Oct 24, 2019, at 1:29 AM, Karthik Vasudeva
mailto:kvasudev...@gmail.com>> wrote:


Thank you for the pointer. I tried changing the network
configuration of the RJ45 port in the embedded system by
updating the eth0.network file as follows

[Match]
Name = eth0

[Network]
Address=192.168.1.103

[Link]
MTUBytes=1500

But still the uhd_find_devices shows the same mgmt_addr in
the embedded system as shown below

root@ni-n3xx-3198219:~# uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
UHD_3.14.1.1-0-g0347a6d8
--
-- UHD Device 0
--
Device Address:
serial: 3198219
claimed: False
mgmt_addr: 127.0.0.1
product: n310
type: n3xx

Karthik



On Thu, Oct 24, 2019 at 12:04 AM Marcus D. Leech
mailto:patchvonbr...@gmail.com>>
wrote:

On 10/24/2019 12:03 AM, Karthik Vasudeva wrote:

Thank you for the clarification. Actually, I am using
the RJ45 connection through a router and tried probuhd
udp ports opening along with mgmt_addr but still the
same problem. Please find the below error message

kvasude2@veneno:~$ uhd_usrp_probe --args
mgmt_addr=127.0.0.1,addr=192.168.10.2
[INFO] [UHD] linux; GNU C++ version 7.4.0;
Boost_106501; UHD_3.14.1.HEAD-0-g0347a6d8
Error: LookupError: KeyError: No devices found for ->
Device Address:
mgmt_addr: 127.0.0.1
addr: 192.168.10.2

I used mgmt_addr shown below from the embedded system.
Please correct me if I am wrong.

127.0.0.1 is always your local host machine, so not
correct in this case.

If you read through the document I pointed you at,
you'll see that by default, that RJ45 connection uses
DHCP to get an address.  The document
  talks about changing that to a static address if you
need to.




root@ni-n3xx-3198219:~# uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.3.0;
Boost_106600; UHD_3.14.1.1-0-g0347a6d8
--
-- UHD Device 0
--
Device Address:
serial: 3198219
claimed: False
mgmt_addr: 127.0.0.1
product: n310
type: n3xx

Karthik



On Wed, Oct 23, 2019 at 11:33 PM Marcus D. Leech
mailto:patchvonbr...@gmail.com>> wrote:

On 10/23/2019 11:00 PM, Karthik Vasudeva wrote:

I tried uhd_usrp_probe again but still the same
problem. Please find the below error message

kvasude2@veneno:~$ uhd_usrp_probe --args
addr=192.168.10.2
[INFO] [UHD] linux; GNU C++ version 7.4.0;
Boost_106501; UHD_3.14.1.HEAD-0-g0347a6d8
Error: LookupError: KeyError: No devices found fo

Re: [USRP-users] uhd_fft failure

2019-10-24 Thread Saeid Hashemi via USRP-users

Yes, I did those steps as well to install gnuradio from source.
Installed the binary for python-sip, now I'm getting another error:

nuc03@nuc03:~/gnuradio/build$ /home/nuc03/gnuradio/gr-uhd/apps/uhd_fft
Traceback (most recent call last):
  File "/home/nuc03/gnuradio/gr-uhd/apps/uhd_fft", line 43, in 
from PyQt4 import Qt
ImportError: No module named PyQt4


On Mon, Oct 21, 2019 at 12:19 PM Ettus Research Support 
wrote:

> Hi Saeid - Not sure what's going on with your GR install ... did you do
> "sudo make install" after doing "make"? Did you do "sudo ldconfig" after
> installing?
>
> It looks like you need to install "python-sip" to get around this latest
> issue. Same basic method as "python-six", whatever that was that you did
> successfully. - MLD
>
> On Fri, Oct 18, 2019 at 3:19 PM Saeid Hashemi via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Okay, so installing python-six fixed that, and I was able to install
>> 3.7.13.5 from source.
>> The sample apps like uhd_fft are not in the path like they used to be
>> with binary installation. And trying it from the apps folder gives me:
>>
>> nuc03@nuc03:/usr/local/bin$ /home/nuc03/gnuradio/gr-uhd/apps/uhd_fft
>> Traceback (most recent call last):
>>   File "/home/nuc03/gnuradio/gr-uhd/apps/uhd_fft", line 39, in 
>> import sip
>> ImportError: No module named sip
>>
>>
>> On Thu, Oct 17, 2019 at 10:26 AM Michael Dickens <
>> michael.dick...@ettus.com> wrote:
>>
>>> Yes sorry about the GR37 release version: 3.7.13.5 is the correct on.
>>> Installing Py27-six should be pretty straight forward & should allow you to
>>> proceed with that install. GR38 has it's own set of dependencies, some of
>>> which overlap with GR37 and some of which don't. You'll want to follow the
>>> install guide for your OS to get those dependencies. Good luck! - MLD
>>>
>>> On Wed, Oct 16, 2019 at 3:02 PM Saeid Hashemi  wrote:
>>>
 Hi Michael,

 The gnuradio git repository does not have a tag for v3.17.14.5, and
 using v3.7.13.5 gives me:

 -- Python checking for six - python 2 and 3 compatibility library
 -- Python checking for six - python 2 and 3 compatibility library - not
 found
 CMake Error at volk/CMakeLists.txt:98 (message):
   six - python 2 and 3 compatibility library required to build VOLK


 -- Configuring incomplete, errors occurred!
 See also "/home/nuc03/gnuradio/build/CMakeFiles/CMakeOutput.log".
 See also "/home/nuc03/gnuradio/build/CMakeFiles/CMakeError.log".


 Checking out tag v3.8.0.0 results in Cmake dependency of 3.8 and up, so
 I need to install that manually.


 On Sat, Oct 12, 2019 at 11:02 AM Michael Dickens <
 michael.dick...@ettus.com> wrote:

> OK. Thanks for the info Saeid. I'll look into creating a VM using
> Ubuntu 16.04.1 to see what happens. - MLD
>
> On Fri, Oct 11, 2019 at 4:47 PM Saeid Hashemi 
> wrote:
>
>> It's Ubuntu 16.04.1, but yes, I will follow the source build
>> instructions.
>>
>> On Fri, Oct 11, 2019 at 3:11 PM Michael Dickens <
>> michael.dick...@ettus.com> wrote:
>>
>>> Hi Saeid - Thanks for the followup. I totally agree that if you just
>>> "sudo apt install gnuradio", compatible versions should be installed. 
>>> Are
>>> you using Ubuntu 16.04.6 LTS (Xenial Xerus)? If you choose to install 
>>> from
>>> source, you can follow instructions such as the GR recommended way here 
>>> <
>>> https://wiki.gnuradio.org/index.php/UbuntuInstall#Xenial_Xerus_.2816.04.29
>>> >. I have an Ubuntu 18.04 install that went very smoothly using this 
>>> >guide,
>>> but maybe the guide is outdated for older Ubuntu; or, our packages need 
>>> to
>>> be updated for that OS version ... Cheers! - MLD
>>>
>>> On Fri, Oct 11, 2019 at 2:24 PM Saeid Hashemi 
>>> wrote:
>>>
 I will follow your advice, but it's worth mentioning I simply did
 apt-get gnuradio and should therefore have a compatible version of uhd
 installed automatically as a dependency. I did not install uhd 
 separately.

>>> --
>>> Michael Dickens
>>> Ettus Research Technical Support
>>> Email: supp...@ettus.com
>>> Web: https://ettus.com/
>>>
>>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>

>>>
>>> --
>>> Michael Dickens
>>> Ettus Research Technical Support
>>> Email: supp...@ettus.com
>>> Web: https://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

[USRP-users] Error when trying to run USRP N310s using external LO

2019-10-24 Thread Mark Wagner via USRP-users

Hi all,

I'm currently trying to run a set of USRP N310s all using the same external
LO, but I seem to be getting this error

"[ERROR] [0/Radio_1] RX LO lowband does not support setting source to
external"

which will repeat for all the radios. I tried looking online for the source
of the error but no dice. It seems like the radios are ignoring the LO I'm
giving them and using their internal ones instead. Any thoughts?

-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-users] E320 Multi TX Stream Operation in GR 3.8 stops during configuration of the USRP sink

2019-10-24 Thread Sam Reiter via USRP-users

Alex,

I suspect this is something specific to GNU Radio 3.8, but it's not
something I've seen up to this point. To help narrow down the problem,
could you run your test flowchart on GNU Radio 3.7 and report back the
results?

Sam

On Tue, Oct 22, 2019 at 8:11 AM Alexander W via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey,
>
> I am currently setting up an E320 and want to use both TX Chains
> simultaneously. I first did the benchmark_rate test:
>
> $ ~/pybombs_gnuradio/lib/uhd/examples/benchmark_rate--args
> "addr=192.168.10.2"--duration 60--channels "0,1"--rx_rate 1e6
>  --rx_subdev "A:0 A:1"
>
> This ran fine and I moved over to gnuradio. The test flowchart consists of
> two sine signal sources as input for one sink block. Arguments in the USRP
> sink block are set to the following:
>
> - Device Address: addr=192.168.10.2
> - Mb0: SubDev Spec: A:0 A:1
> - Num Channels: 2
>
> Rest of the arguments are the default values. Starting the flowchart
> returns:
> ...
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
>
> >>> Done (return code -11)
>
> I tried to see where this comes from. The segfault is triggered after a
> call to set the center frequency of the second channel:
> ...
> self.uhd_usrp_sink_0 = uhd.usrp_sink(
> ",".join(('addr=192.168.10.2', "")),
> uhd.stream_args(
> cpu_format="fc32",
> args='',
> channels=[],
> ),
> '',
> )
> self.uhd_usrp_sink_0.set_subdev_spec('A:0 A:1', 0)
> self.uhd_usrp_sink_0.set_center_freq(freq, 0)
> self.uhd_usrp_sink_0.set_normalized_gain(0.5, 0)
> print("91")
> self.uhd_usrp_sink_0.set_antenna('TX/RX', 0)
> print("93")
> self.uhd_usrp_sink_0.set_center_freq(freq, 1)
> <-- Segfault appears in this call
> print("95")
> self.uhd_usrp_sink_0.set_normalized_gain(0.5, 1)
> print("97")
> self.uhd_usrp_sink_0.set_antenna('TX/RX', 1)
> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
> ...
>
> Used UHD Version: UHD 3.14.1.1-0-g0347a6d8
> Used GR Version: 3.8.0.0
>
> Did anyone run into the same issue? As the error code is during the config
> call I am not sure if this connected to a wrong config or something else.
>
> Thanks in advance. Regards,
> Alex
> ___
> 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] N310 generation of a project/bit file from Ettus design (HG version)

2019-10-24 Thread Samuel Berhanu via USRP-users

Problem ended up being the specific tag/repo version i made the bit file
from. The hash I was at was f114cfa0d. Curiously, the golden bitfile from
the Ettus server, at least for this specific version, does not load.

Colleague suggested to try it with a different bit file/version  and that
seems to do the trick.

It still stumps me that I can't find out what the issue is with the I2C
expander but for now, I might have to give up on that considering the time
spent and no response.

On Tue, Oct 22, 2019 at 1:58 PM Samuel Berhanu  wrote:

> As I have mentioned a bit earlier, I have noticed that there was an issue
> trying to run a no-Os setup but was not getting ACK from the TCA9548
> expander. [Curious if anyone has gone the no-Os route and found an issue
> there.]
>
> I went ahead and proceeded to make a bin file from a HG bit file  (used
> the Xilinx SDK gui to generate a bin file.
>
> The entry in the swif file  is the following:
>
> //arch = zynq; split = false; format = BIN
> all:
> {
>
> /home/berhas1/fluffybunny/fluffy_with_NI/usrp3/top/n3xx/build-N310_HG/n3xx.bit
> }
>
> I copied the generated file into the SDcard /primary/lib/firmware folder
> and renamed the n3xx.bit.bin to n310.bin.
>
> My thought was that this bin file should work with the dtbo already there
> in the design. After loading the bin file using fpga-manager (dto method)
> or even hard rebooting the machine, it looks like the kernel is panicking
> and not able to correctly load some drivers or addresses.
>
> Does this mean that, even for a generic untouched HG design, i would have
> to go through the process of making a dtbo (hence generating a device tree
> from Xilinx SDK)?
>
> Here is the terminal output when the error happens at bin file writing
> time:
>
> [  OK  ] Started Network Name Resolution.
> [  OK  ] Reached target Network.
> [  OK  ] Started Mender OTA update service.
> [  OK  ] Reached target Host and Network Name Lookups.
> [   12.860517] macb e000b000.ethernet eth0: link up (1000/Full)
> [   13.889925] fpga_manager fpga0: writing n310.bin to Xilinx Zynq FPGA
> Manager
> [   15.012332] libphy: nixge_mii_bus: probed
>
> [   15.036810] libphy: nixge_mii_bus: probed
> [   15.040902] Unhandled fault: imprecise external abort (0x1406) at
> 0x004f1dcc
> [   15.047895] pgd = eddec000
> [   15.050572] [004f1dcc] *pgd=
> [   15.054138] Internal error: : 1406 [#1] PREEMPT SMP ARM
> [   15.055350] nixge 4000.ethernet sfp0: renamed from eth1
> [   15.064894] Modules linked in:
> [   15.067932] CPU: 0 PID: 194 Comm: python3 Not tainted
> 4.12.26-yocto-standard #1
> [   15.075225] Hardware name: Xilinx Zynq Platform
> [   15.079736] task: ee0063c0 task.stack: edde8000
> [   15.084259] PC is at nixge_mdio_read+0x90/0x180
> [   15.088763] LR is at 0x280
> [   15.091801] pc : []lr : [<0280>]psr: 80030013
> [   15.091801] sp : edde9a58  ip : 0018  fp : edde9a7c
> [   15.103270] r10: edcb5078  r9 : 0003  r8 : 804dd639
> [   15.108467] r7 :   r6 : 000f4240  r5 : edc9f500  r4 : 0081
> [   15.114980] r3 :   r2 : 0008  r1 : 0003  r0 : 803e93f9
> [   15.121491] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>  Segment none
> [   15.128609] Control: 18c5387d  Table: 2ddec04a  DAC: 0051
> [   15.134335] Process python3 (pid: 194, stack limit = 0xedde8210)
> [   15.140324] Stack: (0xedde9a58 to 0xeddea000)
> [   15.144663] 9a40:
> e000 0001
> [   15.152834] 9a60: edcb5000 0004 40010006 edcb5058 edde9abc edde9a80
> c05dcc50 c05ed554
> [   15.161005] 9a80: edde9adc edde9a90 c016df5c c016d8a4 edde9ab4 edde9af4
> 0001 edcb5000
> [   15.169166] 9aa0: 0004 0001  edcb5078 edde9adc edde9ac0
> c05dab88 c05dcbf4
> [   15.177326] 9ac0: edcb5000 0004 edde9af4 0001 edde9b44 edde9ae0
> c05dbf98 c05dab68
> [   15.185484] 9ae0:  edc0cb80 edde9b24 edde9af8 c06ed628 
>  
> [   15.193642] 9b00:      
> edde9b44 edc18300
> [   15.201802] 9b20: 0001 edcb5000 0004   edcb5078
> edde9b74 edde9b48
> [   15.209962] 9b40: c06f4144 c05dbf30 edde9b74 edde9b58 c06f4564 c06ed6bc
> edcb5000 edc18f80
> [   15.218120] 9b60: edc18300 0004 edde9bac edde9b78 c06f46e4 c06f4050
>  
> [   15.226280] 9b80: edde9ba4 edc9f000 edcb5000 ee00c200 edc9f500 edc18f80
> 0006 
> [   15.234440] 9ba0: edde9bdc edde9bb0 c05ed900 c06f45dc c0146e68 0006
> ee00c210 c05ed6c8
> [   15.242599] 9bc0: ee00c210 c0d80314  c0d80314 edde9bfc edde9be0
> c05701c4 c05ed6d4
> [   15.250758] 9be0: ee00c210 c0e35150   edde9c24 edde9c00
> c056e330 c0570170
> [   15.258917] 9c00: c0d80314 ee00c210 edde9c70 ee00c244 c0e3512c 
> edde9c44 edde9c28
> [   15.267076] 9c20: c056e5a0 c056e12c edde9c70 c056e4fc  ee00c244
> edde9c6c edde9c48
> [   15.275235] 9c40: c056c7c8 c056e508 ef16e06c ee6d3d38 ee00c210 ee00c210
> c0d73658 0001
> [

Re: [USRP-users] Controlling an X310 from embedded devices

2019-10-24 Thread Muri, Richard - 1002 - MITLL via USRP-users

That was my concern and why I want to control it from an FPGA. My initial 
thought was I use an FPGA to fill the data buffers with DMA and then use an ARM 
to handle the control flow, but that doesn’t help me receive data at the rates 
the x300 series is capable of supplying. Is there a way to accept received 
packets into a DMA?

 

Alternatively, how crazy would it be to use an ARM for the 
initialization/configuration, and then build the appropriate data and command 
packets in FPGA and send those directly to the USRP?

 

Thanks,

Richard

 

From: Marcus D Leech  
Sent: Wednesday, October 23, 2019 10:54 PM
To: Nick Foster 
Cc: Muri, Richard - 1002 - MITLL ; 
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Controlling an X310 from embedded devices

 

I run B210 from an Odoid XU4 platform and can get up to about 12Msps out of it, 
depending on what I’m doing. 

 

But no way you’ll do the 10s of Msps that the X3xx series is capable of. 

Sent from my iPhone





On Oct 23, 2019, at 8:35 PM, Nick Foster via USRP-users 
mailto:usrp-users@lists.ettus.com> > wrote:



You should have no trouble running UHD on an ARM architecture. The Ettus E300 
series radios are ARM devices. UHD does a huge amount of initialization and 
configuration for the X310, and in any case the X310 doesn't use VRT in any 
real capacity. You won't realistically be able to divorce the X310 from UHD.

 

Your biggest headache on an embedded machine will be keeping up with high data 
rates, and waiting for UHD to compile in the first place. =)

 

Nick

 

On Wed, Oct 23, 2019 at 4:59 PM Muri, Richard - 1002 - MITLL via USRP-users 
mailto:usrp-users@lists.ettus.com> > wrote:

Hello,

 

I’m looking into controlling an X310 from an embedded device. I wanted to probe 
the users list before I bury myself into a rabbit hole.

 

Is it possible to control a USRP directly from an FPGA? I noticed that UHD use 
VRT as the transport protocol (http://files.ettus.com/manual/page_rtp.html). If 
I have an FPGA that speaks VRT over Ethernet or Aurora can I control a USRP, 
and are there examples/documentation of controlling a USRP without running an 
instance of UHD? In my use case I need to send timed transmit commands and data 
packets, and timed receive commands and receive data packets. 

 

In the case that running without UHD is a headache I don’t want to brave, are 
there examples of running UHD on ARM cores?

 

Any insight is appreciated.

 

Thanks,

Richard

 

 

___
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



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] X310 and N310: using multiple RF

2019-10-24 Thread BERTOLINI Rodolphe via USRP-users

Hello USRP-users mailing list,

We are using an X310 for OpenAirInterface (OAI). It has one RF card.
I wonder the following:


  *   With the following configuration:
 *   USRP X310, HG image, one RF card
 *   host connected to USRP through 1*10Gbps and 1*1Gbps
  *   I run OAI on the 10Gbps ethernet interface, and while it is running I 
tried to run an other instance via the 1Gbps ethernet interface. I didn't 
expect it to work, but I didn't expect neither the error message: uhd tells me 
that no USRP was found (I made sure it looks-up through the 1Gbps interface).
 *   My interpretation is that once that all of the available RF cards have 
an established link with the host, USRP closes all of the free interfaces 
(PCIe, ethernet...)
 *   Thus, if I put an other RF card, and tell the USRP to use only one 
ethernet interface per RF card, then I would be able to run one OAI instance 
through an ethernet interface + an RF card, and an other instance through the 
other ethernet interface + the other RF card. Is it correct?
 *   Now if we consider the N310, its 4 RF cards and its 2 ethernet 
interfaces: (ignoring limitation from OAI bandwidth requirements) is it 
possible to run two instances of OAI through a single ethernet interface, so 
that I could run four instance through two ethernet interfaces?
 *   If all of the above is correct, do you have any idea on how to achieve 
this?

Thank you
Regards,
Rodolphe
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [Discuss-gnuradio] Not able to find USRP N310 in host mode

Re: [USRP-users] uhd_fft failure

[USRP-users] Error when trying to run USRP N310s using external LO

Re: [USRP-users] [usrp-users] E320 Multi TX Stream Operation in GR 3.8 stops during configuration of the USRP sink

Re: [USRP-users] N310 generation of a project/bit file from Ettus design (HG version)

Re: [USRP-users] Controlling an X310 from embedded devices

[USRP-users] X310 and N310: using multiple RF

7 matches

Site Navigation

Mail list logo

Footer information