Re: [USRP-users] blocking one of channel in multi usrp

[harfan ryanu via USRP-users]

Hi Marcus,
I have tried setting the tx_subdev "A:0 B:0 A:0 B:0" probably you mean only
"A:0 B:0" since it produce another error saying input port already
connected. I have tried another several benchmark configuration as follow:
1. ./benchmark_rate --tx_rate "1e6" --args "addr=192.168.40.2" --tx_subdev
"A:0 B:0" --channel "0,1" or ./benchmark_rate --tx_rate "1e6" --args
"addr=192.168.50.2" --tx_subdev "A:0 B:0" --channel "0,1" --> result
success with 0 error
2. ./benchmark_rate --tx_rate "1e6" --args "addr0=192.168.40.2,
addr1=192.168.50.2" --tx_subdev "A:0 B:0 A:0 B:0" --channel "0,1,2,3" --ref
"external" --pps "external" --> produce error Error: RuntimeError: On node
0/DmaFIFO_0, input port 0 is already connected.
3. ./benchmark_rate --tx_rate "1e6" --args "addr0=192.168.40.2,
addr1=192.168.50.2" --tx_subdev "A:0 B:0" --channel "0,1,2,3" --ref
"external" --pps "external"--> only 2 out of 4 red LED is On for a few
second, and the benchmark rate freeze at [00:00:06.374504] Testing transmit
rate 1.00 Msps on 4 channels.
4. ./benchmark_rate --tx_rate "1e6" --args "addr0=192.168.40.2,
addr1=192.168.50.2" --tx_subdev "A:0 B:0" --channel "0,1" --ref "external"
--pps "external"--> only 1 out of 2 red LED is On for a few second, and the
benchmark rate freeze at [00:00:06.374504] Testing transmit rate 1.00
Msps on 4 channels.

When i change -tx_rate in all the 4 test into --rx_rate. They work pretty
well and not produce any error. It seems the problem only come when i try
to create multi usrp object and it only happen during TX only. Even in
fourth test i only use channel 0 & 1 which in only exist in first USRP, the
problem still occurs. All the error after the freeze creates error message
saying BIST failed (code:1) if i try to re run the benchmark test, and i
have to turn on and of the power of the USRP.

Do you have any idea why it could happen? I have configure the cpufreq-info
and net.core.rmem_max & wmem_max to 5000 and sudo ethtool -G tx 4078 rx
4078 to both usrp interface to no avail. What confuse me is why it is only
happen during TX, while the RX is doing fine. I attach the benchmark test
run output below until the freeze occurs.

Thank you for your respond

Regards,
Harfan




./benchmark_rate --tx_rate "1e6" --args "addr0=192.168.40.2,
addr1=192.168.50.2" --tx_subdev "A:0 B:0" --channel "0,1,2,3" --ref
"external" --pps "external"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.11.1.0-release
[WARNING] [UHD] Unable to set the thread priority. Performance may be
negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam

[00:00:00.02] Creating the usrp device with: addr0=192.168.40.2,
addr1=192.168.50.2...
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [GPS] No GPSDO found
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1317 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [GPS] No GPSDO found
[INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1304 MB/s)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
[INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0)
Using Device: Multi USRP:
  Device: X-Series Device
  Mboard 0: X310
  Mboard 1: X310
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
  RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: UBX RX
  RX Channel: 2
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
  RX Channel: 3
RX DSP: 0
RX Dboard: B
RX Subdev: UBX RX
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
  TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: UBX TX
  TX Channel: 2
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
  TX Channel: 3
TX DSP: 0
TX Dboard: B
TX Subdev: UBX TX

Now confirming lock on clock 

Re: [USRP-users] DC power supply for E313

[Neel Pandeya via USRP-users]

Hello Jong:

I think Robin answered this in a separate thread with you, so I'm just
responding to conclude this thread.

The behavior that you describe is a result of a corrupted bit in the AVR
EEPROM firmware that results in the power-on sequence requiring the power
button to be pushed. This corruption can occur when power is abruptly
removed from the device, instead of powering it down cleanly. The most
straightforward way to resolve this issue is to RMA your E313. The latest
revision of the E313 always powers on when power is applied, and ignores
the state of the power button.

--​Neel Pandeya




On 3 May 2018 at 00:50, liu Jong via USRP-users 
wrote:

> Hi all,
> We know that when we insert network cable to e313,the e313 will power on
> and press power button is not needed. Now,we take DC power supply(12V) for
> e313,and we must press power button of e310 and then power on.
> It is normal?How can we achieve power on and no press power button with DC
> power supply for e313?
>
> thank you.
> best regards
> Jon
>
> ___
> 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] Rx streaming to alternate destination

[Neel Pandeya via USRP-users]

Hello Rob:

This capability is not supported with the multi_usrp API on the X300, X310,
N310.

It was supported on the N200/N210.

https://files.ettus.com/manual/page_usrp2.html#usrp2_altstream

However, this capability is supported for the X300, X310, N310 using the
RFNoC API.

--​Neel Pandeya
​408-610-6370




On 7 May 2018 at 15:55, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I am using UHD from a custom c++ application and I would like to control
> the USRP from one port and send the Rx streaming samples to a separate
> application at a different IP address using the other USRP SFP port.  I
> found in the documentation for stream_args_t that there are "port" and
> "addr" args that can be set to send the streaming to an alternate
> destination.
>
> When I specify these args, I am not seeing traffic on the specified
> addr/port.  This occurs using an N310.  I would like this functionality to
> work for both X310 and N310.  I am wondering if I am missing a step or
> two.  Please let me know.
>
> Rob
>
> ___
> 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] BRAM usage of the X300/X310 design

[Reinhold Frederick William Hollender via USRP-users]

There's a map option in ise that will give a very detailed listing if the
resource usage of every block in your design hierarchy.  I'm sure there's
something similar for vivado.

I can't remember the name of it, but I'm sure you can find it if you search
around a little.

Regards,
William

