Re: [USRP-users] Noise Capture with B200mini

[Marcus D. Leech via USRP-users]

On 05/14/2019 06:13 PM, Marcus Müller via USRP-users wrote:

Hello Andre,

I suspect three things being at work here:

1. Spurs from the mixer / synthesizer: Plot the |FFT|² (i.e. simply
play back the file through a Qt GUI frequency sink) with a high FFT
length. Do you see peaks in there? With the PSD (assuming the signal is
WSS) being both the Magnitude square of the Fourier transform of the
signal AND the value of the Fourier transform of the autocorrelation
function, peaks here indicate a sinusoidal correlation, as you might be
observing.

2. The anti-aliasing filters of course convert a perfectly white signal
to a bandlimited signal: you should see "roundish" rolloff at the edges
of the nyquist zone. That of course (through the inverse FT)
corresponds to a non-dirac autocorrelation function, i.e. correlation.

3. By overdriving the analog receive chain, you might be bringing it to
behave nonlinearly; a simple thought experiment shows that this might
be ruining the whiteness of your noise (i.e. the uncorrelatedness):
uncorrelated noise must have a zero mean.
Squaring zero-mean noise of any variance > 0 must lead to non-zero mean
noise.
Zero-mean noise means a dirac impulse in the PSD at f=0.
That means correlatedness.

Also, nonlinearity will lead to increased spurs and spur
intermodulation (see 1.).

So, make sure you're not overdriving your receive chain – it's a
delicate flower!

Best regards,
Marcus


A diode noise source is rarely producing more than +35dB ENR, which 
means a PSD of about -140dBm/Hz PSD.  That's nowhere close to

  over-driving anything.

However, you also need to make sure that your gain is set high enough so 
that your external noise swamps things like internal spurs
  (which, BTW, are rather inevitable in any general-purpose RF design) 
by 10dB or more.


I have to pay attention to this when doing astronomical interferometry 
so that I don't get correlations from internal correlated sources that I
  don't want.  For *constant* correlated spurs, I tend to just put a 
DC-block after my conjugate multiply, since constant-level correlated spurs
  will tend to show up as a DC offset in the correlated output. Your 
mileage may vary, void where prohibited, batteries not included, etc, etc.




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

Re: [USRP-users] Noise Capture with B200mini

[Marcus Müller via USRP-users]

Hello Andre,

I suspect three things being at work here:

1. Spurs from the mixer / synthesizer: Plot the |FFT|² (i.e. simply
play back the file through a Qt GUI frequency sink) with a high FFT
length. Do you see peaks in there? With the PSD (assuming the signal is
WSS) being both the Magnitude square of the Fourier transform of the
signal AND the value of the Fourier transform of the autocorrelation
function, peaks here indicate a sinusoidal correlation, as you might be
observing.

2. The anti-aliasing filters of course convert a perfectly white signal
to a bandlimited signal: you should see "roundish" rolloff at the edges
of the nyquist zone. That of course (through the inverse FT)
corresponds to a non-dirac autocorrelation function, i.e. correlation. 

3. By overdriving the analog receive chain, you might be bringing it to
behave nonlinearly; a simple thought experiment shows that this might
be ruining the whiteness of your noise (i.e. the uncorrelatedness):
uncorrelated noise must have a zero mean.
Squaring zero-mean noise of any variance > 0 must lead to non-zero mean
noise.
Zero-mean noise means a dirac impulse in the PSD at f=0.
That means correlatedness.

Also, nonlinearity will lead to increased spurs and spur
intermodulation (see 1.).

So, make sure you're not overdriving your receive chain – it's a
delicate flower!

Best regards,
Marcus

On Tue, 2019-05-14 at 13:38 -0600, Andre Rosete via USRP-users wrote:
> Hello
> 
> I captured noise samples (from an attached noise diode) with the
> B200mini using GNU Radio Companion. I set the gain to 90 dB with the
> intention of minimizing the noise figure. However, this caused the
> noise samples to show correlation - as if they were samples of a
> signal, rather than AWGN, which should be uncorrelated. I used 40 MHz
> of bandwidth and 40 Megasamples per second, with center frequency at
> 5800 MHz.
> 
> Is this a known issue, and are there optimal settings that I can use
> to minimize noise sample correlation? For example, with respect to
> gain?
> 
> ___
> 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] Noise Capture with B200mini

