Re: [USRP-users] [EXTERNAL] B205mini: Setting Q signal component to zero distorts the I component

[Varban Metodiev via USRP-users]

zero out the Q and
> plot the I you would get this aliasing.  If you were to zero out the I and
> plot the Q, you would also get this aliasing.  If you add them together,
> the real parts make the whole sine wave.  It just shifts, like water, back
> and forth from the I and Q, periodically, directly proportional to the
> under sampling.
>
>
>
> Try a few different scenarios, (locked clock, unlocked clock, under
> sampled, oversampled, etc.) and observe how it changes.
>
>
>
> In QAM signals the first thing you need to do is estimate clock drift and
> then de-rotate your signal.  You do these things periodically so that you
> can track and properly sample the incoming signal.
>
>
>
> Best of luck!
>
>
> Thanks,
> Nicholas
>
>
>
>
>
> *From:* USRP-users *On Behalf Of *Varban Metodiev via USRP-users
> *Sent:* Monday, March 09, 2020 7:14 AM
> *To:* usrp-users 
> *Subject:* [EXTERNAL] [USRP-users] B205mini: Setting Q signal component
> to zero distorts the I component
>
>
>
> Dear all,
>
>
>
> I have two B205mini devices. One of those is my transmitting side and the
> other one is the receiver. Both are connected via a cable (and an
> attenuator, of course).
>
>
>
> Here is what I execute on the receiver:
>
> *rx_samples_to_file --freq 433e6 --rate 2e6 --bw 1e6 --gain 0 --nsamps 0
> --spb 200*
>
>
>
> And on the transmitter:
>
> *tx_waveforms --rate 1e6 --freq 433e6 --ampl 0.6 --gain 70 --bw 1e6
> --wave-type SINE --wave-freq 10e3 --spb 100 --otw sc16*
>
>
>
> The results are being read in GNU Octave:
>
> *samples_file=fopen('/home/vmetodiev/Development/SDR/uhd/host/build/examples/usrp_samples.dat',
> 'rb');*
> *data=fread(samples_file, 'int16');*
>
>
>
> So... when both I/Q channels carry the sines that are generated by the
> wave_table function, the results looks fine - attachment "iq.png".
>
>
>
> However, I need to work only with the I channel and force the Q to
> *disappear*, that is why I added the following lines in the
> *tx_waveforms.cpp* code to zero it:
>
>
>
> // Zero the Q component
>
> for (size_t n = 0; n < buff.size(); n++) {
>
> buff[n] = std::complex( buff[n].real(), *0 *);
>
> }
>
>
>
> And the result is a strangely distorted I-component sine - attachment
> "i_only.png".
>
>
>
> May you please advise if it is possible to avoid this, because I am doing
> something a bit strange that is not related to the normal I/Q modulations?
>
>
>
> Thanks in advance,
>
> V.
>
>
>
>
>
>
>
>
>
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [EXTERNAL] B205mini: Setting Q signal component to zero distorts the I component

[Varban Metodiev via USRP-users]

Hi Nicholas,

Thanks a lot for your explanations! I tried to increase the sampling rate
at the receiver - the sine changed itself again and I still have the  same
amplitude differences (attached below).
Another problem that I observed is that it works fine only at 433MHz. When
I tried to set 868MHz/915MHz it became even less readable. At 2.4GHz and
5GHz it was looked like noise...

So...

Try a few different scenarios, (locked clock, unlocked clock, under
sampled, oversampled, etc.) and observe how it changes.

---> May you please tell me a bit more about those locked and unlocked
clocks?


Thanks again,

Varban


On Mon, Mar 9, 2020 at 9:16 AM Linnenkamp, Nicholas <
nlinnenk...@perspectalabs.com> wrote:

> V.
>
>
>
> I could be wrong…
>
>
>
> It appears that you are under sampling on the receive USRP.  This is
> probably due to the transmitter and the receiver not sharing the same clock
> and the receiver is drifting (slower).  You can have the two USRPs share
> the same 10Mhz clock to remove this problem but it is present in every QAM
> communication system.  Distributed systems don’t have the benefit of common
> clock even with GPS so it is something that everyone deals with eventually.
>
>
>
> This is a good picture of when you under sample and get aliasing.
>
>
>
>
> https://dsp.stackexchange.com/questions/31899/how-do-you-simultaneously-undersample-and-oversample
>
>
>
> This is one of the best treatments of QAM signals that I have ever read.
>
>
>
>
> https://mriquestions.com/uploads/3/4/5/7/34572113/quad_signals_tutorial-lyons.pdf
>
>
>
> The real part of the signal is getting shifted from the In Phase to the
> Quadrature and back again over time.  If you were to zero out the Q and
> plot the I you would get this aliasing.  If you were to zero out the I and
> plot the Q, you would also get this aliasing.  If you add them together,
> the real parts make the whole sine wave.  It just shifts, like water, back
> and forth from the I and Q, periodically, directly proportional to the
> under sampling.
>
>
>
> Try a few different scenarios, (locked clock, unlocked clock, under
> sampled, oversampled, etc.) and observe how it changes.
>
>
>
> In QAM signals the first thing you need to do is estimate clock drift and
> then de-rotate your signal.  You do these things periodically so that you
> can track and properly sample the incoming signal.
>
>
>
> Best of luck!
>
>
> Thanks,
> Nicholas
>
>
>
>
>
> *From:* USRP-users *On Behalf Of *Varban Metodiev via USRP-users
> *Sent:* Monday, March 09, 2020 7:14 AM
> *To:* usrp-users 
> *Subject:* [EXTERNAL] [USRP-users] B205mini: Setting Q signal component
> to zero distorts the I component
>
>
>
> Dear all,
>
>
>
> I have two B205mini devices. One of those is my transmitting side and the
> other one is the receiver. Both are connected via a cable (and an
> attenuator, of course).
>
>
>
> Here is what I execute on the receiver:
>
> *rx_samples_to_file --freq 433e6 --rate 2e6 --bw 1e6 --gain 0 --nsamps 0
> --spb 200*
>
>
>
> And on the transmitter:
>
> *tx_waveforms --rate 1e6 --freq 433e6 --ampl 0.6 --gain 70 --bw 1e6
> --wave-type SINE --wave-freq 10e3 --spb 100 --otw sc16*
>
>
>
> The results are being read in GNU Octave:
>
> *samples_file=fopen('/home/vmetodiev/Development/SDR/uhd/host/build/examples/usrp_samples.dat',
> 'rb');*
> *data=fread(samples_file, 'int16');*
>
>
>
> So... when both I/Q channels carry the sines that are generated by the
> wave_table function, the results looks fine - attachment "iq.png".
>
>
>
> However, I need to work only with the I channel and force the Q to
> *disappear*, that is why I added the following lines in the
> *tx_waveforms.cpp* code to zero it:
>
>
>
> // Zero the Q component
>
> for (size_t n = 0; n < buff.size(); n++) {
>
> buff[n] = std::complex( buff[n].real(), *0 *);
>
> }
>
>
>
> And the result is a strangely distorted I-component sine - attachment
> "i_only.png".
>
>
>
> May you please advise if it is possible to avoid this, because I am doing
> something a bit strange that is not related to the normal I/Q modulations?
>
>
>
> Thanks in advance,
>
> V.
>
>
>
>
>
>
>
>
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Polling the "sample_rx" via a user defined register (B205mini)

[Varban Metodiev via USRP-users]

Hi Jonathon,

Please ignore my last email, I had a serious mistake with the TX gain
configuration...

Anyway, thanks again for the directions you provided. It was really helpful!

Best,
V.

On Mon, Mar 2, 2020 at 1:33 PM Varban Metodiev 
wrote:

> Hi Jonathon,
>
> After separating the I and Q channels, I think that the values with
> detached RX input look reasonable (please see *I_Q_data_custom_build.txt*).
> What do you think?
> I am reading my custom register with a modified version of
> *rx_samples_to_file* (attached as well, line 92 - 100).
>
> Now, when I try to send some reference sine waves via the *tx_waveforms*
> example running on another PC attached to another USRP B205mini, I get
> unexplainable data.
> The default data type in the *tx_waveforms* is fc32, do I need to
> recompile it with sc16 for this case?
>
> Kind regards,
> V.
>
> On Wed, Feb 26, 2020 at 1:36 AM Varban Metodiev 
> wrote:
>
>> Hi Jonathon,
>>
>> Thank you very much for your reply.
>>
>> What do you want to accomplish?
>> --> Right now, I just want to monitor the 'sample_rx' values. Eventually,
>> I will use this to calibrate the reference input of my custom Verilog
>> decoder (attached) that aims to detect spikes and measure their length
>> (like those from the attachment).
>>
>> It is a short complex int where the upper 16-bits are I and the lower
>> 16-bits are Q.
>> --> Well... that could be the explanation. I will try to monitor them
>> separately and get back to you.
>>
>> Kind regards,
>> Varban
>>
>> On Tue, Feb 25, 2020 at 8:50 PM Jonathon Pendlum <
>> jonathon.pend...@ettus.com> wrote:
>>
>>> Hi Varban,
>>>
>>> I am now getting random 32-bit values when polling it from the UHD
>>>> (instead of a constant that indicates a "zero" reception)
>>>
>>>
>>> Even with the antenna disconnected you can expect some LSBs to toggle
>>> due to inherent receiver noise.
>>>
>>> 1) How should I interpret the 32-variable?
>>>>
>>>
>>> It is a short complex int where the upper 16-bits are I and the lower
>>> 16-bits are Q.
>>>
>>>
>>>> 2) Is the strobe_rx the correct signal that indicates new sample
>>>> arrival?
>>>>
>>>
>>> Yes
>>>
>>>
>>>> 2) Do I need new_rx_control?
>>>
>>>
>>> No
>>>
>>> Have I done this correctly in general, or there is something completely
>>>> wrong in my approach?
>>>
>>>
>>> What do you want to accomplish?
>>>
>>> Jonathon
>>>
>>> On Mon, Feb 17, 2020 at 5:03 AM Varban Metodiev via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> After exposing the *sample_rx* from radio_legacy.v
>>>> <https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/radio_200/radio_legacy.v>
>>>>  to
>>>> a user defined register and sampling it at rising edge of the
>>>> *strobe_rx*, I am now getting random 32-bit values when polling it
>>>> from the UHD (instead of a constant that indicates a "zero" reception). I
>>>> am doing this with disconnected antenna using a modified rx_samples C++
>>>> example application.
>>>>
>>>> I have the following questions:
>>>> 1) How should I interpret the 32-variable?
>>>> 2) Is the strobe_rx the correct signal that indicates new sample
>>>> arrival?
>>>> 2) Do I need new_rx_control?
>>>>
>>>> Have I done this correctly in general, or there is something completely
>>>> wrong in my approach?
>>>>
>>>> Thanks,
>>>> Varban
>>>> ___
>>>> 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] Polling the "sample_rx" via a user defined register (B205mini)

[Varban Metodiev via USRP-users]

Hi Jonathon,

After separating the I and Q channels, I think that the values with
detached RX input look reasonable (please see *I_Q_data_custom_build.txt*).
What do you think?
I am reading my custom register with a modified version of
*rx_samples_to_file* (attached as well, line 92 - 100).

Now, when I try to send some reference sine waves via the *tx_waveforms*
example running on another PC attached to another USRP B205mini, I get
unexplainable data.
The default data type in the *tx_waveforms* is fc32, do I need to recompile
it with sc16 for this case?

Kind regards,
V.

On Wed, Feb 26, 2020 at 1:36 AM Varban Metodiev 
wrote:

> Hi Jonathon,
>
> Thank you very much for your reply.
>
> What do you want to accomplish?
> --> Right now, I just want to monitor the 'sample_rx' values. Eventually,
> I will use this to calibrate the reference input of my custom Verilog
> decoder (attached) that aims to detect spikes and measure their length
> (like those from the attachment).
>
> It is a short complex int where the upper 16-bits are I and the lower
> 16-bits are Q.
> --> Well... that could be the explanation. I will try to monitor them
> separately and get back to you.
>
> Kind regards,
> Varban
>
> On Tue, Feb 25, 2020 at 8:50 PM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Varban,
>>
>> I am now getting random 32-bit values when polling it from the UHD
>>> (instead of a constant that indicates a "zero" reception)
>>
>>
>> Even with the antenna disconnected you can expect some LSBs to toggle due
>> to inherent receiver noise.
>>
>> 1) How should I interpret the 32-variable?
>>>
>>
>> It is a short complex int where the upper 16-bits are I and the lower
>> 16-bits are Q.
>>
>>
>>> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
>>>
>>
>> Yes
>>
>>
>>> 2) Do I need new_rx_control?
>>
>>
>> No
>>
>> Have I done this correctly in general, or there is something completely
>>> wrong in my approach?
>>
>>
>> What do you want to accomplish?
>>
>> Jonathon
>>
>> On Mon, Feb 17, 2020 at 5:03 AM Varban Metodiev via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dear all,
>>>
>>> After exposing the *sample_rx* from radio_legacy.v
>>> <https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/radio_200/radio_legacy.v>
>>>  to
>>> a user defined register and sampling it at rising edge of the
>>> *strobe_rx*, I am now getting random 32-bit values when polling it from
>>> the UHD (instead of a constant that indicates a "zero" reception). I am
>>> doing this with disconnected antenna using a modified rx_samples C++
>>> example application.
>>>
>>> I have the following questions:
>>> 1) How should I interpret the 32-variable?
>>> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
>>> 2) Do I need new_rx_control?
>>>
>>> Have I done this correctly in general, or there is something completely
>>> wrong in my approach?
>>>
>>> Thanks,
>>> Varban
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
vmetodiev@ubuntu:~/Development/SDR/uhd/host/build/examples$ sudo 
./rx_samples_to_file --freq 2e9 --rate 1e6 --bw 1e6 --gain 60 