On Sat, May 19, 2018, 11:56 AM Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> We don't have a more-granular usage report for FPGA utilization. But you
> can experiment by removing blocks that you don't need, and seeing how many
> resources free up as a result.
>
> What is the error that you're seeing? Which version of Vivado are you
> using? Are you using the rfnoc-devel branch, or a tagged release such as
> 3.10.3.0 or 3.11.0.1?
>
> --​Neel Pandeya
>
>
>
>
> On 23 April 2018 at 01:04, Nives Novković via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Martin,
>>
>> I saw that utilization report but as I can see it is not divided by
>> blocks, it just says the complete usage of resources? I understand about
>> not being able to provide the support for a completely stripped design,
>> that is not my intention. I have also tried to build the project following
>> the instructions but I got the error about design not satisfying timing
>> constraints.
>>
>> Kind regards,
>> Nives
>>
>> 2018-04-19 23:18 GMT+02:00 Martin Braun :
>>
>>> On 04/19/2018 07:35 AM, Nives Novković via USRP-users wrote:
>>> > I can see by the official numbers that the default Ettus FPGA design on
>>> > X310 takes about 50% BRAM and on X300 about 90%. I would like to make
>>> my
>>> > own design for Ettus but use only ADC and Ethernet cores from the
>>> > default design. Does anybody know how much BRAM blocks would only those
>>> > 2 cores from the original design take up? Thank you in advance!
>>>
>>> Our current UHD images packages (which you get when you run
>>> uhd_images_downloader) include a utilization report. I'm assuming you
>>> mean you want to remove all RFNoC blocks except for the radio -- if you
>>> really want to remove *everything*, that would be an invasive change,
>>> for which we wouldn't be able to provide any support.
>>>
>>> -- M
>>>
>>
>>
>> ___
>> 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] B200/ADI9361 - Influence of master clock rate on EVM

[Sylvain Munaut via USRP-users]

Or actually it might just be that the usrp_dev->get_rx_bandwidth()
call doesn't return what's really programmed.
Looking at _setup_rates, the var _baseband_bw is setup there.

In case (1) I have rate=N and divfactor=32  (as I mentionned in the
first mail, I force FIR 4x interp here) and _baseband_bw will end up
being N
In case (2) I have rate=2*N  and divfactor=16, so _baseband_bw will
end up being 2*N

Thanks for the pointer !

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] B200mini sc12 wire format broken?

[Neel Pandeya via USRP-users]

Hello Emanuel:

Could you please post the error message from the console?

Does this error persist in UHD 3.11.1.0?

--​Neel Pandeya




On 4 May 2018 at 06:51, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/04/2018 01:45 AM, Emanuel via USRP-users wrote:
>
> Hi,
>
>
>
> I switched from UHD release 3.10.2.0 to the latest release 3.11.0.0 and
> recognized in my Gnuradio application, that UHD gives errors when using the
> sc12 wire format. However, only when I use the USRP in receive mode. In
> transmit mode, the sc12 format works. The sc8 and sc16 wire format work
> well for the receive mode. The same issue comes with 3.11.0.1.
>
> Release 3.10.2.0 does not show this error.
>
>
>
> Did anyone else experience that?
>
>
>
> Best regards,
>
> Emanuel
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Could you perhaps share the error log?  That would help developers and
> others...
>
>
>
>
> ___
> 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] Build E310_sg3.bit problem

[Артем Асадчий via USRP-users]

Hi everyone,

I've got a problem, when try to build E310_sg3.bit:

ERROR: [Place 30-487] The packing of instances into the device could not be
obeyed. There are a total of 13300 slices in the pblock, of which 7850
slices are available, however, the unplaced instances require 9752 slices.
Please analyze your design to determine if the number of LUTs, FFs, and/or
control sets can be reduced.
ERROR: [Place 30-99] Placer failed with error: 'Detail Placement failed
please check previous errors for details.'
[00:10:36] Current task: Placer +++ Current Phase: 3.5 Small Shape Detail
PlacemERROR: [Common 17-69] Command failed: Placer could not place all
instances
[00:10:37] Current task: Placer +++ Current Phase: 3.5 Small Shape Detail
Placement
[00:10:37] Current task: Placer +++ Current Phase: Finished
[00:10:37] Process terminated. Status: Failure


Warnings:   560
Critical Warnings:  39
Errors: 3

Makefile.e300.inc:103: recipe for target 'bin' failed
make[1]: *** [bin] Error 1
make[1]: Leaving directory '/home/artyom/workspace/ettus/
rfnoc/uhd/fpga-src/usrp3/top/e300'
Makefile:63: recipe for target 'E310_sg3' failed
make: *** [E310_sg3] Error 2

How can i solve this problem?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How do I interface my X310 to a NVIDIA K80 GPU

[Neel Pandeya via USRP-users]

Hello LJ Eads:

There are some tutorials that will help you get started with GNU Radio.

https://kb.ettus.com/Suggested_Videos

The UHD USRP Source and UHD USRP Sink blocks in GNU Radio represent your
X300/X310 radio. The source block is for receiving samples, and the sink
block is for transmitting samples.

Which 10 Giagbit Ethernet card are you using? The Intel X520-DA2, X540-DA2,
and X710-DA2 cards work very reliably under Ubuntu 16.04.4.

Please let me know if you have any further questions.

--​Neel Pandeya
​408-610-6370




