Re: [USRP-users] how to write test for block with two output ports

[ishai alouche via USRP-users]

Thank you Dario.

I look on the example, and I have another question.

like I mentioned my block is source block. In order to create the block I
looked on the Siggen block and i saw that in the axi_wrapper we don't use
the tlast signal by define the resize_output and by define packets Now, in
the the add sub block the block don't include at all the axi_wrapper.
So i can create the streaming without the tlast signal without the
axi_wrapper?

BR ishai

On Sun, Jul 22, 2018 at 11:43 PM, Dario Pennisi  wrote:

> Hi ishai,
> Although a block with different number of inputs and outputs is feasible
> in rfnoc, uhd won't work well with it so I would suggest you define it with
> the same number of inputs and outputs and then just connect the unused into
> to a null source/sink
>
> For a complete example on how to implement it look at the add sub block
> which has two inputs and two outputs... Just copy that and replace the
> internal algorithm and you're done.
>
> Just one caveat... Since you are sharing a single axi interface of the
> internal matrix you are limited to around 300 msps total so if you plan to
> output two 200 msps streams you will see overruns and nothing will work.
>
> If you need to output two 200 msps streams the only way is manually
> instantiating your block and connect it to two axi ports. You can check
> x300_core which contains the instances of the radios... You can add you
> block along with them...
> Best regards,
>
> Dario Pennisi
>
>
> Da: ishai alouche via USRP-users
> Inviato: domenica 22 luglio, 20:58
> Oggetto: [USRP-users] how to write test for block with two output ports
> A: usrp-users@lists.ettus.com
>
>
> Hi all,
>
> I use the X310 usrp and i create new block with rdnocmodtools.
>
> My block have one input and two outputs and I have two questions:
>
> 1. I try to understand how I define two output ports. I found two way to
> do it, the first is by duplicate the axi_wrapper block, and the second is
> without axi_wrapper at all and using chdr_framer instead (like in the
> split_stream block). My question is how is the correct way to write it? and
> second when we use chdr_framer and when I duplicate the axi_wrapper in
> general.
>
> 2. The second question is about the test bench. I wrote my block with two
> axi_wrapper and i try to check it.In the test bench I try to read the two
> ports with  tb_streamer.recv() function, but I didn't success and the
> function didn't read the results. I also want to know how i can use the
> tb_streamer.pull_word() command with two poets. I mean with
> tb_streamer.recv() the third argument was the port, i.e. 1 or 2, what is
> the correct syntax if I want to use tb_streamet.pull_word() for two ports.
>
> Thank in advance
> Ishai
>
>
>


-- 
ישי אלוש
054-5823400
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] tlast signal in source block

[ishai alouche via USRP-users]

Hi all,

I use the rfnocmodtools in order to create a source block. In order to
understand how to do it I look on the Siggen block to. In the Siggen block
the axi_wrapper do not use the tlast and define packet instead. I did the
same but when I connect between my source block to another block that i
created, the data don't pass at all.

Can someone help me to understand how to define the axi_wrapper of the
second block in order that it's work without waiting to the tlast?

Thank in advance

-- 
ישי אלוש
054-5823400
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] SFP Transceivers for N310 1/10Gbps Fiber Ethernet

[Rob Kossler via USRP-users]

I have used this SFP+ transceiver for both the X310 and N310, both with XG
images.  I do not remember if I tried the X310 with the HG image, but I
think so. I am using 10gbe with single mode fiber - approximately 100m.

Rob

On Wed, Jul 25, 2018 at 1:51 AM Zhongyuan Zhao  wrote:

> Hi Rob,
>
> Thanks, I just tested FS SFP-10GLR-31 on HG image (I connected to SFP1)
> but unfortunately it does not work. Maybe I should do some more test.
> That module actually work for my Dell switch.
> Which FPGA image did you use? Are you connecting fiber to SFP0 or SFP1 or
> both? Is that 10Gb Ethernet connection?
> Thanks.
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
> Suite 117, Schorr Center,
> Lincoln, Nebraska 68588-0115
>
> On Mon, Jul 23, 2018 at 12:45 PM, Rob Kossler  wrote:
>
>> I am successfully using this 10gbe SFP+/LC singlemode 1310nm transceiver
>> from fs.com.
>> FS SFP-10GLR-31
>> I am also using this QSFP+/MTP transceiver (for Intel XL-710 in 4x10gbe
>> mode)
>> FS QSFP-PLR4-40G
>>
>> On Mon, Jul 23, 2018 at 1:10 PM Ashish Chaudhari via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Zhongyuan,
>>>
>>> >> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?
>>>
>>> No it's not. Depending on what N310 FPGA image you build/use, the port
>>> speeds are locked down. The HG image is 1G on SFP0 and 10G on SFP1
>>> whereas the XG image has 10G on both SFP ports. The transceiver might
>>> support both speeds but the USRP won't.
>>>
>>> >> Could you recommend any SFP transceivers that work on your case? both
>>> >> 1Gbps and 10Gbps.
>>>
>>> What speed do you need for your application? What is the speed of the
>>> switch that you are working with? The solutions for 1Gbps and 10Gbps
>>> are vastly different. Generally speaking fiber-optics that support
>>> 10GBASE-SR, -LR and -ER should work with the N310 when the SFP port is
>>> in 10G mode and optics that support 1000BASE-LX, -SX and -CX should
>>> work in 1G mode. For Ethernet, I should mention that certain switch
>>> and NIC vendors explicitly disallow certain non-approved optical
>>> modules, so on the switch side I would double check with the vendor
>>> that the transceiver works with your switch. On the USRP side, we
>>> accept all optics. I haven't used the specific Finisar module
>>> (FTLX1475D3BCV) but in general we have seen good results with Finisar,
>>> Amphenol FCI and Elpeus transceivers. We do most of our testing with
>>> full cable assemblies, although those might be a bit harder to find
>>> for the lengths that you are looking for.
>>>
>>> As a data point here are the ones that are known to work:
>>>
>>> https://www.mouser.com/ProductDetail/Finisar/FCBG110SD1C03?qs=sGAEpiMZZMsi6nco80NB4Pt5EfrefmupuvEijLXVquZ4ABfDcakyUQ%3d%3d
>>>
>>> https://www.serversupply.com/NETWORKING/TRANSCEIVER/10%20GIGABIT/INTEL/FTLX8571D3BCVIT1.htm
>>>
>>> Thanks,
>>> Ashish
>>>
>>>
>>> On Sat, Jul 21, 2018 at 2:17 PM, Zhongyuan Zhao via USRP-users
>>>  wrote:
>>> > Has anyone tried 10G/1G Dual Rate (10GBASE-LR/LW and 1000BASE-LX) 10km
>>> > 1310nm Single Mode Datacom SFP+ Optical Transceiver?
>>> > https://www.finisar.com/optical-transceivers/ftlx1475d3bcv
>>> >
>>> > Thanks.
>>> >
>>> >
>>> >
>>> > Zhongyuan Zhao
>>> >
>>> > PhD Candidate,
>>> > Department of Computer Science & Engineering,
>>> > University of Nebraska-Lincoln
>>> > Suite 117, Schorr Center,
>>> > Lincoln, Nebraska 68588-0115
>>> >
>>> > On Fri, Jul 20, 2018 at 2:06 PM, Zhongyuan Zhao 
>>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I am working on a project where several N310s are connected to a
>>> >> fiber-Ethernet switch. The fibers are of single mode with length from
>>> 1km to
>>> >> 10km. My problem is selecting the right SFP transceivers.
>>> >>
>>> >> Currently, I used the official SFP to RJ45 converter (come from Ettus
>>> with
>>> >> N310) followed by another pair of RJ45 to SFP converter.
>>> >>
>>> >>
>>> https://www.amazon.com/gp/product/B06XC1VDMD/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
>>> >> This is a work around solution. I tried to connect N310 and Dell N3048
>>> >> switch (2 SFP ports)
>>> >> directly through a pair of 10Gtek SFP transceivers (1Gbps) that come
>>> with
>>> >> the RJ45 to SFP converter but it does not work.
>>> >>
>>> >> Could you recommend any SFP transceivers that work on your case? both
>>> >> 1Gbps and 10Gbps.
>>> >> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?
>>> >>
>>> >> Thank you very much!
>>> >>
>>> >> Regards,
>>> >> Zhongyuan Zhao
>>> >>
>>> >> PhD Candidate,
>>> >> Department of Computer Science & Engineering,
>>> >> University of Nebraska-Lincoln
>>> >> Suite 117, Schorr Center,
>>> >> Lincoln, Nebraska 68588-0115
>>> >
>>> >
>>> >
>>> > ___
>>> > USRP-users mailing list
>>> > USRP-users@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >
>>>
>>> __

