Re: [USRP-users] Problems with MPM 3.13 on N310

[Rob Kossler via USRP-users]

Thanks Michael,
Are you saying that when running with STREAM_MODE_START_CONTINUOUS, I can
expect a "md.end_of_burst==true" shortly after issuing the
STREAM_MODE_STOP_CONTINUOUS?  If so, that seems like a much better method
for flushing all of the samples following the stop command.

In any event, I have no problem switching over to use
STREAM_MODE_NUM_SAMPS_AND_DONE.  My issue with one or two overruns was
several years ago and I believe it was specific to the B210 (and I don't
think that increasing start delays helped at that point, but I could be
wrong).  And in general, I want to decrease rather than increase start
delays because my application runs in a fast-as-you-can
capture/process/display loop.  So, the more I increase the start delay, the
slower my loop.
Rob

On Thu, Aug 23, 2018 at 7:37 PM Michael West  wrote:

> Hi Rob,
>
> Excellent feedback as always.  Thank you.  We will look into the RX burst
> behavior using STREAM_MODE_START_CONTINUOUS, but it may take some time.
> The flush routine should have a timeout for the recv() call and be looking
> for md.end_of_burst to exit, but I'm sure there is more to the issue than
> that.  BTW, to avoid the overruns at startup, just set a start time a
> little in the future and minimize the amount of code between the
> issue_stream_cmd() call and the first recv() call.
>
> Regards,
> Michael
>
> On Thu, Aug 23, 2018 at 11:37 AM, Rob Kossler  wrote:
>
>> Martin, Michael,
>> Sorry for the long delay in responding.  I hadn't been monitoring the
>> user's list this past week and the replies you sent did not come directly
>> to my inbox.  In any event, I compiled the latest MPM and it seems to work
>> fine.  Thank you.
>>
>> Now, to the secondary issue I mentioned in the first post of this thread:
>> rx streaming timeouts. These timeouts intermittently occur in my
>> application when doing repeated rx captures (i.e., error never occurs on
>> first capture).  I tracked it down today to my application's use of
>> STREAM_MODE_START_CONTINUOUS rather than STREAM_MODE_NUM_SAMPS_AND_DONE for
>> the capture.  After changing my code to use the latter, it works well with
>> no timeouts.
>>
>> A couple of remarks:
>>
>>- I don't know if this is of concern to you or not. Perhaps I should
>>be using it the new way anyway.  A long time ago I had made the decision 
>> to
>>use STREAM_MODE_START_CONTINUOUS because I was getting one or two 
>> overflows
>>right at the start of the capture (B210) and I didn't want the capture to
>>abort as it did if I used STREAM_MODE_NUM_SAMPS_AND_DONE.
>>- With other products (B210 & X310), I have been using my application
>>and STREAM_MODE_START_CONTINUOUS for several years, successfully.  (That
>>said, I do want to mention that I have had occasional issues ever since
>>Ettus moved away from 3.9 such that I still use 3.9 when I am able to do
>>so.  Perhaps this stream mode change would have fixed such occasional
>>issues???)
>>- If you are interested in this issue, I modified the Ettus example
>>"txrx_loopback_to_file" to add a 'for loop' around the receive captures 
>> and
>>changed the stream mode to always be STREAM_MODE_START_CONTINUOUS.  The
>>changes I made are few and straightforward.  If you run compile this
>>modified example and run with the command line shown in the terminal log
>>(see attached), you should be able to duplicate this issue.
>>
>> Rob
>>
>>
>> On Thu, Aug 16, 2018 at 4:05 PM Martin Braun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Rob,
>>>
>>> we pushed a fix for the TX spectrum issue to UHD-3.13 and master.
>>>
>>> -- M
>>>
>>> On 08/15/2018 05:24 PM, Michael West wrote:
>>> > Hi Rob,
>>> >
>>> > We have reproduced the TX corruption issue and we are troubleshooting.
>>> > In the meantime, you can try using the head of UHD-3.13 with the
>>> > force_reinit=1 as Martin suggested.  If that doesn't do the trick, we
>>> > did find a combination that seems to work:  UHD and FPGA image from the
>>> > head of UHD-3.13 and MPM from the head of UHD-3.12.  Let us know if
>>> > either of these helps you work around the issue.  We will let you know
>>> > as soon as we have a fix.
>>> >
>>> > Regards,
>>> > Michael
>>> >
>>> >
>>> > On Wed, Aug 15, 2018 at 3:52 PM, Martin Braun via USRP-users
>>> > mailto:usrp-users@lists.ettus.com>>
>>> wrote:
>>> >
>>> > On 08/09/2018 02:31 PM, Rob Kossler via USRP-users wrote:
>>> > > When I first started using MPM 3.13, I was pleased to see the
>>> fast
>>> > > initialization times compared to previous versions.  Now, after
>>> > spending
>>> > > the better part of a couple of days troubleshooting issues, I am
>>> much
>>> > > less thrilled with this version.
>>> > >
>>> > > The two attachments show the resulting spectrum from an external
>>> > Tx->Rx
>>> > > RF loopback experiment.  The only difference between the two
>>> > figures is
>>> > > the change of MPM f

