[USRP-users] Lightning Surge Protection for USRP N310

[Zhongyuan Zhao via USRP-users]

Hi,

I have an USRP N310 that will be connected to rooftop antennas. The USRP is
located in an equipment room filled with telecom equipments on the rooftop
of a high building. The antenna is outdoor along with many other
cellular/microwave antennas.

Does the USRP N310 has any internal lightning surge protection circuit?
What is your recommend practice for lightning surge protection? Or do you
have any documents for this?
Shall I use lightning surge arrester on every antenna cable including the
active GPS antenna?

Thanks!

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Lightning Surge Protection for USRP N310

[Marcus D. Leech via USRP-users]

On 05/11/2018 12:57 PM, Zhongyuan Zhao via USRP-users wrote:

Hi,

I have an USRP N310 that will be connected to rooftop antennas. The 
USRP is located in an equipment room filled with telecom equipments on 
the rooftop of a high building. The antenna is outdoor along with many 
other cellular/microwave antennas.


Does the USRP N310 has any internal lightning surge protection circuit?
What is your recommend practice for lightning surge protection? Or do 
you have any documents for this?
Shall I use lightning surge arrester on every antenna cable including 
the active GPS antenna?


Thanks!

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln


Yes, you should probably have well-grounded lightning protection in 
front of the device.  The telecom folks probably already have an "entry 
bulkhead" where
  all their coax comes through, with inline arrestors on every 
circuit.   It would be wise to follow their practice in this regard.


Here at CCERA  (http://www.ccera.ca) we use an aluminum bulkhead panel 
on the cable entrance to the lab, and that panel is directly grounded to
  a ground rod right outside the lab window.  Each coax circuit has a 
relatively-inexpensive inline coaxial surge protector on it--designed 
for 75 ohm

  CATV circuits.

You may want to look at products by companies like Polyphaser.



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

Re: [USRP-users] Lightning Surge Protection for USRP N310

[Robin Coxe via USRP-users]

Hi Zhongyuan.   The USRP N310 does not have any internal lighting surge
protection.  It is intended as a benchtop SDR.   For other use cases, you
are free to customize the device as you see fit.   Marcus's suggestions are
good ones.

-Robin



On Fri, May 11, 2018 at 10:06 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/11/2018 12:57 PM, Zhongyuan Zhao via USRP-users wrote:
>
> Hi,
>
> I have an USRP N310 that will be connected to rooftop antennas. The USRP
> is located in an equipment room filled with telecom equipments on the
> rooftop of a high building. The antenna is outdoor along with many other
> cellular/microwave antennas.
>
> Does the USRP N310 has any internal lightning surge protection circuit?
> What is your recommend practice for lightning surge protection? Or do you
> have any documents for this?
> Shall I use lightning surge arrester on every antenna cable including the
> active GPS antenna?
>
> Thanks!
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
>
>
> Yes, you should probably have well-grounded lightning protection in front
> of the device.  The telecom folks probably already have an "entry bulkhead"
> where
>   all their coax comes through, with inline arrestors on every circuit.
> It would be wise to follow their practice in this regard.
>
> Here at CCERA  (http://www.ccera.ca) we use an aluminum bulkhead panel on
> the cable entrance to the lab, and that panel is directly grounded to
>   a ground rod right outside the lab window.  Each coax circuit has a
> relatively-inexpensive inline coaxial surge protector on it--designed for
> 75 ohm
>   CATV circuits.
>
> You may want to look at products by companies like Polyphaser.
>
>
>
>
> ___
> 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] USRP sample rate bound to signal bandwidth

[Jacob Knoles via USRP-users]

Hey guys,

Please pardon my ignorance, I am trying to learn everything I need for DSP
/ OFDM on the fly. But I have noticed something with this OFDM gnuradio
example. If I take the example and run it directly into the usrp without
changing any variables, I get a 350 KHz wide signal out.
Now the sample rate is only 100k, the occupied carriers are -26 to 26 (zero
omitted) with  pm 21 and pm 7 as pilot carriers. The fft length is 64.

If the bandwidth is directly related to the sampling rate how am I getting
3x the bandwidth at low sample rates.

For some further comparison I changed only the sample rate to a few other
values, here is what I observed:

Sample Rate : Observed Bandwidth
100k : 350 KHz
50k   : 350 KHz
1M: 840 KHz
20M  : 17 MHz

The 1M and 20M rates make sense but I don't understand what is happening
with the 100k and 50k rates.

Thank you for the help.
-
Jacob Knoles



On Wed, May 9, 2018 at 6:22 PM Marcus D. Leech  wrote:

> On 05/09/2018 07:57 PM, Jacob Knoles wrote:
>
> Thanks for the quick reply guys.
>
> Marcus the Re-sampling option makes perfect sense, and I believe, in
> theory, since I am writing data to a file for later use I could interpolate
> it just before writing then read it out at the usrp sample rate, right?
>
> Yes.
>
>
> Ian, very interesting suggestion. I will have to give it a try. Thanks for
> the input. And since I am doing all of the heavy processing prior to tx'ing
> I don't image this change will create too great of a burden on the CPU. As
> for reading from the file, I am just creating a small data set which gets
> loaded into memory and repeated.
>
> Thanks!!
> -
> Jacob Knoles
>
>
>
> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>
>> > On May 9, 2018, at 4:07 PM, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> >
>> > On 05/09/2018 06:53 PM, Jacob Knoles via USRP-users wrote:
>> >> Hello All,
>> >>
>> >> I am trying to generate OFDM signals of various bandwidths using the
>> X300 (UBX-160), particularly 20/40/80 and 160 MHz bandwidths.
>> >> I have used the gnuradio ofdm_tx.grc example file to generate a data
>> file which I then feed into the USRP an monitor on a spectrum analyzer.
>> >>
>> >> To quickly note, I do not care about the data being transferred, it
>> will not be received or demodulated in any way and is simply an interfering
>> signal.
>> >>
>> >> At this time I can produce a 20 MHz wide OFDM signal as well as a 100
>> MHz wide signal (?) but the 40/80 MHz signals are rounded and look more
>> like an 802.11b signal.
>> >>
>> >> I have noted a message from the X300 that the requested sample rates
>> (40/80 MS respectively) cannot be achieved due to the 200/x ratio being odd.
>> >>
>> >> So my question is this, how do I decouple the USRP's sample rate with
>> the bandwidth of the signal I am trying to produce?
>> >> To put it another way, I produce a data file at 40 MS/s rate then run
>> it on the X300 at 100 MS/s and I get a 100 MHz wide signal instead of the
>> 40 MHz I want.
>> >>
>> >> Thanks for the help.
>> >> -
>> >> Jacob Knoles
>> >>
>> > You would need to interpolate it up to the desired rate.  UHD has no
>> way of knowing that your samples represent data sampled at 40Msps, so when
>> you
>> >  pull it out of your file at 100Msps, it will get presented as if it
>> were 100Msps data.
>> >
>> > You'll need to use some DSP code, or Gnu Radio to up-sample your sample
>> file.
>> >
>> ….or perhaps generate it off line using a non 2^n Fourier transform size
>> that targets the USRP sample rate…for example instead of 64 bins @ 40MHz,
>> 80 bins @ 50MHz,
>> With zero data in the extra outlying bins (as you would have anyway in
>> other bins). Might get interesting getting high bitrates out of a file, but
>> equally, high bitrate M:N sample rate conversion will also be tricky for CPU
>> ___
>> 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] USRP sample rate bound to signal bandwidth

