Re: [USRP-users] RFNoC flowgraph runs right the second time

[Jon Pendlum via USRP-users]

Hey Jason,

Have you tried using a smaller SPP such as 256?

Jonathon

On Thu, Jul 26, 2018 at 2:39 AM, Jason Matusiak via USRP-users
 wrote:
> So, somehow I got things working for the first run in a certain situation.
> I attached 2 pictures to show my flowgraphs.  Again, my LBT block is
> currently just swapping the inputs to the outputs (in0 -> out1 and in1 ->
> out0).
>
> The working image seems to work everytime.
>
> The non-working image, seems to never work anymore (I get those "timeout on
> channel 0" errors).
>
> Currently, my swapping is like the RFNoC loopback example.  What I wonder
> is, could I be having some sort of issues due to back-pressure or something.
> I tried with some DMA-FIFOs around, but that didn't seem to help in any way.
>
> This is my swap:
>
> assign m_axis_data_tready[1] = s_axis_data_tready[0];
> assign s_axis_data_tvalid[1] = m_axis_data_tvalid[0];
> assign s_axis_data_tlast[1] = m_axis_data_tlast[0];
> assign s_axis_data_tdata[63:32] = m_axis_data_tdata[31:0];
>
> assign m_axis_data_tready[0] = s_axis_data_tready[1];
> assign s_axis_data_tvalid[0] = m_axis_data_tvalid[1];
> assign s_axis_data_tlast[0] = m_axis_data_tlast[1];
> assign s_axis_data_tdata[31:0] = m_axis_data_tdata[63:32];
>
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] RFNoC flowgraph runs right the second time
> Date: 7/25/18 10:42 am
> To: "Ettus Mail List" 
> Cc: "Martin Braun" 
>
> Thanks Martin. I tried that, but it actually seems to be working when I look
> at the results.  I saw you post earlier to someone about changing UHD's
> logging level.  Is this something that can be done via a config file?  I
> looked around, but all I could find was some references to c++ usage.
>
>
>> Jason,
>>
>> this is a tough one. I have no ideas, other than 'throw in a couple of
>> ILAs and see where it's stuck'.
>
>> -- 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] about rfnoc nocshell

[Jon Pendlum via USRP-users]

Hi,

1) You cannot reduce noc_shell resource usage much. You can try
putting all your custom logic in just one RFNoC block, that way you do
not incur the overhead of multiple noc_shell instances.
2) Do you mean "Can I access PS DDR memory directly from the FPGA
fabric?" If so, yes you can via the HP AXI ports. You'll need
something to interface with the HP AXI port though. Xilinx's AXI
Datamover or AXI DMA IP blocks are decent choices.

Jonathon

On Fri, Jul 6, 2018 at 3:26 AM, carry chen via USRP-users
 wrote:
> hello,list,
>
> I have study the rfnoc,I have 2 question:
> 1. I find nocshell module use large resource, e310 resource is less, so can
> I adjust some param to reduce the resoure comsume? I only config one radio(1
> ddc+1 duc),I find use so many resouce
> 2.Can I share memory between ps and pl direct?
>
> Best,Regards,
> Carry
>
> ___
> 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] noc_block_null_source_sink module

[Jon Pendlum via USRP-users]

Hey Jason,

The block is functionally complete, in fact I think it was the first
block ever made. There is a UHD C++ example,
rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC
xml for GNU Radio needs to be created though.

Jonathon

On Wed, Jul 18, 2018 at 4:38 AM, Jason Matusiak via USRP-users
 wrote:
> I was having trouble finding information on this block. I could see its
> usefulness in an application I am looking into, but I wasn't sure how
> complete the block was (I don't really see anything using it, nor a GRC xml
> file for it).
>
> Thanks
>
> ___
> 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] Possible to enable via RFNoC block via RFNoC

[Jon Pendlum via USRP-users]

Hey Jason,