On 2 May 2018 at 05:14, Eads, LJ D. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I just setup a X310 that I plan on using with GNURadio over 10 gigabit.. I
> have everything working and functioning properly (drivers and all) but my
> only concern right now is that GNURadio is running off of the sound card on
> my server and not the GPU. GNURadio isn't able to handle practically
> anything because I am limited by the sound card capability.
>
> How  would I be able to use the CPU (Sixteen-Core Intel Xeon Processor
> E5-2683 v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU
> Computing Accelerator - 24GB GDDR5 - Passive Cooler) for better
> functionality of the X310?
>
> Thank you,
>
> LJ Eads
>
>
> -Original Message-
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
> usrp-users-requ...@lists.ettus.com
> Sent: Tuesday, May 1, 2018 12:00 PM
> To: usrp-users@lists.ettus.com
> Subject: USRP-users Digest, Vol 93, Issue 1
>
> Send USRP-users mailing list submissions to
> usrp-users@lists.ettus.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> or, via email, send a message with subject or body 'help' to
> usrp-users-requ...@lists.ettus.com
>
> You can reach the person managing the list at
> usrp-users-ow...@lists.ettus.com
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of USRP-users digest..."
>
>
> Today's Topics:
>
>1. Fwd: USRP No antenna port listed (Daniel Guarecuco)
>2. Re: Fwd: USRP No antenna port listed (Marcus D. Leech)
>3. Re: New (soon) owner question (USB3 over Ethernet) (Marcus M?ller)
>4. Turbo Product Codes on USRP E312 (Ronakraj Gosalia)
>5. How to define FIR RFnoc block with float taps (Allouche Ishai)
>6. Re: How to define FIR RFnoc block with float taps (Marcus M?ller)
>
>
> --
>
> Message: 1
> Date: Mon, 30 Apr 2018 14:54:17 -0400
> From: Daniel Guarecuco 
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] Fwd: USRP No antenna port listed
> Message-ID:
>  xzbjq...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
> I have an USRP1 with a BasicTX and a BasicRX.
> I have been trying to receive data with no luck,  it seems there is a
> problem with the antenna port.
> I run uhd_usrp_probe.exe and this is what I get:
>
> C:\Program Files\UHD\bin>uhd_usrp_probe
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900;
> UHD_3.11.0.
> 0-release
> [INFO] [NIRIO] rpc_client stopping...
> [INFO] [NIRIO] rpc_client stopped.
> [ERROR] [UHD] Device discovery error: input stream error [INFO] [USRP1]
> Opening a USRP1 device...
> [INFO] [USRP1] Using FPGA clock rate of 64.00MHz...
>   _
>  /
> |   Device: USRP1 Device
> | _
> |/
> |   |   Mboard: USRP1
> |   |   serial: 480f888c
> |   |   name: USRP_ettus
> |   |
> |   |   Time sources:  none
> |   |   Clock sources: internal
> |   |   Sensors:
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: Basic RX (0x0001)
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: AB
> |   |   |   |   Name: BasicRX (AB)
> |   |   |   |   Antennas:
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 5.0 to 5.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: BA
> |   |   |   |   Name: BasicRX (BA)
> |   |   |   |   Antennas:
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 

Re: [USRP-users] B200/ADI9361 - Influence of master clock rate on EVM

[Ian Buckley via USRP-users]

That’s strange, by default the analog filters should be being configured from 
the master_clock_rate to have optimal bandwidth for the master_clock_rate on 
the assumption your signal uses the bulk of that bandwidth.
UHD version?

> On May 19, 2018, at 2:37 AM, Sylvain Munaut via USRP-users 
>  wrote:
> 
> Hi,
> 
> 
> I'm comparing two cases that, in theory (at least in my understanding
> of things), should yield the same result but don't :)
> 
> 1) I'm sending data to the USRP at sample_rate N with
> master_clock_rate N and the ADI has FIR 4x, HB 2x,2x,2x
> 2) I'm sending data to the USRP at sample_rate N with
> master_clock_rate 2*N and the ADI has FIR 2x, HB 2x,2x,2x
>In this second case I'm also using a patched FPGA image that
> essentially disables the half band filters of the FPGA so that it
> inserts 0 between each sample instead of doing the half band.
> 
> In both case, the FIR from the ADI is programmed with my own taps (the
> same in both case).
> 
> Now I would expect the result to be the same ... since essentially the
> only thing that changes is that either the ADI is doing the 4x
> interpolation or the FPGA is doing 2x and then the ADI is doing 2x,
> but in both case the signal ends up at the same rate and filtered by
> the same taps and the final DAC rate is also the same.
> 
> (i.e. in both case the samples before the FIR filtering are  "a 0 0 0
> b 0 0 0 c 0 0 0 d 0 0 0 ...". Yes I know that's probably not how it's
> internally done in the ADI but that should be mathematically
> equivalent to this).
> 
> But turns out the results are not the same. Not a catastrophic
> difference but 0.5% ~ 1% EVM change.
> 
> What I'm wondering is if changing the master_clock_rate has an
> influence on other parts of the system that I'm not seeing and that
> could explain this. At first I thought maybe the analog filters are
> configured based on the master_clock_rate, but calling
> get_tx_bandwidth shows 56 MHz full bandwidth in both cases.
> 
> Any theory ?
> 
> 
> Cheers,
> 
>Sylvain Munaut
> 
> ___
> 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] blocking one of channel in multi usrp

[Marcus D. Leech via USRP-users]

On 05/19/2018 12:47 PM, harfan ryanu wrote:

Hi Marcus,
Thank you for your respond,
I just realize it seems somebody in the mail list has the same exact 
problem with me, but i check noone has answered to the problem.

I have tried to run
./benchmark_rate --tx_rate "1e6" --args 
"addr0=192.168.40.2,addr1=192.168.50.2" --channels "0,2" --ref 
"external" --pps "external".
But i got the same problem, only one light from 2 channel is turned on 
(Red), and after that the benchmark rate freeze. The second time i run 
benchmark rate after i force quit (ctrl+c) i got error message saying 
BIST failed (code:1), and have to turn the power off and turn on both 
usrp to make it work again.
However the problem doesnt appear if i try benchmark rate with only 1 
address and both channel (channel "0,1"), or trying to run benchmark 
rate with only rx_rate. When i try to run
/benchmark_rate --rx_rate "1e6" --args 
"addr0=192.168.40.2,addr1=192.168.50.2" --channels "0,2" --ref 
"external" --pps "external".

I can see both RX channel turned green, and no error appear.
Is it possible something might happen with the tx front end? Please 
give me some advice how to solve this.


Thank you for your respond

Regards,
Harfan


 Could you try explicitly setting the subdev spec:

--tx_subdev "A:0 B:0 A:0 B:0"


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

Re: [USRP-users] Minimize latency over PCIe on X310

[Neel Pandeya via USRP-users]

Hello Eugene:

I would not suggest modifying the PCIe transfer block sizes. Although the
PCIe bus might be able to achieve latencies of 10 us, there is additional
latency introduced by UHD and the FPGA. In order to achieve a latency less
than 10us, you would have to do processing in the FPGA, using the RFNoC
framework. You won't be able to achieve such a low latency passing samples
between the host computer and the radio.

--​Neel Pandeya




On 25 April 2018 at 17:20, Eugene Grayver via USRP-users <
usrp-users@lists.ettus.com> wrote:

> One more comment on the latency issue.  I increased the sample rate to 100
> Msps and setup the machine to stay in full-frequency (i.e. no p-states)
> mode.  The minimum latency I can achieve is now 110 us.
>
>
>
> I instrumented rtdsc timer to check the delay between receiving a packet
> and sending it out. The delay between the two is very steady between 9-15
> us.  So, the latency is about 10 packet’s worth.
>
>
>
> Can one of the developers chime in?
>
>
>
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>
>
>
> ___
> 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] Minimize latency on X310 using PCIe

