Re: [USRP-users] RFNoC loopback

2018-09-30 Thread Daniel Rauschen via USRP-users 

Hi Nick,
that would be great, thanks.
Daniel

On 28.09.2018 20:33, Nick Foster wrote:
Haven't had time to look at it, but certainly you should be able to 
connect blocks directly in UHD; this should be independent of loopback 
operation. I'll give it a shot in the next few days.


Nick

On Fri, Sep 28, 2018 at 2:39 AM Daniel Rauschen via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Has nobody figured out how to do a RFNoC loopback in UHD/C++ ?


On 26.09.2018 17:12, Daniel Rauschen via USRP-users wrote:

Hi,

sure, find the cpp attached.

Thanks and best regards,
Daniel

On 26.09.2018 16:56, Brian Padalino wrote:

On Wed, Sep 26, 2018 at 10:36 AM Daniel Rauschen via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

Hi all,

I have a question regarding a RFNoC loopback in plain UHD.

I am familiar with [1] and I have a working solution with
gr-ettus and
python. The problem is, I can not figure out how to connect
the blocks
in plain UHD. Does anyone have a working example in UHD for
a RFNoC
loopback?

Connecting in UHD/c++ fails with following error: "Error:
RuntimeError:
On node 0/Radio_0, output port 0 is already connected."...

Any help is highly appreciated :)


You didn't show us how you tried to connect them?  Can you
attach your source file?

Brian




___
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] timed burst problem on B200

2018-09-30 Thread Mitchell J Grabner via USRP-users 
Im trying to send 10,000 samples and it looks like I'm receiving the 
10,000 samples; I will double check tomorrow morning and post some 
graphs of what I'm receiving.


On 9/30/2018 8:46 PM, Marcus D. Leech via USRP-users wrote:

On 09/30/2018 06:34 PM, Mitchell J Grabner via USRP-users wrote:
I've been testing with a long time_spec of 2.0 seconds. The weird 
thing is the device responds with an ack @ the specified 2.0 seconds 
that the burst left at that time... even though it indeed when to the 
RFIC immediately when the send() is called. This is on uhd 3.10 and 
3.14-git.


thanks,
Mitch

How are you confirming that this is what's happening?

There will be LO leakage happening before your actual signal is 
transmitted, so if you're just looking at the spectrum, you might be
  fooled into thinking that it was sending the actual data, just from 
the LO leakage.  Just a thought.  Trying to puzzle this out.





On 9/30/2018 4:49 PM, Marcus Müller wrote:

Shoot, there goes my hypothesis!
But: how much time do you leave between set_time_now and then using md
in a send() call? Maybe the setting happens concurrently...

Best regards,
Marcus

On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:

Hi Marcus,

I use set_time_now(). For my project the devices are assumed
un-synchronized.

thanks

On 9/30/2018 1:11 PM, Marcus Müller wrote:

Hi Mitch,

this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?

Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
users
wrote:

I've used both 3.10.3 and 3.14 (latest git master)

double time_to_transmit = 2.0;

uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(time_to_transmit);

//then while loop through samples

//get burst ack

On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
wrote:

I set the device time stamp to zero and immediately send the
packets
to the device with a timestamp of 2.0 seconds. Also wouldn't
a
past
timestamp give late packet error?

Thanks,
Mitch

Could you show us how you're setting the metadata? (Like, the
code),
and what version of UHD you're using?



On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:

Hello,

I'm trying to get a timed burst working on a B200 and it
looks like
the device is transmitting the samples the instant they
reach
the
device (tested by listening on a second device) instead
of
holding
them until the time specified in md.time_spec.
I set up the first packet's metadata with start_of_burst,
has_time_spec and give it time_spec =
uhd::time_spec_t(time_to_send); The following packets
have no
burst
metadata and the last has end_of_burst. I wait for packet
ack
with
recv_async_msg and it is received after the time
specified
in
time_spec even though the samples left immediately. There
are
no
other errors like underflow, overflow or late packets.
Has
anyone
had this issue or has any idea how to fix it? I must be
missing
something very simple.

Thanks for the help,
Mitch


Keep in mind that the time-to-send is from the perspective
of
the
device, so you have to make sure that your own flow is
synchronized to
the same time as the device.

If a packet arrives with a time specified that is in the
past,
it
gets sent immediately.



___
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



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

Re: [USRP-users] timed burst problem on B200