Creating the usrp device with: ...
[INFO] [UHD] linux; GNU C++ version 9.2.1 20191008; Boost_106700; 
UHD_4.0.0.0-436-g45719260
[INFO] [B200] Detected Device: B205mini
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test... 
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz... 
[INFO] [B200] Actually got clock rate 16.00 MHz.
Using Device: Single USRP:
  Device: B-Series Device
  Mboard 0: B205mini
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1

Setting RX Rate: 1.00 Msps...
[INFO] [B200] Asking for clock rate 32.00 MHz... 
[INFO] [B200] Actually got clock rate 32.00 MHz.
Actual RX Rate: 1.00 Msps...

Setting RX Freq: 2000.00 MHz...
Setting RX LO Offset: 0.00 MHz...
Actual RX Freq: 2000.00 MHz...

Setting RX Gain: 60.00 dB...
Actual RX Gain: 60.00 dB...

Sett

Re: [USRP-users] Polling the "sample_rx" via a user defined register (B205mini)

[Varban Metodiev via USRP-users]

Hi Jonathon,

Thank you very much for your reply.

What do you want to accomplish?
--> Right now, I just want to monitor the 'sample_rx' values. Eventually, I
will use this to calibrate the reference input of my custom Verilog decoder
(attached) that aims to detect spikes and measure their length (like those
from the attachment).

It is a short complex int where the upper 16-bits are I and the lower
16-bits are Q.
--> Well... that could be the explanation. I will try to monitor them
separately and get back to you.

Kind regards,
Varban

On Tue, Feb 25, 2020 at 8:50 PM Jonathon Pendlum 
wrote:

> Hi Varban,
>
> I am now getting random 32-bit values when polling it from the UHD
>> (instead of a constant that indicates a "zero" reception)
>
>
> Even with the antenna disconnected you can expect some LSBs to toggle due
> to inherent receiver noise.
>
> 1) How should I interpret the 32-variable?
>>
>
> It is a short complex int where the upper 16-bits are I and the lower
> 16-bits are Q.
>
>
>> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
>>
>
> Yes
>
>
>> 2) Do I need new_rx_control?
>
>
> No
>
> Have I done this correctly in general, or there is something completely
>> wrong in my approach?
>
>
> What do you want to accomplish?
>
> Jonathon
>
> On Mon, Feb 17, 2020 at 5:03 AM Varban Metodiev via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear all,
>>
>> After exposing the *sample_rx* from radio_legacy.v
>> <https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/radio_200/radio_legacy.v>
>>  to
>> a user defined register and sampling it at rising edge of the *strobe_rx*,
>> I am now getting random 32-bit values when polling it from the UHD (instead
>> of a constant that indicates a "zero" reception). I am doing this with
>> disconnected antenna using a modified rx_samples C++ example application.
>>
>> I have the following questions:
>> 1) How should I interpret the 32-variable?
>> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
>> 2) Do I need new_rx_control?
>>
>> Have I done this correctly in general, or there is something completely
>> wrong in my approach?
>>
>> Thanks,
>> Varban
>> ___
>> 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] Polling the "sample_rx" via a user defined register (B205mini)

[Varban Metodiev via USRP-users]

Dear all,