Re: [USRP-users] RFNoC flowgraph runs right the second time

[Jason Matusiak via USRP-users]

 Thanks Martin. I tried that, but it actually seems to be working when I look 
at the results. I saw you post earlier to someone about changing UHD's logging 
level. Is this something that can be done via a config file? I looked around, 
but all I could find was some references to c++ usage.


> Jason,
 > 
 > this is a tough one. I have no ideas, other than 'throw in a couple of
 > ILAs and see where it's stuck'.
 
 > -- M
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 01:56 AM, RizThon wrote:


You can try using the "num_recv_frames" option in the device
argument--I'd suggest trying 128 and 256.


I get tons of errors right after seeing [INFO] [B200] Operating over 
USB 3. Would this explain why I can't seem to stream fast?


Here's what I get for 128
Creating the usrp device with: num_recv_frames=128...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; 
UHD_3.12.0.0-release

[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1

[...]
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1

[INFO] [B200] Initialize CODEC control...
[...]

With 256 the program crashes and I only see
Creating the usrp device with: num_recv_frames=256...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; 
UHD_3.12.0.0-release

[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1

[ERROR] [USB] libusb_sessi

Can this be a USB driver problem? I'm using the one from 
http://files.ettus.com/binaries/misc/ dated 29-Mar-2016 19:52.


Can I run any test to make sure everything is fine (B210, drivers, 
software)?


I'll also note that, near as I can tell, LimeSDR drivers dont'
reliably report overruns, so you may be getting them without
knowing about it.


I always check the timestamps returned, so I'm pretty sure I only get 
very few overruns with the Lime.

Presuming you followed the instructions here for UHD installation:

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

Everything should be fine.

I can't remember if we covered this or not.  Are you externally-powering 
the B210?   Some USB ports don't quite provide enough power.



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

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

On Wed, Jul 25, 2018 at 10:57 PM Marcus D. Leech  wrote:

> Presuming you followed the instructions here for UHD installation:
>
> https://files.ettus.com/manual/page_install.html
>
> Everything should be fine.
>
Yes I installed
http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe
as well as the driver
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
In the device manager, I see it under *USRPs / Ettus Research LLC B200/B210*



> I can't remember if we covered this or not.  Are you externally-powering
> the B210?   Some USB ports don't quite provide enough power.
>
I only tried it bus-powered.

Unfortunately it seems my power supply doesn't work well. When I plug it,
the power led turns on then off. If I then connect the USB, it's still off.

What's the min/max voltage I can use? Maybe I can use a different power
supply.

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

[USRP-users] RFNoC: null source

[Carlos Alberto Ruiz Naranjo via USRP-users]

Hello,

how can I connect in RFNoC a port to a null source in GNURadio?

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

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 12:18 PM, RizThon wrote:



On Wed, Jul 25, 2018 at 10:57 PM Marcus D. Leech > wrote:


Presuming you followed the instructions here for UHD installation:

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

Everything should be fine.

Yes I installed 
http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe 
as well as the driver 
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
In the device manager, I see it under /USRPs / Ettus Research LLC 
B200/B210/


I can't remember if we covered this or not.  Are you
externally-powering the B210?   Some USB ports don't quite provide
enough power.

I only tried it bus-powered.

Unfortunately it seems my power supply doesn't work well. When I plug 
it, the power led turns on then off. If I then connect the USB, it's 
still off.


What's the min/max voltage I can use? Maybe I can use a different 
power supply.


Thanks.

Use a 5-6V supply capable of 2 or 3 amps.


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

Re: [USRP-users] B210 sampling rate

[Anon Lister via USRP-users]

Used to have to compile the driver for the lime in debug mode to get
underrun reporting. Though I believe they may have changed some of that
recently.

On Tue, Jul 24, 2018, 23:57 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/24/2018 11:42 PM, RizThon via USRP-users wrote:
>
> I have used the b2x0 radios for some applications myself, we have had no
>> luck sampling much higher than 30MS/s. I think real-world USB3 speeds max
>> out around 100MB/s.
>>
>> Will
>
>
> Thanks Will, that matches my experience. At 28MS/s it tells me I need to
> stream at 112MB/s.
>
> You cannot stream faster than about 30Msps from the B210 when in
>> dual-channel mode.  This is a limitation of the data bus architecture on  the
>> AD9371 chip, and not strictly a limitation of the B2xx FPGA.
>
>
> Sorry for the misunderstanding. On the B210, I'm in *single channel*, RX
> only, and I start having overruns at 28MS/s.
>
> You can try using the "num_recv_frames" option in the device argument--I'd
> suggest trying 128 and 256.
>
> I'll also note that, near as I can tell, LimeSDR drivers dont' reliably
> report overruns, so you may be getting them without knowing about it.
>
>
>
> I was just giving my experience with a Lime where I can stream in dual
> channel, RX only, at 56MS/s. In that case though the Lime sends its data
> back as SC12, meaning it can pack a bit more samples.
>
> FYI, we fixed a couple of sc12/8 related issues on our latest master
>> branch. As Marcus says, if you're doing dual channel on the B210, you
>> can only go to 30.72 Msps though.
>>
>
> Should I play with the OTW format? Does the B210 handle SC12 (
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions 
> *Only
> some devices* for SC12).
>
> I tried rx_samples_to_file.exe from
> http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe
> . If I choose SC8, then I can stream faster. It seems I can go up to 49MS/s
> without error, over 20 seconds.
>
> At 50MS/s and up I get an error
> rx_samples_to_file.exe --null --time 20 --freq 2450e6 --gain 50 --spb
> 1 --rate 50e6 --wirefmt sc8
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: bad vrt header or packet fragment
> Error: Receiver error: ERROR_CODE_BAD_PACKET
>
> I modified the code to allow --wirefmt sc12, I also get an error, even at
> 28MS/s
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: bad vrt header or packet fragment
> but again I'm not sure if the B210 handles that format .
>
> UHD 3.13 is just out, so I tried
> http://files.ettus.com/binaries/uhd/uhd_003.013.000.000-release/Windows-7-x86_64/uhd_3.13.0.0-release_Win32_VS2014.exe
> . I now get 2850 overruns at 28MS/s in SC16, while I'd get up to 5 with the
> previous version. In SC8 I can go up to 40MS/s only, instead of 49. With
> the x64 version I get similar results. So for now I reverted back to 3.12.
>
>
>
>
>
> ___
> 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] B210 sampling rate

[RizThon via USRP-users]

>
> Use a 5-6V supply capable of 2 or 3 amps.
>
> Thanks, it's actually working fine, the led properly turned green after
the firmware and gateware were uploaded.

Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

It seems I still can't stream faster than around 28MS/s. I still get
similar results with .\rx_samples_to_file.exe (using --null to not store to
file).

Should I try to run some tests from
http://files.ettus.com/manual/page_rdtesting.html ?

Concerning the error "[ERROR] [USB]
libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
I get when specifying num_recv_frames, what could I do? Should I try a
different driver? Has anyone already experienced that error?

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

[USRP-users] read/write ddr3 in usrp e310 PL

[carry chen via USRP-users]

Hi,list


I know usrp e310 have a ddr3 in PL part, now I need store some data in ddr3 so

I can do some dsp algo.


So how Can I read/write the ddr3 easy? How many space I can use in ddr3?

Is there some example?


Thanks!


Best, Regards,

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

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 01:08 PM, RizThon wrote:



Use a 5-6V supply capable of 2 or 3 amps.


Thanks, it's actually working fine, the led properly turned green 
after the firmware and gateware were uploaded.


Trying .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:   0
  Num timeouts (Tx):   0
  Num timeouts (Rx):   0

It seems I still can't stream faster than around 28MS/s. I still get 
similar results with .\rx_samples_to_file.exe (using --null to not 
store to file).


Should I try to run some tests from 
http://files.ettus.com/manual/page_rdtesting.html ?


Concerning the error "[ERROR] [USB] 
libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE 
-1" that I get when specifying num_recv_frames, what could I do? 
Should I try a different driver? Has anyone already experienced that 
error?


Thanks.

Try with a smaller number?The Windows LIBUSB behaves differently 
than the Linux version.  On Linux, I can usually ask for 256 without

  any issue.  Try 64.


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

Re: [USRP-users] SFP Transceivers for N310 1/10Gbps Fiber Ethernet

[Zhongyuan Zhao via USRP-users]

I tried that FS SFP+ transceiver again with HG image and it works when the
other side is connected to a correct NIC. It seems to be another
confirmation of FS SFP-10GLR-31 module.
Thank you Rob and Ashish.

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115

On Wed, Jul 25, 2018 at 8:39 AM, Rob Kossler  wrote:

> I have used this SFP+ transceiver for both the X310 and N310, both with XG
> images.  I do not remember if I tried the X310 with the HG image, but I
> think so. I am using 10gbe with single mode fiber - approximately 100m.
>
> Rob
>
> On Wed, Jul 25, 2018 at 1:51 AM Zhongyuan Zhao  wrote:
>
>> Hi Rob,
>>
>> Thanks, I just tested FS SFP-10GLR-31 on HG image (I connected to SFP1)
>> but unfortunately it does not work. Maybe I should do some more test.
>> That module actually work for my Dell switch.
>> Which FPGA image did you use? Are you connecting fiber to SFP0 or SFP1 or
>> both? Is that 10Gb Ethernet connection?
>> Thanks.
>>
>> Zhongyuan Zhao
>>
>> PhD Candidate,
>> Department of Computer Science & Engineering,
>> University of Nebraska-Lincoln
>> Suite 117, Schorr Center,
>> Lincoln, Nebraska 68588-0115
>>
>> On Mon, Jul 23, 2018 at 12:45 PM, Rob Kossler  wrote:
>>
>>> I am successfully using this 10gbe SFP+/LC singlemode 1310nm transceiver
>>> from fs.com.
>>> FS SFP-10GLR-31
>>> I am also using this QSFP+/MTP transceiver (for Intel XL-710 in 4x10gbe
>>> mode)
>>> FS QSFP-PLR4-40G
>>>
>>> On Mon, Jul 23, 2018 at 1:10 PM Ashish Chaudhari via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi Zhongyuan,

 >> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket?

 No it's not. Depending on what N310 FPGA image you build/use, the port
 speeds are locked down. The HG image is 1G on SFP0 and 10G on SFP1
 whereas the XG image has 10G on both SFP ports. The transceiver might
 support both speeds but the USRP won't.

 >> Could you recommend any SFP transceivers that work on your case? both
 >> 1Gbps and 10Gbps.

 What speed do you need for your application? What is the speed of the
 switch that you are working with? The solutions for 1Gbps and 10Gbps
 are vastly different. Generally speaking fiber-optics that support
 10GBASE-SR, -LR and -ER should work with the N310 when the SFP port is
 in 10G mode and optics that support 1000BASE-LX, -SX and -CX should
 work in 1G mode. For Ethernet, I should mention that certain switch
 and NIC vendors explicitly disallow certain non-approved optical
 modules, so on the switch side I would double check with the vendor
 that the transceiver works with your switch. On the USRP side, we
 accept all optics. I haven't used the specific Finisar module
 (FTLX1475D3BCV) but in general we have seen good results with Finisar,
 Amphenol FCI and Elpeus transceivers. We do most of our testing with
 full cable assemblies, although those might be a bit harder to find
 for the lengths that you are looking for.

 As a data point here are the ones that are known to work:
 https://www.mouser.com/ProductDetail/Finisar/FCBG110SD1C03?qs=
 sGAEpiMZZMsi6nco80NB4Pt5EfrefmupuvEijLXVquZ4ABfDcakyUQ%3d%3d
 https://www.serversupply.com/NETWORKING/TRANSCEIVER/10%20GIGABIT/INTEL/
 FTLX8571D3BCVIT1.htm

 Thanks,
 Ashish


 On Sat, Jul 21, 2018 at 2:17 PM, Zhongyuan Zhao via USRP-users
  wrote:
 > Has anyone tried 10G/1G Dual Rate (10GBASE-LR/LW and 1000BASE-LX) 10km
 > 1310nm Single Mode Datacom SFP+ Optical Transceiver?
 > https://www.finisar.com/optical-transceivers/ftlx1475d3bcv
 >
 > Thanks.
 >
 >
 >
 > Zhongyuan Zhao
 >
 > PhD Candidate,
 > Department of Computer Science & Engineering,
 > University of Nebraska-Lincoln
 > Suite 117, Schorr Center,
 > Lincoln, Nebraska 68588-0115
 >
 > On Fri, Jul 20, 2018 at 2:06 PM, Zhongyuan Zhao 
 wrote:
 >>
 >> Hi,
 >>
 >> I am working on a project where several N310s are connected to a
 >> fiber-Ethernet switch. The fibers are of single mode with length
 from 1km to
 >> 10km. My problem is selecting the right SFP transceivers.
 >>
 >> Currently, I used the official SFP to RJ45 converter (come from
 Ettus with
 >> N310) followed by another pair of RJ45 to SFP converter.
 >>
 >> https://www.amazon.com/gp/product/B06XC1VDMD/ref=oh_aui_
 detailpage_o00_s00?ie=UTF8&psc=1
 >> This is a work around solution. I tried to connect N310 and Dell
 N3048
 >> switch (2 SFP ports)
 >> directly through a pair of 10Gtek SFP transceivers (1Gbps) that come
 with
 >> the RJ45 to SFP converter but it does not work.
 >>
 >> Could you recommend any SFP transceivers that work on your case? both
 >> 1Gbps and 10Gbps.
 >> Does 1

[USRP-users] USRP-1 and UHD versions

[Jim Rorick via USRP-users]

Folks -

Quick question - saw that 3.13 was released with lots of changes. I’m a poor 
old retired guy using a legacy USRP-1 (WX, LFTX/LFRX daughter boards) with 
GNURADIO for amateur radio. At what version should I lock-in UHD? When does 
USRP-1 support disappear?  I’m using 3.9 at the moment.

Cheers,
Jim
_
Jim Rorick KA3LXM
ka3...@arrl.net






signature.asc
Description: Message signed with OpenPGP
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP-1 and UHD versions

[Martin Braun via USRP-users]

On 07/25/2018 02:08 PM, Jim Rorick via USRP-users wrote:
> Folks -
> 
> Quick question - saw that 3.13 was released with lots of changes. I’m a poor 
> old retired guy using a legacy USRP-1 (WX, LFTX/LFRX daughter boards) with 
> GNURADIO for amateur radio. At what version should I lock-in UHD? When does 
> USRP-1 support disappear?  I’m using 3.9 at the moment.

Jim,

we have no plans to remove USRP1 code, although it's not impossible that
that will happen some day. On the flip side, we're also not doing
anything with the USRP1 code, so sticking with 3.9 is safe. Nothing that
we've done since then will affect the USRP1, unless you want to use
fancy new logging features, config files, or other non-hardware related
features.

Cheers,
Martin



signature.asc
Description: OpenPGP digital signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Log all signals in simulation

[Erik Malone via USRP-users]

What I'd like to do is run a test bench in batch mode, preferably
overnight, and log all signals in the design.  That way I could test more
scenarios without having to bring up the gui.

Thank you,
Erik

On Tue, Jul 24, 2018 at 2:14 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/23/2018 03:17 PM, Erik Malone via USRP-users wrote:
> > Hi
> >
> > I'm looking for a way to log all signals when simulating an RFNoC design
> > in batch mode.  This would help me to run longer tests and then bring up
> > a waveform whenever an error occurred.  Preferably, I'd like to keep
> > within Ettus' current simulation flow.
>
> Do you mean, within the testbench? Vivado's xsim will make all signals
> available to you, you just need to add them to the list of signals that
> you want to observe.
>
> -- M
>
> ___
> 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] B210 sampling rate