[Neel Pandeya via USRP-users]

Hello Donna:

In order to achieve a latency less than 10us, you would have to do
processing in the FPGA, using the RFNoC framework. You won't be able to
achieve such a low latency passing samples between the host computer and
the radio.

Regarding streaming rates, have you set read and write socket buffer sizes,
and set CPU governors to "performance" mode, and set each core to the
maximum clock speed?

--​Neel Pandeya



On 1 May 2018 at 15:08, Donna Branchevsky via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I would like to minimize the absolute latency of the X310 using the PCIe 
> interface.
>
> Currently I have a script consisting of two threads, one receives data from 
> RX (and places that data into a buffer) and the second thread transmits that 
> data from the buffer. (Everything is in c++ using UHD and Boost libraries, no 
> GNU radio)
>
> I am decreasing the delta between the receiver start time and transmitter 
> start time, and trying to make this difference as small as possible without 
> late packets or underflows during run time. The current goal is 
> receiver_start_time-transmitter_start_time<=10us.
>
> Currently, using the PCIe interface, I have only been able to achieve a delta 
> of 110us without any underflows or late packets.
>
> In order to get to the latency I am currently at (110us) I have:
>
> *Set CPU core affinities for both of the threads
>
> *Run chrt --rr 1 with my script to give real time priority
>
> *Turned off CPU power saving states
>
> *Ran this script with both UHD 3.9 and 3.11 (3.11 yields better results)
>
> For some reason I am able to run my script with a tx/rx sampling rate of 
> 100Msps with UHD 3.11, but if I run the same setup with UHD 3.9 at 100Msps, I 
> get severe underflow. Also, regardless of the delta, I am unable to run my 
> sampling rate at 200Msps without severe underflow using either UHD 3.9 or 
> 3.11.
>
> I am wondering what additional advice you can give me for further reducing 
> this latency.
>
> Let me know if I can provide additional clarifications.
>
>
> Thanks,
>
> Donna
>
>
>
>
> ___
> 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] Host synchronization within a continuous stream

[Yichao Yu via USRP-users]

> What is your status on this issue?

No progress.

> If this issue is still outstanding for you, could you please share your
> program with us (you can email it to us directly and privately, if you
> prefer), so we can see exactly what you're doing.

I believe the only part of the code that's relevant is

```
// uhd::tx_streamer::sptr m_tx_stm;
// const std::complex *p;
// const std::complex *end;
// uhd::tx_metadata_t md;
while (p < end) {
size_t nsent = m_tx_stm->send(p, end - p, md);
if (nsent > 0) {
md.start_of_burst = false;
md.has_time_spec = false;
}
p += nsent;
}
```

which is in an outer loop to pull data from the thread that generates the data.
Other than the pausing that I'd like to get rid of, the outer loop
does **NOT** do any operation on the stream. In particular, the
metadata is **NOT** reinitialized in each loop and the whole outer
(infinite) loop is supposed to be a single continous burst.

All what I need to know is when (at what time) a particular data point
is actually outputted.
I don't necessarily need it for all points, but I do need to know
every (on the order of) 1s **WITHOUT** interrupting the output. It'll
be better if I can get hardware trigger too (i.e. let the X310 record
when an external signal happens in terms of which data point the
trigger time corresponds to).

And to summarize again what times we are dealing with, the three
"time" we have are,

1. Computer time (i.e. `clock_gettime`)
2. USRP time (i.e. `uhd::usrp::multi_usrp::get_time_now`)
3. Output stream data index.

Computer time is only relevant due to how our trigger currently works.
It can be removed if we can get a trigger from the X310 hardware
directly. Synchronizing it to the USRP time is also easy and we don't
have any problem with that.

The only problem  we have is to synchronize 3 to 2. When there's no
underflow (or other timing error) synchronizing 3 and 2 is easy, so
the only problem is how to do this when there is an underflow (which
is bound to happen after running the output continously for months if
not hours).

Take another step back, the whole reason we need this is external
trigger and that's why it'll be good enough if we simply know which
data point is being outputted when an external trigger event happens.

>
> --Neel Pandeya
>
>
>
>
> On 19 April 2018 at 10:28, Yichao Yu via USRP-users
>  wrote:
>>
>> > I'm still a bit confused about the time synchronization being an issue
>> > at all – even after a packet dropout, all packets coming from the X3xx
>> > contain a timestamp, so you'd *never* have to call get_time_now (and it
>> > won't do any good, for asynchronity reasons).
>>
>> Hmmm, maybe I failed to mention this but I'm actually **sending** data
>> and not receiving data.
>> If that's not where the issue is then we're using `tx_stream::send` to
>> push data to the device and I don't think (could be wrong of course)
>> there's a timestamp returned from that (after all it's async).
>> If there's a different function that I can use to get a (async) reply
>> including the time stamp, that'll almost certainly solve my issue.
>>
>> >
>> > I know this is much too ask at this point, but if you could outline the
>> > most pressing issue you have right now, I think it'd enable me (us!) to
>> >  help you quickest.
>> >
>> > Best regards,
>> > Marcus
>> >
>> > On Thu, 2018-04-19 at 11:48 -0400, Yichao Yu wrote:
>> >> Forwarding to the mailing list after getting no reply from ettus in 4
>> >> months!!!
>> >>
>> >> Sorry for the top post but it's increasingly clear that the ad-hoc
>> >> method of resetting the device every now and then is giving us a lot
>> >> of problems and it's getting worse with libuhd update.
>> >> We really need to know how many datapoint the hardware actually
>> >> outputs, is there no way to do it? (For context, see below)
>> >>
>> >> > > That is exactly the approach I'd recommend! The timing resolution
>> >> > > would
>> >> > > actually be much finer than you assume – the clock in which the
>> >> > > timestamps
>> >> > > are counted ticks at the Master Clock Rate of 200 MHz.
>> >> >
>> >> > The time resolution here actually comes from the trigger source (or
>> >> > uncertainties to get current time in general).
>> >> > After more testing the serial port read seems to be rounded to 1ms,
>> >> > which limits our time resolution.
>> >> >
>> >> > > I think the main problems is that you base things of
>> >> > > get_time_now; don't do
>> >> > > that, if you can avoid it by any means. Instead, think of it like
>> >> > > this: The
>> >> > > USRP has an internal clock. Consider that to be the only
>> >> > > "correct" clock.
>> >> > > Your receive signals (if you have any) are tagged with it. Your
>> >> > > transmit
>> >> > > signal should be referenced against it. So, if you can, schedule
>> >> > > only by
>> >> > > counting up the 