Re: [USRP-users] Problems with MPM 3.13 on N310

[Michael West via USRP-users]

Hi Rob,

Excellent feedback as always.  Thank you.  We will look into the RX burst
behavior using STREAM_MODE_START_CONTINUOUS, but it may take some time.
The flush routine should have a timeout for the recv() call and be looking
for md.end_of_burst to exit, but I'm sure there is more to the issue than
that.  BTW, to avoid the overruns at startup, just set a start time a
little in the future and minimize the amount of code between the
issue_stream_cmd() call and the first recv() call.

Regards,
Michael

On Thu, Aug 23, 2018 at 11:37 AM, Rob Kossler  wrote:

> Martin, Michael,
> Sorry for the long delay in responding.  I hadn't been monitoring the
> user's list this past week and the replies you sent did not come directly
> to my inbox.  In any event, I compiled the latest MPM and it seems to work
> fine.  Thank you.
>
> Now, to the secondary issue I mentioned in the first post of this thread:
> rx streaming timeouts. These timeouts intermittently occur in my
> application when doing repeated rx captures (i.e., error never occurs on
> first capture).  I tracked it down today to my application's use of
> STREAM_MODE_START_CONTINUOUS rather than STREAM_MODE_NUM_SAMPS_AND_DONE for
> the capture.  After changing my code to use the latter, it works well with
> no timeouts.
>
> A couple of remarks:
>
>- I don't know if this is of concern to you or not. Perhaps I should
>be using it the new way anyway.  A long time ago I had made the decision to
>use STREAM_MODE_START_CONTINUOUS because I was getting one or two overflows
>right at the start of the capture (B210) and I didn't want the capture to
>abort as it did if I used STREAM_MODE_NUM_SAMPS_AND_DONE.
>- With other products (B210 & X310), I have been using my application
>and STREAM_MODE_START_CONTINUOUS for several years, successfully.  (That
>said, I do want to mention that I have had occasional issues ever since
>Ettus moved away from 3.9 such that I still use 3.9 when I am able to do
>so.  Perhaps this stream mode change would have fixed such occasional
>issues???)
>- If you are interested in this issue, I modified the Ettus example
>"txrx_loopback_to_file" to add a 'for loop' around the receive captures and
>changed the stream mode to always be STREAM_MODE_START_CONTINUOUS.  The
>changes I made are few and straightforward.  If you run compile this
>modified example and run with the command line shown in the terminal log
>(see attached), you should be able to duplicate this issue.
>
> Rob
>
>
> On Thu, Aug 16, 2018 at 4:05 PM Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Rob,
>>
>> we pushed a fix for the TX spectrum issue to UHD-3.13 and master.
>>
>> -- M
>>
>> On 08/15/2018 05:24 PM, Michael West wrote:
>> > Hi Rob,
>> >
>> > We have reproduced the TX corruption issue and we are troubleshooting.
>> > In the meantime, you can try using the head of UHD-3.13 with the
>> > force_reinit=1 as Martin suggested.  If that doesn't do the trick, we
>> > did find a combination that seems to work:  UHD and FPGA image from the
>> > head of UHD-3.13 and MPM from the head of UHD-3.12.  Let us know if
>> > either of these helps you work around the issue.  We will let you know
>> > as soon as we have a fix.
>> >
>> > Regards,
>> > Michael
>> >
>> >
>> > On Wed, Aug 15, 2018 at 3:52 PM, Martin Braun via USRP-users
>> > mailto:usrp-users@lists.ettus.com>> wrote:
>> >
>> > On 08/09/2018 02:31 PM, Rob Kossler via USRP-users wrote:
>> > > When I first started using MPM 3.13, I was pleased to see the fast
>> > > initialization times compared to previous versions.  Now, after
>> > spending
>> > > the better part of a couple of days troubleshooting issues, I am
>> much
>> > > less thrilled with this version.
>> > >
>> > > The two attachments show the resulting spectrum from an external
>> > Tx->Rx
>> > > RF loopback experiment.  The only difference between the two
>> > figures is
>> > > the change of MPM from 3.12 to 3.13. The baseband signal consists
>> > of 100
>> > > equal amplitude tones equally spaced over 80% of the sampling freq
>> > > (31.25e6, in my case).  Note that the 3.12 results are as
>> > expected.  The
>> > > 3.13 results show energy over the full bandwidth and significant
>> > > variations in tone magnitude.  I confirmed with a spectrum
>> > analyzer that
>> > > the trouble was on the Tx side rather than Rx.
>> > >
>> > > I also experienced issues with streaming timeouts occurring on
>> the 2nd
>> > > time I issued a streaming command.  However, with all of the
>> > variations
>> > > I have been going through while troubleshooting this issue, I
>> > cannot say
>> > > for certain that this secondary issue is related to the MPM
>> version.
>> > > Presently, I am not seeing these streaming timeouts and I'm not
>> > sure of
>> > > the exact conditions that c

