Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

2018-04-20 Thread The Tilla via USRP-users
Well, that is super awesome news 

 

Glad you guys made these improvements.

 

How would I know this, I don’t think I have seen this information anywhere?

 

From: Michael West  
Sent: Thursday, April 19, 2018 9:21 PM
To: Stanley, John P. 
Cc: ROBIN TORTORA ; Stanley, John P. via USRP-users 

Subject: Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 
daughter cards

 

Hi John/Robin:

The calibration utilities rely on leakage across the RF switch.  The newer UBX 
boards (rev C and later) have RF switches with much higher isolation.  The 
benefit is a lot less leakage from TX onto RX.  The drawback is that the 
calibration utilities will only work if you connect the TX/RX to the RX2 port 
with a 30 dB attenuator in line.

Regards,

Michael

 

On Thu, Apr 19, 2018 at 11:12 AM, Stanley, John P. via USRP-users 
 > wrote:

While uncalibrated LO leakage has never been great in the UBX for us, the dc 
offset calibration procedure has given us adequate enough improvement.  We’re 
generally using offset tuning, but we still need that extra 15-20 dB 
suppression we get from the calibration procedure.

The issue we’re seeing with these newer Rev C boards, though, is that the 
calibration doesn’t just fail to improve LO suppression; it actively makes it 
worse. Offset tuning is pretty fruitless when the LO spur alone is >0 dBm at 
the mid-point of available RF gain. 

 

 

From: ROBIN TORTORA  >
Reply-To: ROBIN TORTORA  >
Date: Thursday, April 19, 2018 at 1:44 PM
To: "Stanley, John P. via USRP-users"  >, "Stanley, John P." 
 >
Subject: Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 
daughter cards

 


___
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] Buffer underrun issue with simultaneous transmit and receive on the X310

2017-08-14 Thread The Tilla via USRP-users
I think some of the issue here as well is the tx_metadata.

 

For continuous streaming, the first packet ONLY should have startofburst = true…

 

Further packets after the first one should have startofburst = false, cuz they 
really are not start of burst, they are continuations of the initial burst.

 

Furthermore, for continuous streaming as soon as possible, you should not 
provide a timespec.

 

If you continually provide a timespec to each packet, it will continually try 
to send them at time = 0.1, which is not what you want…

 

If you want to start your tx at a specific time, then similar to startofburst, 
you should only provide a timespec with the first packet, all subsequent 
packets should not include a timespec.

 

Does that make sense?

 

It can be a bit confusing at first, but after writing a few apps, you will be 
an expert 

 

 

From: Jason W Zheng [mailto:jason.w.zh...@aero.org] 
Sent: Monday, August 14, 2017 4:41 PM
To: ROBIN TORTORA ; mle...@ripnet.com
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310

 

Hi Robin, Marcus

 

It makes no sense to me, then why changing transmit to be on its own channel 
(daughtercard) would cause the program to work. 

 

// set up TX streams and threads

std::thread tx_threads[NUM_CHANNELS];

uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];

uhd::tx_metadata_t md;

md.start_of_burst = true;

md.end_of_burst = false;

md.has_time_spec = true;

md.time_spec = uhd::time_spec_t(0.1); 

 

for (int i = 0; i < NUM_CHANNELS; i++){

stream_args.channels = std::vector(1,i); //changing this from i 
to 1 causes it to work for unknown reasons

tx_streams[i] = usrp->get_tx_stream(stream_args);

//start the thread

std::cout << "Starting tx thread " << i << std::endl;

tx_threads[i] = std::thread(txTask,tx_buffs[i],tx_streams[i],md);

}

 

The relevant line is commented in the above code snippet. When I change the 
channels arguments for the tx stream_args to be on it's own channel 
(daughterboard) separate from the receive, the underflows go away. 

 

 

@Marcus, in the code I posted, there is no coordination between the transmit 
and the receive threads. This is for example purposes. The transmit and receive 
buffers are independent. The transmit thread buffer is prefilled with 0's and 
is constantly transmitting 0's. 

 

  _  

From: ROBIN TORTORA  >
Sent: Monday, August 14, 2017 1:06:20 PM
To: Jason W Zheng via USRP-users; Jason W Zheng
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310 

 

Willing to bet significant money your tx thread is being put on the physical 
processor that does not have your NIC card attached to it...

 

Then, all data must go over QPI between processors.

 

NUMA is not good for this.

 

You can experiment with affinity to make sure things are all on the same 
physical processor as your NIC...

 

We no longer buy multi-processor boxes for issues like this, NUMA is bad...

 

On August 14, 2017 at 2:32 PM Jason W Zheng via USRP-users 
 > wrote:

 

I'm running on a server with 2 Intel Xeon E5-2650 v4, CPU is listed here:

https://ark.intel.com/products/91767/Intel-Xeon-Processor-E5-2650-v4-30M-Cache-2_20-GHz

 

The network card I'm using is the recommended Intel X520-DA2

 

I also have over 500 gigs of ram, so that is not an issue

 

I don't think my cpu or network card are the issue as when I change my code to 
receive and transmit on separate channels, it works without any underflows. 

 

 

  _  

From: USRP-users  > on behalf of Jason W Zheng via 
USRP-users  >
Sent: Monday, August 14, 2017 11:27:24 AM
To: ROBIN TORTORA
Cc: usrp-users@lists.ettus.com  
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310 

 

How should I set the tx metadata? My application will essentially stream 
continuously. 

 

Thanks,

Jason


  _  


From: ROBIN TORTORA  >
Sent: Monday, August 14, 2017 11:17:07 AM
To: Jason W Zheng via USRP-users; Jason W Zheng
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310 

 

I dont see you setting the tx metadata object members to any values, so you are 
essentially going to tx with default metadata IF there is a constructor that 
initializes all the members to a consistent value...

On August 14, 2017 at 1:56 PM Jason W Zheng via USRP-users 
 > wrote:

 

Since I haven't gotten a