Re: [USRP-users] Changing the transmitted samples per packet

[Marcus D Leech via USRP-users]

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


Sent from my iPhone

> On Jan 13, 2021, at 11:51 AM, Ephraim Moges via USRP-users 
>  wrote:
> 
> 
> Good morning,
> 
> Is their a simple command like tx_streamer.get_max_num_samps that sets the 
> maximum number samples per packet?
> 
> Thank you,
> 
> Moges
> ___
> 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] UHD 4.0 RFNoC testbench throws fatal error with GUI xsim

[Cédric Hannotier via USRP-users]

Hi Wade,

On 13/01/21 10:00, Wade Fife wrote:
> On Wed, Jan 13, 2021 at 4:58 AM Cédric Hannotier via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Is there a way to reconcile both modes (cli & GUI) without editing
> > my testbench every time I need to switch between these two modes?
>
> You can probably just call $finish() instead of test.end_tb() to stop the
> simulation in both CLI and GUI modes. If you want the summary at the end,
> take a look at what end_tb() does in PkgTestExec.sv.

Indeed!
After reading PkgTestExec.sv, I found something that reconcile both:

test.start_tb()
...
test.end_tb(0) // will not call $finish()
$finish()

Thanks!
-- 

Cédric Hannotier

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

[USRP-users] Changing the transmitted samples per packet

[Ephraim Moges via USRP-users]

Good morning,

Is their a simple command like tx_streamer.get_max_num_samps that sets the
maximum number samples per packet?

Thank you,

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

Re: [USRP-users] Packet length control in rx_streamer

[Rob Kossler via USRP-users]

Wade,
It is very possible that the FPGA side is doing exactly what you are saying
and keeping the packet size intact as it goes over the wire.  The only
reason I mentioned SEP in my previous email was that I wasn't sure one way
or another.  But, the UHD side of things could clearly manipulate packet
sizes as well prior to returning a "packet" via the rx_streamer->recv()
function.  So, while you are right that I could install and learn how to
use wireshark, my question was perhaps more related to the use of
rx_streamer such that I wouldn't have to.

In my present SW, I ask the recv() function to return
rx_streamer->get_max_num_samps() and this effectively becomes my recv()
packet length. I had expected that rx_streamer->get_max_num_samps() would
use some graph propagation forwarding policy to determine what the packet
length would be.  In other words, if the Radio has SPP=567 and the
rx_streamer is connected directly to the Radio, I would expect
rx_streamer->get_max_num_samps() to return the value 567.  But, maybe this
assumption is not correct.

Rob

On Wed, Jan 13, 2021 at 11:12 AM Wade Fife  wrote:

> I don't think the streamer changes the packet size. I believe what the
> block sends is what goes out on the wire (plus network headers). I wonder
> if the size is not being set correctly by the block, or maybe the way
> you're checking the length isn't looking at the actual packet size? That's
> why I suggested wireshark as an option.
>
> Wade
>
> On Wed, Jan 13, 2021 at 9:47 AM Rob Kossler  wrote:
>
>> Hi Wade,
>> Right. The block controls the packet size.  But, I am attempting to
>> verify that my block is actually behaving properly with respect to this
>> packet length.  In order to test this, I created a graph "host => myblock
>> => host" and I am looking at the packet sizes I receive on the host.
>> However, I am being stymied by the rx_streamer (and/or SEP) which is
>> preventing me from seeing the packet size output from my block because the
>> streamer is changing it.  How, do I keep the streamer from changing it?
>> Rob
>>
>> On Wed, Jan 13, 2021 at 10:42 AM Wade Fife  wrote:
>>
>>> The block ultimately determines the size of the packets that are sent
>>> out. Some block controllers (like the radio) use the spp argument to set
>>> the length that the block generates. I don't know what's going on in your
>>> case, but I would suggest looking at how the packet length is being
>>> controlled by the block. You could also use wireshark to confirm the packet
>>> length.
>>>
>>> Wade
>>>
>>> On Tue, Jan 12, 2021 at 3:47 PM Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi,
 I have a custom rfnoc block that I am trying to test with the graph
 "host => myblock => host".  "myblock" is supposed to output packets of a
 given size (256) and I am trying to verify that it is doing so.  However,
 in my simple application to test this graph, I get the following behavior:

- if I don't set "spp" in my rx_streamer args, I get packet length
= 1989.
- if I set "spp" in my rx_streamer args, I get the packet length
that I set.
- But, what I really want is to get packets of the same size as the
block output.

 Is this something that needs to get configured in my block controller?
 Perhaps there is some packet forwarding policy.  It's a bit confusing to
 me.  How can I keep the rx_streamer from changing the packet size that is
 output from my block?

 Note: all sizes above are in "samples", not "bytes".

 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] Packet length control in rx_streamer

[Wade Fife via USRP-users]

I don't think the streamer changes the packet size. I believe what the
block sends is what goes out on the wire (plus network headers). I wonder
if the size is not being set correctly by the block, or maybe the way
you're checking the length isn't looking at the actual packet size? That's
why I suggested wireshark as an option.

Wade

On Wed, Jan 13, 2021 at 9:47 AM Rob Kossler  wrote:

> Hi Wade,
> Right. The block controls the packet size.  But, I am attempting to verify
> that my block is actually behaving properly with respect to this packet
> length.  In order to test this, I created a graph "host => myblock => host"
> and I am looking at the packet sizes I receive on the host. However, I am
> being stymied by the rx_streamer (and/or SEP) which is preventing me from
> seeing the packet size output from my block because the streamer is
> changing it.  How, do I keep the streamer from changing it?
> Rob
>
> On Wed, Jan 13, 2021 at 10:42 AM Wade Fife  wrote:
>
>> The block ultimately determines the size of the packets that are sent
>> out. Some block controllers (like the radio) use the spp argument to set
>> the length that the block generates. I don't know what's going on in your
>> case, but I would suggest looking at how the packet length is being
>> controlled by the block. You could also use wireshark to confirm the packet
>> length.
>>
>> Wade
>>
>> On Tue, Jan 12, 2021 at 3:47 PM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>> I have a custom rfnoc block that I am trying to test with the graph
>>> "host => myblock => host".  "myblock" is supposed to output packets of a
>>> given size (256) and I am trying to verify that it is doing so.  However,
>>> in my simple application to test this graph, I get the following behavior:
>>>
>>>- if I don't set "spp" in my rx_streamer args, I get packet length =
>>>1989.
>>>- if I set "spp" in my rx_streamer args, I get the packet length
>>>that I set.
>>>- But, what I really want is to get packets of the same size as the
>>>block output.
>>>
>>> Is this something that needs to get configured in my block controller?
>>> Perhaps there is some packet forwarding policy.  It's a bit confusing to
>>> me.  How can I keep the rx_streamer from changing the packet size that is
>>> output from my block?
>>>
>>> Note: all sizes above are in "samples", not "bytes".
>>>
>>> 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] UHD 4.0 RFNoC testbench throws fatal error with GUI xsim

[Wade Fife via USRP-users]

Hi Cédric,

You can probably just call $finish() instead of test.end_tb() to stop the
simulation in both CLI and GUI modes. If you want the summary at the end,
take a look at what end_tb() does in PkgTestExec.sv. Also, note that the
test object isn't required. You can remove all the test calls from your
code and just use SystemVerilog assertions instead if you prefer.

Wade