[Ian Buckley via USRP-users]

What TX gain have you got set? Are you sure you are operating the PA in it’s 
linear region? OFDM waveforms are notorious for there PAPR requirements.

> On May 11, 2018, at 11:23 AM, Jacob Knoles  wrote:
> 
> Hey guys, 
> 
> Please pardon my ignorance, I am trying to learn everything I need for DSP / 
> OFDM on the fly. But I have noticed something with this OFDM gnuradio 
> example. If I take the example and run it directly into the usrp without 
> changing any variables, I get a 350 KHz wide signal out. 
> Now the sample rate is only 100k, the occupied carriers are -26 to 26 (zero 
> omitted) with  pm 21 and pm 7 as pilot carriers. The fft length is 64. 
> 
> If the bandwidth is directly related to the sampling rate how am I getting 3x 
> the bandwidth at low sample rates. 
> 
> For some further comparison I changed only the sample rate to a few other 
> values, here is what I observed:
> 
> Sample Rate : Observed Bandwidth
> 100k : 350 KHz
> 50k   : 350 KHz
> 1M: 840 KHz
> 20M  : 17 MHz
> 
> The 1M and 20M rates make sense but I don't understand what is happening with 
> the 100k and 50k rates. 
> 
> Thank you for the help.  
> -
> Jacob Knoles
> 
> 
> 
> On Wed, May 9, 2018 at 6:22 PM Marcus D. Leech  > wrote:
> On 05/09/2018 07:57 PM, Jacob Knoles wrote:
>> Thanks for the quick reply guys. 
>> 
>> Marcus the Re-sampling option makes perfect sense, and I believe, in theory, 
>> since I am writing data to a file for later use I could interpolate it just 
>> before writing then read it out at the usrp sample rate, right? 
> Yes.
> 
>> 
>> Ian, very interesting suggestion. I will have to give it a try. Thanks for 
>> the input. And since I am doing all of the heavy processing prior to tx'ing 
>> I don't image this change will create too great of a burden on the CPU. As 
>> for reading from the file, I am just creating a small data set which gets 
>> loaded into memory and repeated.
>> 
>> Thanks!! 
>> -
>> Jacob Knoles
>> 
>> 
>> 
>> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> > On May 9, 2018, at 4:07 PM, Marcus D. Leech via USRP-users 
>> > mailto:usrp-users@lists.ettus.com>> wrote:
>> > 
>> > On 05/09/2018 06:53 PM, Jacob Knoles via USRP-users wrote:
>> >> Hello All,
>> >> 
>> >> I am trying to generate OFDM signals of various bandwidths using the X300 
>> >> (UBX-160), particularly 20/40/80 and 160 MHz bandwidths.
>> >> I have used the gnuradio ofdm_tx.grc example file to generate a data file 
>> >> which I then feed into the USRP an monitor on a spectrum analyzer.
>> >> 
>> >> To quickly note, I do not care about the data being transferred, it will 
>> >> not be received or demodulated in any way and is simply an interfering 
>> >> signal.
>> >> 
>> >> At this time I can produce a 20 MHz wide OFDM signal as well as a 100 MHz 
>> >> wide signal (?) but the 40/80 MHz signals are rounded and look more like 
>> >> an 802.11b signal.
>> >> 
>> >> I have noted a message from the X300 that the requested sample rates 
>> >> (40/80 MS respectively) cannot be achieved due to the 200/x ratio being 
>> >> odd.
>> >> 
>> >> So my question is this, how do I decouple the USRP's sample rate with the 
>> >> bandwidth of the signal I am trying to produce?
>> >> To put it another way, I produce a data file at 40 MS/s rate then run it 
>> >> on the X300 at 100 MS/s and I get a 100 MHz wide signal instead of the 40 
>> >> MHz I want.
>> >> 
>> >> Thanks for the help.
>> >> -
>> >> Jacob Knoles
>> >> 
>> > You would need to interpolate it up to the desired rate.  UHD has no way 
>> > of knowing that your samples represent data sampled at 40Msps, so when you
>> >  pull it out of your file at 100Msps, it will get presented as if it were 
>> > 100Msps data.
>> > 
>> > You'll need to use some DSP code, or Gnu Radio to up-sample your sample 
>> > file.
>> > 
>> ….or perhaps generate it off line using a non 2^n Fourier transform size 
>> that targets the USRP sample rate…for example instead of 64 bins @ 40MHz, 80 
>> bins @ 50MHz,
>> With zero data in the extra outlying bins (as you would have anyway in other 
>> bins). Might get interesting getting high bitrates out of a file, but 
>> equally, high bitrate M:N sample rate conversion will also be tricky for CPU
>> ___
>> 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] USRP sample rate bound to signal bandwidth

[Jacob Knoles via USRP-users]

In the DSP prior to sending to USRP I scale everything by a const 0.05, the
TX gain for the USRP is 0.5 normalized.
-
Jacob Knoles



On Fri, May 11, 2018 at 11:40 AM Ian Buckley  wrote:

> What TX gain have you got set? Are you sure you are operating the PA in
> it’s linear region? OFDM waveforms are notorious for there PAPR
> requirements.
>
> On May 11, 2018, at 11:23 AM, Jacob Knoles  wrote:
>
> Hey guys,
>
> Please pardon my ignorance, I am trying to learn everything I need for DSP
> / OFDM on the fly. But I have noticed something with this OFDM gnuradio
> example. If I take the example and run it directly into the usrp without
> changing any variables, I get a 350 KHz wide signal out.
> Now the sample rate is only 100k, the occupied carriers are -26 to 26
> (zero omitted) with  pm 21 and pm 7 as pilot carriers. The fft length is
> 64.
>
> If the bandwidth is directly related to the sampling rate how am I getting
> 3x the bandwidth at low sample rates.
>
> For some further comparison I changed only the sample rate to a few other
> values, here is what I observed:
>
> Sample Rate : Observed Bandwidth
> 100k : 350 KHz
> 50k   : 350 KHz
> 1M: 840 KHz
> 20M  : 17 MHz
>
> The 1M and 20M rates make sense but I don't understand what is happening
> with the 100k and 50k rates.
>
> Thank you for the help.
> -
> Jacob Knoles
>
>
>
> On Wed, May 9, 2018 at 6:22 PM Marcus D. Leech  wrote:
>
>> On 05/09/2018 07:57 PM, Jacob Knoles wrote:
>>
>> Thanks for the quick reply guys.
>>
>> Marcus the Re-sampling option makes perfect sense, and I believe, in
>> theory, since I am writing data to a file for later use I could interpolate
>> it just before writing then read it out at the usrp sample rate, right?
>>
>> Yes.
>>
>>
>> Ian, very interesting suggestion. I will have to give it a try. Thanks
>> for the input. And since I am doing all of the heavy processing prior to
>> tx'ing I don't image this change will create too great of a burden on the
>> CPU. As for reading from the file, I am just creating a small data set
>> which gets loaded into memory and repeated.
>>
>> Thanks!!
>> -
>> Jacob Knoles
>>
>>
>>
>> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>>
>>> > On May 9, 2018, at 4:07 PM, Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>> >
>>> > On 05/09/2018 06:53 PM, Jacob Knoles via USRP-users wrote:
>>> >> Hello All,
>>> >>
>>> >> I am trying to generate OFDM signals of various bandwidths using the
>>> X300 (UBX-160), particularly 20/40/80 and 160 MHz bandwidths.
>>> >> I have used the gnuradio ofdm_tx.grc example file to generate a data
>>> file which I then feed into the USRP an monitor on a spectrum analyzer.
>>> >>
>>> >> To quickly note, I do not care about the data being transferred, it
>>> will not be received or demodulated in any way and is simply an interfering
>>> signal.
>>> >>
>>> >> At this time I can produce a 20 MHz wide OFDM signal as well as a 100
>>> MHz wide signal (?) but the 40/80 MHz signals are rounded and look more
>>> like an 802.11b signal.
>>> >>
>>> >> I have noted a message from the X300 that the requested sample rates
>>> (40/80 MS respectively) cannot be achieved due to the 200/x ratio being odd.
>>> >>
>>> >> So my question is this, how do I decouple the USRP's sample rate with
>>> the bandwidth of the signal I am trying to produce?
>>> >> To put it another way, I produce a data file at 40 MS/s rate then run
>>> it on the X300 at 100 MS/s and I get a 100 MHz wide signal instead of the
>>> 40 MHz I want.
>>> >>
>>> >> Thanks for the help.
>>> >> -
>>> >> Jacob Knoles
>>> >>
>>> > You would need to interpolate it up to the desired rate.  UHD has no
>>> way of knowing that your samples represent data sampled at 40Msps, so when
>>> you
>>> >  pull it out of your file at 100Msps, it will get presented as if it
>>> were 100Msps data.
>>> >
>>> > You'll need to use some DSP code, or Gnu Radio to up-sample your
>>> sample file.
>>> >
>>> ….or perhaps generate it off line using a non 2^n Fourier transform size
>>> that targets the USRP sample rate…for example instead of 64 bins @ 40MHz,
>>> 80 bins @ 50MHz,
>>> With zero data in the extra outlying bins (as you would have anyway in
>>> other bins). Might get interesting getting high bitrates out of a file, but
>>> equally, high bitrate M:N sample rate conversion will also be tricky for CPU
>>> ___
>>> 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] USRP sample rate bound to signal bandwidth

[Ian Buckley via USRP-users]

I may not have written my last response helpfully…the absolute value of gain 
doesn’t tell you much about your actual power output, it’s very waveform 
dependant. It was a hint to go vary this and see what happens.
If you drop a QT GUI Frequency Sink after your Cyclic prefixer you’ll get a 
good feel for where all your signal power should be in an ideal world. If 
that’s not what you see on a spectrum analyzer then something downstream is 
causing your problem.
If you think about it, your actual OFDM waveform generation part of the flow 
graph is Nyquist limited by the sample rate it runs at. Any digital 
interpolation that happens from that sample rate to the ADC clock rate within 
the FPGA applies appropriate filtering to prevent significant aliasing.

Now I think about it, you previously mentioned you are X310 based….not sure it 
can interpolate in H/W from as low as 50/100kHz…the limit used to be 512:1 when 
I originally designed it. Have you checked what UHD reports when the flow graph 
starts? You may not be running at the sample rate you asked for……(May need flow 
graph interpolator in S/W for low bandwidths)


> On May 11, 2018, at 11:43 AM, Jacob Knoles  wrote:
> 
> In the DSP prior to sending to USRP I scale everything by a const 0.05, the 
> TX gain for the USRP is 0.5 normalized.
> -
> Jacob Knoles
> 
> 
> 
> On Fri, May 11, 2018 at 11:40 AM Ian Buckley  > wrote:
> What TX gain have you got set? Are you sure you are operating the PA in it’s 
> linear region? OFDM waveforms are notorious for there PAPR requirements.
> 
>> On May 11, 2018, at 11:23 AM, Jacob Knoles > > wrote:
>> 
>> Hey guys, 
>> 
>> Please pardon my ignorance, I am trying to learn everything I need for DSP / 
>> OFDM on the fly. But I have noticed something with this OFDM gnuradio 
>> example. If I take the example and run it directly into the usrp without 
>> changing any variables, I get a 350 KHz wide signal out. 
>> Now the sample rate is only 100k, the occupied carriers are -26 to 26 (zero 
>> omitted) with  pm 21 and pm 7 as pilot carriers. The fft length is 64. 
>> 
>> If the bandwidth is directly related to the sampling rate how am I getting 
>> 3x the bandwidth at low sample rates. 
>> 
>> For some further comparison I changed only the sample rate to a few other 
>> values, here is what I observed:
>> 
>> Sample Rate : Observed Bandwidth
>> 100k : 350 KHz
>> 50k   : 350 KHz
>> 1M: 840 KHz
>> 20M  : 17 MHz
>> 
>> The 1M and 20M rates make sense but I don't understand what is happening 
>> with the 100k and 50k rates. 
>> 
>> Thank you for the help.  
>> -
>> Jacob Knoles
>> 
>> 
>> 
>> On Wed, May 9, 2018 at 6:22 PM Marcus D. Leech > > wrote:
>> On 05/09/2018 07:57 PM, Jacob Knoles wrote:
>>> Thanks for the quick reply guys. 
>>> 
>>> Marcus the Re-sampling option makes perfect sense, and I believe, in 
>>> theory, since I am writing data to a file for later use I could interpolate 
>>> it just before writing then read it out at the usrp sample rate, right? 
>> Yes.
>> 
>>> 
>>> Ian, very interesting suggestion. I will have to give it a try. Thanks for 
>>> the input. And since I am doing all of the heavy processing prior to tx'ing 
>>> I don't image this change will create too great of a burden on the CPU. As 
>>> for reading from the file, I am just creating a small data set which gets 
>>> loaded into memory and repeated.
>>> 
>>> Thanks!! 
>>> -
>>> Jacob Knoles
>>> 
>>> 
>>> 
>>> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> > On May 9, 2018, at 4:07 PM, Marcus D. Leech via USRP-users 
>>> > mailto:usrp-users@lists.ettus.com>> wrote:
>>> > 
>>> > On 05/09/2018 06:53 PM, Jacob Knoles via USRP-users wrote:
>>> >> Hello All,
>>> >> 
>>> >> I am trying to generate OFDM signals of various bandwidths using the 
>>> >> X300 (UBX-160), particularly 20/40/80 and 160 MHz bandwidths.
>>> >> I have used the gnuradio ofdm_tx.grc example file to generate a data 
>>> >> file which I then feed into the USRP an monitor on a spectrum analyzer.
>>> >> 
>>> >> To quickly note, I do not care about the data being transferred, it will 
>>> >> not be received or demodulated in any way and is simply an interfering 
>>> >> signal.
>>> >> 
>>> >> At this time I can produce a 20 MHz wide OFDM signal as well as a 100 
>>> >> MHz wide signal (?) but the 40/80 MHz signals are rounded and look more 
>>> >> like an 802.11b signal.
>>> >> 
>>> >> I have noted a message from the X300 that the requested sample rates 
>>> >> (40/80 MS respectively) cannot be achieved due to the 200/x ratio being 
>>> >> odd.
>>> >> 
>>> >> So my question is this, how do I decouple the USRP's sample rate with 
>>> >> the bandwidth of the signal I am trying to produce?
>>> >> To put it another way, I produce a data file at 40 MS/s rate 

