Re: [USRP-users] Rfnoc latency

[Nick Foster via USRP-users]

In a packet-switched system, because a whole packet must be buffered before
being passed through the crossbar, your delay is going to be governed by
your packet size and your sample rate. If you are decimating down to a
lower sample rate, you will incur larger delays.

To a first approximation, you can say the delay of a block will be (packet
size / sample rate), plus a bit of overhead. If I understand the Sunderlin
paper correctly, that overhead is what he's measuring.

I am able to get loopback operation in an X310 down to about 26us latency
with several blocks in the loop through careful optimization of packet size
and by keeping the full 200Msps sample rate (even though my application
only requires 30kHz of bandwidth). If you can run your custom block at full
bus speed, that's the best way to ensure low latency. If you require narrow
bandwidths, consider a cascade of FIR filters instead of DDC-[block]-DUC.

Nick

On Fri, Sep 28, 2018 at 2:44 AM Sebastian Bräuer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I am currently working on a custom block that implements
> Listen-Before-Talk directly on the X310 and I have question regarding
> the latency that I can expect in between RFnoC blocks. This article [1]
> claims that each block delays the signal by about 2us which would put
> the turn-around time for my block to about 10us (RxRadio -> DDC ->
> custom block -> DUC -> TxRadio) but I am measuring turn-around times of
> roughly 150us, far higher than expected. My custom block does not buffer
> anything besides some flops.
>
> Has anyone an idea what might be the cause of this? I already tried
> reducing the spp of the radio with very limited success.
>
> [1] https://pubs.gnuradio.org/index.php/grcon/article/view/37
>
>
> ___
> 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 loopback

[Nick Foster via USRP-users]

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 <
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 <
> 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 
> listUSRP-users@lists.ettus.comhttp://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] External LO amplitude issue

[Marcus D. Leech via USRP-users]

On 09/28/2018 12:45 PM, Yun Li via USRP-users wrote:

Hi there,

I am testing external LO on N310 (UHD_3.13.0.2-1-g78745bda). The setup 
is I have a X310 sending SINE waves to N310's channel 1,2,3 via a 
splitter. A signal generator sends 2x frequency 3dBm signal to N310's 
LO IN 0/1 and LO IN 2/3 via a splitter. According to the doc, there is 
supposed to be a 180 degree phase shift which I did observe in 
following plot.


image.png

But the question is why all 3 channels are now having very different 
amplitude. If I use internal LO, the amplitude of all 3 channels are 
the same.


Thanks.
Yun


What happens if you increase the LO power by 1dB or so?



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

[USRP-users] External LO amplitude issue

[Yun Li via USRP-users]

Hi there,

I am testing external LO on N310 (UHD_3.13.0.2-1-g78745bda). The setup is I
have a X310 sending SINE waves to N310's channel 1,2,3 via a splitter. A
signal generator sends 2x frequency 3dBm signal to N310's LO IN 0/1 and LO
IN 2/3 via a splitter. According to the doc, there is supposed to be a 180
degree phase shift which I did observe in following plot.

[image: image.png]

But the question is why all 3 channels are now having very different
amplitude. If I use internal LO, the amplitude of all 3 channels are the
same.

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

Re: [USRP-users] [Discuss-gnuradio] Technical Issue

[Marcus D. Leech via USRP-users]

On 09/28/2018 05:35 AM, tadikondasuresh wrote:

Good afternoon sir, I have two USRP N210 Radio Modules.
*Technical Issue*:
Sir, one of USRP N210 radio module TX/RX port is working and RX2 port 
is not responding... and another radio module TX/RX port is not 
responding only TX/RX is responding... Please Suggest any remedies.


*Thanks & Regards,
Suresh T,
Navstar Integrated Systems Pvt ltd,
9866212494*



This discussion really belongs on the usrp-users mailing list, not here.

What do you mean by "not responding".