You can send a command packet to another block via noc_shell's cmd_out
port. Command packets basically encapsulate a settings bus write. In
the payload of the command packet, the upper 32 bits are the settings
register address and the lower 32 bits are the data. Also, the block
will reply with a response packet, make sure to receive it (or just
leave ackin_tready set to 1'b1.)

There are a few things to be aware of though when manually sending out
command packets in a RFNoC block:
- This is a raw packet, so you will need to setup the header which
includes knowing the SID of the receiving block. That is easy if you
know which xbar port it is connected to: SID = {8'd0 (xbar ID), 4'd#
(xbar port), 4'd0 (block port)}. To find the xbar port, look at the
rfnoc_ce_auto_inst_.v file and find the array index of the
receiving block. For X3x0 devices, xbar port = array index + 5.
- The host will be unaware of any changes you made. If that is an
issue, you could try implementing a readback register that the host
regularly polls.
- Sending many timed commands requires extra care. RFNoC blocks store
timed commands in a FIFO until they are executed. UHD tracks the FIFO
depth to prevent overflow, but noc_shell does not. You can control the
depth of the FIFO via noc_shell's CMD_FIFO_SIZE parameter.

Jonathon

On Tue, Jul 31, 2018 at 4:12 AM, Jason Matusiak via USRP-users
 wrote:
> I am curious if it is possible to enable an RFNoC block from another RFNoC
> block?  An example would be, turning on the siggen when another RFNoC block
> decides that it should run.
>
> I don't believe that I've seen this done anywhere, so I have a suspicion
> that there isn't a good way to get messages from one RFNoC to another
> without going through the host first.
>
> ___
> 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] Time alignment failure for four channels coherent receiver in X310

[Jack Yang via USRP-users]

Thank you so much!! Julian! Starting the RX streamer a little bit in the
future works!! Now I can align 4 channels as coherent receiver with 50M sps
without problem.
Also thanks for Marcus's help


All Best,
Jack


On Sun, Jul 29, 2018 at 12:49 PM, Julian Arnold 
wrote:

> Hey,
>
> have you tried starting the RX streamer a little bit in the future, i.e
> change the following lines:
>
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
>
> to something like (out of the top of my head):
>
> stream_cmd.stream_now = false;
> stream_cmd.time_spec = usrp->get_time_now() + 0.05;
>
> ?
>
> I have seen the same behavior on my B210 in dual channel RX setups when
> starting the streamer immediately. So maybe this helps.
>
> Cheers,
> Julian
>
> On 29.07.2018 21:23, Jack Yang via USRP-users wrote:
>
>> Hi Marcus,
>>
>> Even I used 1Msps or less than this sampling rate, I still saw this time
>> alignment issue. When I am using GNURadio system with python script instead
>> of using UHD API, I can run 10Msps for my 4 channel phase array receiver
>> without any problems. My final goal is to have 50Msps for my 4 channel
>> phase array receiver with dual 10 GiGe cable setup and CDUA computation for
>> wideband AoA detection. My desktop spec is Processors: Intel Core i9 7900X
>> 10-Core 3.3GHz (4.3GHz TurboBoost), Memory: 32GB ORIGIN PC DDR4 Powered by
>> Kingston 3000MHz (4 X 8GB),.
>>
>> Thanks!
>>
>> All Best,
>> Jack
>>
>>
>>
>>
>>
>>
>> On Sun, Jul 29, 2018 at 11:59 AM, Marcus D. Leech > > wrote:
>>
>> On 07/29/2018 12:56 PM, Jack Yang wrote:
>>
>>> Hi Marcus,
>>>
>>> Thanks for your mail. Yes, I am using 10GiGe interface to run the
>>> UHD C++ code.
>>> Any thoughts or suggestions?
>>>
>>> All Best,
>>> Jack
>>>
>>> On Sun, Jul 29, 2018 at 9:35 AM, Marcus D. Leech via USRP-users
>>> mailto:usrp-users@lists.ettus.com>>
>>> wrote:
>>>
>>> On 07/29/2018 12:52 AM, Jack Yang via USRP-users wrote:
>>>
 Hi,

 I have rewrote "rx_samples_to_file.cpp" for making four
 channel coherent receiver (phased-array receiver) in X310.
 When I executed my code, the terminal showed that

 *[ERROR] [STREAMER] The receive packet handler failed to
 time-align packets. 1002 received packets were processed by
 the handler. However, a timestamp match could not be
 determined.*

 I have attached my code as the following link
 (https://www.dropbox.com/s/x0u0tw5e65iaual/rx_samples_X310_
 TwinRx.cpp?dl=0
 ).
 The info for my UHD version is shown in below
 *"[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
 Boost_105800; UHD_3.11.0.HEAD-0-ga1b5c4ae"*


 Could someone guide me how to fix this issue? I am using two
 TwinRx with a X310 for my coherent receiver. I basically
 followed gr-doa python configuration to set up the USRP
 device in C++ code. However, I cannot find out why the time
 alignment is failed in here.

 The detailed print-out message is also listed here

 Thanks!

 All Best,
 Jack

 Creating the usrp device with: addr=192.168.40.2...
 [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
 Boost_105800; UHD_3.11.0.HEAD-0-ga1b5c4ae
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Determining maximum frame size...
 [INFO] [X300] Maximum frame size: 8000 bytes.
 [INFO] [X300] Setup basic communication...
 [INFO] [X300] Loading values from EEPROM...
 [INFO] [X300] Setup RF frontend clocking...
 [INFO] [X300] Radio 1x clock:200
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1316 MB/s)
 [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes,
 but 1 input ports
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes,
 but 1 input ports
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [CORES] Performing timer loopback test...
 [INFO] [CORES] Timer loopback test passed
 [INFO] [CORES] Performing timer loopback test...
 [INFO] [CORES] Timer loopback test passed
 Using Device: Single USRP:

Re: [USRP-users] Possible to enable via RFNoC block via RFNoC

[Brian Padalino via USRP-users]

On Mon, Jul 30, 2018 at 3:14 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am curious if it is possible to enable an RFNoC block from another RFNoC
> block?  An example would be, turning on the siggen when another RFNoC block
> decides that it should run.
>

Not sure I understand the use case or what you're trying to accomplish.


>
> I don't believe that I've seen this done anywhere, so I have a suspicion
> that there isn't a good way to get messages from one RFNoC to another
> without going through the host first.
>

You need to describe the sources and destinations of all the RFNoC blocks
and have no loops when doing so.

If you want IQ generated with gaps, that's fine, but you can't arbitrarily
change the flowgraph after start up.

Can you describe, using a graph, possibly even with fictitious blocks, what
you're trying to do and each blocks functionality?

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

[USRP-users] Possible to enable via RFNoC block via RFNoC

[Jason Matusiak via USRP-users]

I am curious if it is possible to enable an RFNoC block from another RFNoC 
block?  An example would be, turning on the siggen when another RFNoC block 
decides that it should run.
 
I don't believe that I've seen this done anywhere, so I have a suspicion that 
there isn't a good way to get messages from one RFNoC to another without going 
through the host first.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Using Two DDC Chain in N210

[Marcus D. Leech via USRP-users]

On 07/30/2018 12:30 PM, Amirhosein naseri via USRP-users wrote:

Hi everybody

I want to use Two DDC chain in usrp N210 to get streams for example 
around freq0 and freq1 with sample rate 400e3 for each channel.
first i use uhd.tune_request_t function as argument fot 
set_center_freq function as below :


usrp1.set_center_freq ( uhd.tune_request_t (freq1,0) , 0)
usrp1.set_center_freq ( uhd.tune_request_t (freq1,freq2-freq1) , 0)

I got two stream, first correspond to freq1 is true but for second 
stream correspond two freq2 it's not.
second stream has frequency shift equal to sum of CORDIC frequency of 
freq1 and freq2 ...


I test different configuration for arguments of uhd.tune_request_t but 
i can't solve the problem 


anyone has any advice in true usage of uhd.tune_request_t for using 
two DDC chain of N210 ?


Tnx.

You'll have to use the policy arguments to prevent retuning of the RF 
hardware in the second tune.When I have done this in the past, I've
  set the RF hardware to exactly half-way between the two target 
frequencies, and used the DDCs to bring in the frequencies I wanted.


https://files.ettus.com/manual/structuhd_1_1tune__request__t.html


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

[USRP-users] Using Two DDC Chain in N210

[Amirhosein naseri via USRP-users]

Hi everybody 

I want to use Two DDC chain in usrp N210 to get streams for example around 
freq0 and freq1 with sample rate 400e3 for each channel.first i use 
uhd.tune_request_t function as argument fot set_center_freq function as below : 

usrp1.set_center_freq ( uhd.tune_request_t (freq1,0) , 0)usrp1.set_center_freq 
( uhd.tune_request_t (freq1,freq2-freq1) , 0)
I got two stream, first correspond to freq1 is true but for second stream 
correspond two freq2 it's not.second stream has frequency shift equal to sum of 
CORDIC frequency of freq1 and freq2 ...
I test different configuration for arguments of uhd.tune_request_t but i can't 
solve the problem 
anyone has any advice in true usage of uhd.tune_request_t for using two DDC 
chain of N210 ?
Tnx.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP X310 Remote Configuration

[Jason Matusiak via USRP-users]

I've actually done this with success, unfortunately, I am not allowed to share 
it :(.  It wasn't too hard, I used a core in the block to hold the data, and 
then I just repeated it when I sent it out over and over.
 
The catch was that there was a little bit of an issue within rfnoc at the time 
(you can see mailing lists conversations from back then in the archives) that 
kept it from kicking off at startup (an enable switch worked fine though).  
Jonathon P helped with a patch to get me going, but that obviously has been 
mainlined by now since they have a siggen working (it didn't exist yet when I 
did my block).  The issue had something to do with the block sending data 
before everything have been initialized and came up properly.
 
So it isn't too bad to create one.  Good luck!
 
 
- Original Message - Subject: Re: [USRP-users] USRP X310 Remote 
Configuration
From: "Rob Kossler via USRP-users" 
Date: 7/30/18 9:33 am
To: "Farnaz Chamanzadeh" 
Cc: "usrp-users" 

 Perhaps look at the RFNoC siggen block. You will need to add some component 
such as a block memory or fifo to store the samples on the fpga and then you 
will need a way to populate the memory and then play it out when desired.
Rob


  On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh  
wrote:
 Dear Rob,  Thanks for your helpful response. The reason that we need to use a 
switch is due to hour host hardware limits, which only have one 10GBE. 
About the second remark in your email, do you have an example or a reference 
where a similar case was implemented which we can use  as a guideline for our 
implementation? 
 
Best regards,
Farnaz


 On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler  wrote:
  Hi Farnaz, A couple of remarks and questions
- Remark 1: in order to get 200 MS/s transmit streaming, you will NEED to have 
the samples on the USRP. The host-to-USRP streaming does not work at 200 MS/s 
for the transmit case (unless something has recently changed). The host-to-USRP 
max for transmit is 100 MS/s per channel
- Remark 2: that leads into your question about having the samples stored on 
the USRP rather than streamed from host.  This is not presently a capability, 
but can be added with some modest FPGA work.  I have been desiring such 
capability for a couple of years - I hope that Ettus adds such capability in 
the future.
- Question 1: why do you plan to use a 10gbe switch with a single connection to 
the host PC?  Why not have multiple 10Gbe links at the PC which connect to each 
USRP individually.  A NIC such as Intel XL-710 provides 4 10gbe links.
 
Rob
 


  On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users 
 wrote:
 Dears,  
To be more specific, we want to control multiple USRPs with one (remote) 
computer. We would like to stream known and periodic signal from each USRP. The 
sequence on each USRP is unique and is different from other USRPs. 
 
 Since the samples from each USRP are known, it would be more convenient if we 
can generate the samples once and preferably store them locally on each USRP. 
In this configuration,  we want to use the host computer to send control 
commands to the USRPs specifying when each of them must transmit its specific 
samples. The USRPs are assumed to be synchronized, so the control commands from 
the host will generate a TDMA scheme. Each USRP will start signal transmission 
upon receiving the control command from the host computer. I would like to know 
that:
 
1. Is it possible to store the samples on the USRPs? or should we stream the 
samples from the host computer to the USRPs for each transmission?
2.  Can we use the full bandwidth and 200MS/s in this setup?  
3. After knowing the answer to the previous question,  I would like to know how 
we can implement it? do you happen to have a demo or an example that can guide 
us in this implementation? 
 
Best,
Farnaz
 
 
 
 
 

 On Wed, Jun 27, 2018 at 4:50 AM, Michael West  wrote:
   Hi Farnaz,
 
To clarify and expand on Marcus' comments, the answer is maybe.  You can do 
burst captures and transmissions at full rate and you can even use timed 
commands to synchronize them, but there are limitations.  If you can describe 
in more detail what you want to do, we can more clearly tell you if it is 
possible.  How many channels do you plan to do simultaneously?  How many 10 GbE 
connections between the host and switch?  How many 10 GbE connections between 
each USRP and the switch?
 
There is buffering of the TX samples on the X310 and it is configurable.  The 
current default is 32 MB.  The DRAM is a total of 1 GB, and it can be divided 
up however necessary.
 
Regards,
Michael


 On Mon, Jun 25, 2018 at 12:23 PM, Marcus Mller via USRP-users 
 wrote:
 Dear Fernaz,
 
 you can't cheat 10Gig bandwidth! If you time-share any medium, then
 it's bandwidth must be shared. Since ethernet is de facto a timesharing
 thing, anyway, no, this won't work:
 Since you need to push through all the data through a single 10GigE
 

Re: [USRP-users] Latency between multiple daughter boards on one USRP X310

[Derek Kozel via USRP-users]

Hello Fabian and Young,

The suggestion about timed commands is on point, I think that is what is
missing. Using unknown PPS will not hurt as there are two radio blocks with
timekeepers and using the unknown PPS setting, or external or gpsdo if
installed, will ensure that they are aligned.

> 3) If that does not work, maybe the FPGA can handly only one command at a
time - even if you tell him to execute two. Then it may be possible to
start one command timed before the other and extend that sequence of
samples with the correct amount of zeros.

Each radio channel has it's own queue for timed commands so it is possible
to schedule all channels simultaneously.

Derek

On Mon, Jul 30, 2018 at 8:08 AM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Young,
>
> I am not an expert, but I have three suggestions:
> 1) Using 'Unknown PSS' or any other sync method should not have no affect,
> as this is for syncing two or more USRPs. You have only one FPGA and that
> is in sync with itself ;)
> 2) Did you tried using timed commands? (see function set_command_time())
> 3) If that does not work, maybe the FPGA can handly only one command at a
> time - even if you tell him to execute two. Then it may be possible to
> start one command timed before the other and extend that sequence of
> samples with the correct amount of zeros.
>
> Best regards,
> Fabian
>
> Am 30.07.2018 um 08:34 schrieb YoungC_Park via USRP-users:
>
>> Hi all,
>>
>> I hope someone could help me on my situation. I could not find similar
>> cases on the usrp archive.
>>
>> I have one USRP X310 that has UBX-160(slot A) , LFTX board(slot B) and
>> GPS module installed.
>>
>> - my UHD is 3.11.0
>>
>> - Using uhd API based on tx_samples from_file.cpp, I can generate dual
>> output bursts from UBX160 and LFTX with 200MHz master clock and 100Msps on
>> USRP X310.
>>
>> - However, the second output (ch 1, red in the picture) is lagged from
>> the first one (ch 0, yellow) by about (~10us with +-4us uncertainty)
>>
>> - The baseband burst is a sawtooth waveform of two cycles(2000 samples
>> long). and UBX160 modulates it into fc = 1GHz whereas LFTX generates it as
>> is.
>>
>> - This lagging is quite constant (10us) even if I change the sampling
>> rate (10,20,50, 100MSps).
>>
>> - Tried 'Unknown PPS', 'gpsdo', 'internal',,, but no difference.
>>
>> - When I switch the order of channels to (1,0) as opposed to (0,1), then
>> the ch0 lags behind the ch1, which seems that this is related to some
>> sequenced process…
>>
>> We are seeking for helps on the cause and cure about this lagging…
>>
>> Thanks,
>>
>> Young C. Park
>>
>>
>>
>> ___
>> 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