Re: [USRP-users] blocking one of channel in multi usrp

[harfan ryanu via USRP-users]

Hi Marcus,
Thank you for your respond,
I just realize it seems somebody in the mail list has the same exact
problem with me, but i check noone has answered to the problem.
I have tried to run
./benchmark_rate --tx_rate "1e6" --args "addr0=192.168.40.2,addr1=192.168.50.2"
--channels "0,2" --ref "external" --pps "external".
But i got the same problem, only one light from 2 channel is turned on
(Red), and after that the benchmark rate freeze. The second time i run
benchmark rate after i force quit (ctrl+c) i got error message saying BIST
failed (code:1), and have to turn the power off and turn on both usrp to
make it work again.
However the problem doesnt appear if i try benchmark rate with only 1
address and both channel (channel "0,1"), or trying to run benchmark rate
with only rx_rate. When i try to run
/benchmark_rate --rx_rate "1e6" --args "addr0=192.168.40.2,addr1=192.168.50.2"
--channels "0,2" --ref "external" --pps "external".
I can see both RX channel turned green, and no error appear.
Is it possible something might happen with the tx front end? Please give me
some advice how to solve this.

Thank you for your respond

Regards,
Harfan

On Sun, May 20, 2018, 02:21 Marcus D. Leech  wrote:

> On 05/19/2018 12:13 PM, harfan ryanu wrote:
> > Hi Marcus,
> > Thank you for your respond,,
> > That is one of the solution i am thinking right now, but to be able to
> > send zero and turn the gain, i believe i have to use multi usrp object
> > using only one stream to send to both channel right?
> Yes.
>
> > However i got another problem when i try multi usrp object, during the
> > tx_streamer->send command only one channel is transmitting for a few
> > second (only one red LED is on in TX/RX), and after that the
> > application freeze. It is not happening with the rx channel, when the
> > application execute rx_streamer->recv all the channel specified in
> > channel args has the green light ON. I dont know why it only happen
> > with the TX only not with the RX. Do you have any idea why could this
> > happen?
> >
> >
> My guess is that there's an issue in your code.  Since this scenario is
> known to work reliably.  Assuming you're running a standard FPGA image and
>haven't modified UHD in any way...
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] blocking one of channel in multi usrp

[Marcus D. Leech via USRP-users]

On 05/19/2018 12:13 PM, harfan ryanu wrote:

Hi Marcus,
Thank you for your respond,,
That is one of the solution i am thinking right now, but to be able to 
send zero and turn the gain, i believe i have to use multi usrp object 
using only one stream to send to both channel right?

Yes.

However i got another problem when i try multi usrp object, during the 
tx_streamer->send command only one channel is transmitting for a few 
second (only one red LED is on in TX/RX), and after that the 
application freeze. It is not happening with the rx channel, when the 
application execute rx_streamer->recv all the channel specified in 
channel args has the green light ON. I dont know why it only happen 
with the TX only not with the RX. Do you have any idea why could this 
happen?



My guess is that there's an issue in your code.  Since this scenario is 
known to work reliably.  Assuming you're running a standard FPGA image and

  haven't modified UHD in any way...



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

Re: [USRP-users] BRAM usage of the X300/X310 design

[Neel Pandeya via USRP-users]

We don't have a more-granular usage report for FPGA utilization. But you
can experiment by removing blocks that you don't need, and seeing how many
resources free up as a result.

What is the error that you're seeing? Which version of Vivado are you
using? Are you using the rfnoc-devel branch, or a tagged release such as
3.10.3.0 or 3.11.0.1?

--​Neel Pandeya




On 23 April 2018 at 01:04, Nives Novković via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Martin,
>
> I saw that utilization report but as I can see it is not divided by
> blocks, it just says the complete usage of resources? I understand about
> not being able to provide the support for a completely stripped design,
> that is not my intention. I have also tried to build the project following
> the instructions but I got the error about design not satisfying timing
> constraints.
>
> Kind regards,
> Nives
>
> 2018-04-19 23:18 GMT+02:00 Martin Braun :
>
>> On 04/19/2018 07:35 AM, Nives Novković via USRP-users wrote:
>> > I can see by the official numbers that the default Ettus FPGA design on
>> > X310 takes about 50% BRAM and on X300 about 90%. I would like to make my
>> > own design for Ettus but use only ADC and Ethernet cores from the
>> > default design. Does anybody know how much BRAM blocks would only those
>> > 2 cores from the original design take up? Thank you in advance!
>>
>> Our current UHD images packages (which you get when you run
>> uhd_images_downloader) include a utilization report. I'm assuming you
>> mean you want to remove all RFNoC blocks except for the radio -- if you
>> really want to remove *everything*, that would be an invasive change,
>> for which we wouldn't be able to provide any support.
>>
>> -- M
>>
>
>
> ___
> 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] blocking one of channel in multi usrp

[Marcus D. Leech via USRP-users]

On 05/16/2018 07:02 AM, harfan ryanu via USRP-users wrote:

Hi all,
Currently I am developing an application with multi usrp using two 
X310. My current configuration is using all 4 channel in usrp with all 
subdev enabled (A:0 B:0), both feed by an external clock. However I am 
curious if we have already issued stream command, is it possible to 
block one of the channel especially during send or recv command? My 
goal is controlling which channel can active while the other is not 
active / not transmitting anything.
I would be glad if anyone could provide me some recommendation on how 
to implement such thing.


Thank you very much,,

Regards,
Harfan

An approach that may work for you, depending on timing requirements, is 
to send zeros on the "blocked" channel, and turns its RF gain all the

  way down during the time when it is "blocked".



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

Re: [USRP-users] Host synchronization within a continuous stream

[Neel Pandeya via USRP-users]

Hello Yichao Yu:

What is your status on this issue?

If this issue is still outstanding for you, could you please share your
program with us (you can email it to us directly and privately, if you
prefer), so we can see exactly what you're doing.

--​Neel Pandeya