2018-09-30 Thread Mitchell J Grabner via USRP-users 
I'll be able to give you a copy tomorrow morning. Ok no rush, thank you 
for taking a look for me. Safe travels!


On 9/30/2018 8:15 PM, Marcus Müller wrote:

OK, this is alarming; could you be as nice as making a minimum piece of
code that we can run locally to reproduce? I must admit I'm more or
less in an international flight boarding line, so I might not be able
to look at this for the next 72h.

Best regards,
Marcus
On Sun, 2018-09-30 at 18:34 -0400, Mitchell J Grabner wrote:

I've been testing with a long time_spec of 2.0 seconds. The weird
thing
is the device responds with an ack @ the specified 2.0 seconds that
the
burst left at that time... even though it indeed when to the RFIC
immediately when the send() is called. This is on uhd 3.10 and 3.14-
git.

thanks,
Mitch

On 9/30/2018 4:49 PM, Marcus Müller wrote:

Shoot, there goes my hypothesis!
But: how much time do you leave between set_time_now and then using
md
in a send() call? Maybe the setting happens concurrently...

Best regards,
Marcus

On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:

Hi Marcus,

I use set_time_now(). For my project the devices are assumed
un-synchronized.

thanks

On 9/30/2018 1:11 PM, Marcus Müller wrote:

Hi Mitch,

this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?

Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
users
wrote:

I've used both 3.10.3 and 3.14 (latest git master)

double time_to_transmit = 2.0;

uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(time_to_transmit);

//then while loop through samples

//get burst ack

On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
wrote:

I set the device time stamp to zero and immediately send
the
packets
to the device with a timestamp of 2.0 seconds. Also
wouldn't
a
past
timestamp give late packet error?

Thanks,
Mitch

Could you show us how you're setting the metadata?  (Like,
the
code),
and what version of UHD you're using?



On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users
wrote:

On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users
wrote:

Hello,

I'm trying to get a timed burst working on a B200 and
it
looks like
the device is transmitting the samples the instant
they
reach
the
device (tested by listening on a second device)
instead
of
holding
them until the time specified in md.time_spec.
I set up the first packet's metadata with
start_of_burst,
has_time_spec and give it time_spec =
uhd::time_spec_t(time_to_send); The following packets
have no
burst
metadata and the last has end_of_burst. I wait for
packet
ack
with
recv_async_msg and it is received after the time
specified
in
time_spec even though the samples left immediately.
There
are
no
other errors like underflow, overflow or late
packets.
Has
anyone
had this issue or has any idea how to fix it? I must
be
missing
something very simple.

Thanks for the help,
Mitch


Keep in mind that the time-to-send is from the
perspective
of
the
device, so you have to make sure that your own flow is
synchronized to
 the same time as the device.

If a packet arrives with a time specified that is in
the
past,
it
gets sent immediately.



___
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] timed burst problem on B200

2018-09-30 Thread Marcus D. Leech via USRP-users 

On 09/30/2018 06:34 PM, Mitchell J Grabner via USRP-users wrote:
I've been testing with a long time_spec of 2.0 seconds. The weird 
thing is the device responds with an ack @ the specified 2.0 seconds 
that the burst left at that time... even though it indeed when to the 
RFIC immediately when the send() is called. This is on uhd 3.10 and 
3.14-git.


thanks,
Mitch

How are you confirming that this is what's happening?

There will be LO leakage happening before your actual signal is 
transmitted, so if you're just looking at the spectrum, you might be
  fooled into thinking that it was sending the actual data, just from 
the LO leakage.  Just a thought.  Trying to puzzle this out.





On 9/30/2018 4:49 PM, Marcus Müller wrote:

Shoot, there goes my hypothesis!
But: how much time do you leave between set_time_now and then using md
in a send() call? Maybe the setting happens concurrently...

Best regards,
Marcus

On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:

Hi Marcus,

I use set_time_now(). For my project the devices are assumed
un-synchronized.

thanks

On 9/30/2018 1:11 PM, Marcus Müller wrote:

Hi Mitch,

this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?

Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
users
wrote:

I've used both 3.10.3 and 3.14 (latest git master)

double time_to_transmit = 2.0;

uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(time_to_transmit);

//then while loop through samples

//get burst ack

On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
wrote:

I set the device time stamp to zero and immediately send the
packets
to the device with a timestamp of 2.0 seconds. Also wouldn't
a
past
timestamp give late packet error?