[USRP-users] 回复:Re: overflowed when running two B210 simultaneously inone pc

[李春明 via USRP-users]

Hi，

thanks for you attention, i used two multi usrp object for each one. and usb 3 
used.

--原始邮件--
发件人："Marcus D. Leech via USRP-users ";
发送时间：2018年7月30日(星期一) 晚上11:36
收件人："usrp-users" ;
主题：Re: [USRP-users] overflowed when running two B210 simultaneously inone pc
---
On 07/30/2018 09:32 AM, lichunming via   USRP-users wrote:
 
 Dear All, I've got the following problem: I used 
two B210 boards simultaneously in one program on one desktop pc with i7-7700K 
cpu, the two B210 was set different centre frequency. I started board A 
firstly, and it worked with no problem. Then I started board B and there was  
"overflowed" problems reported by uhd. I added some logs in UHD, found the 
problem was produced in bellow line: (function: 
get_and_process_single_packet,file: super_recv_packet_handler.hpp) if 
(info.ifpi.packet_type != vrt::if_packet_info_t::PACKET_TYPE_DATA){ 
 return PACKET_INLINE_MESSAGE; } The error was produced every 
~40 packets and only occured on board A, board B seemed works rightly. 
When the error occured my program would not work properly as some packets was 
dropped.  My program env is: GNU C++ version 7.3.0; 
Boost_106501; UHD_3.11.1.0-1-g4ee2c1da.  Does anyone encounter 
the similar problem? or could you give me some hints to find the root cause?
 It seems it can not setup two B210 at one time with uhd_usrp_make() like 