On 19 April 2018 at 10:28, Yichao Yu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> > I'm still a bit confused about the time synchronization being an issue
> > at all – even after a packet dropout, all packets coming from the X3xx
> > contain a timestamp, so you'd *never* have to call get_time_now (and it
> > won't do any good, for asynchronity reasons).
>
> Hmmm, maybe I failed to mention this but I'm actually **sending** data
> and not receiving data.
> If that's not where the issue is then we're using `tx_stream::send` to
> push data to the device and I don't think (could be wrong of course)
> there's a timestamp returned from that (after all it's async).
> If there's a different function that I can use to get a (async) reply
> including the time stamp, that'll almost certainly solve my issue.
>
> >
> > I know this is much too ask at this point, but if you could outline the
> > most pressing issue you have right now, I think it'd enable me (us!) to
> >  help you quickest.
> >
> > Best regards,
> > Marcus
> >
> > On Thu, 2018-04-19 at 11:48 -0400, Yichao Yu wrote:
> >> Forwarding to the mailing list after getting no reply from ettus in 4
> >> months!!!
> >>
> >> Sorry for the top post but it's increasingly clear that the ad-hoc
> >> method of resetting the device every now and then is giving us a lot
> >> of problems and it's getting worse with libuhd update.
> >> We really need to know how many datapoint the hardware actually
> >> outputs, is there no way to do it? (For context, see below)
> >>
> >> > > That is exactly the approach I'd recommend! The timing resolution
> >> > > would
> >> > > actually be much finer than you assume – the clock in which the
> >> > > timestamps
> >> > > are counted ticks at the Master Clock Rate of 200 MHz.
> >> >
> >> > The time resolution here actually comes from the trigger source (or
> >> > uncertainties to get current time in general).
> >> > After more testing the serial port read seems to be rounded to 1ms,
> >> > which limits our time resolution.
> >> >
> >> > > I think the main problems is that you base things of
> >> > > get_time_now; don't do
> >> > > that, if you can avoid it by any means. Instead, think of it like
> >> > > this: The
> >> > > USRP has an internal clock. Consider that to be the only
> >> > > "correct" clock.
> >> > > Your receive signals (if you have any) are tagged with it. Your
> >> > > transmit
> >> > > signal should be referenced against it. So, if you can, schedule
> >> > > only by
> >> > > counting up the device time in your program.
> >> >
> >> > The main problem is that `get_time_now` is slow... (compare to
> >> > clock_gettime at least).
> >> > Also, thhe synchronization between the system clock and the usrp
> >> > clock
> >> > isn't actually the big problem.
> >> > The big problem is synchronizing the output with the usrp clock
> >> > when
> >> > there's missing samples.
> >> >
> >> > > > 1. Periodically stop the burst and start a new timed burst with
> >> > > > a
> >> > > > small time gap in the middle. If we do this frequent enough we
> >> > > > should
> >> > > > be able to consume away the missing time. There are some point
> >> > > > in the
> >> > > > continuous run where it is kind of ok to do this but we'd still
> >> > > > like
> >> > > > to avoid doing this as much as possible since it can make the
> >> > > > whole
> >> > > > system less predictable.
> >> > >
> >> > > That's pretty much the usual method of doing this.
> >> >
> >> > Yeah, I noticed after reading some of the examples. However, in
> >> > this
> >> > case, we really want to find a better way if at all possible since
> >> >
> >> > 1. This is basically solving the problem causing by a timing issue
> >> > (missing samples) by making it worse (i.e. missing a lot more
> >> > samples)
> >> >
> >> > 2. I'm 100% sure we are going to be affected by the periodic
> >> > turning
> >> > off at one point or another
> >> >
> >> > Since there's no way for me to know how many samples are
> >> > missing,
> >> > as long as there has been any underflow, I have to contineously
> >> > drop
> >> > samples in case I haven't waited long enough yet.
> >> > Although not driven by this currently, we do have equipment
> >> > that
> >> > could be quite unhappy if the input is off this frequently.
> >>
> >>
> >>
> >>
> >> >
> >> > > Hope this gets a discussion starting!
> >>
> >>
> >>
> >> > >
> >> > > Best regards,
> >> > > Marcus
> >> > >
> >> > >
> >> > > On Tue, Dec 12, 2017 at 7:07 PM, Yichao Yu via USRP-users
> >> > >  wrote:
> >> > > >
> >> > > > > Had a look at if this can be done by catching underrun event
> >> > > > > and from
> >> > > > > what I can see in how that 

Re: [USRP-users] Implementing multi usrp

[risa asir via USRP-users]

Hi Marcus,
Thank you very much for your previous reply.
Yeah i have progressed very far from my previous question. However, i still
have a problem when i try to run the application using 2 USRP, I saw only 1
light indicator in TX/RX is ON which i believe only one USRP is sending the
data (On RX side both indicator is ON). And suddenly the application freeze
after that. When i try to re-run the application, i got a following error
saying "what():  RuntimeError: BIST failed! (code: 1)"

To fix the BIST failed, i have to power cycle both USRP, but it doesnt
solve the "only one USRP is sending" problem, and the problem keep coming
back.

I then try to do the benchmark_rate test to make sure the problem comes
from the application not from the usrp, by using the following :

./benchmark_rate --tx_rate "1e6" --args
"addr0=192.168.40.2,addr1=192.168.140.2" --channels "0,2" --ref "external"
--pps "external".

However, I still got the same problem: Only 1 out of 2 channel is sending
the data and the benchmark_test freezes. After that i have to power cycle
both USRP to make it work again.
The weird thing is If i try benchmark_rate using rx_rate all the RX
channels light is On and benchmark test success with 0 error.

At this point i am concluding something wrong with the tx front end.
Could you give me an insight what might happen and how to fix the problem?

It is my pleasure to get answer from you

Thank you very much,
Regards,
Risa.


2018-05-19 19:17 GMT+10:00 Marcus Müller :