What daughtercards do you have installed on your N210 radios?

And again, this discussion should be continued on the usrp-users mailing 
list.


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

Re: [USRP-users] Issue using usrp_image_loader with X310 Radio

[Marcus D. Leech via USRP-users]

On 09/28/2018 09:33 AM, Jason Meyer wrote:
Yes, I’m seeing the same behavior with a standard image as with my 
custom image.



Jason
So, I'm wondering if something is dropping ethernet frames during the 
upload to the device, resulting in a corrupt image.





On Sep 27, 2018, at 8:31 PM, Marcus D. Leech > wrote:



On 09/27/2018 07:09 PM, Jason Meyer wrote:
The command produces output as if there is no issue. It shows the 
progress of the image being loaded, and at the end states that the 
process was a success and to power-cycle to see the changes made. 
However when I power-cycle, I am unable to communicate with the USRP 
until I load the FPGA image via JTAG. This has happened with 3 
different USRPs.



Jason
Does the "cannot communicate with the device" happen even after 
loading a standard image?





On Thu, Sep 27, 2018 at 6:40 PM Marcus D. Leech > wrote:


On 09/27/2018 06:34 PM, Jason Meyer wrote:

Hi Marcus,

I am using UHD v3.11.1.0. The command format I've used is:

uhd_image_loader --args="type=x300,addr=192.168.10.2"
--fpga-path="/usr/local/share/uhd/images/.bit"


Does the command produce any output?

How are you confirming that it's reverting to a previous image?

Except for broken hardware, this should "just work". But you've
mentioned the same behavior on multiple X310s.





Jason

On Thu, Sep 27, 2018 at 5:28 PM Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

On 09/27/2018 03:46 PM, Jason Meyer via USRP-users wrote:
> Hello,
>
> I have been working with multiple X310 USRPs and
attempting to load
> custom FPGA firmware onto the motherboard EEPROM using the
> uhd_image_loader command. The command appears to be
successful, but
> the FPGA fails to load the image on reboot. The image
functions just
> fine when I program it through JTAG and Vivado Hardware
Manager, but I
> would like to store it in EEPROM to avoid needing to
re-program every
> time I reboot the radios. The same error has occurred on
multiple
> motherboards, and continues to occur when I use
uhd_image_loader to
> load an image retrieved from uhd_images_downloader.
>
> What options do I have for debugging the EEPROM?
>
> Thank you,
> Jason Meyer
>
>
This should "Just Work(tm)"

How exactly are you using uhd_image_loader, and what
version of UHD are
you using?




___
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] Issue using usrp_image_loader with X310 Radio

[Jason Meyer via USRP-users]

Yes, I’m seeing the same behavior with a standard image as with my custom image.


Jason

> On Sep 27, 2018, at 8:31 PM, Marcus D. Leech  wrote:
> 
>> On 09/27/2018 07:09 PM, Jason Meyer wrote:
>> The command produces output as if there is no issue. It shows the progress 
>> of the image being loaded, and at the end states that the process was a 
>> success and to power-cycle to see the changes made. However when I 
>> power-cycle, I am unable to communicate with the USRP until I load the FPGA 
>> image via JTAG. This has happened with 3 different USRPs.
>> 
>> 
>> Jason
> Does the "cannot communicate with the device" happen even after loading a 
> standard image?
> 
> 
>> 
>>> On Thu, Sep 27, 2018 at 6:40 PM Marcus D. Leech   
>>>  wrote:
 On 09/27/2018 06:34 PM, Jason Meyer wrote:
 Hi Marcus,
 
 I am using UHD v3.11.1.0. The command format I've used is:
 
 uhd_image_loader --args="type=x300,addr=192.168.10.2" 
 --fpga-path="/usr/local/share/uhd/images/.bit"
 