usrp3(X300) device? Thanks and Kind regards,Springming 
   
  You can't have more than one B210 in a single multi_usrp object.
 
 What sample rates are you running?   Is this using USB3 or USB2?___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] overflowed when running two B210 simultaneously in one pc

[Marcus D. Leech via USRP-users]

On 07/30/2018 09:32 AM, lichunming via USRP-users wrote:

Dear All,

I've got the following problem:
I used two B210 boardssimultaneously in one program on  one desktop pc with i7-7700K cpu, 
the two B210 was set different centre frequency. I started board A firstly, and it worked 
with no problem. Then I started board B and there was  "overflowed" problems 
reported by uhd. I added some logs in UHD, found the problem was produced in bellow line:
(function: get_and_process_single_packet,file: super_recv_packet_handler.hpp)
/if (info.ifpi.packet_type != vrt::if_packet_info_t::PACKET_TYPE_DATA){/
/  return PACKET_INLINE_MESSAGE;/
/}/
The error was produced every ~40 packets and only occured on board A, board B 
seemed works rightly.
When the error occured my program would not work properly as some packets was 
dropped.
My program env is: GNU C++ version 7.3.0; Boost_106501; 
UHD_3.11.1.0-1-g4ee2c1da.
Does anyone encounter the similar problem? or could you give me some hints to 
find the root cause?
It seems it can not setup two B210 at one time with uhd_usrp_make() like 
usrp3(X300) device?
Thanks and Kind regards,
Springming