> Hi Risa,
>
> the chances of us getting mad are extremely slim :)
>
> I presume you've already made progress in this; if not: what line exactly
> does your debugger say your segmentation fault happens? If you haven't
> worked with a debugger before (in your case, probably gdb), it's a skill
> that pays to learn within days, if not hours, of coding.
>
> Best regards,
> Marcus
>
>
> On 11 May 2018 01:06:05 GMT+02:00, risa asir via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>>
>> Hi all,
>> I am a newbie in USRP and UHD. Please dont be mad at me if I am wrong. I
>> am currently trying to implement SRSLTE using multi usrp. However I have
>> been stuck for days trying to contain real data from the buffer received.
>> If I try to assign the buffs_ptr with the data_c, it says core Segmentation
>> fault (core dumped). I attach my piece of code below. Please help me for
>> some idea to solve this. I am very grateful for your help.
>>
>> Thank you.
>>
>> Regards,
>> Risa
>>
>>
>>
>>
>> int multi_usrp_recv_with_time_multi(void *h,
>>void *data[SRSLTE_MAX_PORTS],
>>uint32_t nsamples,
>>bool blocking,
>>time_t *secs,
>>double *frac_secs) {
>> md = rx_md_first;
>> size_t rxd_samples = 0;
>> const size_t rx_nof_samples = rx_stream_handle->get_max_num_samps();
>> int trials = 0;
>> if (blocking) {
>> uint32_t n = 0;
>> while (n < nsamples && trials < 100) {
>> void *buffs_ptr[4];
>> for (size_t i=0;i> cf_t *data_c = (cf_t*) data[i];
>> buffs_ptr[i] = _c[n];
>> }
>> size_t num_samps_left = nsamples - n;
>> size_t num_rx_samples = (num_samps_left > rx_nof_samples) ? 
>> rx_nof_samples : num_samps_left;
>>// printf("testing1");
>> rxd_samples = 0;
>> rxd_samples = rx_stream_handle->recv(buffs_ptr,num_rx_samples, 
>> md,1.0,false);
>> printf("rxd_samples: %lu", rxd_samples);
>> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_TIMEOUT) {
>> printf("ERROR_CODE_TIMEOUT");
>> };
>> if (md.error_code == 
>> uhd::rx_metadata_t::ERROR_CODE_LATE_COMMAND){
>> printf("ERROR_CODE_LATE_COMMAND");
>> };
>> if (md.error_code == 
>> uhd::rx_metadata_t::ERROR_CODE_BROKEN_CHAIN){
>> printf("ERROR_CODE_BROKEN_CHAIN");
>> };
>> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_OVERFLOW){
>> printf("ERROR_CODE_OVERFLOW");
>> };
>> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_ALIGNMENT){
>> printf("ERROR_CODE_ALIGNMENT");
>> };
>> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_BAD_PACKET){
>> printf("ERROR_CODE_BAD_PACKET");
>> };
>>
>> md = rx_md;
>> n += rxd_samples;
>> trials++;
>> }
>> } else {
>> rxd_samples = rx_stream_handle->recv(data,nsamples, md,0.0,false);
>> }
>> if (secs && frac_secs) {
>> *secs = md.time_spec.get_full_secs();
>> *frac_secs = md.time_spec.get_frac_secs();
>>
>> }
>> return nsamples;
>>  }
>>
>>
> 

[USRP-users] Adding IP to RFNoC-OOT

[Matthias Schraml via USRP-users]

Hi all,

 

creating RFNoC-OOT without Xilinx IP blocks works fine, but somehow I
struggle with adding the Xilinx IP xcix files from Vivado to the RFNoC-OOT. 

The rfnocmodtool creates a Makefile.srcs (manually modifying this file is
not recommended according to the tutorial). In contrast, some other
RFNoC-OOTs use Makefile.inc files. So am I supposed to create these
Makefile.inc files manually and how do I add xcix files?

It might be useful to have an "add-ip" (or "add-hls") function in the
rfnocmodtool to create the Makefiles and the folder structure for Xilinx IP
blocks or HLS files.

 

Additionally I think in one commit a few days ago to the noc_block template
a "." before set_time() is missing. This leads to an error while building an
image with a fresh OOT.

 

Thanks in advance for your help!

 

Best regards,

Matthias

 

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

Re: [USRP-users] blocking one of channel in multi usrp

[harfan ryanu via USRP-users]

Hi Marcus,
Thank you for your reply.
Currently I have created two streamer with first streamer goes to channel 0
and second streamer goes to channel 2. The sampling rate is same for both
channel. I am successfully controlling the stream from channel 0 to channel
2. However when i try to change back to channel 0, i got suddenly a lot of
LL message.
I have another problem when trying to use both channel at the same time,
only one of the tx is working (i can see by looking at the TX LED indicator
in one of USRP in is not On, while RX LED indicator in both of USRP is On).
I believe both USRP has already synchronized. I am still stuck in trying to
find the core cause for both problem.
Do you have any idea why it might happen?

Thank you very much,

Regards,
Harfan

2018-05-19 18:37 GMT+10:00 Marcus Müller :

> Go Harfan,
> It is internally assumed that a streamer during its life time has a fixed
> number of streams. What sampling rate are we talking about? Is continuity
> for the other channels a concern? What is the time scale we're switching
> channels on an off?
>
> Best regards,
> Marcus
>
>
> On 16 May 2018 13:02:01 GMT+02:00, harfan ryanu via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>>
>> Hi all,
>> Currently I am developing an application with multi usrp using two X310.
>> My current configuration is using all 4 channel in usrp with all subdev
>> enabled (A:0 B:0), both feed by an external clock. However I am curious if
>> we have already issued stream command, is it possible to block one of the
>> channel especially during send or recv command? My goal is controlling
>> which channel can active while the other is not active / not transmitting
>> anything.
>> I would be glad if anyone could provide me some recommendation on how to
>> implement such thing.
>>
>> Thank you very much,,
>>
>> Regards,
>> Harfan
>>
>
> --
> This was written on my cellular phone. whilst an impressive piece of
> engineering, this might not be the perfect device to write emails on -
> please excuse my brevity.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] B200/ADI9361 - Influence of master clock rate on EVM

[Sylvain Munaut via USRP-users]

Hi,


I'm comparing two cases that, in theory (at least in my understanding
of things), should yield the same result but don't :)

1) I'm sending data to the USRP at sample_rate N with
master_clock_rate N and the ADI has FIR 4x, HB 2x,2x,2x
2) I'm sending data to the USRP at sample_rate N with
master_clock_rate 2*N and the ADI has FIR 2x, HB 2x,2x,2x
In this second case I'm also using a patched FPGA image that
essentially disables the half band filters of the FPGA so that it
inserts 0 between each sample instead of doing the half band.

In both case, the FIR from the ADI is programmed with my own taps (the
same in both case).

Now I would expect the result to be the same ... since essentially the
only thing that changes is that either the ADI is doing the 4x
interpolation or the FPGA is doing 2x and then the ADI is doing 2x,
but in both case the signal ends up at the same rate and filtered by
the same taps and the final DAC rate is also the same.