Thanks,
Mitch

Could you show us how you're setting the metadata? (Like, the
code),
and what version of UHD you're using?



On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:

Hello,

I'm trying to get a timed burst working on a B200 and it
looks like
the device is transmitting the samples the instant they
reach
the
device (tested by listening on a second device) instead
of
holding
them until the time specified in md.time_spec.
I set up the first packet's metadata with start_of_burst,
has_time_spec and give it time_spec =
uhd::time_spec_t(time_to_send); The following packets
have no
burst
metadata and the last has end_of_burst. I wait for packet
ack
with
recv_async_msg and it is received after the time
specified
in
time_spec even though the samples left immediately. There
are
no
other errors like underflow, overflow or late packets.
Has
anyone
had this issue or has any idea how to fix it? I must be
missing
something very simple.

Thanks for the help,
Mitch


Keep in mind that the time-to-send is from the perspective
of
the
device, so you have to make sure that your own flow is
synchronized to
the same time as the device.

If a packet arrives with a time specified that is in the
past,
it
gets sent immediately.



___
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] timed burst problem on B200

2018-09-30 Thread Marcus Müller via USRP-users 
OK, this is alarming; could you be as nice as making a minimum piece of
code that we can run locally to reproduce? I must admit I'm more or
less in an international flight boarding line, so I might not be able
to look at this for the next 72h.

Best regards,
Marcus
On Sun, 2018-09-30 at 18:34 -0400, Mitchell J Grabner wrote:
> I've been testing with a long time_spec of 2.0 seconds. The weird
> thing 
> is the device responds with an ack @ the specified 2.0 seconds that
> the 
> burst left at that time... even though it indeed when to the RFIC 
> immediately when the send() is called. This is on uhd 3.10 and 3.14-
> git.
> 
> thanks,
> Mitch
> 
> On 9/30/2018 4:49 PM, Marcus Müller wrote:
> > Shoot, there goes my hypothesis!
> > But: how much time do you leave between set_time_now and then using
> > md
> > in a send() call? Maybe the setting happens concurrently...
> > 
> > Best regards,
> > Marcus
> > 
> > On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:
> > > Hi Marcus,
> > > 
> > > I use set_time_now(). For my project the devices are assumed
> > > un-synchronized.
> > > 
> > > thanks
> > > 
> > > On 9/30/2018 1:11 PM, Marcus Müller wrote:
> > > > Hi Mitch,
> > > > 
> > > > this is but a shot in the blue, but:
> > > > How you're setting the device clock to 0? set_time_now() or
> > > > _next_pps(), or _unknown_pps()?
> > > > 
> > > > Best regards,
> > > > Marcus the other
> > > > On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
> > > > users
> > > > wrote:
> > > > > I've used both 3.10.3 and 3.14 (latest git master)
> > > > > 
> > > > > double time_to_transmit = 2.0;
> > > > > 
> > > > > uhd::tx_metadata_t md;
> > > > > md.start_of_burst = false;
> > > > > md.end_of_burst = false;
> > > > > md.has_time_spec = true;
> > > > > md.time_spec = uhd::time_spec_t(time_to_transmit);
> > > > > 
> > > > > //then while loop through samples
> > > > > 
> > > > > //get burst ack
> > > > > 
> > > > > On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:
> > > > > > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
> > > > > > wrote:
> > > > > > > I set the device time stamp to zero and immediately send
> > > > > > > the
> > > > > > > packets
> > > > > > > to the device with a timestamp of 2.0 seconds. Also
> > > > > > > wouldn't
> > > > > > > a
> > > > > > > past
> > > > > > > timestamp give late packet error?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Mitch
> > > > > > 
> > > > > > Could you show us how you're setting the metadata?  (Like,
> > > > > > the
> > > > > > code),
> > > > > > and what version of UHD you're using?
> > > > > > 
> > > > > > 
> > > > > > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users
> > > > > > > wrote:
> > > > > > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users
> > > > > > > > wrote:
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > I'm trying to get a timed burst working on a B200 and
> > > > > > > > > it
> > > > > > > > > looks like
> > > > > > > > > the device is transmitting the samples the instant
> > > > > > > > > they
> > > > > > > > > reach
> > > > > > > > > the
> > > > > > > > > device (tested by listening on a second device)
> > > > > > > > > instead
> > > > > > > > > of
> > > > > > > > > holding
> > > > > > > > > them until the time specified in md.time_spec.
> > > > > > > > > I set up the first packet's metadata with
> > > > > > > > > start_of_burst,
> > > > > > > > > has_time_spec and give it time_spec =
> > > > > > > > > uhd::time_spec_t(time_to_send); The following packets
> > > > > > > > > have no
> > > > > > > > > burst
> > > > > > > > > metadata and the last has end_of_burst. I wait for
> > > > > > > > > packet
> > > > > > > > > ack
> > > > > > > > > with
> > > > > > > > > recv_async_msg and it is received after the time
> > > > > > > > > specified
> > > > > > > > > in
> > > > > > > > > time_spec even though the samples left immediately.
> > > > > > > > > There
> > > > > > > > > are
> > > > > > > > > no
> > > > > > > > > other errors like underflow, overflow or late
> > > > > > > > > packets.
> > > > > > > > > Has
> > > > > > > > > anyone
> > > > > > > > > had this issue or has any idea how to fix it? I must
> > > > > > > > > be
> > > > > > > > > missing
> > > > > > > > > something very simple.
> > > > > > > > > 
> > > > > > > > > Thanks for the help,
> > > > > > > > > Mitch
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Keep in mind that the time-to-send is from the
> > > > > > > > perspective
> > > > > > > > of
> > > > > > > > the
> > > > > > > > device, so you have to make sure that your own flow is
> > > > > > > > synchronized to
> > > > > > > > the same time as the device.
> > > > > > > > 
> > > > > > > > If a packet arrives with a time specified that is in
> > > > > > > > the
> > > > > > > > past,
> > > > > > > > it
> > > > > > > > gets sent immediately.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ___
> > > > > > > >