On Wed, Jan 13, 2021 at 4:58 AM Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 12/01/21 13:42, Jonathon Pendlum via USRP-users wrote:
> > Hi Cedric,
>
> Hi Jonathon,
>
> > "Fatal: The connected block has an incompatible backend interface".
> >
> >
> > Try adding a short delay, such as #1 or @posedge( at the start of the
> > testbench to get past this.
>
> Thanks for the workaround, it works!
> However, it has some side effects.
>
> Doing
>
> //test.start_tb
> #1
> ...
> //test.end_tb
>
> or
>
> test.start_tb
> ...
> //test.end_tb
>
> give the same result.
> Indeed, the issue is with test.end_tb finishing the simulation.
> It is fine in cli, but not in GUI, since Vivado is generating waves.
>
> Commenting out test.end_tb solves the issue with GUI mode,
> but then the simulation does not stop in cli mode after
> all tests are completed (it only stops after 10ms).
> Furthermore, I loose the summary at the end (time elapsed,
> #passed/failed tests, etc.)
>
> Is there a way to reconcile both modes (cli & GUI) without editing
> my testbench every time I need to switch between these two modes?
>
> Regards
> --
>
> Cédric Hannotier
>
> ___
> 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] Packet length control in rx_streamer

[Rob Kossler via USRP-users]

Hi Wade,
Right. The block controls the packet size.  But, I am attempting to verify
that my block is actually behaving properly with respect to this packet
length.  In order to test this, I created a graph "host => myblock => host"
and I am looking at the packet sizes I receive on the host. However, I am
being stymied by the rx_streamer (and/or SEP) which is preventing me from
seeing the packet size output from my block because the streamer is
changing it.  How, do I keep the streamer from changing it?
Rob

On Wed, Jan 13, 2021 at 10:42 AM Wade Fife  wrote:

> The block ultimately determines the size of the packets that are sent out.
> Some block controllers (like the radio) use the spp argument to set the
> length that the block generates. I don't know what's going on in your case,
> but I would suggest looking at how the packet length is being controlled by
> the block. You could also use wireshark to confirm the packet length.
>
> Wade
>
> On Tue, Jan 12, 2021 at 3:47 PM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> I have a custom rfnoc block that I am trying to test with the graph "host
>> => myblock => host".  "myblock" is supposed to output packets of a given
>> size (256) and I am trying to verify that it is doing so.  However, in my
>> simple application to test this graph, I get the following behavior:
>>
>>- if I don't set "spp" in my rx_streamer args, I get packet length =
>>1989.
>>- if I set "spp" in my rx_streamer args, I get the packet length that
>>I set.
>>- But, what I really want is to get packets of the same size as the
>>block output.
>>
>> Is this something that needs to get configured in my block controller?
>> Perhaps there is some packet forwarding policy.  It's a bit confusing to
>> me.  How can I keep the rx_streamer from changing the packet size that is
>> output from my block?
>>
>> Note: all sizes above are in "samples", not "bytes".
>>
>> 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] Packet length control in rx_streamer

[Wade Fife via USRP-users]

The block ultimately determines the size of the packets that are sent out.
Some block controllers (like the radio) use the spp argument to set the
length that the block generates. I don't know what's going on in your case,
but I would suggest looking at how the packet length is being controlled by
the block. You could also use wireshark to confirm the packet length.

Wade

On Tue, Jan 12, 2021 at 3:47 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I have a custom rfnoc block that I am trying to test with the graph "host
> => myblock => host".  "myblock" is supposed to output packets of a given
> size (256) and I am trying to verify that it is doing so.  However, in my
> simple application to test this graph, I get the following behavior:
>
>- if I don't set "spp" in my rx_streamer args, I get packet length =
>1989.
>- if I set "spp" in my rx_streamer args, I get the packet length that
>I set.
>- But, what I really want is to get packets of the same size as the
>block output.
>
> Is this something that needs to get configured in my block controller?
> Perhaps there is some packet forwarding policy.  It's a bit confusing to
> me.  How can I keep the rx_streamer from changing the packet size that is
> output from my block?
>
> Note: all sizes above are in "samples", not "bytes".
>
> 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] meta-ettus-v4.0.0.0 segfault

[Philip Balister via USRP-users]