>>> Does the command produce any output?
>>> 
>>> How are you confirming that it's reverting to a previous image?
>>> 
>>> Except for broken hardware, this should "just work".  But you've mentioned 
>>> the same behavior on multiple X310s.
>>> 
>>> 
 
 
 Jason
 
> On Thu, Sep 27, 2018 at 5:28 PM Marcus D. Leech via USRP-users 
>  wrote:
> On 09/27/2018 03:46 PM, Jason Meyer via USRP-users wrote:
> > Hello,
> >
> > I have been working with multiple X310 USRPs and attempting to load 
> > custom FPGA firmware onto the motherboard EEPROM using the 
> > uhd_image_loader command. The command appears to be successful, but 
> > the FPGA fails to load the image on reboot. The image functions just 
> > fine when I program it through JTAG and Vivado Hardware Manager, but I 
> > would like to store it in EEPROM to avoid needing to re-program every 
> > time I reboot the radios. The same error has occurred on multiple 
> > motherboards, and continues to occur when I use uhd_image_loader to 
> > load an image retrieved from uhd_images_downloader.
> >
> > What options do I have for debugging the EEPROM?
> >
> > Thank you,
> > Jason Meyer
> >
> >
> This should "Just Work(tm)"
> 
> How exactly are you using uhd_image_loader, and what version of UHD are 
> you using?
> 
> 
> 
> 
> ___
> 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 OFDM blocks error building FPGA image

[Jon Pendlum via USRP-users]

Hi Sarah,

I have submitted a pull request with some OFDM improvements including a fix
for this issue, hopefully it will be merged soon. I'll send you the patch
set to try out in the meantime.

Jonathon

On Fri, Sep 28, 2018 at 11:05 AM Sarah Tran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
> I am trying to build a custom FPGA image for my X310
> (daughterboards=UBX-160) using the uhd_image_builder gui and trying to use
> the following blocks:
>
> fft
>
> schmidl_cox
>
> eq
>
> ofdm_constellation_demapper
>
>
> as the code is running and building, it always stops on this error:
>
> '
> [00:22:41] Current task: Logic Optimization +++ Current Phase: Finished
> [00:22:41] Starting Connectivity Check Task
> ERROR: [Opt 31-2] SRLC32E
> x300_core/inst_eq/inst_axi_wrapper/header_fifo/fifo_short/gen_srlc32e[64].srlc32e
> is missing a connection on D pin.
> [00:22:51] Current task: Connectivity Check +++ Current Phase: Starting
> [00:22:51] Current task: Connectivity Check +++ Current Phase: Finished
> [00:22:51] Process terminated. Status: Failure
>
> 
> Warnings:   862
> Critical Warnings:  36
> Errors: 1
>
> Makefile.x300.inc:111: recipe for target 'bin' failed
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory '/home/lsop/rfnoc/fpga/usrp3/top/x300'
> Makefile:119: recipe for target 'X310_RFNOC_HG' failed
> make: *** [X310_RFNOC_HG] Error 2'
>
> I can't seem to get it resolved, and I was wondering if there was a trick
> that someone else was able to use to get it to build. Any help or insight
> is appreciated.
>
> Thank you,
> Sarah
>
> ___
> 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] Rfnoc latency

[Sebastian Bräuer via USRP-users]

Hi,

I am currently working on a custom block that implements
Listen-Before-Talk directly on the X310 and I have question regarding
the latency that I can expect in between RFnoC blocks. This article [1]
claims that each block delays the signal by about 2us which would put
the turn-around time for my block to about 10us (RxRadio -> DDC ->
custom block -> DUC -> TxRadio) but I am measuring turn-around times of
roughly 150us, far higher than expected. My custom block does not buffer
anything besides some flops.

Has anyone an idea what might be the cause of this? I already tried
reducing the spp of the radio with very limited success.

[1] https://pubs.gnuradio.org/index.php/grcon/article/view/37


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

Re: [USRP-users] RFNoC loopback

[Daniel Rauschen via USRP-users]

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