You can't have more than one B210 in a single multi_usrp object.

What sample rates are you running?   Is this using USB3 or USB2?


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

Re: [USRP-users] USRP X310 Remote Configuration

[Rob Kossler via USRP-users]

Perhaps look at the RFNoC siggen block. You will need to add some component
such as a block memory or fifo to store the samples on the fpga and then
you will need a way to populate the memory and then play it out when
desired.

Rob

On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh 
wrote:

> Dear Rob,
> Thanks for your helpful response. The reason that we need to use a switch
> is due to hour host hardware limits, which only have one 10GBE.
> About the second remark in your email, do you have an example or a
> reference where a similar case was implemented which we can use  as a
> guideline for our implementation?
>
> Best regards,
> Farnaz
>
> On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler  wrote:
>
>> Hi Farnaz,
>> A couple of remarks and questions
>> - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED to
>> have the samples on the USRP. The host-to-USRP streaming does not work at
>> 200 MS/s for the transmit case (unless something has recently changed). The
>> host-to-USRP max for transmit is 100 MS/s per channel
>> - Remark 2: that leads into your question about having the samples stored
>> on the USRP rather than streamed from host.  This is not presently a
>> capability, but can be added with some modest FPGA work.  I have been
>> desiring such capability for a couple of years - I hope that Ettus adds
>> such capability in the future.
>> - Question 1: why do you plan to use a 10gbe switch with a single
>> connection to the host PC?  Why not have multiple 10Gbe links at the PC
>> which connect to each USRP individually.  A NIC such as Intel XL-710
>> provides 4 10gbe links.
>>
>> Rob
>>
>>
>> On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dears,
>>>
>>> To be more specific, we want to control multiple USRPs with one (remote)
>>> computer. We would like to stream known and periodic signal from each USRP.
>>> The sequence on each USRP is unique and is different from other USRPs.
>>>
>>>  Since the samples from each USRP are known, it would be more
>>> convenient if we can generate the samples once and preferably store them
>>> locally on each USRP. In this configuration,  we want to use the host
>>> computer to send control commands to the USRPs specifying when each of them
>>> must transmit its specific samples. The USRPs are assumed to be
>>> synchronized, so the control commands from the host will generate a TDMA
>>> scheme. Each USRP will start signal transmission upon receiving the control
>>> command from the host computer. I would like to know that:
>>>
>>> 1. Is it possible to store the samples on the USRPs? or should we stream
>>> the samples from the host computer to the USRPs for each transmission?
>>> 2.  Can we use the full bandwidth and 200MS/s in this setup?
>>> 3. After knowing the answer to the previous question,  I would like to
>>> know how we can implement it? do you happen to have a demo or an example
>>> that can guide us in this implementation?
>>>
>>> Best,
>>> Farnaz
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 27, 2018 at 4:50 AM, Michael West 
>>> wrote:
>>>
 Hi Farnaz,

 To clarify and expand on Marcus' comments, the answer is maybe.  You
 can do burst captures and transmissions at full rate and you can even use
 timed commands to synchronize them, but there are limitations.  If you can
 describe in more detail what you want to do, we can more clearly tell you
 if it is possible.  How many channels do you plan to do simultaneously?
 How many 10 GbE connections between the host and switch?  How many 10 GbE
 connections between each USRP and the switch?

 There is buffering of the TX samples on the X310 and it is
 configurable.  The current default is 32 MB.  The DRAM is a total of 1 GB,
 and it can be divided up however necessary.

 Regards,
 Michael

 On Mon, Jun 25, 2018 at 12:23 PM, Marcus Müller via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Dear Fernaz,
