On 05/18/2018 05:55 PM, harfan ryanu via USRP-users wrote:
> Hi All,
> I have question related to two function in UHD. There is a function to
> choose subdev (set_tx/rx_subdev_spec) and set antenna
> (set_tx/rx_antenna). What is the difference between these two function?
> If i choose for example s
Hi,
Yes, Its B210 and works with other example like tx_ofdm.
Ayaz
From: Martin Braun
Sent: Wednesday, June 13, 2018 3:22:57 PM
To: Ayaz Mahmud; discuss-gnura...@gnu.org; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] TX-RX file through OFDM errors
O
On 05/12/2018 05:17 AM, EJ Kreinar via USRP-users wrote:
> I also find this confusing...
>
> Even better: how about a scheme where x3xx finds both x300/x310, but
> x310 only gets x310, etc??
We use the 'product' key for that.
-- M
___
USRP-users maili
On 05/01/2018 05:13 AM, Ronakraj Gosalia via USRP-users wrote:
> Hi everyone,
>
> I am using a USRP E312 with GNU Radio 3.7.10.2. GNU Radio has an inbuilt
> FEC block that supports Turbo Product Codes (TPC). I'm trying to run a
> flowgraph (completely in simulation) on the E312 that includes a TPC
On 01/26/2018 02:28 AM, Дмитрий Михайличенко via USRP-users wrote:
> Hi,
>
> I am trying to do FFT using corresponding RFNoC block in X310. It works
> if FFT size is 1024 but fails if the size is 2048 or 4096. The block
> does not return any data and I see the following errors in uhd:
>
> [ERROR]
It's the right file, however, this kind of modification is outside of
the scope of what we can help you with. Good luck!
-- M
On 06/13/2018 02:49 PM, Farhad Mirkazemi wrote:
> Hello martin,
>
> Thanks for your reply;meanwhile, I am modifying/setting the r divider to
> "2" in the clock_ctrl.cpp o
I assume you're using a BasicRX/TX combo and a recent UHD version (3.11
and above).
How exactly are you using receiving? Are you sending a single stream
command, or multiple stream commands? If its the latter, are you setting
time stamps?
-- M
On 06/05/2018 11:25 AM, Nicolai Kern via USRP-users
Thanks again; I figured my second question.Have a great day.
On Wednesday, June 13, 2018, 5:50:31 PM EDT, Farhad Mirkazemi via
USRP-users wrote:
Hello martin,
Thanks for your reply;meanwhile, I am modifying/setting the r divider to "2" in
the clock_ctrl.cpp of usrp2 to be able to us
On 06/07/2018 03:55 AM, Derek Kozel via USRP-users wrote:
> Hello Walter,
>
> The N310 uses MPMD as it's host side interface so the appropriate flag
> is -DENABLE_MPMD. I'll see about documenting that better. The E3xx build
> flag is entirely separate.
> http://files.ettus.com/manual/page_usrp_n3x
Matis,
you also need to keep in mind that via USB, we can only receive a
certain amount of samples at a time, and it's not a factor of 16384.
-- M
On 06/08/2018 04:18 PM, Marcus Müller via USRP-users wrote:
> Hi Matis,
>
> the time stamp of the first buffer after a disruption should indeed be
>
Hello martin,
Thanks for your reply;meanwhile, I am modifying/setting the r divider to "2" in
the clock_ctrl.cpp of usrp2 to be able to use 20 MHz clock reference instead of
10 MHz. Am I modifying the correct file?
Thank you in advance
On Wednesday, June 13, 2018, 5:16:38 PM EDT, Martin
On 06/09/2018 12:59 PM, Zhongyuan Zhao via USRP-users wrote:
> Hi,
>
> I was configuring N310 for the first time. My UHD version is 3.12 with
> branch of python-api,
>
> When I try to update the SD image of firmware, according to
> the https://kb.ettus.com/N300/N310_Getting_Started_Guides
>
>
I'm not sure this is the XML file. It looks like the traffic is going
from your block to the radio block controller because the outgoing SID
is not set properly.
However, the outgoing ctrl_iface SID is derived from the incoming
packet. Have you had other blocks work in the past?
Did it stop working
On 06/11/2018 12:42 PM, Luis Felipe Albarracin Sanchez via USRP-users wrote:
>
> Hello all,
>
> I am having an Issue when trying to test a model with a USRP B210, i
> have instaled GNURadio, via:
>
> *$ apt install gnuradio*
>
> then i tried to connect mi USRP to the model, but the followig er
Two more comments:
- The clock is not exported by default. So MB 1 won't see a reference
clock, and then you get the error you saw.
- You can get frequency alignment between the boards this way, but the
time will definitely be un-aligned, like Michael said.
-- M
On 06/11/2018 03:38 PM, Michael W
I would expect it grow indefinitely, but it might slow down after 1.2
MB. If repeat is on, expect lots of data.
The 106 bytes vs. 64 bytes is more interesting. I don't see why, but
maybe somewhere the last 42 bytes are getting stuck. It might even be in
GNU Radio.
Try a file that's a multiple of
On 06/12/2018 10:28 AM, Ayaz Mahmud via USRP-users wrote:
> Hi,
>
>
>
> I am trying to transmit and receive a .png file through OFDM (*Block
> diagram attached*). The file size is only 1.5kB. While running I am
> getting the below warning & error in console. Can someone point out the
> reason b
On 06/13/2018 12:30 AM, ishai alouche via USRP-users wrote:
> Hi all,
>
> I open with rfnocnodtool new block with the name siggen like the block
> that exist in the basic rfnoc block in the gnu-radio. So i have two
> rfnoc block with the same name in different directory.
> I decide to delete the n
On 06/13/2018 12:49 PM, Farhad Mirkazemi via USRP-users wrote:
> I'm trying to manipulate my usrp2 clock using the example clock_ctrl.cpp
> but when I try to build it, I get cmake error related as following; the
> warning should be ok but I don't understand the error which says it does
> not know L
On 06/13/2018 03:23 PM, Sylvain Munaut via USRP-users wrote:
Hi,
So the question is: Is it possible to modify something ins the firmware in
order to establish only USB 3.0 connections?
The USB3-only behavior of the ICRON USB3-over-fiber is one of the
reasons that I rejected it as a solution
Hello all,
I'm trying to manipulate my usrp2 clock using the example clock_ctrl.cpp but
when I try to build it, I get cmake error related as following; the warning
should be ok but I don't understand the error which says it does not know
LIBUHD_REGISTER_COMPONENT. Can any of you possibly help m
Just a follow-up, for anyone wondering:
The system worked flawlessly. And, as expected, a SATA-3 SSD is not fast
enough to store a dual, 200 MSps (6.4 Gbps x 2) stream from an X310 on the
fly, but saving files to RAM works great for now.
By the way, a quick advice for everyone: always check the m
This is the connector :
https://www.digikey.com/product-detail/en/te-connectivity-amp-connectors/1-1734261-2/A98759CT-ND/1855540
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-us
Hi,
> So the question is: Is it possible to modify something ins the firmware in
> order to establish only USB 3.0 connections?
The problem is that there is no firmware when you first plug it :)
It relies on the FX3 boot rom to download the code into USB and this
USB boot mode only supports USB 2
I’ve scoured the web looking for more details about the side connector pins
(jtag/gpio) on the B200/205 mini, and haven’t been able to find much. Is there
a standard part number for the connector for fabricating a wiring
harness/pigtail? I’m aware of the adapter cables Ettus sells, I have some o
Hi Anisha,
There's a quick gotcha here: the "no_reload_fpga" flag also skips
programming the FPGA when *starting* the program.
You should try programming the FPGA manually before running with
"no_reload_fpga": `cat imagename.bit > /dev/xdevcfg`
Cheers,
EJ
On Wed, Jun 13, 2018 at 10:24 AM Anisha
Koen
OK a few low level H/W and CHDR hints to help you along:
“Time” when we talk about the H/W and how it’s implemented is a 64bit value
that counts in units of 1/master_clock_rate which for X310 is generally 5nS.
The reference for time is a 64bit counter that’s driven from a block called
“ti
Hello,
Recently we bought a B200mini-i USRP. Since the datasheet shows that this
USRP uses a high-speed USB 3.0 connection, we were using a host with a USB
3.0 port which was not backwards compatible with USB 2.0. We can't get the
USRP being recognized through this USB 3.0 host so far.Testing it
On 06/13/2018 11:13 AM, RizThon via USRP-users wrote:
Hi all,
I have a C program that uses SoapySDR that works for a LimeSDR but I'm
having troubles with a B210.
I'm simply receiving as many samples as possible by packets of 680
samples, in mono channel, at 56MS/s. Soon after starting the pr
Hi all,
I have a C program that uses SoapySDR that works for a LimeSDR but I'm
having troubles with a B210.
I'm simply receiving as many samples as possible by packets of 680 samples, in
mono channel, at 56MS/s. Soon after starting the program, I only receive
260 samples instead of 680. I close t
Hi,
Is there a way to run the e310 without loading the idle image after
completion? I saw from here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-September/021984.html
that there is a flag you can pass called "no_reload_fpga", however, when
I try uhd_usrp_probe --args=no_r
On 06/13/2018 05:43 AM, Ivan Zahartchuk via USRP-users wrote:
Hello. I'm trying to write a block in gnuradio for broadband reception.
The main problem at the moment is to transfer data to the fft block.
I'm new to python and so it's hard for me to figure this out.importnumpyasnp
I need an arra
Hello. I'm trying to write a block in gnuradio for broadband reception.
The main problem at the moment is to transfer data to the fft block.
I'm new to python and so it's hard for me to figure this out.import numpy as np
I need an array of data to pass to the gnuradio.fft.fft.vcc block
from gnur
Hi all,
I open with rfnocnodtool new block with the name siggen like the block that
exist in the basic rfnoc block in the gnu-radio. So i have two rfnoc block
with the same name in different directory.
I decide to delete the new block the i created.
So i stared to delete all the files that i creat
34 matches
Mail list logo