Re: [USRP-users] USRP sample rate bound to signal bandwidth

[Jacob Knoles via USRP-users]

Ugh, that was it, the usrp is coercing the sampling rate to 390k which
gives me a 350MHz ish bandwidth. Must have missed that earlier.

Thanks for the help.
-
Jacob Knoles



On Fri, May 11, 2018 at 12:36 PM Ian Buckley  wrote:

> I may not have written my last response helpfully…the absolute value of
> gain doesn’t tell you much about your actual power output, it’s very
> waveform dependant. It was a hint to go vary this and see what happens.
> If you drop a QT GUI Frequency Sink after your Cyclic prefixer you’ll get
> a good feel for where all your signal power should be in an ideal world. If
> that’s not what you see on a spectrum analyzer then something downstream is
> causing your problem.
> If you think about it, your actual OFDM waveform generation part of the
> flow graph is Nyquist limited by the sample rate it runs at. Any digital
> interpolation that happens from that sample rate to the ADC clock rate
> within the FPGA applies appropriate filtering to prevent significant
> aliasing.
>
> Now I think about it, you previously mentioned you are X310 based….not
> sure it can interpolate in H/W from as low as 50/100kHz…the limit used to
> be 512:1 when I originally designed it. Have you checked what UHD reports
> when the flow graph starts? You may not be running at the sample rate you
> asked for……(May need flow graph interpolator in S/W for low bandwidths)
>
>
> On May 11, 2018, at 11:43 AM, Jacob Knoles  wrote:
>
> In the DSP prior to sending to USRP I scale everything by a const 0.05,
> the TX gain for the USRP is 0.5 normalized.
> -
> Jacob Knoles
>
>
>
> On Fri, May 11, 2018 at 11:40 AM Ian Buckley  wrote:
>
>> What TX gain have you got set? Are you sure you are operating the PA in
>> it’s linear region? OFDM waveforms are notorious for there PAPR
>> requirements.
>>
>> On May 11, 2018, at 11:23 AM, Jacob Knoles  wrote:
>>
>> Hey guys,
>>
>> Please pardon my ignorance, I am trying to learn everything I need for
>> DSP / OFDM on the fly. But I have noticed something with this OFDM gnuradio
>> example. If I take the example and run it directly into the usrp without
>> changing any variables, I get a 350 KHz wide signal out.
>> Now the sample rate is only 100k, the occupied carriers are -26 to 26
>> (zero omitted) with  pm 21 and pm 7 as pilot carriers. The fft length is
>> 64.
>>
>> If the bandwidth is directly related to the sampling rate how am I
>> getting 3x the bandwidth at low sample rates.
>>
>> For some further comparison I changed only the sample rate to a few other
>> values, here is what I observed:
>>
>> Sample Rate : Observed Bandwidth
>> 100k : 350 KHz
>> 50k   : 350 KHz
>> 1M: 840 KHz
>> 20M  : 17 MHz
>>
>> The 1M and 20M rates make sense but I don't understand what is happening
>> with the 100k and 50k rates.
>>
>> Thank you for the help.
>> -
>> Jacob Knoles
>>
>>
>>
>> On Wed, May 9, 2018 at 6:22 PM Marcus D. Leech  wrote:
>>
>>> On 05/09/2018 07:57 PM, Jacob Knoles wrote:
>>>
>>> Thanks for the quick reply guys.
>>>
>>> Marcus the Re-sampling option makes perfect sense, and I believe, in
>>> theory, since I am writing data to a file for later use I could interpolate
>>> it just before writing then read it out at the usrp sample rate, right?
>>>
>>> Yes.
>>>
>>>
>>> Ian, very interesting suggestion. I will have to give it a try. Thanks
>>> for the input. And since I am doing all of the heavy processing prior to
>>> tx'ing I don't image this change will create too great of a burden on the
>>> CPU. As for reading from the file, I am just creating a small data set
>>> which gets loaded into memory and repeated.
>>>
>>> Thanks!!
>>> -
>>> Jacob Knoles
>>>
>>>
>>>
>>> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>

 > On May 9, 2018, at 4:07 PM, Marcus D. Leech via USRP-users <
 usrp-users@lists.ettus.com> wrote:
 >
 > On 05/09/2018 06:53 PM, Jacob Knoles via USRP-users wrote:
 >> Hello All,
 >>
 >> I am trying to generate OFDM signals of various bandwidths using the
 X300 (UBX-160), particularly 20/40/80 and 160 MHz bandwidths.
 >> I have used the gnuradio ofdm_tx.grc example file to generate a data
 file which I then feed into the USRP an monitor on a spectrum analyzer.
 >>
 >> To quickly note, I do not care about the data being transferred, it
 will not be received or demodulated in any way and is simply an interfering
 signal.
 >>
 >> At this time I can produce a 20 MHz wide OFDM signal as well as a
 100 MHz wide signal (?) but the 40/80 MHz signals are rounded and look more
 like an 802.11b signal.
 >>
 >> I have noted a message from the X300 that the requested sample rates
 (40/80 MS respectively) cannot be achieved due to the 200/x ratio being 
 odd.
 >>
 >> So my question is this, how do I decouple the USRP's 