(i.e. in both case the samples before the FIR filtering are  "a 0 0 0
b 0 0 0 c 0 0 0 d 0 0 0 ...". Yes I know that's probably not how it's
internally done in the ADI but that should be mathematically
equivalent to this).

But turns out the results are not the same. Not a catastrophic
difference but 0.5% ~ 1% EVM change.

What I'm wondering is if changing the master_clock_rate has an
influence on other parts of the system that I'm not seeing and that
could explain this. At first I thought maybe the analog filters are
configured based on the master_clock_rate, but calling
get_tx_bandwidth shows 56 MHz full bandwidth in both cases.

Any theory ?


Cheers,

Sylvain Munaut

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

Re: [USRP-users] Trouble compiling UHD on windows

[Marcus Müller via USRP-users]

Hi Miguel,

I'm definitely not an expert on windows software building, but "the libuhd 
environment" actually sounds like it is what you want to build. You probably 
shouldn't try to link your build of libuhd against our build.

Best regards,
Marcus

On 14 May 2018 06:16:12 GMT+02:00, Miguel P via USRP-users 
 wrote:
>Hello,
>
>As I wanted a statically linked .lib I downloaded the source, but I've
>had a lot of trouble trying to build the library. I'm using VS 2017,
>and the latest Boost version, and libuhd. I compiled Boost for static
>linkage and the complete libuhd system. Then cloned the uhd and tried
>set up cmake "ENABLE_STATIC_LIBS". Then when I tried to build the
>solution I first got linking errors because
>"boost_unit_test_framework-vc141-mt-x64-1_67.lib" was missing. I'm not
>sure why it would want to link to a dynamic link library, but I just
>rebuilt boost and added the dynamic lib so that uhd linkage would
>work. And then it worked (eventually depending on a Boost .dll), but
>the "uhd_static" project still failed to compile.
>"1>c:\lib\uhd\host\lib\utils\log_c.cpp(19): error C2491: '_uhd_log':
>definition of dllimport function not allowed" which as I understand is
>because functions are being "__declspec(dllimport)" and for static
>linkage you don't want that.. I tried to manually set UHD_API to no
>
>How can I fix this? Is there interest in keeping UHD compatible to
>Windows (as you mostly focused on Linux)?
>
>Thanks in advance.
>
>___
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
This was written on my cellular phone. whilst an impressive piece of 
engineering, this might not be the perfect device to write emails on - please 
excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD and process forking

[Marcus Müller via USRP-users]

Hi Keith,

in principle, you could continue using the multi_usrp in **one** of the 
processes. The real problem stems from the question of who inherits the sockets 
(in the case of network USRPs), the USB handles, or kernel ring buffer handles.
In the end, only one process might react to packets coming from the USRP. Also, 
this is C++, so if you don't watch out in your main process, and your 
multi_usrp loses scope, its destructor would be called, with devastating 
effects on the state of your USRP.

On the other hand, there is, at least as far as I can remember from the top of 
my head, nothing to react to until you start a streamer. But I wouldn't 
recommend relying on that as kind of API; I don't think we guarantee usability 
of a multi_usrp after forking, but the last word on that is Martin's.

Maybe if you described your use case, we could chime in with approaches.

Best regards,
Marcus

On 14 May 2018 18:09:51 GMT+02:00, Keith k via USRP-users 
 wrote:
>Hello all
>
>My intuition tells me this would be a bad idea, but before I try
>anything
>with this, does anyone have any thoughts about how the multi-usrp
>object
>would react in a situation where the process has been forked? I know
>that
>the call to create a multi-usrp object will fail if called in a second
>process, so I imagine it won't like being in 2 separate address spaces.
>
>-- 
>-Keith Kotyk

-- 
This was written on my cellular phone. whilst an impressive piece of 
engineering, this might not be the perfect device to write emails on - please 
excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] blocking one of channel in multi usrp

[Marcus Müller via USRP-users]

Go Harfan,
It is internally assumed that a streamer during its life time has a fixed 
number of streams. What sampling rate are we talking about? Is continuity for 
the other channels a concern? What is the time scale we're switching channels 
on an off?

Best regards,
Marcus

On 16 May 2018 13:02:01 GMT+02:00, harfan ryanu via USRP-users 
 wrote:
>Hi all,
>Currently I am developing an application with multi usrp using two
>X310. My
>current configuration is using all 4 channel in usrp with all subdev
>enabled (A:0 B:0), both feed by an external clock. However I am curious
>if
>we have already issued stream command, is it possible to block one of
>the
>channel especially during send or recv command? My goal is controlling
>which channel can active while the other is not active / not
>transmitting
>anything.
>I would be glad if anyone could provide me some recommendation on how
>to
>implement such thing.
>
>Thank you very much,,
>
>Regards,
>Harfan

-- 
This was written on my cellular phone. whilst an impressive piece of 
engineering, this might not be the perfect device to write emails on - please 
excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC and MicroBlaze

[Marcus Müller via USRP-users]

Hello Alice,

I'm myself not aware of an existing project (maybe I just forget, though) which 
puts a microblaze into an rfnoc block, but:
Why not? You can put anything that you can instantiate in verilog into a block; 
I'd presume you might want to add a bus-independent clock to drive your 
processor.
With that in mind, you can use any processor implementation you can get rtl 
files for; I don't know what you want to use that microblaze for, but I'd 
generally recommend picking a CPU core that both fits the processing needs 
(simple logic on minimal space or signal processing with performance?) and the 
toolchains you're used to (you might feel more comfortable with a modern GCC 
rather than the microblaze gcc5, for example, or with the way to add 
specialized instructions to your Rocketcore risc-v CPU).

So, maybe you want to discuss your purpose of putting a processor in a CE! That 
way, maybe we might chime in with specific feedback.

Best regards,
Marcus

On 16 May 2018 14:14:07 GMT+02:00, Alice Lo Valvo via USRP-users 
 wrote:
>Hello,
>
>I have some questions. I read that there is the possibility to
>integrate 
>a MicroBlaze into RFNoC project. Do you know something about this? This
>
>is a new world for me and I tried to understand which steps to do for 
>adding a MicroBlaze block in the FPGA of USRP X300. There is already a 
>.bit file where it is already implemented a MicroBlaze?
>
>Thanks in advance,
>Alice
>
>___
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
This was written on my cellular phone. whilst an impressive piece of 
engineering, this might not be the perfect device to write emails on - please 
excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com