After exposing the *sample_rx* from radio_legacy.v

to
a user defined register and sampling it at rising edge of the *strobe_rx*,
I am now getting random 32-bit values when polling it from the UHD (instead
of a constant that indicates a "zero" reception). I am doing this with
disconnected antenna using a modified rx_samples C++ example application.

I have the following questions:
1) How should I interpret the 32-variable?
2) Is the strobe_rx the correct signal that indicates new sample arrival?
2) Do I need new_rx_control?

Have I done this correctly in general, or there is something completely
wrong in my approach?

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

Re: [USRP-users] Simultaneous TX and RX from the UHD

[Varban Metodiev via USRP-users]

Hi Marcus,

Thanks a lot!

Best regards,
Varban

On Sunday, January 26, 2020, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 01/26/2020 06:57 AM, Varban Metodiev via USRP-users wrote:
>
>> Dear USRP Community,
>>
>> I need to do a realistic loopback TX-RX communication (via a feeder and
>> attenuator) of my B205mini device.
>>
>> I took the examples from tx_samples_c.c and rx_samples_c.c, and tried
>> running them as two different POSIX threads. However, this way I could get
>> only transmission working, without any reception. When trying from GNU
>> Radio - both the source and sink modules work simultaneously without any
>> problem, meaning that I have done something really wrong in my approach...
>>
>> Could you please advise what is the correct structural pattern for
>> simultaneous RX and TX on a single USRP device via the UHD framework?
>>
>> Best regards,
>> Varban
>>
>> Varban:
>
> There's an example that does this:
>
> txrx_loopback_to_file
>
>
> You can look at the source code of that example to get some ideas of how
> to properly structure such a thing.
>
>
>
>
>
> ___
> 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] Simultaneous TX and RX from the UHD

[Varban Metodiev via USRP-users]

Dear USRP Community,

I need to do a realistic loopback TX-RX communication (via a feeder and
attenuator) of my B205mini device.

I took the examples from tx_samples_c.c and rx_samples_c.c, and tried
running them as two different POSIX threads. However, this way I could get
only transmission working, without any reception. When trying from GNU
Radio - both the source and sink modules work simultaneously without any
problem, meaning that I have done something really wrong in my approach...

Could you please advise what is the correct structural pattern for
simultaneous RX and TX on a single USRP device via the UHD framework?

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

Re: [USRP-users] 12 bits I/Q samples

[Varban Metodiev via USRP-users]

Hi Arash,

May you please provide some examples of what samples you've gathered?

Thanks,
Varban

On Tue, Jan 21, 2020 at 12:07 PM Arash Jafari via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Everybody,
>
> according to FPGA implementation of my board which a USRP-b200, the Least
> significant 4bits of I or Q samples are always 0 (0x???0), which in turn
> means the recorded sample as short complex 16 bits (sc16) cpu format should
> have four zero at LSB.
> But almost 10% of recorded samples do not obey this rule
> Any comment is highly appreciated!
>
> Kind regards,
>
> --
>
> Dipl.-Ing. Arash Jafari
>
> Phone: +43 650 844 3617
> E-mail: arash.jafari.tele...@gmail.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

[USRP-users] Adding my custom RX module inside the FPGA (USRP b205mini)

[Varban Metodiev via USRP-users]

Dear all,

I have written a simple RX logic in Verilog and now I want to integrate it
inside the FPGA. I have the following questions:

1) What is the correct way to connect it after the DDC (so that I will get
1:1 samples with those from GNURadio)?
2) How should I expose it to the UHD driver? I read the radio_legacy.v
example about the custom UHD registers but I couldn't get how to specify
the register address mapping.

Thank you in advance,
Varban
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Header files cannot be opened upon trying to compile the FPGA image for b205mini

[Varban Metodiev via USRP-users]

Hi Marcus,

At first, I tried sourcing the "settings64.sh" file, as per the official
instructions:
Build Instructions (Xilinx ISE only)Makefile based Builder

   - To add xtclsh to the PATH and to setup up the Xilinx build environment
   run
  - *source /Xilinx/14.7/ISE_DS/settings64.sh (64-bit
  platform)*

However, I did not see the PATH variable being concatenated with the xtclsh
path. That is why I got the path from "which xtclsh" and manually appended
it to the PATH.

In both cases  (with or without xtclpath present inside the PATH), I always
get the problem with opening the Verilog headers.