>
> you can't cheat 10Gig bandwidth! If you time-share any medium, then
> it's bandwidth must be shared. Since ethernet is de facto a timesharing
> thing, anyway, no, this won't work:
> Since you need to push through all the data through a single 10GigE
> connection, your 10 gigabits per second need to be divided along *all
> simultaneously operating* USRPs. So, if you have, say 10 USRPs, and all
> should be working at the same time, you've only got 1 gigabit per
> second per USRP, which limits you to about 25 MSample/s per USRP. It's
> really the same principle as a single internet access being shared by
> all people attached to the same router.
>
> Now, if these USRPs *don't* have to transmit all at the same time, then
> more is possible.
>
> > Also, does anyone know if it is possible to store the samples on the
> transmit USRPs?
>
> I'll go with a: no, at least probably not 

[USRP-users] overflowed when running two B210 simultaneously in one pc

[lichunming via USRP-users]

Dear All, I've got the following problem:
I used two B210 boardssimultaneously in one program on one desktop pc with 
i7-7700K cpu, the two B210 was set different centre frequency. I started board 
A firstly, and it worked with no problem. Then I started board B and there was 
"overflowed" problems reported by uhd. I added some logs in UHD, found the 
problem was produced in bellow line:
(function: get_and_process_single_packet,file: super_recv_packet_handler.hpp)
if (info.ifpi.packet_type != vrt::if_packet_info_t::PACKET_TYPE_DATA){
return PACKET_INLINE_MESSAGE;
}
The error was produced every ~40 packets and only occured on board A, board B 
seemed works rightly.
When the error occured my program would not work properly as some packets was 
dropped.