[RizThon via USRP-users]

I already tried smaller values, but not small enough. It seems the highest
I can go is num_recv_frames=44. Anything higher gives me errors.

At 40MS/s, without that parameter, I get 160 to 180 overflows over 20
seconds, while with  num_recv_frames=44 I only get 20 to 30.

This actually allows me to stream at 55MS/s in *sc8* for 20s without any
overflow! With sc16 though, I don't seem much difference and still get more
than 5000 overflows.

Is it possible to use sc12 with the B2x0? The ADC having a 12 bits
resolution, we wouldn't lose any data.

Concerning num_recv_frames, is this a problem with the Windows USB driver,
meaning I wouldn't get better results on another Windows computer? I tried
other drivers, using Zadig. Only the "WinUSB" driver works, but it doesn't
work better than the original Ettus driver.

Do you advise people to use Linux rather than Windows for USB performance
reasons? Should using 256 or 128 fix my streaming problems?

Thanks.



On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech  wrote:

> On 07/25/2018 01:08 PM, RizThon wrote:
>
> Use a 5-6V supply capable of 2 or 3 amps.
>>
>> Thanks, it's actually working fine, the led properly turned green after
> the firmware and gateware were uploaded.
>
> Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
> Benchmark rate summary:
>   Num received samples: 201778444
>   Num dropped samples:  2800
>   Num overruns detected:2800
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
> It seems I still can't stream faster than around 28MS/s. I still get
> similar results with .\rx_samples_to_file.exe (using --null to not store
> to file).
>
> Should I try to run some tests from
> http://files.ettus.com/manual/page_rdtesting.html ?
>
> Concerning the error "[ERROR] [USB]
> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
> I get when specifying num_recv_frames, what could I do? Should I try a
> different driver? Has anyone already experienced that error?
>
> Thanks.
>
> Try with a smaller number?The Windows LIBUSB behaves differently than
> the Linux version.  On Linux, I can usually ask for 256 without
>   any issue.  Try 64.
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 10:18 PM, RizThon wrote:
I already tried smaller values, but not small enough. It seems the 
highest I can go is num_recv_frames=44. Anything higher gives me errors.


