Re: [USRP-users] USRP B210 hardware architecture

[Marcus D. Leech via USRP-users]

On 01/22/2020 01:53 AM, massoud pourmandi via USRP-users wrote:


Dear colleagues,

we have a USRP B210 in our lab, though, I have some questions 
regarding this device.


First, I can’t find its hardware architecture? I would be glad if you 
send me its detailed information.


I’m using *Gnuradio* as my simulation environment. In this simulator, 
when I connect a signal generator with sin wave to USRP B210 with a 
const carrier frequency, the output signal probability undertakes a 
modulation by USRP carrier frequency. I need to check its hardware 
architecture in order to inspect how this modulation is carried out.


Secondly, I have checked this device’s datasheet, and the datasheet 
underlines that this is a full-duplex device. If you check the device, 
you will notice two pairs of ports (RFA and RFB).


How does this duplexity work?

Thank you for your time.



The schematics are here:

http://files.ettus.com/schematics/b200/b210.pdf

There are two mostly-independent TX and RX channels in the B210.

A full-duplex application would have an usrp_source and a usrp_sink in 
it, configured appropriately.


So, a simple late-night summary of what happens:

When you transmit a baseband signal out of Gnu Radio, it is digitally 
up-sampled in the FPGA to the sample rate of the DAC in the AD9361
  chip, where it is mixed with the local-oscillator signal to produce 
the RF carrier that is transmitted from the antenna.


Conversely, on the receiver side, the signal arrives at the antenna, is 
mixed down to complex baseband, where it is sampled by the ADC in
  the AD9361, usually down-sampled in the FPGA, and presented to your 
application as a stream of complex-baseband samples.


This is broadly-similar for ANY SDR hardware out there, the details 
differ, but in broad general strokes they are the same.



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

[USRP-users] USRP B210 hardware architecture

[massoud pourmandi via USRP-users]

Dear colleagues,

we have a USRP B210 in our lab, though, I have some questions regarding
this device.

First, I can’t find its hardware architecture? I would be glad if you send
me its detailed information.

I’m using *Gnuradio* as my simulation environment. In this simulator, when
I connect a signal generator with sin wave to USRP B210 with a const
carrier frequency, the output signal probability undertakes a modulation by
USRP carrier frequency. I need to check its hardware architecture in order
to inspect how this modulation is carried out.

Secondly, I have checked this device’s datasheet, and the datasheet
underlines that this is a full-duplex device. If you check the device, you
will notice two pairs of ports (RFA and RFB).

How does this duplexity work?

Thank you for your time.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] ettus usrp B200 driver - not working on linux ubuntu

[Marcus D. Leech via USRP-users]

On 01/21/2020 11:50 AM, Michael Dickens via USRP-users wrote:
Hi Paweł - I'd recommend using these install instructions < 
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux 
 >. 
Please note specifically the section for "Configuring USB". It sounds 
like you've done most of the work already; just a couple parts that 
might be additions or different to be finalized. Hope this is useful! 
- MLD
I'll also point out that USB over a VM has always been a pain, not just 
for USRPs.


We don't really recommend that you run the Ettus USB type radios through 
a VM, because USB support in VMs is flaky and under-performing

  in general.




On Tue, Jan 21, 2020 at 11:33 AM Paweł Gocyla via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hello,

I have a problem with ettus usrp B200 on linux ubuntu.

I have made all steps regarding UHD and driver installation with
this tutorial:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z015BIZSA2=pl-PL

I turned on support for usb 3.0 in vmware settings.
I installed intel drivers for support of usb 3.0 (on windows host)
-> after that vmware was finding this device as B200 for a while
but after host windows restart is identifying this device as
before as WestBridge. In ubuntu I have warning from vmware
workstation that there is a driver error.

In windows host this device is properly identyfied as Ettus
Research LLC B20/B210. On ubuntu I installed driver via apt -
libuhd3.15.0.

uhd_usrp_probe and uhd_find_devices can't find any usrp devices.

lsusb also doesn't recognise this usrp B200 device.


I was searching in google for more information but I don't have
any ideas how to fix it and what is wrong.

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



