[USRP-users] USRP N320 and N321 questions

[Minutolo, Lorenzo (389I) via USRP-users]

Hi,
I have some question about your new products.

1) What is the suggested hardware for communicating with the QSFP+ port? As I 
understand this a normal 40 Gbit PCIe card won’t work.

2) Does the embedded linux system gives any error while handling two channels 
at 200Msps full duplex without any signal processing (i.e. benchmark rate)?

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

[USRP-users] XG firmware and packet routing

[Minutolo, Lorenzo (389I) via USRP-users]

Hi All,

I'm Using the X300 with the XG firmware from UHD 3.14, connected to the host pc 
via primary and secondary addresses.

Since I'm using four different streamer I'd like to be able to tell to each 
streamer which address to use. Is that possible?


Thanks,

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

Re: [USRP-users] [EXTERNAL] Re: Recording the full X3x0 bandwidth

[Minutolo, Lorenzo (389I) via USRP-users]

Hi All,

We're using the USRP x3x0 for cosmology and many other applications: we use 
them to read out our cryogenics detectors.

Do you need the full spectral bandwidth of the device? Things get much easier 
if you decimate the signal before storing it to disk. The system we realized 
uses a GPU to decimate USRPs data streams before saving them to disk.

Check it out (https://arxiv.org/abs/1812.02200) , it should be opensource soon.

[1812.02200] A flexible GPU-accelerated radio-frequency readout for 
superconducting detectors
arxiv.org
We have developed a flexible radio-frequency readout system suitable for a 
variety of superconducting detectors commonly used in millimeter and 
submillimeter astrophysics, including Kinetic Inductance detectors (KIDs), 
Thermal KID bolometers (TKIDs), and Quantum Capacitance Detectors (QCDs). Our 
system avoids custom FPGA-based readouts and instead uses commercially 
available software radio hardware for ADC/DAC and a GPU to handle real time 
signal processing. Because this system is written in common C/CUDA, 
the range of different algorithms that can be quickly implemented make it 
suitable for the readout of many others cryogenic detectors and for the testing 
of different and possibly more effective data acquisition schemes.



Lorenzo


From: USRP-users  on behalf of Joe Martin 
via USRP-users 
Sent: Saturday, March 9, 2019 10:23:28 AM
To: Mark-Jan Bastian
Cc: usrp-users@lists.ettus.com
Subject: [EXTERNAL] Re: [USRP-users] Recording the full X3x0 bandwidth

Thank you Mark-Jan for the additional information.  I’ll study it and compare 
with my system.  Much appreciated.

Best regards,

Joe

> On Mar 9, 2019, at 11:19 AM, Mark-Jan Bastian  wrote:
>
> Hi Joe,
>
> With sudo lspci -vvv you will see the capabilties, including the low-level
> PCIe bus speed and link count negotiation of the devices. The sudo is needed
> to get the low-level LnkCap and LnkCtl bits:
>
> For a 16-lane videocard on a laptop here, likely soldered right on the 
> motherboard:
>
> The PCIe capabilities: 8 GT/sec, max 16 lanes:
>LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit 
> Latency L0s <1us, L1 <4us
>ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
> What the speed ended up to be 8GT/sec, 16 lanes:
>LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
>ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive- BWMgmt- ABWMgmt-
>DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR+, OBFF 
> Via message
>DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, 
> OBFF Disabled
> Below is a variant of the LnkCtl record, providing even more information on 
> even the equalisation of the
> SERDES link that is used by this PCIe device: (equalisation is the analog RF 
> signal processing to overcome
> losses while routing the signal over the motherboard and the connectors):
>LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
> Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
> Compliance De-emphasis: -6dB
>LnkSta2: Current De-emphasis Level: -6dB, 
> EqualizationComplete+, EqualizationPhase1+
> EqualizationPhase2+, EqualizationPhase3+, 
> LinkEqualizationRequest-
>
> Above could be regarded as a 'depth first' approach for those who would like 
> to stay purely software-oriented.
> I like to treat a PC in such scenario as an embedded system,  first get the 
> powersupplies, clocks and other
> hardware right, design the clockdomains and datarates, then gradually move up 
> the software/control/kernel/driver
> stack to verify for anomalies that could trigger such intermittent problems.
>
> Mark-Jan
>
> On Sat, Mar 09, 2019 at 10:40:39AM -0700, Joe Martin wrote:
>> Hi Mark,
>>
>> I am intrigued by your response and have obtained a tree view for my system 
>> as you suggested to Paul.  I???m unfamiliar with the tree view and don???t 
>> understand how to check the number of PCIe lanes that are available to the 
>> disk controller and disks and how to check how many PCIe bridges are in 
>> between on my motherboard configuration.
>>
>> I have a screenshot of the tree view showing my 10G ethernet connection (but 
>> it is 220KB in size so I didn???t attach it here) but I am not familiar with 
>> how to determine what you asked about from the tree and what to do about the 
>> configuration in any case.  Is the configuration fixed and not changeable, 
>> in any case?
>>
>> If so, then perhaps your alternative suggestion regarding booting from a USB 
>> stick into a ramdisk is a viable route?  I???m unfortunately not familiar 
>> with the details of how to do that so perhaps a couple of brief 

[USRP-users] usrp x300 multiple addresses and multiple streamers

[Minutolo, Lorenzo (389I) via USRP-users]

Hi All,

I'm using a USRP x300 configured with two WBX-120 daughterboards and the XG 
firmware version from the UHD 3.13.

The link with the host pc is done with two 10GBe connections.


In my C++ application I have the necessity of receiving and streaming signals 
to both daughterboards at the same time from four different threads. To do so, 
I'm making the multi_usrp object using primary and secondary address and 
getting each tx/rx streamer (each with a single channel) inside a thread. 
Everything is working except that the UHD api is using only one of the two 
10Gbe interfaces for communicating with the USRP, limiting the bandwidth I can 
use.


The only way I found to make the dual 10GBe link to work is initializing a 
streamer object with multiple channels; thing that I would like to avoid.


is there a way to tell the UHD api which address to use for each streamer?


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