At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 
seconds, while with num_recv_frames=44 I only get 20 to 30.


This actually allows me to stream at 55MS/s in *sc8* for 20s without 
any overflow! With sc16 though, I don't seem much difference and still 
get more than 5000 overflows.


Is it possible to use sc12 with the B2x0? The ADC having a 12 bits 
resolution, we wouldn't lose any data.


Concerning num_recv_frames, is this a problem with the Windows USB 
driver, meaning I wouldn't get better results on another Windows 
computer? I tried other drivers, using Zadig. Only the "WinUSB" driver 
works, but it doesn't work better than the original Ettus driver.


Do you advise people to use Linux rather than Windows for USB 
performance reasons? Should using 256 or 128 fix my streaming problems?


Thanks.



On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech > wrote:


On 07/25/2018 01:08 PM, RizThon wrote:



Use a 5-6V supply capable of 2 or 3 amps.


Thanks, it's actually working fine, the led properly turned green
after the firmware and gateware were uploaded.

Trying .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

It seems I still can't stream faster than around 28MS/s. I still
get similar results with .\rx_samples_to_file.exe (using --null
to not store to file).

Should I try to run some tests from
http://files.ettus.com/manual/page_rdtesting.html ?

Concerning the error "[ERROR] [USB]
libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE
-1" that I get when specifying num_recv_frames, what could I do?
Should I try a different driver? Has anyone already experienced
that error?