--
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com 
Web: https://ettus.com/


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


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

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

[Marcus D. Leech via USRP-users]

On 01/21/2020 05:06 AM, Arash Jafari via USRP-users 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,


This is because the FPGA implementation always scales the ADC values to 
whatever is appropriate for the wire format, which by default

  is 16-bits.

The idea is to make the sample formats somewhat independent from the ADC 
of whatever hardware you happen to be using.  This happens
  both implicitly, by virtue of the way a fixed-point DDC operates, and 
explicitly by scaling code in the FPGA.




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

Re: [USRP-users] ettus usrp B200 driver - not working on linux ubuntu

[Michael Dickens via USRP-users]

Hi Paweł - I'd recommend using these install instructions <
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>.
Please note specifically the section for "Configuring USB". It sounds like
you've done most of the work already; just a couple parts that might be
additions or different to be finalized. Hope this is useful! - MLD

On Tue, Jan 21, 2020 at 11:33 AM Paweł Gocyla via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have a problem with ettus usrp B200 on linux ubuntu.
>
> I have made all steps regarding UHD and driver installation with this
> tutorial:
>
> https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z015BIZSA2=pl-PL
>
> I turned on support for usb 3.0 in vmware settings.
> I installed intel drivers for support of usb 3.0 (on windows host) ->
> after that vmware was finding this device as B200 for a while but after
> host windows restart is identifying this device as before as WestBridge. In
> ubuntu I have warning from vmware workstation that there is a driver error.
>
> In windows host this device is properly identyfied as Ettus Research LLC
> B20/B210. On ubuntu I installed driver via apt - libuhd3.15.0.
>
> uhd_usrp_probe and uhd_find_devices can't find any usrp devices.
>
> lsusb also doesn't recognise this usrp B200 device.
>
>
> I was searching in google for more information but I don't have any ideas
> how to fix it and what is wrong.
>
> Thanks in advance for your help !
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://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] using GPIO output to trigger external RF switches

[Sam Reiter via USRP-users]

Thomas,

I believe I mistyped in my initial response to specify a TX rate change
rather than frequency change. It might be more clear if I include some
quick pseudocode describing what I'm talking about:

tune_time = usrp->get_time_now() + uhd::time_spect_t(0.1) //Set a
> future time to execute commands based on the USRP's current sense of time
> set_command_time(tune_time)
> //Commands after this point will wait to execute until tune_time
> set_tx_freq()
> //This will be executed at the command time
> set_gpio_attr()
>   //This will be executed at the command time
> clear_command_time()
>//Clear the command time, subsequent commands will execute ASAP when
> they make it to the radio
> sleep(.01)
>   //Sleep for some arbitrary time. This will roughly
> determine GPIO pulse width
> set_gpio_attr()
> //Return GPIO state to low. This will happen as soon as the radio
> gets it, but you could also set it up as a timed command
>

This approach would not use ATR. It uses timed commands to synchronize your
TX freq change with the GPIO state change. There are almost certainly more
efficient ways to play with the time setting as to minimize the time
between hops, but you get the idea. Based on how you're hopping, you might
benefit from changing the tuning policy so that you only change frequency
in DSP, rather than retuning the LO:

https://files.ettus.com/manual/structuhd_1_1tune__request__t.html

Sam Reiter


On Tue, Jan 21, 2020 at 8:54 AM Thomas Harder  wrote:

> Thank you Jeff and Sam,
>
> I found now also the gpio.cpp example. Really helpful to get familiar with
> GPIO.
>
>
>
> >> To accomplish what you're talking about, I think you'd just need to use
> timed commands >>on both set_tx_rate() and set_gpio_attr(). If these are
> set to execute simultaneously, the >>GPIO line you set will go high on the
> same clock cycle as the LO retune.
>
>
>
> In fact in my code which is based on the “tx_samples_from_file” example I
> start transmitting my data in the file in the future with tx_metadata_t
> time specification and with timed commands I set set_gpio_attr() to the
> same point in future.
>
> But this gives me just 1 output pulse in GPIO what is not sufficient for
> my application.
>
>
>
> I am transmitting  in continuous mode (a fixed modulation in a while loop)
> and my center frequency stays fix during the whole transmission whereas
> with my data in the file I am modulating the center frequency to discrete
> frequencies in the whole bandwidth of 160MHz. I measured a transition time
> of the usrp  of around 20ns between different frequencies in my modulation.
>
> *To be able to postprocess my RF signal I would like to have a pulse each
> time the tx-frequency is changing.*
>
>
>
> As the ATR is just showing if the usrp is transmitting, receiving or idle
> it is not really helpful
>
> And putting set_gpio_attr() in the while loop for my continuous
> transmission is slowing down the streaming and causes underruns.
>
>
>
> Do you think of any other solution to get a pulse each time the
> transmission frequency of the USRP is changing?
>
>
>
> Thomas
>
>
>
> *From: *Sam Reiter 
> *Sent: *Tuesday, January 14, 2020 6:44 PM
> *To: *Jeff S 
> *Cc: *usrp-users@lists.ettus.com; Thomas Harder 
> *Subject: *Re: [USRP-users] using GPIO output to trigger external RF
> switches
>
>
>
> Thomas,
>
>
>
> To accomplish what you're talking about, I think you'd just need to use
> timed commands on both set_tx_rate() and set_gpio_attr(). If these are set
> to execute simultaneously, the GPIO line you set will go high on the same
> clock cycle as the LO retune.
>
>
>
> Sam
>
>
>
>
>
> On Tue, Jan 14, 2020 at 5:59 AM Jeff S via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Thomas,
>
>
>
> I am looking at GPIO right now as well.  As to your question #2 on
> examples, I compiled and am able to run the example I found in the UHD
> software:
>
>
>
> uhd/host/examples/gpio.cpp
>
>
>
> I am able to set individual data lines to experiment with (and eventually
> use as a roadmap for my development) using commands like:
>
>
>
> ./gpio --dwell 0 --bitbang --ddr 0x00ff --out 0x0055
>
>
>
> which I verified works using a logic analyzer.  I eventually want to try
> to create a keying loop, but that may take some FPGA control (?).
>
>
>
> Jeff
>
>
>
>
>
> *From:* USRP-users  on behalf of
> Thomas Harder via USRP-users 
> *Sent:* Tuesday, January 14, 2020 5:07 AM
> *To:* usrp-users@lists.ettus.com 
> *Subject:* [USRP-users] using GPIO output to trigger external RF switches
>
>
>
> Hi,
>
> I am continuously transmitting a waveform with several RF with 200MSPS
> with my USRP X310 (modified code on the basis of “tx_samples_from_file.cpp”
> with a waveform in a .dat file). I would like to get a trigger signal from
> the USRP when it is changing the tx- frequency which I set in my .dat file.
>
> Could the GPIO deliver this trigger without changing the image?
>
> I am using the SRAM image with UHD 3.14.1
>
>
>

[USRP-users] ettus usrp B200 driver - not working on linux ubuntu

[Paweł Gocyla via USRP-users]

Hello,

I have a problem with ettus usrp B200 on linux ubuntu.

I have made all steps regarding UHD and driver installation with this
tutorial:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z015BIZSA2=pl-PL

I turned on support for usb 3.0 in vmware settings.
I installed intel drivers for support of usb 3.0 (on windows host) -> after
that vmware was finding this device as B200 for a while but after host
windows restart is identifying this device as before as WestBridge. In
ubuntu I have warning from vmware workstation that there is a driver error.

In windows host this device is properly identyfied as Ettus Research LLC
B20/B210. On ubuntu I installed driver via apt - libuhd3.15.0.

uhd_usrp_probe and uhd_find_devices can't find any usrp devices.

lsusb also doesn't recognise this usrp B200 device.


I was searching in google for more information but I don't have any ideas
how to fix it and what is wrong.

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

[USRP-users] Ethernet controller speed negotiation issue

[voonna santosh via USRP-users]