[USRP-users] RFNoC loopback

[Weihan Chen via USRP-users]

Hi all,

I was trying this loopback trick (
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/). In step 2, I
did radio_ctrl->set_rx_streamer(true, 0) in UHD. (0/Radio_0 is my RX radio,
which radio_ctrl points to.)
In step 3, a steam_cmd is issued to the RX radio. But, what streamer_args
do I use here? Specifically, what should I fill in the following two
parameters for my stream_cmd:
streamer_args["block_id"] = ???
streamer_args["block_port"] = ???

I tried these:
streamer_args["block_id"] = radio_ctrl->get_block_id().to_string();
streamer_args["block_port"] = str(boost::format("%d")%0)
Then UHD gives me runtime error:
On node 0/Radio_0, output port 0 is already connected.

I'm just confused how the wiring is done before the stream_cmd is issued in
step 3. I would appreciate it if anyone could help.

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

Re: [USRP-users] Problems with MPM 3.13 on N310

[Rob Kossler via USRP-users]

Martin, Michael,
Sorry for the long delay in responding.  I hadn't been monitoring the
user's list this past week and the replies you sent did not come directly
to my inbox.  In any event, I compiled the latest MPM and it seems to work
fine.  Thank you.

Now, to the secondary issue I mentioned in the first post of this thread:
rx streaming timeouts. These timeouts intermittently occur in my
application when doing repeated rx captures (i.e., error never occurs on
first capture).  I tracked it down today to my application's use of
STREAM_MODE_START_CONTINUOUS rather than STREAM_MODE_NUM_SAMPS_AND_DONE for
the capture.  After changing my code to use the latter, it works well with
no timeouts.