Thanks.


Try with a smaller number?The Windows LIBUSB behaves
differently than the Linux version.  On Linux, I can usually ask
for 256 without
  any issue.  Try 64.



The SC12 format should work just fine.

The particular values available for num_recv_frames seem to be libusb 
implementation specific, and to a certain extent controller specific as 
well.


Windows is known to have somewhat poorer performance (at least with 
LibUSB type schemes) that Linux, TBH.



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

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

SC12 actually gives me an error as soon as it starts streaming (with or
without specifying num_recv_frames=44). Using the --continue option, I get
tons of such errors:

[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET

Is this specific to my issues with USB, meaning on Linux it works well, or
is the B210 (and B2x0 generally) not handling sc12?  (
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions *Only
some devices* for SC12).

Thanks again.

On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech  wrote:

> On 07/25/2018 10:18 PM, RizThon wrote:
>
> I already tried smaller values, but not small enough. It seems the highest
> I can go is num_recv_frames=44. Anything higher gives me errors.
>
> At 40MS/s, without that parameter, I get 160 to 180 overflows over 20
> seconds, while with  num_recv_frames=44 I only get 20 to 30.
>
> This actually allows me to stream at 55MS/s in *sc8* for 20s without any
> overflow! With sc16 though, I don't seem much difference and still get more
> than 5000 overflows.
>
> Is it possible to use sc12 with the B2x0? The ADC having a 12 bits
> resolution, we wouldn't lose any data.
>
> Concerning num_recv_frames, is this a problem with the Windows USB driver,
> meaning I wouldn't get better results on another Windows computer? I
> tried other drivers, using Zadig. Only the "WinUSB" driver works, but it
> doesn't work better than the original Ettus driver.
>
> Do you advise people to use Linux rather than Windows for USB performance
> reasons? Should using 256 or 128 fix my streaming problems?
>
> Thanks.
>
>
>
> On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech  wrote:
>
>> On 07/25/2018 01:08 PM, RizThon wrote:
>>
>> Use a 5-6V supply capable of 2 or 3 amps.
>>>
>>> Thanks, it's actually working fine, the led properly turned green after
>> the firmware and gateware were uploaded.
>>
>> Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
>> Benchmark rate summary:
>>   Num received samples: 201778444
>>   Num dropped samples:  2800
>>   Num overruns detected:2800
>>   Num transmitted samples:  0
>>   Num sequence errors (Tx): 0
>>   Num sequence errors (Rx): 0
>>   Num underruns detected:   0
>>   Num late commands:0
>>   Num timeouts (Tx):0
>>   Num timeouts (Rx):0
>>
>> It seems I still can't stream faster than around 28MS/s. I still get
>> similar results with .\rx_samples_to_file.exe (using --null to not store
>> to file).
>>
>> Should I try to run some tests from
>> http://files.ettus.com/manual/page_rdtesting.html ?
>>
>> Concerning the error "[ERROR] [USB]
>> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
>> I get when specifying num_recv_frames, what could I do? Should I try a
>> different driver? Has anyone already experienced that error?
>>
>> Thanks.
>>
>> Try with a smaller number?The Windows LIBUSB behaves differently than
>> the Linux version.  On Linux, I can usually ask for 256 without
>>   any issue.  Try 64.
>>
>>
>> The SC12 format should work just fine.
>
> The particular values available for num_recv_frames seem to be libusb
> implementation specific, and to a certain extent controller specific as
> well.
>
> Windows is known to have somewhat poorer performance (at least with LibUSB
> type schemes) that Linux, TBH.
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com