Do you have a specific shell that you
prepare for synthesis?
---> No, I am just using the official Linux VM installation of Xilinx ISE.
I keep the shell environment by default.

Regards,
Varban

On Sat, Dec 28, 2019 at 12:13 PM Marcus Müller 
wrote:

> Hi Varban,
>
> just a transient observation: your $PATH contains *a lot* of redundant
> ISE paths, as if some script kept recursively sourcing the xilinx
> settings. How are these set? Do you have a specific shell that you
> prepare for synthesis?
>
> Best regards,
> Marcus
> On Fri, 2019-12-27 at 12:47 +, Varban Metodiev via USRP-users
> wrote:
> > Hi,
> >
> > I am trying to compile the FPGA image for a b205mini as per the
> > official instructions. My environment looks like this:
> >
> > [ise@localhost b2xxmini]$ which xtclsh
> > /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xtclsh
> > [ise@localhost b2xxmini]$ pwd
> > /home/ise/USRP/fpga/usrp3/top/b2xxmini
> >
> > [ise@localhost b2xxmini]$ echo $PATH
> > /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/sys
> > gen/util:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin:/opt/Xilinx/14.7/ISE_
> > DS/ISE/../../../DocNav:/opt/Xilinx/14.7/ISE_DS/PlanAhead/bin:/opt/Xil
> > inx/14.7/ISE_DS/EDK/bin/lin64:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microbl
> > aze/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/powerpc-
> > eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/
> > 14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xili
> > nx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/X
> > ilinx/14.7/ISE_DS/common/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/bin/li
> > n64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/I
> > SE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx
> > /14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt
> > /Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_D
> > S/EDK/gnu/powerpc-
> > eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/
> > 14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xili
> > nx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/X
> > ilinx/14.7/ISE_DS/common/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/bin/li
> > n64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/I
> > SE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx
> > /14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt
> > /Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_D
> > S/EDK/gnu/powerpc-
> > eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/
> > 14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xili
> > nx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/X
> > ilinx/14.7/ISE_DS/common/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/bin/li
> > n64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/I
> > SE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx
> > /14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt
> > /Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_D
> > S/EDK/gnu/powerpc-
> > eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/
> > 14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xili
> > nx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/X
> > ilinx/14.7/ISE_DS/common/bin/lin64:/usr/lib64/qt-
> > 3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:
> > /home/ise/bin:/home/ise/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xtclsh
> >
> >
> > Upon starting the "make B205mini", the header files inside
> > /fpga/usrp3/lib/ cannot be accessed.
> >
> > INFO:ProjectMgmt - Include file found:
> >'/home/ise/USRP/fpga/usrp3/lib/wishbone/i2c_master_defines.v' in
> > file
> >"/home/ise/USRP/fpga/usrp3/lib/wishbone/i2c_master_byte_ctrl.v"
> > line 73
> > ERROR:ProjectMgmt - 1 error(s) found w

[USRP-users] Header files cannot be opened upon trying to compile the FPGA image for b205mini

[Varban Metodiev via USRP-users]

Hi,

I am trying to compile the FPGA image for a b205mini as per the
official instructions. My environment looks like this:

[ise@localhost b2xxmini]$ which xtclsh
/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xtclsh
[ise@localhost b2xxmini]$ pwd
/home/ise/USRP/fpga/usrp3/top/b2xxmini

[ise@localhost b2xxmini]$ echo $PATH
/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx/14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/powerpc-eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/Xilinx/14.7/ISE_DS/common/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx/14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/powerpc-eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/Xilinx/14.7/ISE_DS/common/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx/14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/powerpc-eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/Xilinx/14.7/ISE_DS/common/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util:/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin:/opt/Xilinx/14.7/ISE_DS/ISE/../../../DocNav:/opt/Xilinx/14.7/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.7/ISE_DS/EDK/bin/lin64:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/powerpc-eabi/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/arm/lin/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_be/bin:/opt/Xilinx/14.7/ISE_DS/EDK/gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/Xilinx/14.7/ISE_DS/common/bin/lin64:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ise/bin:/home/ise/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xtclsh


Upon starting the "make B205mini", the header files inside
/fpga/usrp3/lib/ cannot be accessed.

INFO:ProjectMgmt - Include file found:
   '/home/ise/USRP/fpga/usrp3/lib/wishbone/i2c_master_defines.v' in file
   "/home/ise/USRP/fpga/usrp3/lib/wishbone/i2c_master_byte_ctrl.v" line 73