A couple of remarks:

   - I don't know if this is of concern to you or not. Perhaps I should be
   using it the new way anyway.  A long time ago I had made the decision to
   use STREAM_MODE_START_CONTINUOUS because I was getting one or two overflows
   right at the start of the capture (B210) and I didn't want the capture to
   abort as it did if I used STREAM_MODE_NUM_SAMPS_AND_DONE.
   - With other products (B210 & X310), I have been using my application
   and STREAM_MODE_START_CONTINUOUS for several years, successfully.  (That
   said, I do want to mention that I have had occasional issues ever since
   Ettus moved away from 3.9 such that I still use 3.9 when I am able to do
   so.  Perhaps this stream mode change would have fixed such occasional
   issues???)
   - If you are interested in this issue, I modified the Ettus example
   "txrx_loopback_to_file" to add a 'for loop' around the receive captures and
   changed the stream mode to always be STREAM_MODE_START_CONTINUOUS.  The
   changes I made are few and straightforward.  If you run compile this
   modified example and run with the command line shown in the terminal log
   (see attached), you should be able to duplicate this issue.

Rob


On Thu, Aug 16, 2018 at 4:05 PM Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Rob,
>
> we pushed a fix for the TX spectrum issue to UHD-3.13 and master.
>
> -- M
>
> On 08/15/2018 05:24 PM, Michael West wrote:
> > Hi Rob,
> >
> > We have reproduced the TX corruption issue and we are troubleshooting.
> > In the meantime, you can try using the head of UHD-3.13 with the
> > force_reinit=1 as Martin suggested.  If that doesn't do the trick, we
> > did find a combination that seems to work:  UHD and FPGA image from the
> > head of UHD-3.13 and MPM from the head of UHD-3.12.  Let us know if
> > either of these helps you work around the issue.  We will let you know
> > as soon as we have a fix.
> >
> > Regards,
> > Michael
> >
> >
> > On Wed, Aug 15, 2018 at 3:52 PM, Martin Braun via USRP-users
> > mailto:usrp-users@lists.ettus.com>> wrote:
> >
> > On 08/09/2018 02:31 PM, Rob Kossler via USRP-users wrote:
> > > When I first started using MPM 3.13, I was pleased to see the fast
> > > initialization times compared to previous versions.  Now, after
> > spending
> > > the better part of a couple of days troubleshooting issues, I am
> much
> > > less thrilled with this version.
> > >
> > > The two attachments show the resulting spectrum from an external
> > Tx->Rx
> > > RF loopback experiment.  The only difference between the two
> > figures is
> > > the change of MPM from 3.12 to 3.13. The baseband signal consists
> > of 100
> > > equal amplitude tones equally spaced over 80% of the sampling freq
> > > (31.25e6, in my case).  Note that the 3.12 results are as
> > expected.  The
> > > 3.13 results show energy over the full bandwidth and significant
> > > variations in tone magnitude.  I confirmed with a spectrum
> > analyzer that
> > > the trouble was on the Tx side rather than Rx.
> > >
> > > I also experienced issues with streaming timeouts occurring on the
> 2nd
> > > time I issued a streaming command.  However, with all of the
> > variations
> > > I have been going through while troubleshooting this issue, I
> > cannot say
> > > for certain that this secondary issue is related to the MPM
> version.
> > > Presently, I am not seeing these streaming timeouts and I'm not
> > sure of
> > > the exact conditions that caused them.
> >
> > Rob,
> >
> > as Michael West already mentioned, we're checking out these issues
> and
> > trying to reproduce. In the meantime, you could try running with
> > force_reinit=1 as a device arg to force clean-slate initialization
> (the
> > way we improved the init time was by skipping certain steps). It'll
> make
> > your init times slow again, of course.
> >
> > -- M
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com 
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > 

[USRP-users] FW: x310 2 twinrx sync channels issue

[Ilay Nissim via USRP-users]

