Re: [USRP-users] Differences between LOs: companion, internal, external.

[Anabel Almodovar via USRP-users]

Dear Marcus,

Thank you very much, now I see it clearer. In case I had to connect several
x310s with the same LO, as shown in the image, if I indicate that channel 1
exports and works as internal mode then channel 1 wouldn't use the LO that
comes from LO in? if I haven't misunderstood, channel 1 should be in
companion mode and all other channels (for all x310) in external mode,
right? with this configuration channel 1 can generate the LO but make use
of the signal coming from the spliter.

[image: share_LO.png]
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Calculate packet error rate using rx-ofdm

[dapodun nudopad via USRP-users]

Hello,
I am currently working with USRP for the gr-digital ofdm rx and tx. I want
to know any reasonable way to calculate the packet error rate. I am using
the signal source at the transmit side while I am planning to get the loss
in packet at the receiver side. Currently, i looked at a dated back to 2015
discussion on this but it says using the packet_len in header formatter by
multiplying it by 10,000 which is 96 * 10,000. However, this gave me an
error and i could not see any FFT signal being transmitted. I even tried to
increase my buffer size but the problem is still persistent. I Supposedly,
the packet error rate should be derived from ratio of received packet
divided by the packet_len.
Therefore, I would be grateful if anyone can suggest a detail way to
calculate the packet loss or show an alternative to getting a reasonable
metrics here.
Thanks. Regards
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Serge Malo via USRP-users]

Hi all,

any news on this saturation issue concerning the N310 with UHD 3.13.0.3 RC1?
I would like to know if Ettus is aware of this problem, and if a new UHD
version is coming with a correction?

Thanks!

Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - -
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol 
Avis : Ce message est confidentiel et protégé par le secret professionnel.
Si vous n'êtes pas le destinataire, veuillez informer l'expéditeur par
courriel immédiatement et effacer ce message et en détruire toute copie. /
Notice: This message is confidential and privileged. If you are not the
addressee, please inform the sender by return e-mail immediately and delete
this message and destroy all copies.


On Wed, 17 Oct 2018 at 16:53, Ali Dormiani via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Attempt 2. Sorry for breaking mailing list rules with the attachments.
> Here is a google drive link to the screenshots, GRC file, and binary files.
> (3 MB zip)
>
>
> https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing
>
> We have three sliders in GNUradio.
>
> 1. TX gain
>
> 2. RX gain
>
> 3. Digital Gain (multiply constant block between our binary file and the
> UHD block.
>
> We also have one TX connected directly to an RX with a 30 dB analog
> attenuation for safety.
>
> Our binary files were generated in MATLAB and are normalized to unity
> magnitude.
>
> Attached, please find the GRC file and our binary files. For reference,
> the waveform we made is a multitone signal so it should be a bunch of
> evenly spaced spikes. I have included some screenshots too. Additionally we
> have verified this strange behavior with a spectrum analyzer.
> By playing around with the sliders you can see how narrow the zone is for
> good results. Intuitivly it seems like TX and RX gain don't really matter.
> They just shift the narrow usability zone for Digital gain.
>
> On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani 
> wrote:
>
>> We have three sliders in GNUradio.
>>
>> 1. TX gain
>>
>> 2. RX gain
>>
>> 3. Digital Gain (multiply constant block between our binary file and the
>> UHD block.
>>
>> We also have one TX connected directly to an RX with a 30 dB analog
>> attenuation for safety.
>>
>> Our binary files were generated in MATLAB and are normalized to unity
>> magnitude.
>>
>> Attached, please find the GRC file and our binary files. For reference,
>> the waveform we made is a multitone signal so it should be a bunch of
>> evenly spaced spikes. I have included some screenshots too. Additionally we
>> have verified this strange behavior with a spectrum analyzer.
>> By playing around with the sliders you can see how narrow the zone is for
>> good results. Intuitivly it seems like TX and RX gain don't really matter.
>> They just shift the narrow usability zone for Digital gain.
>>
>>
>>
>> On Wed, Oct 10, 2018 at 6:20 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 10/10/2018 03:08 PM, Ali Dormiani via USRP-users wrote:
>>>
>>> Hello,
>>>
>>> We have the exact same problem. My lab is waiting on some sfp+ cables so
>>> in a few days I will share our screenshots, code, and data binary files in
>>> order to provide this thread with a second example of this issue. For now,
>>> all I can say is this problem is not isolated to your N310 or Windows.
>>>
>>> We have two N310's running with the same version of UHD (and GNUradio
>>> 3.7.13.4) on Linux kernel 4.18. By using amplitude sliders in GNUradio we
>>> found that there is a very small and strange gain "Goldilocks" zone around
>>> .002 that gives good results. Going higher starts to raise the noise floor
>>> until all signal definition is gone.
>>>
>>> Ali Dormiani
>>> UCSD Noiselab
>>>
>>> What is your RF gain set to in these examples?  Does that change things?
>>>
>>> If you raise things to a level where non-linearity is apparent, does
>>> placing a 10dB attenuator in-line fix it (trying to distinguish between
>>>   the transmitter being non-linear, and your receiver/spectrum analyser).
>>>
>>>
>>>
>>> On Wed, Oct 10, 2018 at 11:33 AM Mathieu Lizée via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi,

 When using the UHD "tx_waveforms" example, I can see that the signal
 emitted by my N310 USRP is saturated when it’s not supposed to be.

 Here's a snapshot of the signal when I set the amplitude to 0.003:
 .\tx_waveforms.exe --rate 12.5e6 --nsamps 125000 --freq 1575.42e6
 --ampl 0.003 --otw sc16 --wave-type SINE --wave-freq 10e3 --channels 2

 [image: tx_waveforms_3e-3_amp]
 

 Here's a snapshot of the signal when I set the amplitude to 0.03:
 .\tx_waveforms.e

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Lundberg, Daniel via USRP-users]