My program env is: GNU C++ version 7.3.0; Boost_106501; 
UHD_3.11.1.0-1-g4ee2c1da.


Does anyone encounter the similar problem? or could you give me some hints to 
find the root cause?
It seems it can not setup two B210 at one time with uhd_usrp_make() like 
usrp3(X300) device?


Thanks and Kind regards,


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

Re: [USRP-users] USRP X310 Remote Configuration

[Farnaz Chamanzadeh via USRP-users]

Dear Rob,
Thanks for your helpful response. The reason that we need to use a switch
is due to hour host hardware limits, which only have one 10GBE.
About the second remark in your email, do you have an example or a
reference where a similar case was implemented which we can use  as a
guideline for our implementation?

Best regards,
Farnaz

On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler  wrote:

> Hi Farnaz,
> A couple of remarks and questions
> - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED to
> have the samples on the USRP. The host-to-USRP streaming does not work at
> 200 MS/s for the transmit case (unless something has recently changed). The
> host-to-USRP max for transmit is 100 MS/s per channel
> - Remark 2: that leads into your question about having the samples stored
> on the USRP rather than streamed from host.  This is not presently a
> capability, but can be added with some modest FPGA work.  I have been
> desiring such capability for a couple of years - I hope that Ettus adds
> such capability in the future.
> - Question 1: why do you plan to use a 10gbe switch with a single
> connection to the host PC?  Why not have multiple 10Gbe links at the PC
> which connect to each USRP individually.  A NIC such as Intel XL-710
> provides 4 10gbe links.
>
> Rob
>
>
> On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dears,
>>
>> To be more specific, we want to control multiple USRPs with one (remote)
>> computer. We would like to stream known and periodic signal from each USRP.
>> The sequence on each USRP is unique and is different from other USRPs.
>>
>>  Since the samples from each USRP are known, it would be more
>> convenient if we can generate the samples once and preferably store them
>> locally on each USRP. In this configuration,  we want to use the host
>> computer to send control commands to the USRPs specifying when each of them
>> must transmit its specific samples. The USRPs are assumed to be
>> synchronized, so the control commands from the host will generate a TDMA
>> scheme. Each USRP will start signal transmission upon receiving the control
>> command from the host computer. I would like to know that:
>>
>> 1. Is it possible to store the samples on the USRPs? or should we stream
>> the samples from the host computer to the USRPs for each transmission?
>> 2.  Can we use the full bandwidth and 200MS/s in this setup?
>> 3. After knowing the answer to the previous question,  I would like to
>> know how we can implement it? do you happen to have a demo or an example
>> that can guide us in this implementation?
>>
>> Best,
>> Farnaz
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 27, 2018 at 4:50 AM, Michael West 
>> wrote:
>>
>>> Hi Farnaz,
>>>
>>> To clarify and expand on Marcus' comments, the answer is maybe.  You can
>>> do burst captures and transmissions at full rate and you can even use timed
>>> commands to synchronize them, but there are limitations.  If you can
>>> describe in more detail what you want to do, we can more clearly tell you
>>> if it is possible.  How many channels do you plan to do simultaneously?
>>> How many 10 GbE connections between the host and switch?  How many 10 GbE
>>> connections between each USRP and the switch?
>>>
>>> There is buffering of the TX samples on the X310 and it is
>>> configurable.  The current default is 32 MB.  The DRAM is a total of 1 GB,
>>> and it can be divided up however necessary.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Jun 25, 2018 at 12:23 PM, Marcus Müller via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Dear Fernaz,

 you can't cheat 10Gig bandwidth! If you time-share any medium, then
 it's bandwidth must be shared. Since ethernet is de facto a timesharing
 thing, anyway, no, this won't work:
 Since you need to push through all the data through a single 10GigE
 connection, your 10 gigabits per second need to be divided along *all
 simultaneously operating* USRPs. So, if you have, say 10 USRPs, and all
 should be working at the same time, you've only got 1 gigabit per
 second per USRP, which limits you to about 25 MSample/s per USRP. It's
 really the same principle as a single internet access being shared by
 all people attached to the same router.

 Now, if these USRPs *don't* have to transmit all at the same time, then
 more is possible.

 > Also, does anyone know if it is possible to store the samples on the
 transmit USRPs?

 I'll go with a: no, at least probably not like you hope it is. Can you
 elaborate on your use case? Maybe we can help you if we better
 understand what you're trying to implement, from a bit of distance?

 Best regards,
 Marcus

 On Mon, 2018-06-25 at 20:32 +0200, Farnaz Chamanzadeh via USRP-users
 wrote:
 > Dear all,
 >
 >  I want to connect multiple USRP X310 to one host PC and control them
 > all 