Hi
We have a Setup with single x310 and 2 twinrx
We use Ubuntu 16.04
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.1-0-ga1b5c4ae
We have an Rx application
We sync all channels(ch0-3) to ch0 lo.
We use internal clock 1pps
We are trying to sample 4 channels,
each time for  a defined period of time,
Each time on a different frequency.
We have issues syncing the channels and get strange results calculating phase 
difference

Case 1:
We zero the time on each sample (not what we would ilke to do)
We than get the same phase difference  for a fixed frequency entered using a 
signal genrator


gDevice->usrp()->set_time_unknown_pps(uhd::time_spec_t(0.0));

uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);

stream_cmd.num_samps   = streamLength;

stream_cmd.stream_now  = false;

stream_cmd.time_spec   =  uhd::time_spec_t(0.2);

rx_stream->issue_stream_cmd(stream_cmd);
case 2:

uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);

stream_cmd.num_samps   = streamLength;

stream_cmd.stream_now  = false;

stream_cmd.time_spec   =  gDevice->usrp()->get_time_now() + 
uhd::time_spec_t(0.2);

rx_stream->issue_stream_cmd(stream_cmd);

on case 2 we get different phase phase difference  on each recording,
the phase difference is changing each time in +-(90/180/270)

can you explain ?
why does gDevice->usrp()->set_time_unknown_pps(uhd::time_spec_t(0.0))
need to get a fixed offset?

Why if we don't do it we get +-(90/180/270) degrees ?
This happens also if we wait for the next pps.


What we would like to d0
As soon as we get a command - try and sample a define times for all channels
This is done in a loop
Can this be done differently?  We tried continuous start stop with no success 
and also

Thanks
Ilay
Software Team Leader


This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.

This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC fifo filling up

[Sylvain Munaut via USRP-users]

Hi,

> Brian, I really only want to send data when appropriate. I don't have the 
> code in front if me at the moment, but I can have tvalid high while I wait 
> for tready, right.

Actually tvalid high with tready low is completey expected. Because
you CANNOT have tvalid depend on the status of tready. (i.e. waiting
for tready to assert tvalid is a spec violation and _will_ cause dead
locks).

> So I don't see why it would be an issue if I change tdata while tvalid is 
> high and tready is low.

But changing tdata which tvalid is high and tready low means that this
data will be "lost" which ... although it won't cause a dead lock is a
bit weird to just drop data randomly depending on the handshake
process ...

> But I've spent the last two days trying to debuf this before I found out it 
> was the axi fifo filling up. It is weird to me that it is slowly falling 
> behind. It makes me feel like tlast maybe has something to do with it.

You do assert tlast periodically right ?
I mean you need to send packets, not a stream.

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] X310 RFNOC image 8 bytes too large

[Sylvain Munaut via USRP-users]

Hi,

> Just for curiosity:
> The .bit-file is exactly the same as the .bin-file, except that the
> .bit-file has an additional header, right? In my case (Vivado 2017.04),
> the header of the .bit-file is 124 Bytes while the uhd_image_loader
> assumes a header size of 116 Bytes. Depends this header size on the
> Vivado version or is there another effect leading to the different file
> sizes?

Sorry, I have no idea ... never looked into it.

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] X310 RFNOC image 8 bytes too large

[Andreas Leuenberger via USRP-users]

Hi Sylvain,

Thank you for your help! It solved my problem.

Just for curiosity:
The .bit-file is exactly the same as the .bin-file, except that the 
.bit-file has an additional header, right? In my case (Vivado 2017.04), 
the header of the .bit-file is 124 Bytes while the uhd_image_loader 
assumes a header size of 116 Bytes. Depends this header size on the 
Vivado version or is there another effect leading to the different file 
sizes?


Cheers,
andreas


On 22.08.2018 17:23, Sylvain Munaut wrote:

~/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HG.bit

You need to use the .bin and not the .bit file.

Cheers,

 Sylvain



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