I think I am seeing the same or a similar problem using the latest master 
(which I think is roughly equivalent to 3.13.0.3 RC1, correct me if I am wrong) 
on an N310.
When I save a signed 16-bit binary file and feed it into the 
replay_sample_from_file example, I can only provide it with a full-scale 
amplitude of ~8 bits in amplitude (+/- 2^8-1), or I get saturation / strange 
corruption of the waveform.  Changing the gain does not seem to have any 
effect.  The N310 is supposed to have a 14-bit DAC, and conversations with 
Ettus imply that the replay block is too simple to cause this, so the problem 
is probably pretty far upstream?  I have described the problem to Ettus, and 
they suggested checking most of the things you and I have already tested 
(gains, input files, etc…).

From: USRP-users  On Behalf Of Serge Malo 
via USRP-users
Sent: Monday, October 29, 2018 9:55 AM
To: sdorm...@eng.ucsd.edu
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Hi all,

any news on this saturation issue concerning the N310 with UHD 3.13.0.3 RC1?
I would like to know if Ettus is aware of this problem, and if a new UHD 
version is coming with a correction?

Thanks!

Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - -
Serge Malo
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol
Avis : Ce message est confidentiel et protégé par le secret professionnel. Si 
vous n'êtes pas le destinataire, veuillez informer l'expéditeur par courriel 
immédiatement et effacer ce message et en détruire toute copie. / Notice: This 
message is confidential and privileged. If you are not the addressee, please 
inform the sender by return e-mail immediately and delete this message and 
destroy all copies.


On Wed, 17 Oct 2018 at 16:53, Ali Dormiani via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Attempt 2. Sorry for breaking mailing list rules with the attachments. Here is 
a google drive link to the screenshots, GRC file, and binary files. (3 MB zip)

https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing

We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.

On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani 
mailto:sdorm...@eng.ucsd.edu>> wrote:
We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.



On Wed, Oct 10, 2018 at 6:20 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
On 10/10/2018 03:08 PM, Ali Dormiani via USRP-users wrote:
Hello,

We have the exact same problem. My lab is waiting on some sfp+ cables so in a 
few days I will share our screenshots, code, and data binary files in order to 
provide this thread with a second example of this issue. For now, all I can say 
is this problem is not isolated to your N310 or Windows.

We have two N310's running with the same version of UHD (and GNUradio 3.7.13.4) 
on Linux kernel 4.18. By using amplitude sliders in GNUradio we found that 
there is a very small and strange gain "Goldilocks" zone around .002 that gives 
good results. Going higher starts to raise the noise floor until all signal 
definition is gone.

Ali Dormiani
UCSD Noiselab
What is your RF gain set to in these examples?  Does that change things?

If you raise things to a level where non-linearity is apparent, does 

Re: [USRP-users] Differences between LOs: companion, internal, external.

[Marcus D. Leech via USRP-users]

On 10/29/2018 06:39 AM, Anabel Almodovar via USRP-users wrote:

Dear Marcus,