Re: [USRP-users] Latency between multiple daughter boards on one USRP X310

[Fabian Schwartau via USRP-users]

Hi Young,

I am not an expert, but I have three suggestions:
1) Using 'Unknown PSS' or any other sync method should not have no 
affect, as this is for syncing two or more USRPs. You have only one FPGA 
and that is in sync with itself ;)

2) Did you tried using timed commands? (see function set_command_time())
3) If that does not work, maybe the FPGA can handly only one command at 
a time - even if you tell him to execute two. Then it may be possible to 
start one command timed before the other and extend that sequence of 
samples with the correct amount of zeros.


Best regards,
Fabian

Am 30.07.2018 um 08:34 schrieb YoungC_Park via USRP-users:

Hi all,

I hope someone could help me on my situation. I could not find similar 
cases on the usrp archive.


I have one USRP X310 that has UBX-160(slot A) , LFTX board(slot B) and 
GPS module installed.


- my UHD is 3.11.0

- Using uhd API based on tx_samples from_file.cpp, I can generate dual 
output bursts from UBX160 and LFTX with 200MHz master clock and 100Msps 
on USRP X310.


- However, the second output (ch 1, red in the picture) is lagged from 
the first one (ch 0, yellow) by about (~10us with +-4us uncertainty)


- The baseband burst is a sawtooth waveform of two cycles(2000 samples 
long). and UBX160 modulates it into fc = 1GHz whereas LFTX generates it 
as is.


- This lagging is quite constant (10us) even if I change the sampling 
rate (10,20,50, 100MSps).


- Tried 'Unknown PPS', 'gpsdo', 'internal',,, but no difference.

- When I switch the order of channels to (1,0) as opposed to (0,1), then 
the ch0 lags behind the ch1, which seems that this is related to some 
sequenced process…


We are seeking for helps on the cause and cure about this lagging…

Thanks,

Young C. Park



___
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] Latency between multiple daughter boards on one USRP X310

[YoungC_Park via USRP-users]

Hi all,

I hope someone could help me on my situation. I could not find similar cases on 
the usrp archive.

 

I have one USRP X310 that has UBX-160(slot A) , LFTX board(slot B) and GPS 
module installed.

- my UHD is 3.11.0

- Using uhd API based on tx_samples from_file.cpp, I can generate dual output 
bursts from UBX160 and LFTX with 200MHz master clock and 100Msps on USRP X310.

- However, the second output (ch 1, red in the picture) is lagged from the 
first one (ch 0, yellow) by about (~10us with +-4us uncertainty)

- The baseband burst is a sawtooth waveform of two cycles(2000 samples long). 
and UBX160 modulates it into fc = 1GHz whereas LFTX generates it as is.

- This lagging is quite constant (10us) even if I change the sampling rate 
(10,20,50, 100MSps).

- Tried 'Unknown PPS', 'gpsdo', 'internal',,, but no difference.

- When I switch the order of channels to (1,0) as opposed to (0,1), then the 
ch0 lags behind the ch1, which seems that this is related to some sequenced 
process…

 

We are seeking for helps on the cause and cure about this lagging…

 

Thanks,

Young C. Park

 



 

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