[Andre Rosete via USRP-users]

Hello

I captured noise samples (from an attached noise diode) with the B200mini
using GNU Radio Companion. I set the gain to 90 dB with the intention of
minimizing the noise figure. However, this caused the noise samples to show
correlation - as if they were samples of a signal, rather than AWGN, which
should be uncorrelated. I used 40 MHz of bandwidth and 40 Megasamples per
second, with center frequency at 5800 MHz.

Is this a known issue, and are there optimal settings that I can use to
minimize noise sample correlation? For example, with respect to gain?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 witn TwinRX: master_clock_rate issue

[Marcus D. Leech via USRP-users]

On 05/14/2019 11:26 AM, Devin Kelly via USRP-users wrote:
Does anyone have any ideas on this?  Is uhd_rx_cfile not the right 
tool to be using?


Devin

The TwinRX *MUST* run with a master clock of effectively 100MHz, because 
of the way the ADCs are shared, and the DDC structure in the
  FPGA.  Further, the fixed analog filtering is designed for a 100MHz 
clock frequency, and the synthesizers on the board require a 100MHz

  clock (AFAIR).

Simply don't specify the master clock rate when using uhd_rx_cfile, and 
the correct default *should* happen.





On Thu, May 9, 2019 at 10:39 AM Devin Kelly > wrote:



Sorry to revive an old post but I'm having the same problem with
UHD 3.12.0.0.  Am I doing something wrong with uhd_rx_cfile or
should I just upgrade to a newer UHD?

$ uhd_rx_cfile -r 10e6 -f 850e6 -a
'args=192.168.40.2,master_clock_rate=200e6' tmp.dat
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat
4.8.5-36); Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
[WARNING] [X300] Cannot update master clock rate! X300 Series does
not allow changing the clock rate during runtime.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from
device: 200 MHz. Actual rate is: 100 MHz.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from
device: 200 MHz. Actual rate is: 100 MHz.
[UHD_RX] Defaulting to mid-point gains:
[UHD_RX] Channel 0 gain: 49.5 dB
^C

Thanks,
Devin

On Thu, Jan 17, 2019 at 12:48 PM Rigney, Kevin E via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

I’m working with the TwinRX and am having the same results as
Emanuel. I was ignoring the warning about the sample rate but
you said that it must run at 200MHz. Can you explain why UHD
sets the sample rate to 100MHz if 200 is required?

Thanks,

-Kevin

On Mon, 14 Jan 2019 at 7:06 AM Emanuel via USRP-users
mailto:usrp-users@lists.ettus.com>>> wrote:

Dear Martin,

thank you for clarification. Yes, please add this to the
manual. We bought those TwinRX for some phase-coherent LTE
signal reception, and now they seem to be not useful at all
(without effort spent in sample rate conversion in
post-processing etc.)

I'm still wondering about the master clock rate though: I
tried the benchmark with the following settings:
./benchmark_rate --args "master_clock_rate=200e6" --rx_subdev
A:0 --rx_rate 10e6
The TwinRX is mounted on slot A and a CBX-120 is mounted on
slot B. I simply wanted a streaming test on the first TwinRX
channel.
During device initialization I get the following warnings, see
below. Can you please comment on them?

[INFO] [0/DUC_1] Initializing block control (NOC ID:
0xD0C0)
[WARNING] [X300] Cannot update master clock rate! X300 Series
does not allow changing the clock rate during runtime.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from
device: 200 MHz. Actual rate is: 100 MHz.
Using Device: Single USRP:
  Device: X-Series Device
  Mboard 0: X310
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: TwinRX RX0
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Unknown (0x0094) - 0
  TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: CBX-120 TX

[00:00:05.874991] Setting device timestamp to 0...
.

Cheers,
Emanuel

___
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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 witn TwinRX: master_clock_rate issue

[Devin Kelly via USRP-users]

Does anyone have any ideas on this?  Is uhd_rx_cfile not the right tool to
be using?

Devin

On Thu, May 9, 2019 at 10:39 AM Devin Kelly  wrote:

>
> Sorry to revive an old post but I'm having the same problem with UHD
> 3.12.0.0.  Am I doing something wrong with uhd_rx_cfile or should I just
> upgrade to a newer UHD?
>
> $ uhd_rx_cfile -r 10e6 -f 850e6 -a
> 'args=192.168.40.2,master_clock_rate=200e6' tmp.dat
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
> Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
> [WARNING] [X300] Cannot update master clock rate! X300 Series does not
> allow changing the clock rate during runtime.
> [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
> MHz. Actual rate is: 100 MHz.
> [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
> MHz. Actual rate is: 100 MHz.
> [UHD_RX] Defaulting to mid-point gains:
> [UHD_RX] Channel 0 gain: 49.5 dB
> ^C
>
> Thanks,
> Devin
>
> On Thu, Jan 17, 2019 at 12:48 PM Rigney, Kevin E via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I’m working with the TwinRX and am having the same results as Emanuel. I
>> was ignoring the warning about the sample rate but you said that it must
>> run at 200MHz. Can you explain why UHD sets the sample rate to 100MHz if
>> 200 is required?
>>
>> Thanks,
>>
>> -Kevin
>>
>> On Mon, 14 Jan 2019 at 7:06 AM Emanuel via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Dear Martin,
>>
>> thank you for clarification. Yes, please add this to the manual. We
>> bought those TwinRX for some phase-coherent LTE signal reception, and now
>> they seem to be not useful at all (without effort spent in sample rate
>> conversion in post-processing etc.)
>>
>> I'm still wondering about the master clock rate though: I tried the
>> benchmark with the following settings: ./benchmark_rate --args
>> "master_clock_rate=200e6" --rx_subdev A:0 --rx_rate 10e6
>> The TwinRX is mounted on slot A and a CBX-120 is mounted on slot B. I
>> simply wanted a streaming test on the first TwinRX channel.
>> During device initialization I get the following warnings, see below. Can
>> you please comment on them?
>>
>> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>> [WARNING] [X300] Cannot update master clock rate! X300 Series does not
>> allow changing the clock rate during runtime.
>> [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
>> MHz. Actual rate is: 100 MHz.
>> Using Device: Single USRP:
>>   Device: X-Series Device
>>   Mboard 0: X310
>>   RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: TwinRX RX0
>>   TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: Unknown (0x0094) - 0
>>   TX Channel: 1
>> TX DSP: 0
>> TX Dboard: B
>> TX Subdev: CBX-120 TX
>>
>> [00:00:05.874991] Setting device timestamp to 0...
>> .
>>
>> Cheers,
>> Emanuel
>>
>> ___
>> 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] vert 2450 quarter wave monopole?

[Koyel Das (Vehere) via USRP-users]

Ok it’s a quarter wave dipole. Thanks!

Regards,
Koyel Das
Senior – Product Engineer
Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: www.vehere.com



Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.

From: Jason Matusiak 
Sent: Tuesday, May 14, 2019 6:10:38 PM
To: 'USRP-users@lists.ettus.com'; Koyel Das (Vehere)
Subject: Re: vert 2450 quarter wave monopole?

According to this, it is a dipole: 
https://kb.ettus.com/images/9/9e/ettus_research_vert2450_datasheet.pdf


From: USRP-users  on behalf of Koyel Das 
(Vehere) via USRP-users 
Sent: Tuesday, May 14, 2019 5:45 AM
To: 'USRP-users@lists.ettus.com'
Subject: [USRP-users] vert 2450 quarter wave monopole?


Hi,


Can someone tell me if vert 2450 is quarter wave monopole antenna? Or what is 
it?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] vert 2450 quarter wave monopole?

[Jason Matusiak via USRP-users]

According to this, it is a dipole: 
https://kb.ettus.com/images/9/9e/ettus_research_vert2450_datasheet.pdf


From: USRP-users  on behalf of Koyel Das 
(Vehere) via USRP-users 
Sent: Tuesday, May 14, 2019 5:45 AM
To: 'USRP-users@lists.ettus.com'
Subject: [USRP-users] vert 2450 quarter wave monopole?


Hi,


Can someone tell me if vert 2450 is quarter wave monopole antenna? Or what is 
it?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] vert 2450 quarter wave monopole?

[Koyel Das (Vehere) via USRP-users]

Hi,


Can someone tell me if vert 2450 is quarter wave monopole antenna? Or what is 
it?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com