I haven't :( I have been looking at packaged testing for volk and
gnuradio. Once I have this sorted, I'll spend a little time looking into
setting this up for fftw to try and catch this problem faster in the future.

Philip

On 1/9/21 3:29 PM, Ben Magistro via USRP-users wrote:
> Finally getting a chance to circle back to this and I would rather be on
> dunfell but the bsp for the E310 doesn't appear to have been ported yet.  I
> made an attempt but cannot build an image successfully and need to do a
> better set of diffs on the kernel patches.
> 
> Has anyone else started on a dunfell port?
> 
> Ben
> 
> 
> ___
> 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] USRP sample rate and bandwidth

[Marcus D. Leech via USRP-users]

On 01/13/2021 01:08 AM, Koyel Das (Vehere) via USRP-users wrote:

Hi,

The USRP sample rate and bandwidth are two different parameters in 
gnuradio so if I want 20 MHz bandwidth and 100 MSps sample rate then 
will setting bandwidth = 20 MHz and sample rate = 100 MHz serve my 
purpose? Normally sample rate (100 MHz in this case) is the bandwidth 
unless filter is used so does that mean USRP is filtering out 20 MHz 
keeping sample rate at 100 MHz by itself?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com //
Indeed, FOR HARDWARE WITH VARIABLE BANDWIDTH, this parameter sets the 
analog filter bandwidth ahead of the ADC.


Many hardware configurations, however, have fixed analog bandwidth ahead 
of the ADC, and this parameter setting will do

  nothing in those situations.

Hardware based on the AD9361 or AD9371 (USRP B2xx, USRP N3xx, USRP E31x) 
has this control, as do some of the older

  daughtercards--DBSRX2, TVRX2.


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

Re: [USRP-users] UHD 4.0 RFNoC testbench throws fatal error with GUI xsim

[Cédric Hannotier via USRP-users]

On 12/01/21 13:42, Jonathon Pendlum via USRP-users wrote:
> Hi Cedric,

Hi Jonathon,

> "Fatal: The connected block has an incompatible backend interface".
> 
> 
> Try adding a short delay, such as #1 or @posedge( at the start of the
> testbench to get past this.

Thanks for the workaround, it works!
However, it has some side effects.

Doing

//test.start_tb
#1
...
//test.end_tb

or

test.start_tb
...
//test.end_tb

give the same result.
Indeed, the issue is with test.end_tb finishing the simulation.
It is fine in cli, but not in GUI, since Vivado is generating waves.

Commenting out test.end_tb solves the issue with GUI mode,
but then the simulation does not stop in cli mode after
all tests are completed (it only stops after 10ms).
Furthermore, I loose the summary at the end (time elapsed,
#passed/failed tests, etc.)

Is there a way to reconcile both modes (cli & GUI) without editing
my testbench every time I need to switch between these two modes?

Regards
-- 

Cédric Hannotier

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

Re: [USRP-users] USRP sample rate and bandwidth

[Kyeong Su Shin via USRP-users]

Hello Koyel:

Yes, BUT please be warned that most USRP daughterboards have fixed filter 
bandwidth, and they may simply ignore the bandwidth parameter (without 
notifications).

Regards,
Kyeong Su Shin

보낸 사람: Koyel Das (Vehere) via USRP-users  대신 
USRP-users 
보낸 날짜: 2021년 1월 13일 수요일 오후 3:08
받는 사람: USRP-users@lists.ettus.com 
제목: [USRP-users] USRP sample rate and bandwidth

Hi,

The USRP sample rate and bandwidth are two different parameters in gnuradio so 
if I want 20 MHz bandwidth and 100 MSps sample rate then will setting bandwidth 
= 20 MHz and sample rate = 100 MHz serve my purpose? Normally sample rate (100 
MHz in this case) is the bandwidth unless filter is used so does that mean USRP 
is filtering out 20 MHz keeping sample rate at 100 MHz by itself?

Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com