Re: [USRP-users] UHD occupying 100% CPU

2018-09-30 Thread Marcus Müller via USRP-users 
Hi Vladica,

did you try the 3.13 release line, too? This might either solve your
issue or at least help us narrow down reasons. I don't think we'll put
out 3.10.X.X and 3.11.X.X releases for ever, since they're not the
current release branch.

Best regards,
Marcus

On Wed, 2018-09-26 at 14:18 +0200, Vladica Sark via USRP-users wrote:
> Hi folks,
> 
> I have a C/C++ code that transmits frames in a given time slots from
> 2x 
> X310. All 4 AFEs are used (2 on each X310). The duty cycle is
> relatively 
> low, 1 frame in each 10 ms. Frame duration is a few hundred 
> microseconds. The processing is not CPU intensive. The problem is
> that 
> all 4 cores on my laptop have 100% utilization during transmission.
> This 
> happens with all UHD 3.10 and 3.11 releases but not with 3.9. With
> 3.9 
> the CPU utilization is less than 10%.
> 
> I had this problem in the past but I was not using a release, but a 
> version under development. I switched to a release, as it was
> suggested 
> here, since the release should have less bugs. Unfortunately, these
> bugs 
> were not corrected in the coming 3.10 and 3.11 releases.
> 
> BR,
> Vladica
> 
> ___
> 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] timed burst problem on B200

2018-09-30 Thread Marcus Müller via USRP-users 
Shoot, there goes my hypothesis!
But: how much time do you leave between set_time_now and then using md
in a send() call? Maybe the setting happens concurrently...

Best regards,
Marcus

