Re: [USRP-users] TX Calibration Interpolation

2019-04-02 Thread Ritesh Saini via USRP-users
Awesome!

https://www.digitalkube.com/elegant-themes-coupon/ 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] Daughtercard Serial Number to Hardware Version

2019-04-02 Thread Dave NotTelling via USRP-users
I forgot to mention that I had talked with Michael West a while back and
been given this idea:

$ /usr/local/lib/uhd/utils/usrp_burn_db_eeprom --unit TX --rev --args
addr=192.168.10.2
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.1.HEAD-0-ga0a71d10
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[WARNING] [UHD] Unable to set the thread priority. Performance may be
negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Reading TX EEPROM on A dboard...
  Current ID: UBX-40 v1 (0x0077)
  Current serial: "XX"
Error: bad lexical cast: source type value could not be interpreted as
target

But it will error out in most cases with the lexical cast error.

On Mon, Apr 1, 2019 at 5:09 PM Dave NotTelling  wrote:

> Is there a way to get the hardware revision of a daughtercard
> (specifically the UBX-40) from the serial number?  Perhaps the serial
> numbers for HW Rev A ended with serial number  kind of thing?  The API
> to retrieve the hardware revision doesn't tend to work with most N210 w/
> UBX-40 setups that I have used, and it would be very helpful to be able to
> get that information without having to take the card out.
>
> I can run uhd_usrp_probe and see "ID: UBX-40 v1" but the hardware rev is B
> according to the sticker on the daughtercard.
>
> Thanks!
>
> -Dave
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] not getting phase coherence between channels

2019-04-02 Thread Marcus D. Leech via USRP-users

On 04/02/2019 01:34 AM, Koyel Das (Vehere) via USRP-users wrote:


Hi,


I am using the given code for data receiving from two channels. I need 
to do LO sharing for phase coherent application, which is done as 
shown in the code and externally as shown in the image attached but I 
am not getting constant phase difference.



We have connected one antenna to input of a power splitter and then 
connected two output ports of the splitter to two ports of USRP. We 
are receiving signals (say noise) from these two ports of USRP. We are 
dividing the whole chunk (5*10^6 samples) of data into 5000 chunks 
each having 1000 continuous samples. Then we are doing FFT of each of 
the chunk of 1000 samples and multiplying the results from the two 
channels. Then averaging 1000 chunks of the multiplication 
(cross-power) together so we are left with 5 averaged chunks each of 
1000 samples of cross-power.  The phase of the cross power is 
omega(td1-td2), where omega is 2*pi*frequency and td1 is the time 
delay of channel1, td2:time delay of channel2. so omega(td1-td2) is 
the phase difference. Since we are doing averaging the noise effect 
should reduce to 0 and we should get phase difference due to time 
delays due to internal circuitry. Now since frequencies are in the 
range of 2.4*10^9 to 2.401*10^9 for 1 MHz bandwidth and td1-td2 is 
also expected to be very small so omega(td1-td2) for this frequency 
range would be almost identical, which is not happening.



In short I am not getting constant phase difference. I have also made 
connections as shown in the attached figure. What is missing in the 
code below:



See:

https://kb.ettus.com/TwinRX_Getting_Started_Guides#LO_Sharing_with_Neighbour_TwinRXs






#include "vdds_device.h"
#include "vdds_util.h"
#include "vdds_device_interface.h"

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


VDDSDevice::VDDSDevice()
{

deviceIPAddress="addr0=192.168.10.2";
gain=70;
sampleRate=1e6;
bandwidth=1e6;
buffer=NULL;
frequncy=2422e6;
numberOfChannel=0;
wrapped=false;
}


void VDDSDevice::init()
{

usrp = uhd::usrp::multi_usrp::make(deviceIPAddress.toStdString());
uhd::usrp::subdev_spec_t subdevClass = std::string("A:0 A:1 B:0 B:1");
usrp->set_rx_subdev_spec(subdevClass);
numberOfChannel=usrp->get_rx_num_channels();
std::cout<<"NUmber Of Channels : "set_rx_lo_freq(frequncy+(sampleRate/2),"LO1",2);
std::coutset_rx_lo_source("internal",usrp->ALL_LOS,2);
usrp->set_rx_lo_export_enabled(true,usrp->ALL_LOS,2);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",3);
usrp->set_rx_lo_source("companion",usrp->ALL_LOS,3);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",0);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,0);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",1);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,1);