[USRP-users] N310 streaming documentation

[Louis Brown via USRP-users]

Is there documentation on getting the N310 streaming interface working?  I'm 
able to ping the SFP0 port at 192.168.10.2 and the on-board at 192.168.1.4, but 
uhd_find_devices and uhd_usrp_probe find nothing:

uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); 
Boost_106600; UHD_3.11.1.0-0-g34c56104
Error: LookupError: KeyError: No devices found for ->
Device Address:
addr: 192.168.10.2

I did update the SD card image with:

http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.11.0.1-20180419/n3xx_common_sdimg_default-v3.11.0.1-20180419.zip


The ASCII art spectrum test works fine, so the hardware seems to be working.

Thanks,
Lou

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

Re: [USRP-users] N310 streaming documentation

[Marcus D. Leech via USRP-users]

On 05/11/2018 05:57 PM, Louis Brown via USRP-users wrote:


Is there documentation on getting the N310 streaming interface 
working?  I'm able to ping the SFP0 port at 192.168.10.2 and the 
on-board at 192.168.1.4, but uhd_find_devices and uhd_usrp_probe find 
nothing:


uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); 
Boost_106600; UHD_3.11.1.0-0-g34c56104

Error: LookupError: KeyError: No devices found for ->
Device Address:
addr: 192.168.10.2

I did update the SD card image with:

http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.11.0.1-20180419/n3xx_common_sdimg_default-v3.11.0.1-20180419.zip


The ASCII art spectrum test works fine, so the hardware seems to be 
working.


Thanks,
Lou


COuld you try adding "type=n300" to your --args ??

--args "addr=192.168.10.2,type=n300"



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

Re: [USRP-users] N310 streaming documentation

[Brent Stapleton via USRP-users]

The `type` should be n3xx, not n300.

--args "addr=192.168.10.2,type=n3xx"

Brent

On Fri, May 11, 2018 at 3:06 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/11/2018 05:57 PM, Louis Brown via USRP-users wrote:
>
>>
>> Is there documentation on getting the N310 streaming interface working?
>> I'm able to ping the SFP0 port at 192.168.10.2 and the on-board at
>> 192.168.1.4, but uhd_find_devices and uhd_usrp_probe find nothing:
>>
>> uhd_usrp_probe --args "addr=192.168.10.2"
>> [INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1);
>> Boost_106600; UHD_3.11.1.0-0-g34c56104
>> Error: LookupError: KeyError: No devices found for ->
>> Device Address:
>> addr: 192.168.10.2
>>
>> I did update the SD card image with:
>>
>> http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.11.
>> 0.1-20180419/n3xx_common_sdimg_default-v3.11.0.1-20180419.zip
>>
>>
>> The ASCII art spectrum test works fine, so the hardware seems to be
>> working.
>>
>> Thanks,
>> Lou
>>
>> COuld you try adding "type=n300" to your --args ??
>
> --args "addr=192.168.10.2,type=n300"
>
>
>
> ___
> 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] N310 streaming documentation

[Marcus D. Leech via USRP-users]

On 05/11/2018 06:14 PM, Brent Stapleton wrote:

The `type` should be n3xx, not n300.

--args "addr=192.168.10.2,type=n3xx"

Brent
Ah.  That's a change from N2xx and B2xx series.   Might I suggest 
putting in synonyms, so that folks used to previous naming schemes won't 
become

  confused?




On Fri, May 11, 2018 at 3:06 PM, Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 05/11/2018 05:57 PM, Louis Brown via USRP-users wrote:


Is there documentation on getting the N310 streaming interface
working?  I'm able to ping the SFP0 port at 192.168.10.2 and
the on-board at 192.168.1.4, but uhd_find_devices and
uhd_usrp_probe find nothing:

uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat
8.1.1-1); Boost_106600; UHD_3.11.1.0-0-g34c56104
Error: LookupError: KeyError: No devices found for ->
Device Address:
addr: 192.168.10.2

I did update the SD card image with:


http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.11.0.1-20180419/n3xx_common_sdimg_default-v3.11.0.1-20180419.zip




The ASCII art spectrum test works fine, so the hardware seems
to be working.

Thanks,
Lou

COuld you try adding "type=n300" to your --args ??

--args "addr=192.168.10.2,type=n300"



___
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] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Thanks, Michael.

So with the fix you referenced RFNoC: Radio now works in Rx mode but does
not seem to work work in Tx mode regardless of what's connected to its
input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks
separately). The  "what():  map::at" error is resolved so there is no error
message but the "TX/RX" indicator light on the X310 front panel fails to
light up. Has that been fixed or is a fix in progress?

On Mon, May 7, 2018 at 9:12 AM, Michael West  wrote:

> Hi Andrew,
>
> First, maint was just updated with the fix for the LFTX and LFRX boards on
> X3x0.
>
> Second, yes, you can install multiple installations of UHD by setting the
> CMAKE_INSTALL_PREFIX different for each installation.  You will have to set
> the PATH and LD_LIBRARY_PATH environment variables appropriately to switch
> between them.
>
> Regards,
> Michael
>
> On Fri, May 4, 2018 at 11:43 AM, switchlanez 
> wrote:
>
>> Thanks Michael. Do you know if I were to install rfnoc under a different
>> prefix would the UHD version be able to be switched between the prefixes?
>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant
>> to install the latest build and checkout that new fix if it it will
>> overwrite the older UHD version.
>>
>> On Fri, May 4, 2018 at 11:25 AM, Michael West 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> The fix is on the master branch (commit 8922095
>>> ).
>>> It is being included in the next set of commits on the maint branch that
>>> should be available in the next few days.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Wed, May 2, 2018 at 1:13 PM, switchlanez 
>>> wrote:
>>>
 Hi Michael,

 I see new commits have been entered in the uhd maint branch in the last
 couple days. Were any related to this issue?

 Andrew

 On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
 wrote:

> Hi Louis/Andrew,
>
> The root cause of the issue has been identified and a fix is in
> progress.  We should have the fix available on the head of the maint 
> branch
> very soon.  Thank you for bringing it to our attention!
>
> Regards,
> Michael
>
> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I have an issue that may be related. Using LFTX and LFRX boards in an
>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
>> with:
>>
>> terminate called after throwing an instance of 'std::out_of_range'
>>   what():  map::at
>>
>> Following for updates.
>>
>> Andrew
>>
>>
>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello Louis:
>>>
>>> Thanks for the detailed feedback. We have reproduced this issue, and
>>> are debugging it now. We will get back to you and post an update 
>>> shortly.
>>>
>>> --​Neel Pandeya
>>>
>>>
>>>
>>>
>>> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Could it be something to do with this commit for address offsets?

 https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
 064b0dc6fbcc04c2ded94b4a

 Lou


 On Apr 12, 2018, at 16:38, Louis Brown  wrote:


 Did something change with respect to daughter board addressing in
 UHD 3.11?
 I have an X310 with LFTX and LFRX  in motherboard slot A.
 When I run benchmark_rate it core dumps as follows:

 /*
 [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
 "addr=192.168.40.2" --tx_rate=10E6

 [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat
 7.3.1-5); Boost_106400; UHD_3.11.0.1-0-unknown
 [00:00:00.06] Creating the usrp device with:
 addr=192.168.40.2...
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Determining maximum frame size...
 [INFO] [X300] Maximum frame size: 8000 bytes.
 [INFO] [X300] Setup basic communication...
 [INFO] [X300] Loading values from EEPROM...
 [INFO] [X300] Setup RF frontend clocking...
 [INFO] [X300] Radio 1x clock:200
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
 [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1
 input ports
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

Tried the X310 today on the maintenance branch, and the TX light illuminates, 
but did not check for proper quadrature output.  Will check it tomorrow.  Was 
able to do 100 Msps full duplex.

Lou


> On May 11, 2018, at 19:18, switchlanez  wrote:
> 
> Thanks, Michael.
> 
> So with the fix you referenced RFNoC: Radio now works in Rx mode but does not 
> seem to work work in Tx mode regardless of what's connected to its input 
> (I've tried GNU Radio's in-tree Signal Source then Null Source blocks 
> separately). The  "what():  map::at" error is resolved so there is no error 
> message but the "TX/RX" indicator light on the X310 front panel fails to 
> light up. Has that been fixed or is a fix in progress?
> 
>> On Mon, May 7, 2018 at 9:12 AM, Michael West  wrote:
>> Hi Andrew,
>> 
>> First, maint was just updated with the fix for the LFTX and LFRX boards on 
>> X3x0.
>> 
>> Second, yes, you can install multiple installations of UHD by setting the 
>> CMAKE_INSTALL_PREFIX different for each installation.  You will have to set 
>> the PATH and LD_LIBRARY_PATH environment variables appropriately to switch 
>> between them.
>> 
>> Regards,
>> Michael
>> 
>>> On Fri, May 4, 2018 at 11:43 AM, switchlanez  wrote:
>>> Thanks Michael. Do you know if I were to install rfnoc under a different 
>>> prefix would the UHD version be able to be switched between the prefixes? 
>>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant 
>>> to install the latest build and checkout that new fix if it it will 
>>> overwrite the older UHD version.
>>> 
 On Fri, May 4, 2018 at 11:25 AM, Michael West  
 wrote:
 Hi Andrew,
 
 The fix is on the master branch (commit 8922095).  It is being included in 
 the next set of commits on the maint branch that should be available in 
 the next few days.
 
 Regards,
 Michael
 
> On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:
> Hi Michael,
> 
> I see new commits have been entered in the uhd maint branch in the last 
> couple days. Were any related to this issue?
> 
> Andrew
> 
>> On Mon, Apr 23, 2018 at 11:12 AM, Michael West  
>> wrote:
>> Hi Louis/Andrew,
>> 
>> The root cause of the issue has been identified and a fix is in 
>> progress.  We should have the fix available on the head of the maint 
>> branch very soon.  Thank you for bringing it to our attention!
>> 
>> Regards,
>> Michael
>> 
>>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users 
>>>  wrote:
>>> I have an issue that may be related. Using LFTX and LFRX boards in an 
>>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates 
>>> with:
>>> 
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  map::at
>>> 
>>> Following for updates.
>>> 
>>> Andrew
>>> 
>>> 
 On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users 
  wrote:
 Hello Louis:
 
 Thanks for the detailed feedback. We have reproduced this issue, and 
 are debugging it now. We will get back to you and post an update 
 shortly.
 
 --​Neel Pandeya
 
 
 
 
> On 12 April 2018 at 18:46, Louis Brown via USRP-users 
>  wrote:
> Could it be something to do with this commit for address offsets?
> 
> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2064b0dc6fbcc04c2ded94b4a
> 
> Lou
> 
> 
>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>> 
>> 
>> Did something change with respect to daughter board addressing in 
>> UHD 3.11?
>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>> When I run benchmark_rate it core dumps as follows:
>> 
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args 
>> "addr=192.168.40.2" --tx_rate=10E6
>> 
>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 
>> 7.3.1-5); Boost_106400; UHD_3.11.0.1-0-unknown
>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size... 
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0... 
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1... 
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>> [WARNING] [RFNOC] [0/Radio_0] defines

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Wow good to know, Lou.

I checked out the head of the uhd maint branch (commit 34c5610
)
and installed it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I
install the head of gr-ettus master branch (commit 4ef12d
)
I get an error:

/home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40:
fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
compilation terminated.
lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target
'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o]
Error 1
make[2]: *** Waiting for unfinished jobs
[ 46%] Built target ettus_swig_swig_2d0df
Scanning dependencies of target pygen_swig_5fc0a
[ 48%] Generating ettus_swig.pyo
[ 51%] Generating ettus_swig.pyc
[ 53%] Built target pygen_swig_5fc0a
CMakeFiles/Makefile2:139: recipe for target
'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I am probably building it wrong. Does anybody know the correct way?

Andrew

On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:

> Tried the X310 today on the maintenance branch, and the TX light
> illuminates, but did not check for proper quadrature output.  Will check it
> tomorrow.  Was able to do 100 Msps full duplex.
>
> Lou
>
>
> On May 11, 2018, at 19:18, switchlanez  wrote:
>
> Thanks, Michael.
>
> So with the fix you referenced RFNoC: Radio now works in Rx mode but does
> not seem to work work in Tx mode regardless of what's connected to its
> input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks
> separately). The  "what():  map::at" error is resolved so there is no
> error message but the "TX/RX" indicator light on the X310 front panel fails
> to light up. Has that been fixed or is a fix in progress?
>
> On Mon, May 7, 2018 at 9:12 AM, Michael West 
> wrote:
>
>> Hi Andrew,
>>
>> First, maint was just updated with the fix for the LFTX and LFRX boards
>> on X3x0.
>>
>> Second, yes, you can install multiple installations of UHD by setting the
>> CMAKE_INSTALL_PREFIX different for each installation.  You will have to set
>> the PATH and LD_LIBRARY_PATH environment variables appropriately to switch
>> between them.
>>
>> Regards,
>> Michael
>>
>> On Fri, May 4, 2018 at 11:43 AM, switchlanez 
>> wrote:
>>
>>> Thanks Michael. Do you know if I were to install rfnoc under a different
>>> prefix would the UHD version be able to be switched between the prefixes?
>>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant
>>> to install the latest build and checkout that new fix if it it will
>>> overwrite the older UHD version.
>>>
>>> On Fri, May 4, 2018 at 11:25 AM, Michael West 
>>> wrote:
>>>
 Hi Andrew,

 The fix is on the master branch (commit 8922095
 ).
 It is being included in the next set of commits on the maint branch that
 should be available in the next few days.

 Regards,
 Michael

 On Wed, May 2, 2018 at 1:13 PM, switchlanez 
 wrote:

> Hi Michael,
>
> I see new commits have been entered in the uhd maint branch in the
> last couple days. Were any related to this issue?
>
> Andrew
>
> On Mon, Apr 23, 2018 at 11:12 AM, Michael West  > wrote:
>
>> Hi Louis/Andrew,
>>
>> The root cause of the issue has been identified and a fix is in
>> progress.  We should have the fix available on the head of the maint 
>> branch
>> very soon.  Thank you for bringing it to our attention!
>>
>> Regards,
>> Michael
>>
>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I have an issue that may be related. Using LFTX and LFRX boards in
>>> an X310, anytime I use the RFNoC Radio block in Rx mode the run 
>>> terminates
>>> with:
>>>
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  map::at
>>>
>>> Following for updates.
>>>
>>> Andrew
>>>
>>>
>>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello Louis:

 Thanks for the detailed feedback. We have reproduced this issue,
 and are debugging it now. We will get back to you and post an update
 shortly.

 --​Neel Pandeya




 On 12 April 2018 at 18:46, Louis Brown via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Could i

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

Did you “git clone — recursive” then switch to the rfnoc branch?  I’m not using 
the rfnoc branch; just the normal maintenance branch, but last time I messed 
with it, you had to do that.

> On May 11, 2018, at 21:16, switchlanez  wrote:
> 
> Wow good to know, Lou.
> 
> I checked out the head of the uhd maint branch (commit 34c5610) and installed 
> it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I install the 
> head of gr-ettus master branch (commit 4ef12d) I get an error:
> 
> /home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40: 
> fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
> compilation terminated.
> lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target 
> 'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o] 
> Error 1
> make[2]: *** Waiting for unfinished jobs
> [ 46%] Built target ettus_swig_swig_2d0df
> Scanning dependencies of target pygen_swig_5fc0a
> [ 48%] Generating ettus_swig.pyo
> [ 51%] Generating ettus_swig.pyc
> [ 53%] Built target pygen_swig_5fc0a
> CMakeFiles/Makefile2:139: recipe for target 
> 'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
> make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> I am probably building it wrong. Does anybody know the correct way?
> 
> Andrew
> 
>> On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:
>> Tried the X310 today on the maintenance branch, and the TX light 
>> illuminates, but did not check for proper quadrature output.  Will check it 
>> tomorrow.  Was able to do 100 Msps full duplex.
>> 
>> Lou
>> 
>> 
>>> On May 11, 2018, at 19:18, switchlanez  wrote:
>>> 
>>> Thanks, Michael.
>>> 
>>> So with the fix you referenced RFNoC: Radio now works in Rx mode but does 
>>> not seem to work work in Tx mode regardless of what's connected to its 
>>> input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks 
>>> separately). The  "what():  map::at" error is resolved so there is no error 
>>> message but the "TX/RX" indicator light on the X310 front panel fails to 
>>> light up. Has that been fixed or is a fix in progress?
>>> 
 On Mon, May 7, 2018 at 9:12 AM, Michael West  
 wrote:
 Hi Andrew,
 
 First, maint was just updated with the fix for the LFTX and LFRX boards on 
 X3x0.
 
 Second, yes, you can install multiple installations of UHD by setting the 
 CMAKE_INSTALL_PREFIX different for each installation.  You will have to 
 set the PATH and LD_LIBRARY_PATH environment variables appropriately to 
 switch between them.
 
 Regards,
 Michael
 
> On Fri, May 4, 2018 at 11:43 AM, switchlanez  
> wrote:
> Thanks Michael. Do you know if I were to install rfnoc under a different 
> prefix would the UHD version be able to be switched between the prefixes? 
> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant 
> to install the latest build and checkout that new fix if it it will 
> overwrite the older UHD version.
> 
>> On Fri, May 4, 2018 at 11:25 AM, Michael West  
>> wrote:
>> Hi Andrew,
>> 
>> The fix is on the master branch (commit 8922095).  It is being included 
>> in the next set of commits on the maint branch that should be available 
>> in the next few days.
>> 
>> Regards,
>> Michael
>> 
>>> On Wed, May 2, 2018 at 1:13 PM, switchlanez  
>>> wrote:
>>> Hi Michael,
>>> 
>>> I see new commits have been entered in the uhd maint branch in the last 
>>> couple days. Were any related to this issue?
>>> 
>>> Andrew
>>> 
 On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
  wrote:
 Hi Louis/Andrew,
 
 The root cause of the issue has been identified and a fix is in 
 progress.  We should have the fix available on the head of the maint 
 branch very soon.  Thank you for bringing it to our attention!
 
 Regards,
 Michael
 
> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users 
>  wrote:
> I have an issue that may be related. Using LFTX and LFRX boards in an 
> X310, anytime I use the RFNoC Radio block in Rx mode the run 
> terminates with:
> 
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  map::at
> 
> Following for updates.
> 
> Andrew
> 
> 
>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users 
>>  wrote:
>> Hello Louis:
>> 
>> Thanks for the detailed feedback. We have reproduced this issue, and 
>> are debugging it now. We will get back to you and post an update 
>> shortly.
>> 
>> --​Ne

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Yes, I did:

git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git


and the "what():  map::at" error is reproduced when I use that branch. So
then I checked out the uhd maint head like you but can't build it properly.
What branch of gr-ettus are you using? Did you install it after installing
the uhd maint head?

Note: I ran into similar gr-ettus build issues when I checked out the uhd
maint branch commit Michael mentioned earlier. My workaround for that was
to instead the uhd rfnoc-devel branch head then modify the
radio_ctrl_impl.hpp and radio_ctrl_impl.cpp files to match what was checked
into uhd maint branch (commit 8922095
).
So I never actually got uhd maint branch to build with with gr-ettus master
branch.

On Fri, May 11, 2018 at 7:21 PM, Louis Brown  wrote:

> Did you “git clone — recursive” then switch to the rfnoc branch?  I’m not
> using the rfnoc branch; just the normal maintenance branch, but last time I
> messed with it, you had to do that.
>
> On May 11, 2018, at 21:16, switchlanez  wrote:
>
> Wow good to know, Lou.
>
> I checked out the head of the uhd maint branch (commit 34c5610
> )
> and installed it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I
> install the head of gr-ettus master branch (commit 4ef12d
> )
> I get an error:
>
> /home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40:
> fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
> compilation terminated.
> lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target
> 'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> [ 46%] Built target ettus_swig_swig_2d0df
> Scanning dependencies of target pygen_swig_5fc0a
> [ 48%] Generating ettus_swig.pyo
> [ 51%] Generating ettus_swig.pyc
> [ 53%] Built target pygen_swig_5fc0a
> CMakeFiles/Makefile2:139: recipe for target 
> 'lib/CMakeFiles/gnuradio-ettus.dir/all'
> failed
> make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
>
> I am probably building it wrong. Does anybody know the correct way?
>
> Andrew
>
> On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:
>
>> Tried the X310 today on the maintenance branch, and the TX light
>> illuminates, but did not check for proper quadrature output.  Will check it
>> tomorrow.  Was able to do 100 Msps full duplex.
>>
>> Lou
>>
>>
>> On May 11, 2018, at 19:18, switchlanez  wrote:
>>
>> Thanks, Michael.
>>
>> So with the fix you referenced RFNoC: Radio now works in Rx mode but does
>> not seem to work work in Tx mode regardless of what's connected to its
>> input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks
>> separately). The  "what():  map::at" error is resolved so there is no
>> error message but the "TX/RX" indicator light on the X310 front panel fails
>> to light up. Has that been fixed or is a fix in progress?
>>
>> On Mon, May 7, 2018 at 9:12 AM, Michael West 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> First, maint was just updated with the fix for the LFTX and LFRX boards
>>> on X3x0.
>>>
>>> Second, yes, you can install multiple installations of UHD by setting
>>> the CMAKE_INSTALL_PREFIX different for each installation.  You will have to
>>> set the PATH and LD_LIBRARY_PATH environment variables appropriately to
>>> switch between them.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, May 4, 2018 at 11:43 AM, switchlanez 
>>> wrote:
>>>
 Thanks Michael. Do you know if I were to install rfnoc under a
 different prefix would the UHD version be able to be switched between the
 prefixes? I'm using an older rfnoc build compatible with Vivado 2015.4 and
 hesitant to install the latest build and checkout that new fix if it it
 will overwrite the older UHD version.

 On Fri, May 4, 2018 at 11:25 AM, Michael West 
 wrote:

> Hi Andrew,
>
> The fix is on the master branch (commit 8922095
> ).
> It is being included in the next set of commits on the maint branch that
> should be available in the next few days.
>
> Regards,
> Michael
>
> On Wed, May 2, 2018 at 1:13 PM, switchlanez 
> wrote:
>
>> Hi Michael,
>>
>> I see new commits have been entered in the uhd maint branch in the
>> last couple days. Were any related to this issue?
>>
>> Andrew
>>
>> On Mon, Apr 23, 2018 at 11:12 AM, Michael West <
>> michael.w...@ettus.com> wrote:
>>
>>> Hi Louis/Andrew,

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

I built from a fresh clone with the normal:



git clone https://github.com/EttusResearch/uhd

cd uhd/host/
mkdir build

cd build

cmake ../

make -j8

make test

sudo make install

sudo ldconfig



Then rebuilt gnuradio after that since they said the ABI changed.


Lou




On May 11, 2018, at 09:43 PM, switchlanez  wrote:


Yes, I did:
git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git



and the "what():  map::at" error is reproduced when I use that branch. So then 
I checked out the uhd maint head like you but can't build it properly. What branch of 
gr-ettus are you using? Did you install it after installing the uhd maint head?


Note: I ran into similar gr-ettus build issues when I checked out the uhd maint 
branch commit Michael mentioned earlier. My workaround for that was to instead 
the uhd rfnoc-devel branch head then modify the radio_ctrl_impl.hpp and 
radio_ctrl_impl.cpp files to match what was checked into uhd maint branch 
(commit 8922095). So I never actually got uhd maint branch to build with with 
gr-ettus master branch.



On Fri, May 11, 2018 at 7:21 PM, Louis Brown  wrote:



Did you “git clone — recursive” then switch to the rfnoc branch?  I’m not using 
the rfnoc branch; just the normal maintenance branch, but last time I messed 
with it, you had to do that.

On May 11, 2018, at 21:16, switchlanez  wrote:


Wow good to know, Lou.

I checked out the head of the uhd maint branch (commit 34c5610) and installed it (set 
"ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I install the head of 
gr-ettus master branch (commit 4ef12d) I get an error:

/home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40: 
fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
compilation terminated.
lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target 
'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs
[ 46%] Built target ettus_swig_swig_2d0df
Scanning dependencies of target pygen_swig_5fc0a
[ 48%] Generating ettus_swig.pyo
[ 51%] Generating ettus_swig.pyc
[ 53%] Built target pygen_swig_5fc0a
CMakeFiles/Makefile2:139: recipe for target 
'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2


I am probably building it wrong. Does anybody know the correct way?


Andrew



On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:



Tried the X310 today on the maintenance branch, and the TX light illuminates, 
but did not check for proper quadrature output.  Will check it tomorrow.  Was 
able to do 100 Msps full duplex.


Lou



On May 11, 2018, at 19:18, switchlanez  wrote:


Thanks, Michael.



So with the fix you referenced RFNoC: Radio now works in Rx mode but does not seem to work work in 
Tx mode regardless of what's connected to its input (I've tried GNU Radio's in-tree Signal Source 
then Null Source blocks separately). The  "what():  map::at" error is resolved so there 
is no error message but the "TX/RX" indicator light on the X310 front panel fails to 
light up. Has that been fixed or is a fix in progress?



On Mon, May 7, 2018 at 9:12 AM, Michael West  wrote:

Hi Andrew,


First, maint was just updated with the fix for the LFTX and LFRX boards on X3x0.


Second, yes, you can install multiple installations of UHD by setting the 
CMAKE_INSTALL_PREFIX different for each installation.  You will have to set the 
PATH and LD_LIBRARY_PATH environment variables appropriately to switch between 
them.


Regards,

Michael



On Fri, May 4, 2018 at 11:43 AM, switchlanez  wrote:

Thanks Michael. Do you know if I were to install rfnoc under a different prefix 
would the UHD version be able to be switched between the prefixes? I'm using an 
older rfnoc build compatible with Vivado 2015.4 and hesitant to install the 
latest build and checkout that new fix if it it will overwrite the older UHD 
version.



On Fri, May 4, 2018 at 11:25 AM, Michael West  wrote:

Hi Andrew,


The fix is on the master branch (commit 8922095).  It is being included in the 
next set of commits on the maint branch that should be available in the next 
few days.


Regards,

Michael



On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:

Hi Michael,


I see new commits have been entered in the uhd maint branch in the last couple 
days. Were any related to this issue?


Andrew



On Mon, Apr 23, 2018 at 11:12 AM, Michael West  wrote:

Hi Louis/Andrew,


The root cause of the issue has been identified and a fix is in progress.  We 
should have the fix available on the head of the maint branch very soon.  Thank 
you for bringing it to our attention!


Regards,

Michael



On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users 
 wrote:

I have an issue that may be related. Using LFTX and LFRX boards in an