On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:
> Hi Marcus,
> 
> I use set_time_now(). For my project the devices are assumed 
> un-synchronized.
> 
> thanks
> 
> On 9/30/2018 1:11 PM, Marcus Müller wrote:
> > Hi Mitch,
> > 
> > this is but a shot in the blue, but:
> > How you're setting the device clock to 0? set_time_now() or
> > _next_pps(), or _unknown_pps()?
> > 
> > Best regards,
> > Marcus the other
> > On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
> > users
> > wrote:
> > > I've used both 3.10.3 and 3.14 (latest git master)
> > > 
> > > double time_to_transmit = 2.0;
> > > 
> > > uhd::tx_metadata_t md;
> > > md.start_of_burst = false;
> > > md.end_of_burst = false;
> > > md.has_time_spec = true;
> > > md.time_spec = uhd::time_spec_t(time_to_transmit);
> > > 
> > > //then while loop through samples
> > > 
> > > //get burst ack
> > > 
> > > On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:
> > > > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
> > > > wrote:
> > > > > I set the device time stamp to zero and immediately send the
> > > > > packets
> > > > > to the device with a timestamp of 2.0 seconds. Also wouldn't
> > > > > a
> > > > > past
> > > > > timestamp give late packet error?
> > > > > 
> > > > > Thanks,
> > > > > Mitch
> > > > 
> > > > Could you show us how you're setting the metadata?  (Like, the
> > > > code),
> > > > and what version of UHD you're using?
> > > > 
> > > > 
> > > > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:
> > > > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > I'm trying to get a timed burst working on a B200 and it
> > > > > > > looks like
> > > > > > > the device is transmitting the samples the instant they
> > > > > > > reach
> > > > > > > the
> > > > > > > device (tested by listening on a second device) instead
> > > > > > > of
> > > > > > > holding
> > > > > > > them until the time specified in md.time_spec.
> > > > > > > I set up the first packet's metadata with start_of_burst,
> > > > > > > has_time_spec and give it time_spec =
> > > > > > > uhd::time_spec_t(time_to_send); The following packets
> > > > > > > have no
> > > > > > > burst
> > > > > > > metadata and the last has end_of_burst. I wait for packet
> > > > > > > ack
> > > > > > > with
> > > > > > > recv_async_msg and it is received after the time
> > > > > > > specified
> > > > > > > in
> > > > > > > time_spec even though the samples left immediately. There
> > > > > > > are
> > > > > > > no
> > > > > > > other errors like underflow, overflow or late packets.
> > > > > > > Has
> > > > > > > anyone
> > > > > > > had this issue or has any idea how to fix it? I must be
> > > > > > > missing
> > > > > > > something very simple.
> > > > > > > 
> > > > > > > Thanks for the help,
> > > > > > > Mitch
> > > > > > > 
> > > > > > 
> > > > > > Keep in mind that the time-to-send is from the perspective
> > > > > > of
> > > > > > the
> > > > > > device, so you have to make sure that your own flow is
> > > > > > synchronized to
> > > > > >the same time as the device.
> > > > > > 
> > > > > > If a packet arrives with a time specified that is in the
> > > > > > past,
> > > > > > it
> > > > > > gets sent immediately.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > 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] Messaging the DDC

2018-09-30 Thread Marcus Müller via USRP-users 
Hi Jason,

I was about to write code, but then realized: gr-ettus' Block impl
already has what you need, the message port "rfnoc", which'll accept
messages in the PMT dict format. You can extract the shape of
information you need to send in from the  tags in
uhd_rfnoc_ddc.xml.

I'm attaching what I hope will fix your problem as a patch (use with
`git apply` from within gr-ettus). We'll most likely upstream a more
general changeset.

Best regards,
Marcus

On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote:
> I have a block that outputs a message with a frequency.  I would love
> to be able to set the frequency adjustment in the RFNoC DDC, but I
> don't see a way to do it it automagically.
> 
> I am guessing that there is no way to do it even though it can be set
> from a variable slider easily. Is there an option I am missing?
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
From 72223fc4bc5ea039d156498686fd1be0c2912af0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marcus=20M=C3=BCller?= 
Date: Sun, 30 Sep 2018 21:19:07 +0200
Subject: [PATCH] Adding a message port to the DDC block XML

Other blocks already have that. The DDC block shouldn't be an exception
to that!

Reference email: [USRP-users] Messaging the DDC
Date:	Wed, 26 Sep 2018 19:45:07 -0400 (09/27/2018 01:45:07 AM)
---
 grc/uhd_rfnoc_ddc.xml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/grc/uhd_rfnoc_ddc.xml b/grc/uhd_rfnoc_ddc.xml
index bb5fdc0..02c2389 100644
--- a/grc/uhd_rfnoc_ddc.xml
+++ b/grc/uhd_rfnoc_ddc.xml
@@ -118,6 +118,12 @@ for chan in xrange($num_chans):
 $num_chans
   
 
+  
+rfnoc
+message
+1
+  
+
   
 out
 complex
-- 
2.17.1

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

Re: [USRP-users] timed burst problem on B200

2018-09-30 Thread Mitchell J Grabner via USRP-users 

Hi Marcus,

I use set_time_now(). For my project the devices are assumed 
un-synchronized.


thanks

On 9/30/2018 1:11 PM, Marcus Müller wrote:

Hi Mitch,

this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?

Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-users
wrote:

I've used both 3.10.3 and 3.14 (latest git master)