// Changes done */
for(size_t count=0;countget_rx_num_channels();count++){
usrp->set_rx_gain(gain,count);
usrp->set_rx_bandwidth(bandwidth,count);
//usrp->set_rx_freq(frequncy,count);
std::cout<<"Antenna : "get_rx_num_channels(); i++){
streamArgs.channels.push_back(i);
}

rxStream = usrp->get_rx_stream(streamArgs);
MAX_SAMPLE_PER_PACKET=rxStream->get_max_num_samps();

if(buffer==NULL){
for(size_t count=0;countchannelBuffers[count]=new 
std::complex[(MAX_SAMPLE_REQUIRED_FOR_DD/MAX_SAMPLE_PER_PACKET)*MAX_SAMPLE_PER_PACKET+MAX_SAMPLE_PER_PACKET];

}
buffer=new 
std::vector*>[(MAX_SAMPLE_REQUIRED_FOR_DD/MAX_SAMPLE_PER_PACKET)+1];
for(size_t 
count=0;count<(MAX_SAMPLE_REQUIRED_FOR_DD/MAX_SAMPLE_PER_PACKET)+1;count++){

for(size_t channel=0;channeluhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);

stream_cmd.num_samps = MAX_SAMPLE_PER_PACKET;
stream_cmd.stream_now = true;
stream_cmd.time_spec = uhd::time_spec_t(0.0);
rxStream->issue_stream_cmd(stream_cmd);

}


void VDDSDevice::setFrequency(double frequncy){
for(size_t count=0;countset_rx_freq(frequncy,count);
}
wrapped=false;
totalNumberOfSamplesRceived=0;
this->frequncy=frequncy;
}

void VDDSDevice::receiveBuffer(double frequncy,size_t 
totalNumberOfSamplesRequired){


uhd::rx_metadata_t md;
totalNumberOfSamplesRceived=0;
double timeout = 0.1;
size_t sampleReceived = 0;
setFrequency(frequncy);

while(startFlag){

   sampleReceived = 
rxStream->recv(buffer[totalNumberOfSamplesRceived/MAX_SAMPLE_PER_PACKET], 

Re: [USRP-users] not getting phase coherence between channels

2019-04-02 Thread Marcus D. Leech via USRP-users

On 04/02/2019 01:34 AM, Koyel Das (Vehere) via USRP-users wrote:


Hi,


I am using the given code for data receiving from two channels. I need 
to do LO sharing for phase coherent application, which is done as 
shown in the code and externally as shown in the image attached but I 
am not getting constant phase difference.



We have connected one antenna to input of a power splitter and then 
connected two output ports of the splitter to two ports of USRP. We 
are receiving signals (say noise) from these two ports of USRP. We are 
dividing the whole chunk (5*10^6 samples) of data into 5000 chunks 
each having 1000 continuous samples. Then we are doing FFT of each of 
the chunk of 1000 samples and multiplying the results from the two 
channels. Then averaging 1000 chunks of the multiplication 
(cross-power) together so we are left with 5 averaged chunks each of 
1000 samples of cross-power.  The phase of the cross power is 
omega(td1-td2), where omega is 2*pi*frequency and td1 is the time 
delay of channel1, td2:time delay of channel2. so omega(td1-td2) is 
the phase difference. Since we are doing averaging the noise effect 
should reduce to 0 and we should get phase difference due to time 
delays due to internal circuitry. Now since frequencies are in the 
range of 2.4*10^9 to 2.401*10^9 for 1 MHz bandwidth and td1-td2 is 
also expected to be very small so omega(td1-td2) for this frequency 
range would be almost identical, which is not happening.



In short I am not getting constant phase difference. I have also made 
connections as shown in the attached figure. What is missing in the 
code below:



What USRP are you using?   I'm *guessing* X310 with TwinRx cards?

If so, you just need the standard "criss cross" arrangement of LO jumper 
cables between the two TwinRX--there's no need to bring the signals

  external to the box.

Also, to align the timekeepers in the two radio blocks in the FPGA, 
you'll have to insert a set_time_unknown_pps() in your setup code. This will

  make sure the streams are aligned.






#include "vdds_device.h"
#include "vdds_util.h"
#include "vdds_device_interface.h"

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


VDDSDevice::VDDSDevice()
{

deviceIPAddress="addr0=192.168.10.2";
gain=70;
sampleRate=1e6;
bandwidth=1e6;
buffer=NULL;
frequncy=2422e6;
numberOfChannel=0;
wrapped=false;
}


void VDDSDevice::init()
{

usrp = uhd::usrp::multi_usrp::make(deviceIPAddress.toStdString());
uhd::usrp::subdev_spec_t subdevClass = std::string("A:0 A:1 B:0 B:1");
usrp->set_rx_subdev_spec(subdevClass);
numberOfChannel=usrp->get_rx_num_channels();
std::cout<<"NUmber Of Channels : "set_rx_lo_freq(frequncy+(sampleRate/2),"LO1",2);
std::coutset_rx_lo_source("internal",usrp->ALL_LOS,2);
usrp->set_rx_lo_export_enabled(true,usrp->ALL_LOS,2);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",3);
usrp->set_rx_lo_source("companion",usrp->ALL_LOS,3);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",0);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,0);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",1);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,1);

// Changes done */
for(size_t count=0;countget_rx_num_channels();count++){
usrp->set_rx_gain(gain,count);
usrp->set_rx_bandwidth(bandwidth,count);
//usrp->set_rx_freq(frequncy,count);
std::cout<<"Antenna : "get_rx_num_channels(); i++){
streamArgs.channels.push_back(i);
}

rxStream = usrp->get_rx_stream(streamArgs);
MAX_SAMPLE_PER_PACKET=rxStream->get_max_num_samps();

if(buffer==NULL){
for(size_t count=0;countchannelBuffers[count]=new 
std::complex[(MAX_SAMPLE_REQUIRED_FOR_DD/MAX_SAMPLE_PER_PACKET)*MAX_SAMPLE_PER_PACKET+MAX_SAMPLE_PER_PACKET];

}
buffer=new 
std::vector*>[(MAX_SAMPLE_REQUIRED_FOR_DD/MAX_SAMPLE_PER_PACKET)+1];
for(size_t 
count=0;count<(MAX_SAMPLE_REQUIRED_FOR_DD/MAX_SAMPLE_PER_PACKET)+1;count++){

for(size_t channel=0;channeluhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);

stream_cmd.num_samps = MAX_SAMPLE_PER_PACKET;
stream_cmd.stream_now = true;
stream_cmd.time_spec = uhd::time_spec_t(0.0);
rxStream->issue_stream_cmd(stream_cmd);

}


void VDDSDevice::setFrequency(double frequncy){
for(size_t count=0;countset_rx_freq(frequncy,count);
}
wrapped=false;
totalNumberOfSamplesRceived=0;
this->frequncy=frequncy;
}

void VDDSDevice::receiveBuffer(double 

Re: [USRP-users] TX Calibration Interpolation

2019-04-02 Thread Dave NotTelling via USRP-users
Marcus,

 Outstanding!  Thank you!

-Dave

On Mon, Apr 1, 2019 at 6:07 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/01/2019 04:34 PM, Dave NotTelling via USRP-users wrote:
> > Assume that I run IQ calibration for frequencies 100 MHz and 102 MHz,
> > but then transmit on 101 MHz.  Does the radio do any interpolation to
> > figure out the most likely calibration information to apply for 101
> > MHz, or do I get no calibration at all?  Also, does the same answer
> > apply to DC offset calibration?
> >
> > This is for an N210 with a UBX-40.
> >
> > Thank you!
> >
> > -Dave
> >
> >
> There is interpolation in  the way UHD manages calibration information.
>
>
>
>
> ___
> 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] x310 brick no ethernet link after fpga burn - urgent

2019-04-02 Thread Ilay Nissim via USRP-users
Tks a lot. Did it, it worked

Regards,
Ilay Nissim
RT Embedded Team Leader
Netline Communications Technologies Ltd
Tel: + (972) 36068171
Fax: + (972) 36068101
http://www.netlinetech.com/
Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL

From: Xavier Arteaga [mailto:xavier.arte...@softwareradiosystems.com]
Sent: Friday, March 15, 2019 2:05 PM
To: Ilay Nissim
Cc: supp...@ettus.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] x310 brick no ethernet link after fpga burn - urgent

Hi,
Same happened to me once before. You need to follow this: 
https://kb.ettus.com/X300/X310_Device_Recovery

Good luck.

Regards,
Xavier

On Fri, 15 Mar 2019 at 12:57, Ilay Nissim via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi
I am using x310 and after upgrading 13.01 to 13.3.1
I have an urgent issue
My FPGA  burn was stoppend in the beginning and now it seems there is a brick
No eth connection on either port
Is there a golden image for the FPGA?
And advice?
Regards

Regards,
Ilay Nissim
RT Embedded Team Leader
Netline Communications Technologies Ltd
Tel: + (972) 36068171
Fax: + (972) 36068101
http://www.netlinetech.com/
Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL


This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com