ERROR:ProjectMgmt - 1 error(s) found while parsing design hierarchy.
WARNING:ProjectMgmt - Circular Reference: work:Module|cam_priority_encoder
>>> Adding source to project: 
>>> /home/ise/USRP/fpga/usrp3/lib/wishbone/axi_stream_to_wb.v
INFO:HDLCompiler:1845 - Analyzing Verilog file
   "/home/ise/USRP/fpga/usrp3/lib/packet_proc/source_flow_control.v" into
   library work
ERROR:HDLCompiler:281 -
   "/home/ise/USRP/fpga/usrp3/lib/packet_proc/source_flow_control.v" Line 55:
   Cannot open include file "chdr_pkt_types.vh".
INFO:HDLCompiler:1845 - Analyzing Verilog file
   "/home/ise/USRP/fpga/usrp3/lib/wishbone/axi_stream_to_wb.v" into library work
ERROR:ProjectMgmt - 1 error(s) found while parsing design hierarchy.
WARNING:ProjectMgmt - Circular Reference: work:Module|cam_priority_encoder
>>> Adding source to project: 
>>> /home/ise/USRP/fpga/usrp3/lib/timing/time_compare.v
INFO:TclTasksC - File "/home/ise/USRP/fpga/usrp3/lib/timing/time_compare.v" is
   already present in the project

May you please advise how add the search path correctly? Or maybe I
have missed something in the environment configuration?

Regards,
Varban

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

[USRP-users] Getting interval between samples

[Varban Metodiev via USRP-users]

Hi,

Recently I have been trying to figure out how to get the sample interval
(in nanoseconds) on my USRP b205mini device that is coming from the radio
IC. In regards with this, I would kindly ask you for assistance on the
following questions:

1) While browsing the Verilog codes, I found out that a clock of 40MHz DDR
is used for reading and writing to the AD9364 IC. When the “USRP Sink”
block in GNU Radio is active, does it constantly poll at 40MHz? My initial
intention was to write a separate counter block in Verilog to get the
interval between the samples but if there are no stops/wait event on the
bus, can I use this as time reference?


2) On the block diagram of the b205mini, it is mentioned that the DDC and
the DUC are integrated in the FPGA. I have two questions here:

- I couldn’t find them in the top module, so.. where is the exact location?

- Is there some way to read the samples directly from the RF IC, before the
DDC?


3) About the UHD interface – are there any examples on how to interface my
own block with my own registers via the USB?


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

Re: [USRP-users] Gnuradio loopback TX and RX example

[Varban Metodiev via USRP-users]

Hi Marcus,

Great... thank you very much for your help!

Regards,
Varban

On Monday, March 25, 2019, Marcus Müller  wrote:

> Hi Varban,
>
> GNU Radio ships with examples; typically, these get installed to
> /usr/[local/]share/gnuradio/examples on Linux and similar systems.
>
> You're looking for
> examples/digital/packet/packet_{rx,tx,loopback_hier}.grc
>
> Best regards,
> Marcus
>
> On Mon, 2019-03-25 at 10:20 +0200, Varban Metodiev via USRP-users
> wrote:
> > Dear all,
> >
> > For quite some time I have been trying to transmit a single byte in a
> > loopback scenario. I have the following questions:
> > 1) Could anyone help me with an example about this?
> > 2) Right now I am sending the digital data directly to the USRP Sink
> > block. Is this fine, or a one should send a digital description of an
> > analog signal to it?
> >
> > Thanks in advance,
> > Varban
> >
> >
> > ___
> > 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] b205mini - cannot get TX at 0-30dBm (with attenuator)

[Varban Metodiev via USRP-users]

Dear all,

This is my first post here and I would dare to ask you for help on the
following ridiculous situation. So... I am experiencing the following issue
on two USRP b205mini boards:
1) From the UHD Sink block in GnuRadio, configured to transmit from 0 to
30dBm gain, I cannot get any transmission on the spectral analyzer. I am
connecting the board via the -30dBm attenuator inbetween.
2) Same is observed not only from GnuRadio, but also from the USRP examples
(like tx_waveforms).
3) When setting  the board up for reception from GnuRadio - it works great.

Could you please advise what I could have done wrong?

Thank you in advance.

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