double time_to_transmit = 2.0;

uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(time_to_transmit);

//then while loop through samples

//get burst ack

On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users wrote:

I set the device time stamp to zero and immediately send the
packets
to the device with a timestamp of 2.0 seconds. Also wouldn't a
past
timestamp give late packet error?

Thanks,
Mitch

Could you show us how you're setting the metadata?  (Like, the
code),
and what version of UHD you're using?



On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:

On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:

Hello,

I'm trying to get a timed burst working on a B200 and it
looks like
the device is transmitting the samples the instant they reach
the
device (tested by listening on a second device) instead of
holding
them until the time specified in md.time_spec.
I set up the first packet's metadata with start_of_burst,
has_time_spec and give it time_spec =
uhd::time_spec_t(time_to_send); The following packets have no
burst
metadata and the last has end_of_burst. I wait for packet ack
with
recv_async_msg and it is received after the time specified
in
time_spec even though the samples left immediately. There are
no
other errors like underflow, overflow or late packets. Has
anyone
had this issue or has any idea how to fix it? I must be
missing
something very simple.

Thanks for the help,
Mitch


Keep in mind that the time-to-send is from the perspective of
the
device, so you have to make sure that your own flow is
synchronized to
   the same time as the device.

If a packet arrives with a time specified that is in the past,
it
gets sent immediately.



___
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] Messaging the DDC

2018-09-30 Thread Marcus Müller via USRP-users 
Hi Jason,

I'd agree, it'd be desirable if the block accepted messages; after all,
that'd be a good, threadsafe thing to have.
I'll be on a flight, and don't have an RFNoC device on me (I know, a
shame), so I won't be able to test, but adding a message handler to 
rfnoc_generic_impl.cc should involve little to no magic.
Then, you could use Tim O'Shea's message lambda block to transform your
message into exactly the shape of message that the message handler
would understand.

Best regards,
Marcus
On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote:
> I have a block that outputs a message with a frequency.  I would love
> to be able to set the frequency adjustment in the RFNoC DDC, but I
> don't see a way to do it it automagically.
> 
> I am guessing that there is no way to do it even though it can be set
> from a variable slider easily. Is there an option I am missing?
> ___
> 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] RFNoC Custom Filtering in Freq domain

2018-09-30 Thread Marcus Müller via USRP-users 
Hi Rob,

it's been a while, but I've played around with an overlap-save FFT
filter in RFNoC. Sadly, I didn't keep the code myself, but I think I
can get it if I ask the right people; it's been my first stumblings in
RFNoC ... so, not quite sure how much help the code would be. Wouldn't
write the same code today, and there's no magic involved there. But a
couple of bugs were definitely created along the way.
It was a rather textbook implementation based on – I think– a 256-FFT.
But: I just had my multiplication done in the overlapping logic, IIRC.
Must've been complex, too, didn't have linear phase in the system I was
simulating with that.

Best regards,
Marcus

On Thu, 2018-09-27 at 13:44 -0400, Rob Kossler via USRP-users wrote:
> Hi,
> I am just getting started on some custom RFNoC development and trying
> to decide how to approach the problem.  Essentially, I want to
> implement a pair of filters in the frequency domain.  It is similar
> to a pair of FIR filters (on a block-by-block basis) but I want the
> capability for very long filters (equal in length to FFT size).  I
> expect that it is not possible to have so many taps using the
> existing FIR filter so that is why I want to apply in the freq
> domain.  
> 
> I noticed that there is a Window RFNoC block that could be used as
> part of my development, but it appears that this window uses "real"
> rather than "complex" coefficients.  Anyway, here are the steps I
> want to implement:
> FFT incoming stream
> Split FFT output into two streams
> Multiply Stream 1 by complex filter 1 (same length as FFT)
> Multiply Stream 2 by complex filter 2 (same length as FFT)
> IFFT Stream 1
> IFFT Stream 2
> I considered modifying the existing window.v to handle complex
> coefficients.  I also considered using the new "replay" NOC block to
> store the coefficients and stream them out in a circular fashion. 
> This might use the "multiply.v" component, but again it would need to
> be modified to handle complex multiplies.
> 
> Anyway, as I am just getting started, I am looking for any helpful
> advice.  Thanks.
> Rob
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] timed burst problem on B200

2018-09-30 Thread Marcus Müller via USRP-users 
Hi Mitch,