Thank you very much, now I see it clearer. In case I had to connect 
several x310s with the same LO, as shown in the image, if I indicate 
that channel 1 exports and works as internal mode then channel 1 
wouldn't use the LO that comes from LO in? if I haven't misunderstood, 
channel 1 should be in companion mode and all other channels (for all 
x310) in external mode, right? with this configuration channel 1 can 
generate the LO but make use of the signal coming from the spliter.


share_LO.png

Indeed, if a channel is marked "internal", it's getting its LO from its 
internal PLL synthesizer.


There's no provision in the X310 design to bring an LO in from outside 
the box, but in theory it should work.



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

[USRP-users] RFNoC Replay block for E310?

[Rob Kossler via USRP-users]

Hi,
I have successfully compiled & used the RFNoC replay block with an X310.
Now, I would like to do the same with an E310.  After some quick
investigation, I noticed that the "use_replay" logic has been included in
both "n3xx_core.v" and "x300_core.v" but not in "e310_core.v" or any other
E310 verilog files.  I also noticed that application note AN-642, Using the
RFNoC Replay Block ,
specifically mentions support for the X300/X310 and N310, but no mention of
the E310.

I'm wondering if I just need to modify "e310_core.v" to implement similar
logic to that in "n3xx_core.v" and/or "x300_core.v" in order to get this
working on the E310?  Or, is there some reason that this will not work such
that I am wasting my time?

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

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Daniel May via USRP-users]

All,

Can anyone else reproduce this issue and/or suggest a solution?

This is happening over the Ethernet interface as well. Application exits,
Tx light stays on, relaunching application causes X310 to enter an
unrecoverable state and requires power cycling. It looks like an issue with
initializing DMA. Tested using v3.13.0.1.

Thanks,
Daniel

On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
usrp-users@lists.ettus.com> wrote:

> All,
>
>
>
> I am using an Ettus x310 over PCIe and am noticing that there is a delay
> from when my program finished sending to the radio and when the radio tells
> me that transmission as ended ( the red Tx light turning off).
>
> As I bump up the sample rate I notice this delay decreases until it is
> nonexistent. Is this intended behavior or have I done something wrong in my
> tests? The procedure to test this is listed below:
>
>
>
> 1.   Download a copy of the official UHD example scripts from
> https://github.com/EttusResearch/uhd/tree/master/host/examples
>
> 2.   Ensure that UHD is installed correctly on your testing device
> and build the example programs above
>
> 3.   Run the following command “ ./tx_waveforms - -rate=100 -
> -freq=15
>
> 4.   Stop the program at any time (how long the radio is running does
> not affect the delay)
>
> 5.   Observe the radio and notice that the red light under the Tx/Rx
> port is still lit on the RF A channel
>
> 6.   If you start another transmission while the light is still red,
> the console output contains hundreds of thousands of L’s and the radio will
> not receive data until the USRP object is recreated.
>
>
>
> I am also curious if there is a hard stop functionality for this radio.
> All the examples I have seen send an End of Burst packet but is there a way
> to completely halt the radio without doing this?
>
>
>
> Thanks for the help!
>
> Andrew
> ___
> 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] Building N310 replay example

[Rob Kossler via USRP-users]

Hi Wade,
I see that a new rfnoc_ce_auto_inst_n310.v has been committed to github to
address this issue (commit 8b37fd8).  But, I don't see what good this will
do given that this file is auto-generated by the uhd_image_builder.py
script which will just overwrite this file.  Additionally, the script will
insert the following two lines rather than the ones you used.  Will this
work as well?
wire ce_clk = radio_clk;
wire ce_rst = radio_rst;

Rob

