Re: [USRP-users] IOError: x300 fw poke32 - reply timed out

[Stefan van der Linden via USRP-users]

It tooks us a while, but we seem to have found the root cause of the 
issue. The RAID array which was being fed the data was able to just cope 
with the dataflow peaks, although the mean dataflow was not a problem. 
Therefore, when some kind of additional process fired up or some other 
imperfection, it caused the buffer being used to overflow in some cases. 
We were able to prevent this from happening by adding an SSD-based write 
cache.
However, we still don't understand why this effectively caused the X300 
and/or the NIC to lock up, although I'm glad the problem is gone.


Kind regards,

Stefan

On 27/09/2018 11:45, Stefan van der Linden wrote:

Hi Marcus,

we've gone and updated UHD (HEAD of remotes/origin/UHD-3.13) and 
changed the MTU to 8000, unfortunately the problem still persists. A 
TCP dump as discussed before is downloadable via: 
https://we.tl/t-zTKY2iHAlK.
Note that 192.168.50.1 is the host and 192.168.50.2 is the X300. The 
download also contains a dump of the shell output, just in case. The 
program ran without problems for a good two hours or so.

Hope this helps in debugging!

Kind regards,

Stefan


On 24/09/2018 22:38, Marcus Müller wrote:

Hi Stefan,

so I've talked to our main software sustainance hero, and we rather
quickly came to the conclusion that it's pretty likely you should move
on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are you
building from source, or are you using binary packages?

Best regards,
Marcus

On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote:

Hi Stefan,

I know it's not of great comfort when an engineer finds a problem to
be
/interesting/, but yours certainly is.
So, first things first: if the computational power and memory of the
host that your USRP is connected to allows, it might be good to have
a
packet capture in some kind of a ring buffer, so that you can infer a
bit on the state at the point where things go wrong:

tcpdump -n # no DNS lookups
-i 
-s 0 # don't stop after a finite amount of packets
-C 400 # 400 million bytes per capture file
-W 2 # rotate through three files of capturs
-w /tmp/rotate.pcap # make sure that you're using a file that's on an
RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs
/path`

So, yes, using an MTU of 8000 would be the first thing that the Ettus
hivemind would recommend, too, but if you say things still go wrong,
we
might need to dig deeper.

I do know that we've improved the bus clocking, and that had impact
on
the X300 firmware. Is trying the last 3.10 release an option for you?

Best regards,
Marcus

On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP-
users
wrote:

Hi,

We are in the process of prototyping a setup using an X300 with two
UBX-40 daughterboards to be used in the validation of an externally
provided signal source. The daughterboards are each dedicated to
one
of two tasks: transmitting a pre-recorded reference signal in a
loop
at 50 MSps, and capturing that same signal again after passing
through a chain of devices under test at 25MSps. This is to run
continuously up to 24 hours.

The X300 is connected to the (dedicated) host computer via a 10Gbps
connection to an Intel X520-DA2 NAC over SFP+. On the host, we are
currently using the kitchen_sink utility included with UHD to run
the
system in multi-channel mode. We are using UHD 3.11.0.1.

The system works flawlessly when performing short measurements
(say,
up to an hour or so). However, having recently started setting up
the
system for long 24 hour tests, we are seeing timeouts from which
UHD
is unable to recover. These timeouts occur randomly: sometimes they
occur after ~1 hours, other times they occur after ~18 hours and
everywhere in between. Naturally, this random behaviour makes it
difficult to debug.

The error message retrieved from UHD is as follows:

As previous messages on this list have mentioned varying the MTU
settings (for example:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html 


), this was the first thing we tried. Unfortunately, these timeouts
occur more often at lower MTU values.

Hopefully someone is able to point us in the right direction.
Perhaps
we are dealing with hardware issues here, but I'd I hope we are
able
to solve this through software.

Thanks,
Stefan van der Linden
___
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] twinrx example

[Koyel Das (Vehere) via USRP-users]

Hi,


I am not finding an example to receive data for twinrx case of USRP x300/310.


I am looking at the following link:


https://github.com/EttusResearch/uhd/tree/master/host/examples



[https://avatars0.githubusercontent.com/u/125709?s=400=4]

uhd/host/examples at master · EttusResearch/uhd · 
GitHub
github.com
The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd 
development by creating an account on GitHub.




Can someone please share the link of c++ code for receiving data from twinrx 
for x300/310?


Regards,

Koyel

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

Re: [USRP-users] Can I use chained DDCs?

[Jason Matusiak via USRP-users]

Brian,
 
It looks like switching from rfnoc-devel to the head of master cleaned up my 
issues (Once I realized a clock rate of 120MHz was no longer supported).  Not 
sure what was the problem, but I won't worry about it at this point.
 
I think you are right on the DDC, I will need to look into that more next.
 
- Original Message - Subject: RE: Re: Re: [USRP-users] Can I 
use chained DDCs?
From: "Jason Matusiak" 
Date: 12/3/18 12:08 pm
To: "Brian Padalino" 
Cc: "USRP-users@lists.ettus.com" 

 Brian,
 
No.  I am leaving it alone on startup.  I was running off of the rfnoc_devel 
branch.  I just changed to master and am attempting to rebuild with RFNOC 
enabled to see if something else has been introduced to it.  I should try to 
roll back a version or two and see what that does for me as well. Thanks!
 
- Original Message - Subject: Re: Re: [USRP-users] Can I use 
chained DDCs?
From: "Brian Padalino" 
Date: 12/3/18 12:03 pm
To: "Jason Matusiak" 
Cc: "USRP-users@lists.ettus.com" 

 Hey Jason,
  On Mon, Dec 3, 2018 at 11:50 AM Jason Matusiak 
 wrote:
 Brian,
 
I am not sure what the issue is here.  I don't think it is the chained DDC 
anymore as I can see the issue with the single DDC using multiple different 
bitfiles.
 
I wasn't re-tuning the Fc anywhere, I was just dropping the sample rate from 
120MHz down to something I could handle.  Right now I am not touching the 
CORDIC modifications at all.
  
Are you trying to change the samplerate at runtime after starting the stream?  
In my experience, ever since around the time the the DDC moved from a CORDIC to 
using a DDS, dynamically changing the samplerate at runtime after starting a 
stream is broken and causes strange behavior.  In my experiences, it's been 
timeouts.
 
  
What version of UHD are you running for your applications?
  
I think I settled on 3.13.0.1 release as my stable base, and I have a few 
patches applied.
 
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Can I use chained DDCs?

[Jason Matusiak via USRP-users]

Brian,
 
No.  I am leaving it alone on startup.  I was running off of the rfnoc_devel 
branch.  I just changed to master and am attempting to rebuild with RFNOC 
enabled to see if something else has been introduced to it.  I should try to 
roll back a version or two and see what that does for me as well. Thanks!
 
- Original Message - Subject: Re: Re: [USRP-users] Can I use 
chained DDCs?
From: "Brian Padalino" 
Date: 12/3/18 12:03 pm
To: "Jason Matusiak" 
Cc: "USRP-users@lists.ettus.com" 

 Hey Jason,
  On Mon, Dec 3, 2018 at 11:50 AM Jason Matusiak 
 wrote:
 Brian,
 
I am not sure what the issue is here.  I don't think it is the chained DDC 
anymore as I can see the issue with the single DDC using multiple different 
bitfiles.
 
I wasn't re-tuning the Fc anywhere, I was just dropping the sample rate from 
120MHz down to something I could handle.  Right now I am not touching the 
CORDIC modifications at all.
  
Are you trying to change the samplerate at runtime after starting the stream?  
In my experience, ever since around the time the the DDC moved from a CORDIC to 
using a DDS, dynamically changing the samplerate at runtime after starting a 
stream is broken and causes strange behavior.  In my experiences, it's been 
timeouts.
 
  
What version of UHD are you running for your applications?
  
I think I settled on 3.13.0.1 release as my stable base, and I have a few 
patches applied.
 
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Can I use chained DDCs?

[Brian Padalino via USRP-users]

Hey Jason,
On Mon, Dec 3, 2018 at 11:50 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Brian,
>
> I am not sure what the issue is here.  I don't think it is the chained DDC
> anymore as I can see the issue with the single DDC using multiple different
> bitfiles.
>
> I wasn't re-tuning the Fc anywhere, I was just dropping the sample rate
> from 120MHz down to something I could handle.  Right now I am not touching
> the CORDIC modifications at all.
>

Are you trying to change the samplerate at runtime after starting the
stream?  In my experience, ever since around the time the the DDC moved
from a CORDIC to using a DDS, dynamically changing the samplerate at
runtime after starting a stream is broken and causes strange behavior.  In
my experiences, it's been timeouts.


>
> What version of UHD are you running for your applications?
>

I think I settled on 3.13.0.1 release as my stable base, and I have a few
patches applied.

Brian

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

Re: [USRP-users] X310, basicRX - using all channels in real mode with DDC

[Gwenhael Goavec-Merou via USRP-users]

I've tried with USRP block instead of RFNoC block (flowgraph attached).
For subdev spec I have used A:AB A:BA B:AB B:BA because in  other cases uhd
fails with : 
thread[thread-per-block[0]: ]: RuntimeError: On
node 0/DDC_0, output port 0 is already connected.

For ch1 et ch3 tried A or B without success.

Gwen

Serie of O in console panel and nothing displayed on plot.


On Fri, 30 Nov 2018 12:04:06 -0500
Rob Kossler  wrote:

> I notice that the GRC is using RFNoC blocks.  Perhaps it would be a good
> test to implement standard UHD USRP blocks.  I think that your
> functionality is possible with the USRP blocks.
> Rob
> 
> On Mon, Nov 19, 2018 at 7:25 AM Gwenhael Goavec-Merou via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
> > Hello,
> >
> > No ideas, advice or anything else to solve my problem?
> >
> > Thank
> >
> > Gwen
> >
> > On Tue, 6 Nov 2018 22:34:27 +0100
> > Gwenhael Goavec-Merou via USRP-users  wrote:
> >  
> > > On Tue, 06 Nov 2018 15:42:10 -0500
> > > "Marcus D. Leech"  wrote:
> > >  
> > > > On 11/06/2018 12:23 PM, Gwenhael Goavec-Merou wrote:  
> > > > > On Tue, 06 Nov 2018 12:09:02 -0500
> > > > > "Marcus D. Leech"  wrote:
> > > > >  
> > > > >> On 11/06/2018 10:24 AM, Gwenhael Goavec-Merou wrote:  
> > > > >>> On Tue, 06 Nov 2018 09:40:09 -0500
> > > > >>> "Marcus D. Leech via USRP-users"   
> > wrote:  
> > > > >>>  
> > > >  On 11/06/2018 04:12 AM, Gwenhael Goavec-Merou via USRP-users  
> > wrote:  
> > > > > Hi,
> > > > >
> > > > > My environment is:
> > > > > USRP: X310 with basicRX (currently one but 6 in a near future)
> > > > > UHD: 3.13.1.0-rc1
> > > > > GNURadio: 3.7.13.4-r2
> > > > > gr-ettus: master branch, up to date
> > > > >
> > > > > I need to sample 4 real signal / USRP and to demodulate /  
> > decimate  
> > > > > before transfer to the PC.
> > > > >
> > > > > I have created a GNURadio flow with:
> > > > > - 2 Radio (id 0 and 1), configured with 2 channels
> > > > > - 2 DDC (id 0 and 1), with 2 channels, with a center frequency  
> > fixed  
> > > > > to XX MHz
> > > > > - 4 complex To Real;
> > > > > - 1 QT Gui with 4 inputs.
> > > > >
> > > > > Each channel of each radio is connected to an DDC input (radio0
> > > > > channel 0 to DDC0 input 0, radio0 channel 1 to DDC0 input 1,  
> > etc.)  
> > > > >
> > > > > With this setup and with an input configured as XX + YY MHz (to  
> > have a  
> > > > > beatnote) I'm able to see a sinusoid on the qt for all channels  
> > (if I  
> > > > > plug / unplug an input signal the corresponding plot is equal to  
> > 0 or  
> > > > > displays the signal).
> > > > > But:
> > > > > 1/ the console panel display continuouly messages about channels
> > > > > overrun 2/ the data flow is not continuous (visible in qt plot)  
> > (I  
> > > > > suppose is due to 1/ )
> > > > > 3/ channels are not aligned (I suppose is due to 1/ and/or 2/
> > > > >
> > > > > Theorically, by reading HDL files for the X310 firmware it's  
> > seems  
> > > > > possible to use this configuration.
> > > > >
> > > > > Then, how to fix my issue?
> > > > > - Is it a USRP/UHD limitation?
> > > > > - gr-ettus seems not heavily upgraded, is something must be  
> > modified  
> > > > > in this repository?
> > > > > - I am just wrong somewhere on my design?
> > > > >
> > > > > Thank you very much
> > > > >
> > > > > Gwen
> > > > >  
> > > >  What is the sample rate as delivered to the PC?  What kind of  
> > PC?  
> > > > >>> The sample rate is 3MS/s for each channels after DDC (200MS/s  
> > before due  
> > > > >>> to the ADC).
> > > > >>> My PC is a Lenovo thinkpad x230 with a 1Gb ethernet card.  
> > > >  Overrun means that your PC isn't keeping up with the sample flow.
> > > >   
> > > > >>> I've just done several test with only 2 channels :
> > > > >>> - 2 radio, 1 channel/radio and 2 DDC with 1 input (first on  
> > radio0, a  
> > > > >>> second radio1) :
> > > > >>> - data continuous (but not synchronized)
> > > > >>> - no message on display panel
> > > > >>> - 2 radio, 1 channel/radio and 1 DDC with 2 input :
> > > > >>> - console panel displays continuouly "Ooverrun on chan 0"
> > > > >>> - data not continuous
> > > > >>> - after a short time : freeze
> > > > >>> - 1 radio with 2 channels and 1 DDC with 2 input :
> > > > >>> - console panel displays continuouly "Ooverrun on chan 0"  
> > and  
> > > > >>> "Ooverrun on chan 1"
> > > > >>> - data not continuous.
> > > > >>> - 1 radio with 2 channels and 2 DDC with 1 input :
> > > > >>> - console panel displays continuouly "Ooverrun on chan 0"
> > > > >>> - data not continuous.
> > > > >>>
> > > > >>> So, the first test seems to show it's possible with my computer to
> > > > >>> receive 2 channel 3MS/s without overrun. Other tests seems to show  

Re: [USRP-users] Can I use chained DDCs?

[Jason Matusiak via USRP-users]

Brian,
 
I am not sure what the issue is here.  I don't think it is the chained DDC 
anymore as I can see the issue with the single DDC using multiple different 
bitfiles.
 
I wasn't re-tuning the Fc anywhere, I was just dropping the sample rate from 
120MHz down to something I could handle.  Right now I am not touching the 
CORDIC modifications at all.
 
What version of UHD are you running for your applications?
 
 
- Original Message - Subject: Re: [USRP-users] Can I use 
chained DDCs?
From: "Brian Padalino" 
Date: 12/3/18 11:44 am
To: "Jason Matusiak" 
Cc: "USRP-users@lists.ettus.com" 

   On Mon, Dec 3, 2018 at 11:32 AM Jason Matusiak via USRP-users 
 wrote:
 Actually, upon further review, I can get this to happen with the stock XG 
image and as simple flowgraph as possible.
 
If I run the stock image as non-RFNoC seems to be fine, so it has something to 
do with me using RFNoC.
 
I tried switing to HG, but I see the same issues.
 
Has anyone else experienced this?  I find it hard to believe that this is 
happening for everyone else, but I can't figure out why it would happen with 
the stock image.  My specs are:
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-28); 
Boost_105300; UHD_4.0.0.rfnoc-devel-702-geec24d7b
 
 
- Original Message - Subject: Can I use chained DDCs?
From: "Jason Matusiak" 
Date: 12/3/18 7:23 am
To: "Ettus Mail List" 

 I have a flowgraph where I use 3 different DDCs on an X310.  There is a dual 
DDC that is connected to the two radios on the X310.  Then I have 2 single DDCs 
chained off of that first one.  I built these DDCs to only have a single 
input/output on them.

   
The dual DDC still only has one AXI input port to it, so it can't handle 2 
radios worth of stuff going into it.  Right?  This seems weird to me.
 

The flowgraph will work, but sometimes won't.  What I see is that things 
sometimes get tuned off center.  I have a tone that I am putting out on a 
different device, I fire up my flowgraph, and I see the tone in both paths 
(that is an example, it doesn't always work on every first run).  I stop the 
flowgraph and run again.  This time it may work, or it might be off-tuned.  If 
I re-tune the radio via Qt, I can see the signal elsewhere.  Why would this be?
 
One more piece of information.  When it is off-tuned, it isn't always the same 
place.  Sometimes it is only off by 100s of kHz, sometimes it is off my 10s of 
MHz.  This is VERY odd to me.   Any advice?

   
I run a modified FPGA with a modified such that I have:  Radio -> Single 
Channel DDC -> Modified Multiple Output DDC -> Host, and I heavily utilize 
changing the center frequencies of each of those DDC's.  It works flawlessly.
 
In your RFNoC application, how are you changing that center frequency of the 
downstream DDC's?  Are you sure you've appropriately translated the frequency 
to whatever new baseband from the first DDC?
 
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Can I use chained DDCs?

[Brian Padalino via USRP-users]

On Mon, Dec 3, 2018 at 11:32 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Actually, upon further review, I can get this to happen with the stock XG
> image and as simple flowgraph as possible.
>
> If I run the stock image as non-RFNoC seems to be fine, so it has
> something to do with me using RFNoC.
>
> I tried switing to HG, but I see the same issues.
>
> Has anyone else experienced this?  I find it hard to believe that this is
> happening for everyone else, but I can't figure out why it would happen
> with the stock image.  My specs are:
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-28);
> Boost_105300; UHD_4.0.0.rfnoc-devel-702-geec24d7b
>
>
>
> - Original Message -
> Subject: Can I use chained DDCs?
> From: "Jason Matusiak" 
> Date: 12/3/18 7:23 am
> To: "Ettus Mail List" 
>
> I have a flowgraph where I use 3 different DDCs on an X310.  There is a
> dual DDC that is connected to the two radios on the X310.  Then I have 2
> single DDCs chained off of that first one.  I built these DDCs to only have
> a single input/output on them.
>
>
The dual DDC still only has one AXI input port to it, so it can't handle 2
radios worth of stuff going into it.  Right?  This seems weird to me.


>
> The flowgraph will work, but sometimes won't.  What I see is that things
> sometimes get tuned off center.  I have a tone that I am putting out on a
> different device, I fire up my flowgraph, and I see the tone in both paths
> (that is an example, it doesn't always work on every first run).  I stop
> the flowgraph and run again.  This time it may work, or it might be
> off-tuned.  If I re-tune the radio via Qt, I can see the signal elsewhere.
> Why would this be?
>
> One more piece of information.  When it is off-tuned, it isn't always the
> same place.  Sometimes it is only off by 100s of kHz, sometimes it is off
> my 10s of MHz.  This is VERY odd to me.   Any advice?
>
>
I run a modified FPGA with a modified such that I have:  Radio -> Single
Channel DDC -> Modified Multiple Output DDC -> Host, and I heavily utilize
changing the center frequencies of each of those DDC's.  It works
flawlessly.

In your RFNoC application, how are you changing that center frequency of
the downstream DDC's?  Are you sure you've appropriately translated the
frequency to whatever new baseband from the first DDC?

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

Re: [USRP-users] rfnoc problem with custom DDC inputs.

[Carlos Alberto Ruiz Naranjo via USRP-users]

Ok, I had a problem with *radio_block_port. *I had a signed number... :(

I think now it runs. I will pass to 1:8 DCC and later with 2:16 DDC. I
continue... :)

El lun., 3 dic. 2018 a las 16:09, Carlos Alberto Ruiz Naranjo (<
carlosruiznara...@gmail.com>) escribió:

> Hello Brian,
>
> thanks for your answer! I have returned today and I am testing your
> changes.
>
> I am using grc and I have the error:
>
> *thread[thread-per-block[0]: ]: LookupError:
> KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*
>
> I assume the error is in the configuration of uhd::device_addr_t. Can you
> explain how it works? I have not understood it well, I'm sorry :( :(
>
> I am configuring it with grc python block:
>
> *self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
> ",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*
>
> I have never tried to change the settings.
>
> Thank you in advance!!! :)
>
> El vie., 30 nov. 2018 a las 16:58, Brian Padalino ()
> escribió:
>
>> Hey Carlos,
>>
>> The attached patch is what I used applied to 3.13.0.1 I want to say.  You
>> get the idea.
>>
>> To get the controller, I use get_block_ctrl(uhd::rfnoc::block_id_t(0,
>> "NAME", 0)) since there is only one instance, for me, in my radio.
>>
>> When setting up the uhd::device_addr_t, I populate: block_port%d,
>> radio_id%d, and radio_port%d where block_port%d is the output block you're
>> looking at streaming from.
>>
>> Hope this is helpful.
>>
>> Good luck.
>>
>> Brian
>>
>> On Fri, Nov 30, 2018 at 4:34 AM Carlos Alberto Ruiz Naranjo <
>> carlosruiznara...@gmail.com> wrote:
>>
>>> Hello Brian,
>>>
>>> I have finished the FPGA code. I got a DDC 1:2 but I have problems with
>>> 1:8. I think I have your same problems: /
>>>
>>> *thread[thread-per-block[0]: ]: LookupError:
>>> KeyError: [0/Radio_0] sr_write(): No such port: 2*
>>>
>>> In rfnoc code:
>>>
>>>
>>>
>>>
>>>
>>> *std::vector >
>>> upstream_radio_nodes =
>>> blk_ctrl->find_upstream_node();
>>> UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " <<
>>> upstream_radio_nodes.size();for(const
>>> boost::shared_ptr :  upstream_radio_nodes)
>>> {node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID,
>>> xport.send_sid.get_src(), block_port);}*
>>>
>>> I've found your post (
>>> http://ettus.80997.x6.nabble.com/USRP-users-Multiple-Output-RFNoC-Block-td9587.html
>>> ), but I'm stuck on the same point.
>>> Could you give me any suggestions?
>>>
>>> Thank you!! :)
>>>
>>>
>>>
>>>
>>> El mié., 28 nov. 2018 a las 16:17, Carlos Alberto Ruiz Naranjo (<
>>> carlosruiznara...@gmail.com>) escribió:
>>>
 Ok! Thank you :)

 El mié., 28 nov. 2018 a las 16:13, Brian Padalino ()
 escribió:

> On Wed, Nov 28, 2018 at 9:43 AM Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com> wrote:
>
>> Thank you! I already have enough work to continue :)
>>
>> One last thing. In the split_stream module, did you concat tuser with
>> m_axis_data_tuser with m_axis_data_tdata?
>>
>
> No tuser at that point.  Just the stream part - tdata, tlast, tvalid,
> and tready.
>
>
>>
>> I'm curious about you election. Why do you think that version 0 is
>> better than version 1?
>>
>
> Not really sure.  It is just the way I ended up.  I think either way
> will work.  Whichever way makes sense to you, try it out!  Have fun! :)
>
> Brian
>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Can I use chained DDCs?

[Jason Matusiak via USRP-users]

Actually, upon further review, I can get this to happen with the stock XG image 
and as simple flowgraph as possible.
 
If I run the stock image as non-RFNoC seems to be fine, so it has something to 
do with me using RFNoC.
 
I tried switing to HG, but I see the same issues.
 
Has anyone else experienced this?  I find it hard to believe that this is 
happening for everyone else, but I can't figure out why it would happen with 
the stock image.  My specs are:
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-28); 
Boost_105300; UHD_4.0.0.rfnoc-devel-702-geec24d7b
 
 
- Original Message - Subject: Can I use chained DDCs?
From: "Jason Matusiak" 
Date: 12/3/18 7:23 am
To: "Ettus Mail List" 

 I have a flowgraph where I use 3 different DDCs on an X310.  There is a dual 
DDC that is connected to the two radios on the X310.  Then I have 2 single DDCs 
chained off of that first one.  I built these DDCs to only have a single 
input/output on them.
 
The flowgraph will work, but sometimes won't.  What I see is that things 
sometimes get tuned off center.  I have a tone that I am putting out on a 
different device, I fire up my flowgraph, and I see the tone in both paths 
(that is an example, it doesn't always work on every first run).  I stop the 
flowgraph and run again.  This time it may work, or it might be off-tuned.  If 
I re-tune the radio via Qt, I can see the signal elsewhere.  Why would this be?
 
One more piece of information.  When it is off-tuned, it isn't always the same 
place.  Sometimes it is only off by 100s of kHz, sometimes it is off my 10s of 
MHz.  This is VERY odd to me.   Any advice?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc problem with custom DDC inputs.

[Carlos Alberto Ruiz Naranjo via USRP-users]

Hello Brian,

thanks for your answer! I have returned today and I am testing your changes.

I am using grc and I have the error:

*thread[thread-per-block[0]: ]: LookupError:
KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*

I assume the error is in the configuration of uhd::device_addr_t. Can you
explain how it works? I have not understood it well, I'm sorry :( :(

I am configuring it with grc python block:

*self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*

I have never tried to change the settings.

Thank you in advance!!! :)

El vie., 30 nov. 2018 a las 16:58, Brian Padalino ()
escribió:

> Hey Carlos,
>
> The attached patch is what I used applied to 3.13.0.1 I want to say.  You
> get the idea.
>
> To get the controller, I use get_block_ctrl(uhd::rfnoc::block_id_t(0,
> "NAME", 0)) since there is only one instance, for me, in my radio.
>
> When setting up the uhd::device_addr_t, I populate: block_port%d,
> radio_id%d, and radio_port%d where block_port%d is the output block you're
> looking at streaming from.
>
> Hope this is helpful.
>
> Good luck.
>
> Brian
>
> On Fri, Nov 30, 2018 at 4:34 AM Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com> wrote:
>
>> Hello Brian,
>>
>> I have finished the FPGA code. I got a DDC 1:2 but I have problems with
>> 1:8. I think I have your same problems: /
>>
>> *thread[thread-per-block[0]: ]: LookupError:
>> KeyError: [0/Radio_0] sr_write(): No such port: 2*
>>
>> In rfnoc code:
>>
>>
>>
>>
>>
>> *std::vector >
>> upstream_radio_nodes =
>> blk_ctrl->find_upstream_node();
>> UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " <<
>> upstream_radio_nodes.size();for(const
>> boost::shared_ptr :  upstream_radio_nodes)
>> {node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID,
>> xport.send_sid.get_src(), block_port);}*
>>
>> I've found your post (
>> http://ettus.80997.x6.nabble.com/USRP-users-Multiple-Output-RFNoC-Block-td9587.html
>> ), but I'm stuck on the same point.
>> Could you give me any suggestions?
>>
>> Thank you!! :)
>>
>>
>>
>>
>> El mié., 28 nov. 2018 a las 16:17, Carlos Alberto Ruiz Naranjo (<
>> carlosruiznara...@gmail.com>) escribió:
>>
>>> Ok! Thank you :)
>>>
>>> El mié., 28 nov. 2018 a las 16:13, Brian Padalino ()
>>> escribió:
>>>
 On Wed, Nov 28, 2018 at 9:43 AM Carlos Alberto Ruiz Naranjo <
 carlosruiznara...@gmail.com> wrote:

> Thank you! I already have enough work to continue :)
>
> One last thing. In the split_stream module, did you concat tuser with
> m_axis_data_tuser with m_axis_data_tdata?
>

 No tuser at that point.  Just the stream part - tdata, tlast, tvalid,
 and tready.


>
> I'm curious about you election. Why do you think that version 0 is
> better than version 1?
>

 Not really sure.  It is just the way I ended up.  I think either way
 will work.  Whichever way makes sense to you, try it out!  Have fun! :)

 Brian

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

[USRP-users] Can I use chained DDCs?

[Jason Matusiak via USRP-users]

I have a flowgraph where I use 3 different DDCs on an X310.  There is a dual 
DDC that is connected to the two radios on the X310.  Then I have 2 single DDCs 
chained off of that first one.  I built these DDCs to only have a single 
input/output on them.
 
The flowgraph will work, but sometimes won't.  What I see is that things 
sometimes get tuned off center.  I have a tone that I am putting out on a 
different device, I fire up my flowgraph, and I see the tone in both paths 
(that is an example, it doesn't always work on every first run).  I stop the 
flowgraph and run again.  This time it may work, or it might be off-tuned.  If 
I re-tune the radio via Qt, I can see the signal elsewhere.  Why would this be?
 
One more piece of information.  When it is off-tuned, it isn't always the same 
place.  Sometimes it is only off by 100s of kHz, sometimes it is off my 10s of 
MHz.  This is VERY odd to me.   Any advice?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] 2955 multiple receivers not working together

[Koyel Das (Vehere) via USRP-users]

Hi Neel,


We are using windows version, which installs gnuradio and we don't need to 
install

anything else ourselves further. I didn't find a UHD folder. Is it possible to 
execute command

"uhd_find_devices" in windows also? If so how?


Regards,

Koyel



From: Neel Pandeya 
Sent: Sunday, December 2, 2018 1:00:02 AM
To: Koyel Das (Vehere)
Cc: usrp-users
Subject: Re: [USRP-users] 2955 multiple receivers not working together

Hello Koyel:

Just run "uhd_find_devices", even with no USRP hardware connected, to find the 
UHD version that you're running. It will be the first line of output. Please 
let us know.

--Neel Pandeya



On Fri, 30 Nov 2018 at 10:10, Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
On 11/30/2018 04:33 AM, Koyel Das (Vehere) wrote:

I am attaching the .grc file. I have installed gnuradio in windows.

Our USRP has gone for repair so can't check the UHD version.


Regards,

Koyel



The attached works for 4 channels just fine with my local UHD installation.


___
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] Bug in timed switching of sample rate

[Xavier Arteaga via USRP-users]

Hi Fabian,
Could it be related with this issue
 I
came across too?

Have you tried an older version?

Regards,
Xavier

On Fri, 30 Nov 2018 at 18:56, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 11/30/2018 06:11 AM, Fabian Schwartau via USRP-users wrote:
> > Hi Marcus,
> >
> > is there any update?
> >
> > Best regards,
> > Fabian
> Still being worked.
>
> >
> > Am 19.11.2018 um 20:22 schrieb Marcus D. Leech via USRP-users:
> >> On 11/19/2018 06:35 AM, Fabian Schwartau via USRP-users wrote:
> >>> Anyone? This is a quite annoying bug and I am having trouble working
> >>> around it as I cannot meet my timing requirements.
> >> I'm only about 50% certain that sample-rate setting is covered by
> >> timed commands.  I'll talk to R and get back to you on this.
> >>
> >>
> >>>
> >>> Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users:
>  Hello everyone,
> 
>  I am experencing some issues when switching the sample rate.
>  I have two synchronized USRP X310 with a total of 4 TwinRX. I am
>  doing timed commands to jump around in the spectrum with all
>  receivers at the same frequency (SIMO stuff).
>  I also need to switch sample rates in between. When I keep the
>  sample rate constant, everything works fine, but once I switch it
>  between two timed receptions, I get very strange errors. Like I get
>  an end-of-frame after just a part of the samples I requested.
>  It seems like it is not possible to time the sample rate switch
>  command. Here is a debug output of my code which makes it quite
>  clear what happens:
> 
>  (1) Changed sample rate from 1e+07 to 5e+07
>  (2) Requested 32768 Samples
>  (3) Requested 32768 Samples
>  (4) Requested 32768 Samples
>  (5) Changed sample rate from 5e+07 to 1e+07
>  (6) Reading 32768 Samples
>  (7) Got only 6553 of 32768 samples at EOF
> 
>  Commands 1-5 are transmitted to the USRP right away using its
>  command buffer. Then my program starts reading the first requested
>  32768 but gets only 6553, which is precisely 1/5th of the requested
>  samples. I guess this is because he switched sample rate to 1/5th
>  right before executing the first stream command. But the sample
>  rate switch is also timed and should be executed after the three
>  stream commands.
> 
>  I attached the part of the code which is responsible for sending
>  the timed commands to the USRPs. This runs basically in a while(1)
>  in a seperate thread, while there is a seconds thread receiving the
>  data blocks, which produced the lines 6-7 of above output.
> 
>  Is this a bug or feature I don't get? Are set_rx_rate commands not
>  timed when using set_command_time? How can I solve this isse? I
>  need very precise timing and also fast switching between
>  frequencies and sample rates.
> 
>  Best regards,
>  Fabian
> 
>  ___
>  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 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] gr-doa

[Arun kumar Verma via USRP-users]

Hi
We are working on a  phase interferometer direction finding application using 
X310 and one twinRx. Our basic model is  to use five channel broadband DF 
antenna  with a switching matrix which converts RF from  5 channels to  to 2 
Channels. So far we able to phase aligned all the channels and calculate angle 
of arrival for instantaneous bandwidth (5MHz) . Our  final requirement is to 
process 40MHz (dual Channel) or 80MHz (signle channel),Is it possible to 
process using 10G PCI card and some high end CPU. With 1G Ethernet I should be 
able to achieve 10MHz BW for dual channel  (20MHz for single channel)  but for 
10MHz i am getting error of time alignment of samples.  At present we are 
taking IQ samples and doing FFT in CPU and calculating AOA. 
Is it possible to do FFT and calculate angle using phase interferometer 
algorithm in less than 2ms for 40MHz BW (dual channel)  with 4K FFT.

Arun Verma



  From: Neel Pandeya 
 To: Arun kumar Verma   
Cc: "usrp-users@lists.ettus.com" 
 Sent: Wednesday, 24 October 2018 4:56 AM
 Subject: Re: [USRP-users] gr-doa
   
Hello Arun:
The gr-doa OOT was tested with UHD 3.10.1.0 and GNU Radio 3.7.10.1, but it 
should work with the latest releases, UHD 3.13.0.2 and GNU Radio 3.7.13.4.
It uses the default FPGA image that comes with whichever version of UHD that 
you're using. It does not require any custom or special FPGA image.
Please let me know if you have any further questions.
--Neel Pandeya



On 23 October 2018 at 13:35, Arun kumar Verma via USRP-users 
 wrote:

Hi
I am working on Direction of Arrival application using X310, just need 
information which FPGA image was used for gr-DOA demo application?
Arun

__ _
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