this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?

Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-users
wrote:
> I've used both 3.10.3 and 3.14 (latest git master)
> 
> double time_to_transmit = 2.0;
> 
> uhd::tx_metadata_t md;
> md.start_of_burst = false;
> md.end_of_burst = false;
> md.has_time_spec = true;
> md.time_spec = uhd::time_spec_t(time_to_transmit);
> 
> //then while loop through samples
> 
> //get burst ack
> 
> On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:
> > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users wrote:
> > > I set the device time stamp to zero and immediately send the
> > > packets 
> > > to the device with a timestamp of 2.0 seconds. Also wouldn't a
> > > past 
> > > timestamp give late packet error?
> > > 
> > > Thanks,
> > > Mitch
> > 
> > Could you show us how you're setting the metadata?  (Like, the
> > code), 
> > and what version of UHD you're using?
> > 
> > 
> > > 
> > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:
> > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:
> > > > > Hello,
> > > > > 
> > > > > I'm trying to get a timed burst working on a B200 and it
> > > > > looks like 
> > > > > the device is transmitting the samples the instant they reach
> > > > > the 
> > > > > device (tested by listening on a second device) instead of
> > > > > holding 
> > > > > them until the time specified in md.time_spec.
> > > > > I set up the first packet's metadata with start_of_burst, 
> > > > > has_time_spec and give it time_spec = 
> > > > > uhd::time_spec_t(time_to_send); The following packets have no
> > > > > burst 
> > > > > metadata and the last has end_of_burst. I wait for packet ack
> > > > > with 
> > > > > recv_async_msg and it is received after the time specified
> > > > > in 
> > > > > time_spec even though the samples left immediately. There are
> > > > > no 
> > > > > other errors like underflow, overflow or late packets. Has
> > > > > anyone 
> > > > > had this issue or has any idea how to fix it? I must be
> > > > > missing 
> > > > > something very simple.
> > > > > 
> > > > > Thanks for the help,
> > > > > Mitch
> > > > > 
> > > > 
> > > > Keep in mind that the time-to-send is from the perspective of
> > > > the 
> > > > device, so you have to make sure that your own flow is
> > > > synchronized to
> > > >   the same time as the device.
> > > > 
> > > > If a packet arrives with a time specified that is in the past,
> > > > it 
> > > > gets sent immediately.
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > 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] B205 External Reference issue

2018-09-30 Thread Marcus Müller via USRP-users 
Hm, there's beauty to that, but also there's beauty in not letting the
oscillator drift of indefinitely after you've locked once.
So, the classical fastlock at startup/loss of reference lock, and then
increasingly reduced loop filter bandwidth would probably be even
better.
But that means relatively intrusive changes; you'd make `PFD_PERIOD_*`
adaptive, you adapt the `err` clip boundaries, `lock_margin` and so on;
the values used in b205_ref_pll are pretty certainly results of
physical-reality-based verification¹. That's the point where you'd
spend serious point characterizing the long-time behaviour of something
that probably depends a lot on the characteristics of your clock source
(unless that clock source is way superior to anything on the USRP).
Also, that'd probably be the point where one would have to think about
replacing the well-understood rational ratio PFD control loop with
something more complex (and thus harder to make meet timing at
acceptable resource usage and quantization loss) like an extended
Kalman that can take the nonlinearities of the system into account. 
To be perfectly honest, I don't see either happen very soon.

So, something like extending the state machine in b205_ref_pll to
another state that has a larger threshold until it drops back into an
adjusting state and adding a settings register to manually fiddle with
the state would be the quick and potentially hazardous solution here,
I'd guess.

Best regards,
Marcus

¹ a.k.a. experimentation  
On Sun, 2018-09-30 at 11:34 +0200, Sylvain Munaut via USRP-users wrote:
> Hi,
> 
> I didn't see the screenshots (not posted to the list ?)
> 
> But if absolute precision of the clock doesn't matter, you might be
> better off disabling the servo loop once it's "close enough". That
> will require fpga modifications to expose the refpll control though.
> Actually I think this would be a nice improvement in general for the
> b205 to have the DAC value exposed in UHD and allow to enable/disable
> the servo loop, just a thought :p
> 
> Cheers,
> 
> Sylvain Munaut
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] about boost::condition_variable

2018-09-30 Thread Marcus Müller via USRP-users 
Hi Guangyao,