Hi There,   Following is the configuration followed by issue description. Have 
you experienced or someone reported similar issue in the past with X552 
Ethernet controllers?
Centos version: 7.7Ethernet controller: X552SFP adaptor: FTLX8571D3BCV-ITixgbe 
default version: 5.1.0Updated ixgbe driver to: 5.6.5INTERMITTENT Issue: Some 
times the link never comes up and even if I bring down and bring up the 
interface(ifconfig down/up). Even I tried probing ixgbe(rmmod/modprobe), no 
luck.
PLEASE HELP
BR,Santosh
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] using GPIO output to trigger external RF switches

[Thomas Harder via USRP-users]

Thank you Jeff and Sam,
I found now also the gpio.cpp example. Really helpful to get familiar with GPIO.

>> To accomplish what you're talking about, I think you'd just need to use 
>> timed commands >>on both set_tx_rate() and set_gpio_attr(). If these are set 
>> to execute simultaneously, the >>GPIO line you set will go high on the same 
>> clock cycle as the LO retune.

In fact in my code which is based on the “tx_samples_from_file” example I start 
transmitting my data in the file in the future with tx_metadata_t  time 
specification and with timed commands I set set_gpio_attr() to the same point 
in future.
But this gives me just 1 output pulse in GPIO what is not sufficient for my 
application.

I am transmitting  in continuous mode (a fixed modulation in a while loop) and 
my center frequency stays fix during the whole transmission whereas with my 
data in the file I am modulating the center frequency to discrete frequencies 
in the whole bandwidth of 160MHz. I measured a transition time of the usrp  of 
around 20ns between different frequencies in my modulation.
To be able to postprocess my RF signal I would like to have a pulse each time 
the tx-frequency is changing.

As the ATR is just showing if the usrp is transmitting, receiving or idle it is 
not really helpful
And putting set_gpio_attr() in the while loop for my continuous transmission is 
slowing down the streaming and causes underruns.

Do you think of any other solution to get a pulse each time the transmission 
frequency of the USRP is changing?

Thomas

From: Sam Reiter
Sent: Tuesday, January 14, 2020 6:44 PM
To: Jeff S
Cc: usrp-users@lists.ettus.com; Thomas Harder
Subject: Re: [USRP-users] using GPIO output to trigger external RF switches

Thomas,

To accomplish what you're talking about, I think you'd just need to use timed 
commands on both set_tx_rate() and set_gpio_attr(). If these are set to execute 
simultaneously, the GPIO line you set will go high on the same clock cycle as 
the LO retune.

Sam


On Tue, Jan 14, 2020 at 5:59 AM Jeff S via USRP-users 
 wrote:
Thomas,

I am looking at GPIO right now as well.  As to your question #2 on examples, I 
compiled and am able to run the example I found in the UHD software:

uhd/host/examples/gpio.cpp

I am able to set individual data lines to experiment with (and eventually use 
as a roadmap for my development) using commands like:

./gpio --dwell 0 --bitbang --ddr 0x00ff --out 0x0055

which I verified works using a logic analyzer.  I eventually want to try to 
create a keying loop, but that may take some FPGA control (?).

Jeff



From: USRP-users  on behalf of Thomas 
Harder via USRP-users 
Sent: Tuesday, January 14, 2020 5:07 AM
To: usrp-users@lists.ettus.com 
Subject: [USRP-users] using GPIO output to trigger external RF switches 
 
Hi,
I am continuously transmitting a waveform with several RF with 200MSPS with my 
USRP X310 (modified code on the basis of “tx_samples_from_file.cpp” with a 
waveform in a .dat file). I would like to get a trigger signal from the USRP 
when it is changing the tx- frequency which I set in my .dat file. 
Could the GPIO deliver this trigger without changing the image? 
I am using the SRAM image with UHD 3.14.1
 
A second question is concerning the GPIO example on 
https://files.ettus.com/manual/page_gpio_api.html.
I copied and paced it in the “tx_waveforms” example just changing the usrp 
device handle to “usrp” but when I compiled it and started tx, I couldn’t 
measure any tension on PIN 4 and 6 as defined in the example. Are there more 
examples how to program the GPIO?
Thank you,
Thomas
___
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] 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] 12 bits I/Q samples

[Arash Jafari via USRP-users]

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