On Fri, Oct 19, 2018 at 12:48 PM Wade Fife via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dan,
>
> The UHD exception you saw appears to be due to ce_clk and ce_rst not be
> connected in the RFNoC variant that you built (N310_RFNOC_HG; it works in
> N310_HG). You can fix this for now by connecting them in
> rfnoc_ce_auto_inst_n310.v (see diff below, or refer to
> rfnoc_ce_default_inst_n310.v as an example of how to set ce_clk and
> ce_rst). I'll look into getting this fixed permanently.
>
> diff --git a/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
> b/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
> index 176dad48..e61038d7 100644
> --- a/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
> +++ b/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
> @@ -14,6 +14,9 @@
>  end
>endgenerate
>
> +  wire ce_clk = bus_clk;
> +  wire ce_rst = bus_rst;
> +
>noc_block_ddc #(.NOC_ID(64'hDDC0___0001), .NUM_CHAINS(1))
> inst_noc_block_ddc (
>  .bus_clk(bus_clk), .bus_rst(bus_rst),
>  .ce_clk(ce_clk), .ce_rst(ce_rst),
>
> Thanks,
>
> Wade
>
>
> On Thu, Oct 18, 2018 at 4:06 PM Lundberg, Daniel <
> daniel.lundb...@gtri.gatech.edu> wrote:
>
>> I tried nuking everything and doing a clean install of the master branch,
>> but still get the same errors.  Here’s a couple of warnings I did not copy
>> in my first e-mail that occur when running the uhd_image_loader with the
>> new fpga .bit:
>>
>>
>>
>> [WARNING] [MPMD IMAGE LOADER] RuntimeError:  Component file does not
>> exist: /path to build/n3xx.dts
>>
>> [WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected
>> compat for component ‘FPGA’.  Expect 5.2 Actual: 5.3
>>
>>
>>
>> The second one seems to indicate a minor mismatch between the UHD master
>> and the FPGA .bit, correct?
>>
>>
>>
>> *From:* Wade Fife 
>> *Sent:* Thursday, October 18, 2018 11:37 AM
>> *To:* Lundberg, Daniel 
>> *Cc:* usrp-users 
>> *Subject:* Re: [USRP-users] Building N310 replay example
>>
>>
>>
>> Hi Dan,
>>
>>
>>
>> I'll see if I can reproduce this with the current master. In the meantime
>> I suggest just double checking that the fpga-src submodule is also up to
>> date. Currently, uhd master is at 7130059 and fpga should be at 340bb07. I
>> know that error would occur with older versions of the FPGA code.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Wade
>>
>>
>>
>> On Thu, Oct 18, 2018 at 9:38 AM Lundberg, Daniel via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> I am trying to to work with the RFNoc replay block on an N310.  I have
>> followed the instructions here:
>> https://kb.ettus.com/Using_the_RFNoC_Replay_Block
>>
>>
>>
>> I have Ubuntu 18.04, and the current master branch of UHD.
>>
>>
>>
>> Those instructions are for the X3xx, but I tried modifying them for the
>> N310, by doing “make N310_RFNOC_HG” after changing to “USE_REPLAY=1”
>>
>> This build of the n3xx.bit completed with no errors, but with 67
>> “critical warnings.  I attempted to forge on anyways, but the
>> uhd_image_loader has several errors (copied at the end of this message).
>>
>>
>>
>> My question is whether or not anyone has successfully enabled the replay
>> block on an N310 with the current master build?  I have not intentionally
>> deviated from the prescribed script in any way to get to this point, so I
>> am a bit lost on how to proceed.
>>
>>
>>
>> Thank you,
>>
>> Dan
>>
>>
>>
>> [ERROR] [UHD] Exception caught in safe-call.
>>
>>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
>> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>>
>>   at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
>>
>> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
>> (CE_03_Port_60) no response packet - AssertionError: bool(buff)
>>
>>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
>> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
>> unsigned int]
>>
>>   at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>>
>>
>>
>> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
>> IOError: Block ctrl (CE_03_Port_60) no response packet - AssertionError:
>> bool(buff)
>>
>>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
>> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
>> unsigned int]
>>
>>   at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>>
>>
>>
>> terminate called after throwing an instance of 'uhd::io_error'
>>
>>   what():  EnvironmentError: IOError: [0/Replay_0] sr_write() failed:

Re: [USRP-users] Building N310 replay example

[Wade Fife via USRP-users]

Rob,

You are correct, the FPGA change is only part of the fix. There will be a
fix to the script as well. Either clock can work, but about 8 months ago
the clock was changed from radio_clk to bus_clk for the default instance.

Thanks,

Wade

On Mon, Oct 29, 2018 at 4:37 PM Rob Kossler  wrote:

> Hi Wade,
> I see that a new rfnoc_ce_auto_inst_n310.v has been committed to github to
> address this issue (commit 8b37fd8).  But, I don't see what good this will
> do given that this file is auto-generated by the uhd_image_builder.py
> script which will just overwrite this file.  Additionally, the script will
> insert the following two lines rather than the ones you used.  Will this
> work as well?
> wire ce_clk = radio_clk;
> wire ce_rst = radio_rst;
>
> Rob
>
> On Fri, Oct 19, 2018 at 12:48 PM Wade Fife via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dan,
>>
>> The UHD exception you saw appears to be due to ce_clk and ce_rst not be
>> connected in the RFNoC variant that you built (N310_RFNOC_HG; it works in
>> N310_HG). You can fix this for now by connecting them in
>> rfnoc_ce_auto_inst_n310.v (see diff below, or refer to
>> rfnoc_ce_default_inst_n310.v as an example of how to set ce_clk and
>> ce_rst). I'll look into getting this fixed permanently.
>>
>> diff --git a/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
>> b/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
>> index 176dad48..e61038d7 100644
>> --- a/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
>> +++ b/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v
>> @@ -14,6 +14,9 @@
>>  end
>>endgenerate
>>
>> +  wire ce_clk = bus_clk;
>> +  wire ce_rst = bus_rst;
>> +
>>noc_block_ddc #(.NOC_ID(64'hDDC0___0001), .NUM_CHAINS(1))
>> inst_noc_block_ddc (
>>  .bus_clk(bus_clk), .bus_rst(bus_rst),
>>  .ce_clk(ce_clk), .ce_rst(ce_rst),
>>
>> Thanks,
>>
>> Wade
>>
>>
>> On Thu, Oct 18, 2018 at 4:06 PM Lundberg, Daniel <
>> daniel.lundb...@gtri.gatech.edu> wrote:
>>
>>> I tried nuking everything and doing a clean install of the master
>>> branch, but still get the same errors.  Here’s a couple of warnings I did
>>> not copy in my first e-mail that occur when running the uhd_image_loader
>>> with the new fpga .bit:
>>>
>>>
>>>
>>> [WARNING] [MPMD IMAGE LOADER] RuntimeError:  Component file does not
>>> exist: /path to build/n3xx.dts
>>>
>>> [WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected
>>> compat for component ‘FPGA’.  Expect 5.2 Actual: 5.3
>>>
>>>
>>>
>>> The second one seems to indicate a minor mismatch between the UHD master
>>> and the FPGA .bit, correct?
>>>
>>>
>>>
>>> *From:* Wade Fife 
>>> *Sent:* Thursday, October 18, 2018 11:37 AM
>>> *To:* Lundberg, Daniel 
>>> *Cc:* usrp-users 
>>> *Subject:* Re: [USRP-users] Building N310 replay example
>>>
>>>
>>>
>>> Hi Dan,
>>>
>>>
>>>
>>> I'll see if I can reproduce this with the current master. In the
>>> meantime I suggest just double checking that the fpga-src submodule is also
>>> up to date. Currently, uhd master is at 7130059 and fpga should be at
>>> 340bb07. I know that error would occur with older versions of the FPGA code.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Wade
>>>
>>>
>>>
>>> On Thu, Oct 18, 2018 at 9:38 AM Lundberg, Daniel via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>> I am trying to to work with the RFNoc replay block on an N310.  I have
>>> followed the instructions here:
>>> https://kb.ettus.com/Using_the_RFNoC_Replay_Block
>>>
>>>
>>>
>>> I have Ubuntu 18.04, and the current master branch of UHD.
>>>
>>>
>>>
>>> Those instructions are for the X3xx, but I tried modifying them for the
>>> N310, by doing “make N310_RFNOC_HG” after changing to “USE_REPLAY=1”
>>>
>>> This build of the n3xx.bit completed with no errors, but with 67
>>> “critical warnings.  I attempted to forge on anyways, but the
>>> uhd_image_loader has several errors (copied at the end of this message).
>>>
>>>
>>>
>>> My question is whether or not anyone has successfully enabled the replay
>>> block on an N310 with the current master build?  I have not intentionally
>>> deviated from the prescribed script in any way to get to this point, so I
>>> am a bit lost on how to proceed.
>>>
>>>
>>>
>>> Thank you,
>>>
>>> Dan
>>>
>>>
>>>
>>> [ERROR] [UHD] Exception caught in safe-call.
>>>
>>>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
>>> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>>>
>>>   at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
>>>
>>> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
>>> (CE_03_Port_60) no response packet - AssertionError: bool(buff)
>>>
>>>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
>>> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
>>> unsigned int]
>>>
>>>   at /home/epuser/workarea-uhd/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>>>
>>>
>>>
>>> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
>>> IOError: Block ctrl (CE_03_

[USRP-users] RFNoC build issue for OOT block

[Rob Kossler via USRP-users]

Hi,
I am having trouble building an image with an OOT block for the N310.  The
build error is provided below (highlighted in YELLOW). Essentially, the OOT
source code is not found.  This happens even on the latest master branch.
However, there is no issue if I target the X310 instead.

I think that there is a bug in the build process.  I noticed a recent
commit where there was a line missing from the makefile, but I still get
the error after fixing this.  Any suggestions?
Rob


irisheyes5@irisheyes5-hp-z240-sff:~/rfnoc/src/uhd-fpga/usrp3/tools/scripts$
./uhd_image_builder.py blk1 -I $HOME/rfnoc/rfnoc-rob/ -d n310 -t
N310_RFNOC_HG
--Using the following blocks to generate image:
* blk1
Adding CE instantiation file for 'N310_RFNOC_HG'
changing temporarily working directory to
/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/n3xx
Setting up a 64-bit FPGA build environment for the USRP-N3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)

Environment successfully initialized.
make -f Makefile.n3xx.inc bin NAME=N310_RFNOC_HG ARCH=zynq
PART_ID=xc7z100/ffg900/-2 SFP0_1GBE=1   SFP1_10GBE=1  BUILD_1G=1
BUILD_10G=1 RFNOC=1 N310=1 TOP_MODULE=n3xx EXTRA_DEFS="SFP0_1GBE=1
SFP1_10GBE=1  BUILD_1G=1 BUILD_10G=1 RFNOC=1 N310=1"
make[1]: Entering directory
'/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx'
BUILDER: Checking tools...
* GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.12
* Vivado v2017.4 (64-bit)
Using parser configuration from:
/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/dev_config.json
[00:00:00] Executing command: vivado -mode batch -source
/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build_n3xx.tcl -log
build.log -journal n3xx.jou
CRITICAL WARNING: [filemgmt 20-1440] File
'/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/ddr3_32bit/ddr3_32bit/user_design/rtl/clocking/mig_7series_v4_0_tempmon.v'
already exists in the project as a part of sub-design file
'/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/ddr3_32bit/ddr3_32bit.xci'.
Explicitly adding the file outside the scope of the sub-design can lead to
unintended behaviors and is not recommended.
[00:00:18] Current task: Initialization +++ Current Phase: Starting
[00:00:18] Current task: Initialization +++ Current Phase: Finished
[00:00:18] Executing Tcl: synth_design -top n3xx -part xc7z100ffg900-2
-verilog_define SFP0_1GBE=1 -verilog_define SFP1_10GBE=1 -verilog_define
BUILD_1G=1 -verilog_define BUILD_10G=1 -verilog_define RFNOC=1
-verilog_define N310=1 -verilog_define GIT_HASH=32'hfebf5eed
[00:00:18] Starting Synthesis Command
CRITICAL WARNING: [Synth 8-2490] overwriting previous definition of module
ram_2port
[/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/n310_ps_bd/n310_ps_bd/control/ram_2port.v:12]
CRITICAL WARNING: [Synth 8-2490] overwriting previous definition of module
cvita_dest_lookup
[/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/n310_ps_bd/n310_ps_bd/packet_proc/cvita_dest_lookup.v:11]
CRITICAL WARNING: [Synth 8-2490] overwriting previous definition of module
cvita_chunker
[/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/build-ip/xc7z100ffg900-2/n310_ps_bd/n310_ps_bd/packet_proc/cvita_chunker.v:15]
ERROR: [Synth 8-439] module 'noc_block_blk1' not found
[/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/rfnoc_ce_auto_inst_n310.v:22]
ERROR: [Synth 8-285] failed synthesizing module 'n3xx_core'
[/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/n3xx_core.v:17]
ERROR: [Synth 8-285] failed synthesizing module 'n3xx'
[/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
[00:05:09] Current task: Synthesis +++ Current Phase: Starting
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the
console or run log file for details
[00:05:09] Current task: Synthesis +++ Current Phase: Finished
[00:05:09] Process terminated. Status: Failure


Warnings:   321
Critical Warnings:  4
Errors: 4

Makefile.n3xx.inc:118: recipe for target 'bin' failed
make[1]: *** [bin] Error 1
make[1]: Leaving directory
'/home/irisheyes5/rfnoc/src/uhd-fpga/usrp3/top/n3xx'
Makefile:125: recipe for target 'N310_RFNOC_HG' failed
make: *** [N310_RFNOC_HG] Error 2
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N210 transmits and receives using the same antenna

[Huacheng Zeng via USRP-users]

Hi All:

I am using N210 (with SBX daughter board) to test the channel reciprocity.
I wish to transmit signal using antenna "Tx/Rx" in time slot 1, and then
receive signal using the same antenna in time slot 2, and so on so forth.

I can do this manually, but do not know how to do it by programming (either
using GR or OOT C++ blocks). Any one can help?

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