boost is a very large C++ project which isn't part of UHD, but a
dependency.
In case you're looking for documentation of anything in the boost::
namespace, https://www.boost.org is the place to look.

Usually, you wouldn't interact with the threading within UHD. What is
the specific thing you need to solve?


Best regards,
Marcus

On Sun, 2018-09-30 at 12:01 +, guangyao yu via USRP-users wrote:
> HI，
>I see boost::condition_variable is used for stream tx/rx data in
> UHD code, but I can't find the other thread code in the code.Someone
> can introduce it ? 
> 
> Thanks :)
> 
> guangyao
> 2018.9.30
> 
> 发自 Android 版 Yahoo 邮箱
> ___
> 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] B205 External Reference issue

2018-09-30 Thread Sylvain Munaut via USRP-users 
Hi,

I didn't see the screenshots (not posted to the list ?)

But if absolute precision of the clock doesn't matter, you might be better
off disabling the servo loop once it's "close enough". That will require
fpga modifications to expose the refpll control though.
Actually I think this would be a nice improvement in general for the b205
to have the DAC value exposed in UHD and allow to enable/disable the servo
loop, just a thought :p

Cheers,

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

Re: [USRP-users] B205 External Reference issue

2018-09-30 Thread Arun kumar Verma via USRP-users 
I have tried that but it increases when i reduce amplitude , in fact for DC 
coupled ref i am getting best result.
I have checked the schematic and in that if i remove R37 and R38 then my 
internal clock will disconnected but i am not sure whether board will work with 
only external clock or not. Can you verify this. I want to disconnect internal 
clock and want only external clock as there I am not getting any drift.
Arun

  From: Marcus D. Leech 
 To: Arun kumar Verma ; "usrp-users@lists.ettus.com" 
 
 Sent: Sunday, 30 September 2018 2:19 AM
 Subject: Re: [USRP-users] B205 External Reference issue
   
 On 09/29/2018 02:20 PM, Arun kumar Verma wrote:
  
  Hi 
  
  Please find the screenshots as you have asked. One image is when we are 
setting ref to internal but external not connected that time it is clean and 
other images is when we are connecting external ref . 
  Regards, arun verma
   
   
 Does the magnitude of this small spur diminish if you reduce the amplitude of 
your external reference?
 
 
 
  
From: Marcus D. Leech 
 To: Arun kumar Verma ; "usrp-users@lists.ettus.com" 
 
 Sent: Wednesday, 26 September 2018 11:56 PM
 Subject: Re: [USRP-users] B205 External Reference issue
  
   On 09/26/2018 02:24 PM, Arun kumar Verma wrote:
  
  
 Hi Marcus  
  well I am connecting external ref of 10MHz on Ref Input SMA connector  and 
once I connect this and set my clock source for external source then we are 
getting spurios, these spurs are low but for AM,FM audio demodulation even Hz 
suprs can  create probelem and that is what we are facing. Right now what we 
using a VCXO of 50ppb satbility  and what we noticed that with the internal 
clock there was a shift in frequency of about 5KHz at 3GHz input while with 
external Ref shift was around 300Hz. Is it  possible to switch off supply 
manually for internal oscillator and board still works? 
  Regards, Arun Verma 
 
   
 Could you please post an image of the situation, showing the spur levels? 
 
 
 
  
 From: Marcus D. Leech via USRP-users 
 To: usrp-users@lists.ettus.com 
 Sent: Wednesday, 26 September 2018 9:15 PM
 Subject: Re: [USRP-users] B205 External Reference issue
  
On 09/26/2018 02:42 AM, Arun kumar Verma via USRP-users wrote:
  
 Hi  
  We are using B205i-mini and we found that  when I am sleclecting external Ref 
using  set_clock_source("ëxternal"); I am getting  intermodulation components 
in Hz. I think supply for the internal oscillator  is still on and it is not 
compeletly shutting down. Is  there any options to switch off the suppy  of 
ineternal oscillator through some API.  
  Regards, Arun Verma 
  
 
  There is only one clock on the B205 -- a 40MHz VCXO.   When you switch to 
"external", the FPGA implements a clock-steering
   "servo" that phase-locks that 40MHz clock to the external reference.
 
 You're probably seeing very low-level clock spurs that appear as a result of 
the servo algorithm.
 
 
 
   ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
  
 
  
 
|  | I’m protected online with Avast Free Antivirus. Get it here — it’s free 
forever.  |

  
 

 
  
 
 

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