[USRP-users] USRP B210 GPS bias-tee Current Limit

[johnhigginsgis]

What is the maximum current that the B210 provide to the GPS antenna?\
\
Is the biasing current provided by the GPSDO or via some onboard bias tee on 
the B210 PCB?

Best regards,
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP B210 fpga build error

[Ethan C]

 Hello,
I am trying to build the default B210 fpga project using Xilinx ISE just to
confirm I can do it before investing more time in a project. I downloaded
UHD 4.6 from the github repo and in ~uhd/fpga/usrp3/top/b200 set up the
Xilinx environment and built the fpga project

source /opt/Xilinx/14.7/ISE_DS/settings64.sh

make b210

I get an error "python: No such file or directory" during the "Generating
Report" part of the build like in the attached screenshots.



I don't quite understand the python line before the error, but I assume
it's calling check_timing.py with b200.twr as a parameter. check_timing.py
is in the expected location, not sure where build-B200//b200.twr is
supposed to be, but there is the touch command right before so it should be
in ~uhd/fpga/usrp3/top/b200.
The USRP B210 I am using wasn't connected when building the fpga project, I
assume that loading the new fpga project into the USRP can be done after
building it
I edited one file in ~uhd/fpga/usrp3/top/b200 by adding a comment so I
guess it's not truly default.
Is there something I'm missing or doing wrong?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP B210 streamer throwing BAD PACKET and TIMEOUT error

[anil . antony]

Hi,

I am using usrp B210 for my 5G test bench setup. The setup is consists of 
Openairinterface5G 5G stack and UHD driver 4.3.0. UHD driver is installed form 
source code approach and only one libuhd driver is in use. My setup is as 
follows, 

* Intel i7, 8 core, 8GB RAM,  3.6GHz CPU with ubuntu18.04, 4.15.0.123 Low 
latency kernel.  

* USB 3.0 connection

* Log periodic antenna (**LP0965 Antenna)**

Snippet of the error:\
\[HW\]   \[recv\] received 14380 samples out of 23040

\[ERROR\] \[STREAMER\] The receive packet handler caught a value exception.

ValueError: bad vrt header or packet fragment

\[HW\]   ERROR_CODE_BAD_PACKET

\[PHY\]   rx_rf: Asked for 23040 samples, got 14380 from USRP

\[PHY\]   problem receiving samples

\[HW\]   \[recv\] received 0 samples out of 23040

\[HW\]   ERROR_CODE_TIMEOUT

kern.log:\
Nov 14 07:04:43 MYTSP00192 kernel: \[489670.971642\] xhci_hcd :00:14.0: 
WARN Cannot submit Set TR Deq Ptr

Nov 14 07:04:43 MYTSP00192 kernel: \[489670.971644\] xhci_hcd :00:14.0: A 
Set TR Deq Ptr command is pending.

Nov 14 11:54:29 MYTSP00192 kernel: \[507057.294029\] enp4s0: Invalid MTU 9000 
requested, hw max 1500

Nov 14 11:54:29 MYTSP00192 kernel: \[507057.592639\] xhci_hcd :00:14.0: bad 
transfer trb length 7680 in event trb\
\
Please help me.\
\
Regards,

Anil
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP B210 not found and power cycle needed

[Francisco Gallardo lópez]

Hi,

We have a remote station with an USRP B210.

We observed that sometimes the remote machine cannot find the USRP B210 (I
think it has to do with uncontrolled power cycles, but I am not 100% sure
about the root cause. The point is that sometimes it happens).

The only way to sort it out is to disconnect the power supply and the USB
cable from the USRP, and then the remote machine can detect it again. i.e.
doing a complete power reboot to the USRP.

It is not a killer because the problem is not always happening, but it is
annoying because it implies sending somebody to disconnect and connect the
USRP B210 cables.

Is anybody experiencing a similar issue? Any idea how to fix it?

The remote machine uses Ubuntu 22.04.3 LTS and the UHD drivers.

Thanks!
Fran
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP B210 problem

[rouba zeitoun]

Dear USRP users

I have been working on USRP B210. However, every time I try to put the
following comment "uhd_usrp_probe" I face this message "fx3 is in state 5".

Even when I try to use gnuradio for transmitting files to another SDR
device I faceD the same problem.

I would really appreciate your advice on a solution or the reason for such
a problem.

Thank you.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP B210 GPIO Control

[vld . popovici]

Hello,

I am trying to get the GPIO header (J504) working on a USRP B210 for power 
amplifier control in GNURadio. It appears this is possible based on the 
documentation, but I am not having any success.

According to this user, GPIO support for the USRP B210 was added in UHD 3.9: 
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00418.html

However, I am running UHD 3.15, and I am getting the same error that user was 
getting on UHD 3.8 when I call self.uhd_usrp_sink_0.set_gpio_attr("TXA", 
"ATR_TX", 1, 0x10, 0):

RuntimeError: LookupError: Path not found in tree: /mboards/0/dboards/A/iface

I added print(self.uhd_usrp_sink_0.get_gpio_banks(0)) above the line causing 
the runtime error, and the three banks listed were ('FP0', 'RXA', 'TXA'). It 
appears that FP0 is the only bank that does not raise this runtime error. I set 
all pins on this bank to ATR_TX by setting the mask to 0x, however, 
none of the pins on the J504 header appear to change state when the USRP 
changes state from transmit to receive. Does this bank actually correspond to 
any physical pins on the B210, or is it just internal to the FPGA?

Is it possible this is a regression? If so, which version of UHD should I use 
for GPIO control on the B210 until this is fixed? I would rather not roll back 
all the way to version 3.9 from 2015.

Thanks.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP B210 with ODR tools

[fabien . cuny7]

Hello everyone,\
I have been using a USRP B210 for 6 months now transmitting a home DAB+ mux 
(with Open Digital Radio tools), and since this yesterday, I'm stuck with this 
error and unable to broadcast again :\
\
\[INFO\] \[UHD\] linux; GNU C++ version 8.2.0; Boost_106700; UHD_3.13.1.0-3\
\[INFO\] \[B200\] Loading firmware image: 
/usr/share/uhd/images/usrp_b200_fw.hex...\
\[INFO\] \[B200\] Detected Device: B210\
\[INFO\] \[B200\] Loading FPGA image: 
/usr/share/uhd/images/usrp_b210_fpga.bin...\
\[INFO\] \[B200\] Operating over USB 2.\
\[INFO\] \[B200\] Detecting internal GPSDO \
\[INFO\] \[GPS\] No GPSDO found\
\[INFO\] \[B200\] Initialize CODEC control...\
Error: RuntimeError: \[ad9361_device_t\] TX charge pump cal failure\
\
I've tried with USB3 and USB2, second TX output, same problem.\
As anyone had encountered this before ? It seems like a DC-to-DC failure ?\
I post the question here as it seems more USRP related problem than ODR. Even 
if I run the uhd_usrp_probe command, the same error is displayed.\
Any explanation/help is welcome :)\
\
Fabien Cuny
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Re: [USRP-users] Usrp b210 without duplexer

[Marcus D Leech via USRP-users]

The maximum power at any receive port should not exceed -15dBm. 

If you’re doing full duplex into a shared antenna then yes you need to use a 
duplexor. 

This isn’t strictly a USRP issue—it’s a generic RF engineering practice that is 
older than most of us here. 

Sent from my iPhone

> On Feb 9, 2021, at 5:17 PM, Ashutosh Singh via USRP-users 
>  wrote:
> 
> Hi all ,
> If I use my USRP b210 without duplexer to transmit and receive  the signals 
> from other USRP , will it not damage my USRP ?
> 
> Thanks 
> ___
> 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] Usrp b210 without duplexer

[Ashutosh Singh via USRP-users]

Hi all ,
If I use my USRP b210 without duplexer to transmit and receive  the signals
from other USRP , will it not damage my USRP ?

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

Re: [USRP-users] USRP B210 UHD library installation issue

[Ashutosh Singh via USRP-users]

Hi Matt,
Thank you for the mail .

If you see my other mail thread "connect OAI UE with OAI enb using DOCKER
EPC S1 interface" I have already tried these things,

Nothing worked out sadly!!

Even adding ppa is also not possible ..Some repo is broken I don't know ,
so I manually downloaded the packages for libuhd and compiled them. Please
check my mail thread. I am forwarding you . You will understand the exact
issue!!




On Wed, Jan 6, 2021 at 7:22 PM Matt Lanoue  wrote:

> Ashutosh,
>
> If you have already installed the UHD libraries for other OAI software
> applications, then you can run your build command without the -I flag.
> If your D2D build requires additional packages not currently installed
> on your system (which I doubt), then you may have to install them via
> your favorite package manager manually. Otherwise, you can modify the
> build script to try a different PPA such as ppa:ettusresearch/uhd
> (like Marcus suggested) or remove all UHD packages installed by the
> OAI script and build UHD from source in the same target destination.
> Be warned that the OAI scripts don't check if you have built UHD
> libraries from source, so if you installed them via a package manager
> at a future time, you might get version mismatches (Marcus helped me
> figure out this same problem on this list).
>
> If you are having troubles with the actual UHD library build, I
> recommend looking into your "cmake_targets/tools/build_helper" file to
> see what OAI actually does with " check_install_usrp_uhd_driver() " or
> "install_usrp_uhd_driver_from_source()". The "check" function actually
> performs the install and the "install from source" command doesn't
> appear to be called. I have made this complaint to the OAI distro and
> am working on pushing a better solution.
>
> Cheers,
> Matt
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 UHD library installation issue

[Matt Lanoue via USRP-users]

Ashutosh,

If you have already installed the UHD libraries for other OAI software
applications, then you can run your build command without the -I flag.
If your D2D build requires additional packages not currently installed
on your system (which I doubt), then you may have to install them via
your favorite package manager manually. Otherwise, you can modify the
build script to try a different PPA such as ppa:ettusresearch/uhd
(like Marcus suggested) or remove all UHD packages installed by the
OAI script and build UHD from source in the same target destination.
Be warned that the OAI scripts don't check if you have built UHD
libraries from source, so if you installed them via a package manager
at a future time, you might get version mismatches (Marcus helped me
figure out this same problem on this list).

If you are having troubles with the actual UHD library build, I
recommend looking into your "cmake_targets/tools/build_helper" file to
see what OAI actually does with " check_install_usrp_uhd_driver() " or
"install_usrp_uhd_driver_from_source()". The "check" function actually
performs the install and the "install from source" command doesn't
appear to be called. I have made this complaint to the OAI distro and
am working on pushing a better solution.

Cheers,
Matt

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

Re: [USRP-users] USRP B210 UHD library installation issue

[Ashutosh Singh via USRP-users]

Hi all ,
I am facing below problem to do sudo apt-get update after adding ppa . This
looking repo is broken . Can anyone comment on this . Its very Urgent !!

[image: image.png]

thanks
Ashutosh


On Sat, Jan 2, 2021 at 2:29 AM Marcus D. Leech 
wrote:

> On 12/31/2020 04:49 PM, Ashutosh Singh wrote:
>
> Hi Marcus,
> I tried tha as well but i think adding PPA repo is the onlY way to go
> (many UHD dependencies get solved by adding PPA repo and because of that
> some issues won't occur LATER while running the binary. Issues occurring
> about uhd library shared_ptr and all):
>
>
> I am not able to compile my binary on one system but its working fine on
> another system:
>
>
> root@yy217925:/home/lab_5g/LTE-D2D/cmake_targets# *./build_oai -I --UE*
> Will install external packages
> Will compile UE
> CMAKE_CMD=cmake ..
> RF HW set to None
> Flags for Deadline scheduler: False
> Flags for CPU Affinity: False
> 2. Setting the OAI PATHS ...
> OPENAIR_DIR= /home/lab_5g/LTE-D2D
> FreeDiameter prefix not found, install freeDiameter if EPC, HSS
> Installing packages
> Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease
> Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease
> Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease
> Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease
> Hit:6 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease
> Ign:5 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
> InRelease
> Err:7 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
> Release
>   404  Not Found [IP: 23.253.215.39 443]
> Reading package lists... Done
> E: The repository '
> http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
> Release' does not have a Release file.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.
> build have failed
>
>
>
>
> Please help!!
>
>
> This looks like a problem with the way OAI tries to build itself.  I don't
> use that stack myself, so I can't really help.
>
> There are perhaps others on here with OAI experience.
>
> I'll note that using the standard-repo provided UHD + friends seems to
> work fine for me for various test applications and Gnu Radio
>   applications, so your issue is mostly because the OAI build insists on
> that PPA, and the PPA is currently unavailable.
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 UHD library installation issue

[Marcus D. Leech via USRP-users]

On 12/31/2020 04:49 PM, Ashutosh Singh wrote:

Hi Marcus,
I tried tha as well but i think adding PPA repo is the onlY way to go 
(many UHD dependencies get solved by adding PPA repo and because of 
that some issues won't occur LATER while running the binary. Issues 
occurring about uhd library shared_ptr and all):



I am not able to compile my binary on one system but its working fine 
on another system:



root@yy217925:/home/lab_5g/LTE-D2D/cmake_targets# *./build_oai -I
--UE*
Will install external packages
Will compile UE
CMAKE_CMD=cmake ..
RF HW set to None
Flags for Deadline scheduler: False
Flags for CPU Affinity: False
2. Setting the OAI PATHS ...
OPENAIR_DIR= /home/lab_5g/LTE-D2D
FreeDiameter prefix not found, install freeDiameter if EPC, HSS
Installing packages
Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease
Hit:6 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease
Ign:5 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic InRelease
Err:7 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic Release
  404  Not Found [IP: 23.253.215.39 443]
Reading package lists... Done
E: The repository
'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.
build have failed




Please help!!


This looks like a problem with the way OAI tries to build itself.  I 
don't use that stack myself, so I can't really help.


There are perhaps others on here with OAI experience.

I'll note that using the standard-repo provided UHD + friends seems to 
work fine for me for various test applications and Gnu Radio
  applications, so your issue is mostly because the OAI build insists 
on that PPA, and the PPA is currently unavailable.



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

Re: [USRP-users] USRP B210 UHD library installation issue

[Ashutosh Singh via USRP-users]

Hi Marcus,
I tried tha as well but i think adding PPA repo is the onlY way to go (many
UHD dependencies get solved by adding PPA repo and because of that some
issues won't occur LATER while running the binary. Issues occurring about
uhd library shared_ptr and all):


I am not able to compile my binary on one system but its working fine on
another system:


root@yy217925:/home/lab_5g/LTE-D2D/cmake_targets# *./build_oai -I --UE*
Will install external packages
Will compile UE
CMAKE_CMD=cmake ..
RF HW set to None
Flags for Deadline scheduler: False
Flags for CPU Affinity: False
2. Setting the OAI PATHS ...
OPENAIR_DIR= /home/lab_5g/LTE-D2D
FreeDiameter prefix not found, install freeDiameter if EPC, HSS
Installing packages
Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease
Hit:6 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease
Ign:5 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
InRelease
Err:7 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
Release
  404  Not Found [IP: 23.253.215.39 443]
Reading package lists... Done
E: The repository '
http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic Release'
does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration
details.
build have failed




Please help!!


On Thu, Dec 31, 2020 at 2:13 AM Marcus D. Leech 
wrote:

> On 12/30/2020 03:54 PM, Ashutosh Singh wrote:
> > Any update over it !!
> >
> I'll point out that unless you need the latest UHD, Ubuntu 18.04
> (Bionic) packages UHD already--
>
> sudo apt-get install libuhd*
>
> Should do the trick without requiring the PPA.
>
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 UHD library installation issue

[Marcus D. Leech via USRP-users]

On 12/30/2020 03:54 PM, Ashutosh Singh wrote:

Any update over it !!

I'll point out that unless you need the latest UHD, Ubuntu 18.04 
(Bionic) packages UHD already--


sudo apt-get install libuhd*

Should do the trick without requiring the PPA.




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

Re: [USRP-users] USRP B210 UHD library installation issue

[Marcus D Leech via USRP-users]

Ettus R are aware of the issue. But it being Christmas break there likely 
won’t be any action for a couple of days. 



Sent from my iPhone

> On Dec 30, 2020, at 3:54 PM, Ashutosh Singh  
> wrote:
> 
> 
> Any update over it !!
> 
>> On Tue, Dec 29, 2020 at 6:28 PM Marcus D. Leech via USRP-users 
>>  wrote:
>>> On 12/29/2020 12:18 PM, Ashutosh Singh via USRP-users wrote:
>> 
>>> Hi ,
>>> I am trying to install the UHD libraries using binaries provided by Ettus 
>>> research following below page:
>>> USRP Hardware Driver and USRP Manual: Binary Installation (ettus.com)
>>> 
>>> 
>>> My System :
>>> 
>>> NAME="Ubuntu"
>>> VERSION="18.04.5 LTS (Bionic Beaver)"
>>> 
>>> 
>>> 
>>> Error:
>>> 
>>> root@yy217925:/home/lab_5g/openairinterface5g/openairinterface5g/cmake_targets/lte_build_oai/build#
>>>  sudo add-apt-repository ppa:ettusresearch/uhd
>>> 
>>>  More info: https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
>>> Press [ENTER] to continue or Ctrl-c to cancel adding it.
>>> 
>>> Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease
>>> Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease
>>> Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease
>>> Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease
>>> Hit:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu bionic InRelease
>>> Hit:7 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease
>>> Ign:6 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic 
>>> InRelease
>>> Err:8 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic 
>>> Release
>>>   404  Not Found [IP: 23.253.215.39 443]
>>> Reading package lists... Done
>>> E: The repository 
>>> 'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic Release' 
>>> does not have a Release file.
>>> N: Updating from such a repository can't be done securely, and is therefore 
>>> disabled by default.
>>> N: See apt-secure(8) manpage for repository creation and user configuration 
>>> details.
>>> 
>>> 
>>> 
>>> Please help me solve it !!
>>> 
>>> 
>>> 
>> 
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> This looks like broken PPA infrastructure.  I have a query in to Ettus 
>> engineering to see what's going on .
>> 
>> 
>> ___
>> 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 B210 UHD library installation issue

[Ashutosh Singh via USRP-users]

Any update over it !!

On Tue, Dec 29, 2020 at 6:28 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 12/29/2020 12:18 PM, Ashutosh Singh via USRP-users wrote:
>
> Hi ,
> I am trying to install the UHD libraries using binaries provided by Ettus
> research following below page:
> USRP Hardware Driver and USRP Manual: Binary Installation (ettus.com)
> 
>
>
> My System :
>
> NAME="Ubuntu"
> VERSION="18.04.5 LTS (Bionic Beaver)"
>
>
>
> *Error:*
>
> *root@yy217925:/home/lab_5g/openairinterface5g/openairinterface5g/cmake_targets/lte_build_oai/build#
> sudo add-apt-repository ppa:ettusresearch/uhd*
>
> * More info: https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
> *
> *Press [ENTER] to continue or Ctrl-c to cancel adding it.*
>
> *Hit:1 http://nl.archive.ubuntu.com/ubuntu
>  bionic InRelease*
> *Hit:2 http://nl.archive.ubuntu.com/ubuntu
>  bionic-updates InRelease*
> *Hit:3 http://nl.archive.ubuntu.com/ubuntu
>  bionic-backports InRelease*
> *Hit:4 http://nl.archive.ubuntu.com/ubuntu
>  bionic-security InRelease*
> *Hit:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu
>  bionic InRelease*
> *Hit:7 http://repo.zabbix.com/zabbix/5.0/ubuntu
>  bionic InRelease*
> *Ign:6 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
>  bionic
> InRelease*
> *Err:8 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
>  bionic
> Release*
> *  404  Not Found [IP: 23.253.215.39 443]*
> *Reading package lists... Done*
> *E: The repository
> 'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
>  bionic
> Release' does not have a Release file.*
> *N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.*
> *N: See apt-secure(8) manpage for repository creation and user
> configuration details.*
>
>
>
> Please help me solve it !!
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> This looks like broken PPA infrastructure.  I have a query in to Ettus
> engineering to see what's going on .
>
>
> ___
> 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 B210 UHD library installation issue

[Marcus D. Leech via USRP-users]

On 12/29/2020 12:18 PM, Ashutosh Singh via USRP-users wrote:

Hi ,
I am trying to install the UHD libraries using binaries provided by 
Ettus research following below page:
USRP Hardware Driver and USRP Manual: Binary Installation (ettus.com) 




My System :

NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"



*Error:*


/root@yy217925:/home/lab_5g/openairinterface5g/openairinterface5g/cmake_targets/lte_build_oai/build#*sudo
add-apt-repository ppa:ettusresearch/uhd*/
/
/
/ More info:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
/
/Press [ENTER] to continue or Ctrl-c to cancel adding it./
/
/
/Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease/
/Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease/
/Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease/
/Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease/
/Hit:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu bionic
InRelease/
/Hit:7 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease/
/Ign:6 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic InRelease/
/Err:8 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic Release/
/  404 Not Found [IP: 23.253.215.39 443]/
/Reading package lists... Done/
/E: The repository
'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
Release' does not have a Release file./
/N: Updating from such a repository can't be done securely, and is
therefore disabled by default./
/N: See apt-secure(8) manpage for repository creation and user
configuration details./



Please help me solve it !!




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This looks like broken PPA infrastructure.  I have a query in to Ettus 
engineering to see what's going on .



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

[USRP-users] USRP B210 UHD library installation issue

[Ashutosh Singh via USRP-users]

Hi ,
I am trying to install the UHD libraries using binaries provided by Ettus
research following below page:
USRP Hardware Driver and USRP Manual: Binary Installation (ettus.com)



My System :

NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"



*Error:*

*root@yy217925:/home/lab_5g/openairinterface5g/openairinterface5g/cmake_targets/lte_build_oai/build#
sudo add-apt-repository ppa:ettusresearch/uhd*

* More info: https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
*
*Press [ENTER] to continue or Ctrl-c to cancel adding it.*

*Hit:1 http://nl.archive.ubuntu.com/ubuntu
 bionic InRelease*
*Hit:2 http://nl.archive.ubuntu.com/ubuntu
 bionic-updates InRelease*
*Hit:3 http://nl.archive.ubuntu.com/ubuntu
 bionic-backports InRelease*
*Hit:4 http://nl.archive.ubuntu.com/ubuntu
 bionic-security InRelease*
*Hit:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu
 bionic InRelease*
*Hit:7 http://repo.zabbix.com/zabbix/5.0/ubuntu
 bionic InRelease*
*Ign:6 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
 bionic
InRelease*
*Err:8 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
 bionic
Release*
*  404  Not Found [IP: 23.253.215.39 443]*
*Reading package lists... Done*
*E: The repository
'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
 bionic
Release' does not have a Release file.*
*N: Updating from such a repository can't be done securely, and is
therefore disabled by default.*
*N: See apt-secure(8) manpage for repository creation and user
configuration details.*



Please help me solve it !!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/23/2020 12:26 PM, Prasad wrote:


I understand it is within the time spec. But the delay goes 
incremented linearly, it means if we wait for 30mins we are getting 
expected signal after 0.5milliseconds from the desire time boundary


So do we need to use rx streamer command to adjust it?.

Since none of us here (likely) are intimately familiar with your 5G 
implementation details, it's hard to say which "button to push" to make

  your implementation correctly deal with inevitable clock-slip.

You'll need a strategy, that's about as much as I can offer, since I'm 
not myself a 5G implementation expert.



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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 9:41 PM
To: Prasad; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/23/2020 11:47 AM, Prasad wrote:

 

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 9:16 PM
To: Prasad; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/23/2020 08:28 AM, Prasad wrote:

Dear Marcus,

 

Verified the code couple of time even tested bypassing USRP and it works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

 

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an apparent "time 
slip"?
30.72e6.

Nearly 40ms one-four sample delay.




 

You're seeing a one to four-sample slip over a period of 40ms, unless I 
misunderstand what you're saying.

At 30.72e6 SPS, that amounts to between 0.8 and 2.4PPM, which is within spec 
for the B210 without an external clock.

The clock quality necessarily determines not only frequency accuracy of the RF 
components, but also of everything else in the system
  including sampling.

I understand it is within the time spec. But the delay goes incremented 
linearly, it means if we wait for 30mins we are getting expected signal after 
0.5milliseconds from the desire time boundary 

So do we need to use rx streamer command to adjust it?.

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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/23/2020 11:47 AM, Prasad wrote:


*From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
*Sent:* Sunday, August 23, 2020 9:16 PM
*To:* Prasad; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP B210: getting RX samples with 
gradually increase delay


On 08/23/2020 08:28 AM, Prasad wrote:

Dear Marcus,

Verified the code couple of time even tested bypassing USRP and it
works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an 
apparent "time slip"?

30.72e6.

Nearly 40ms one-four sample delay.


You're seeing a one to four-sample slip over a period of 40ms, unless I 
misunderstand what you're saying.


At 30.72e6 SPS, that amounts to between 0.8 and 2.4PPM, which is within 
spec for the B210 without an external clock.


The clock quality necessarily determines not only frequency accuracy of 
the RF components, but also of everything else in the system

  including sampling.


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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

 

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 9:16 PM
To: Prasad; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/23/2020 08:28 AM, Prasad wrote:

Dear Marcus,

 

Verified the code couple of time even tested bypassing USRP and it works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

 

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an apparent "time 
slip"?
30.72e6.

Nearly 40ms one-four sample delay.



From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 6:56 AM
To: kp...@trilcomm.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/22/2020 09:08 PM, kp...@trilcomm.com wrote:

Yes relative delay between samples in buffer.

While detecting SYNC signal of 5G periodically, it  detects gradually increased 
delay from its expected position.

It means expected to receive at  2280 position of buffer but its keep detecting 
away from expected position, 2281,2282,2284, and so on.

 

Thanks,

Prasad.

 

My guess is that you have an off-by-one error in your buffer-harvesting code.  
This has nothing to do with the device.




 

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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/23/2020 08:28 AM, Prasad wrote:


Dear Marcus,

Verified the code couple of time even tested bypassing USRP and it 
works fine.


So, suspecting any time_spec either in RX or TX missing in the code?

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an apparent 
"time slip"?




*From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
*Sent:* Sunday, August 23, 2020 6:56 AM
*To:* kp...@trilcomm.com; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP B210: getting RX samples with 
gradually increase delay


On 08/22/2020 09:08 PM, kp...@trilcomm.com <mailto:kp...@trilcomm.com> 
wrote:


Yes relative delay between samples in buffer.

While detecting SYNC signal of 5G periodically, it  detects
gradually increased delay from its expected position.

It means expected to receive at  2280 position of buffer but its
keep detecting away from expected position,
2281,2282,2284, and so on.

Thanks,

Prasad.

My guess is that you have an off-by-one error in your 
buffer-harvesting code.  This has nothing to do with the device.




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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

Dear Marcus,

 

Verified the code couple of time even tested bypassing USRP and it works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

 

Regards,

Prasad.

 

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 6:56 AM
To: kp...@trilcomm.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/22/2020 09:08 PM, kp...@trilcomm.com wrote:

Yes relative delay between samples in buffer.

While detecting SYNC signal of 5G periodically, it  detects gradually increased 
delay from its expected position.

It means expected to receive at  2280 position of buffer but its keep detecting 
away from expected position, 2281,2282,2284, and so on.

 

Thanks,

Prasad.

 

My guess is that you have an off-by-one error in your buffer-harvesting code.  
This has nothing to do with the device.



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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/22/2020 09:08 PM, kp...@trilcomm.com wrote:

Yes relative delay between samples in buffer.
While detecting SYNC signal of 5G periodically, it  detects gradually 
increased delay from its expected position.
It means expected to receive at  2280 position of buffer but its keep 
detecting away from expected position, 2281,2282,2284, and so on.


Thanks,
Prasad.

My guess is that you have an off-by-one error in your buffer-harvesting 
code.  This has nothing to do with the device.



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

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/22/2020 11:27 AM, Prasad via USRP-users wrote:

Hi Marcus,

This delay is gradually increased and sometimes it goes beyond 0.5
milliseconds.
I think it is not like frequency error but the delay in receiving packet.
So are we missing anything during the UHD API ?

Thanks,
Prasad.
Delay *as measured where?*  Relative delay between samples in the same 
buffer?  Please be more specific...




-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com]
Sent: Tuesday, July 21, 2020 11:07 PM
To: usrp-users@lists.ettus.com; Prasad
Subject: Re: [USRP-users] 1 Ts delay in USRP B210

Hello Prasad,

I second everything Marcus L said, and will add:

In your first email you said this is about the UE.

UE (user equipment) are normally things like phones. These don't have
any great clocks of their own. They derive their clocks from that of the
network.

Sure, for prototyping, reducing the frequency error makes sense, but
even if both your basestation (gNodeB in 5G jargon) and your UE have
atomic clocks, they will be unsynchronized if either moves. Doppler!

So, in the end, if you're not in the business of evaluating
synchronization algorithms, you're probably requesting the wrong thing:
Make your UE implementation extract frequency information from the
received downlink signal (there's plenty of implicit and explicit info
in LTE/5G for exactly that), and live with the oscillator you have - it
only needs to be stable for short times. I'm almost certain that any
smartphone will have a worse oscillator than your B210 has.

Best regards,
Marcus M

On 21.07.20 18:38, Marcus D. Leech via USRP-users wrote:

On 07/21/2020 12:31 PM, Prasad wrote:

Then how we can handle this drift in our 5G-NR stack by using
/uhd_rx_streamer_issue_stream_cmd/?

Or we should go with GPSDO/external clock?

Thanks,


Well, since most users on here aren't experts on 5G stacks, me included,
I can't tell you what to do to your stack to handle
   clock drift.  But I WILL say that clock drift is an inevitable issue,
and as you get better clocks, the scale of that issue becomes
   smaller as you spend more money on better clocks.

A built-in GPSDO would not be a bad investment if clock drift at a scale
of 0.8PPM is an issue for your implementation.

Many digital demodulators implement algorithms for dealing with
clock-drift and imprecision on the rx side using PLLs and the like.
   But for 5G I have no idea how that would play out.



*From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
*Sent:* Tuesday, July 21, 2020 9:56 PM
*To:* Prasad; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] 1 Ts delay in USRP B210

On 07/21/2020 12:25 PM, Prasad wrote:

 We are using internal clock, don’t use any GPSDO or external clock.

 So for internal clock is this expected?

 Thanks,

The internal clock is specced to +/- 2PPM.   You're seeing much less
than that, so it's within spec.



*From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
Behalf Of *Marcus D. Leech via USRP-users
*Sent:* Tuesday, July 21, 2020 9:49 PM
*To:* usrp-users@lists.ettus.com 
*Subject:* Re: [USRP-users] 1 Ts delay in USRP B210

On 07/21/2020 12:13 PM, Prasad via USRP-users wrote:

 Soft reminder!

 Thanks,

 *From:*Prasad [mailto:kp...@trilcomm.com]
 *Sent:* Monday, July 20, 2020 7:58 PM
 *To:* 'usrp-users@lists.ettus.com
'
 *Cc:* 'Rao Yenamandra'
 *Subject:* 1 Ts delay in USRP B210

 Dear Team.

 Hope you are doing well and safe.

 We are bringing up our NR-5G UE stack with USRP B210.

 If time permits, would you pls. reply to below concern with your
 valuable information.

 During the synchronization procedure, we observe atleast /±/1
 /Ts/ (Sampling Time) drift in rx streamer in every  ~40ms time
period.

 Are we missing any time_spec during /uhd_rx_streamer_recv/ api or
 in /uhd_tx_streamer_send/ ?

 Master clock rate: 30.72e6

 Sampling rate: 30.72e6

 Carrier frequency: 3.8e9

 We use one B210 to transmit time domain samples back to back and
 others to receive.

 Log snippet:

 Init PSS detected with lag: /4469/ (/PSS detection offset from the
 slot boundary/ )

 sss has been detected

 Init PSS detected with lag: 4469

 sss has been detected

 Init PSS detected with lag: 4469

 sss has been detected

 Init PSS detected with lag: 4469

 sss has been detected

 Init PSS detected with lag: 4470 à1 Ts drift

 sss has been detected

 Init PSS detected with lag: 4470

 sss has been detected

 Init PSS detected with lag: 4470

 sss has been detected

 Init PSS detected with lag: 4471 à1 Ts drift.

 sss has been detected

 Init PSS detected with lag: 4472à1 Ts drift

 sss has been detected

 Init PSS detected with lag: 4472

 sss has been detected

 Init PSS detected with lag: 4472

 sss 

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

Hi Marcus,

This delay is gradually increased and sometimes it goes beyond 0.5
milliseconds.
I think it is not like frequency error but the delay in receiving packet.
So are we missing anything during the UHD API ?

Thanks,
Prasad.
-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: Tuesday, July 21, 2020 11:07 PM
To: usrp-users@lists.ettus.com; Prasad
Subject: Re: [USRP-users] 1 Ts delay in USRP B210

Hello Prasad,

I second everything Marcus L said, and will add:

In your first email you said this is about the UE.

UE (user equipment) are normally things like phones. These don't have
any great clocks of their own. They derive their clocks from that of the
network.

Sure, for prototyping, reducing the frequency error makes sense, but
even if both your basestation (gNodeB in 5G jargon) and your UE have
atomic clocks, they will be unsynchronized if either moves. Doppler!

So, in the end, if you're not in the business of evaluating
synchronization algorithms, you're probably requesting the wrong thing:
Make your UE implementation extract frequency information from the
received downlink signal (there's plenty of implicit and explicit info
in LTE/5G for exactly that), and live with the oscillator you have - it
only needs to be stable for short times. I'm almost certain that any
smartphone will have a worse oscillator than your B210 has.

Best regards,
Marcus M

On 21.07.20 18:38, Marcus D. Leech via USRP-users wrote:
> On 07/21/2020 12:31 PM, Prasad wrote:
>>
>> Then how we can handle this drift in our 5G-NR stack by using
>> /uhd_rx_streamer_issue_stream_cmd/?
>>
>> Or we should go with GPSDO/external clock?
>>
>> Thanks,
>>
> Well, since most users on here aren't experts on 5G stacks, me included,
> I can't tell you what to do to your stack to handle
>   clock drift.  But I WILL say that clock drift is an inevitable issue,
> and as you get better clocks, the scale of that issue becomes
>   smaller as you spend more money on better clocks.
> 
> A built-in GPSDO would not be a bad investment if clock drift at a scale
> of 0.8PPM is an issue for your implementation.
> 
> Many digital demodulators implement algorithms for dealing with
> clock-drift and imprecision on the rx side using PLLs and the like.
>   But for 5G I have no idea how that would play out.
> 
> 
>> *From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
>> *Sent:* Tuesday, July 21, 2020 9:56 PM
>> *To:* Prasad; usrp-users@lists.ettus.com
>> *Subject:* Re: [USRP-users] 1 Ts delay in USRP B210
>>
>> On 07/21/2020 12:25 PM, Prasad wrote:
>>
>>     We are using internal clock, don’t use any GPSDO or external clock.
>>
>>     So for internal clock is this expected?
>>
>>     Thanks,
>>
>> The internal clock is specced to +/- 2PPM.   You're seeing much less
>> than that, so it's within spec.
>>
>>
>>
>> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>> Behalf Of *Marcus D. Leech via USRP-users
>> *Sent:* Tuesday, July 21, 2020 9:49 PM
>> *To:* usrp-users@lists.ettus.com 
>> *Subject:* Re: [USRP-users] 1 Ts delay in USRP B210
>>
>> On 07/21/2020 12:13 PM, Prasad via USRP-users wrote:
>>
>>     Soft reminder!
>>
>>     Thanks,
>>
>>     *From:*Prasad [mailto:kp...@trilcomm.com]
>>     *Sent:* Monday, July 20, 2020 7:58 PM
>>     *To:* 'usrp-users@lists.ettus.com
>> '
>>     *Cc:* 'Rao Yenamandra'
>>     *Subject:* 1 Ts delay in USRP B210
>>
>>     Dear Team.
>>
>>     Hope you are doing well and safe.
>>
>>     We are bringing up our NR-5G UE stack with USRP B210.
>>
>>     If time permits, would you pls. reply to below concern with your
>>     valuable information.
>>
>>     During the synchronization procedure, we observe atleast /±/1
>>     /Ts/ (Sampling Time) drift in rx streamer in every  ~40ms time
>> period.
>>
>>     Are we missing any time_spec during /uhd_rx_streamer_recv/ api or
>>     in /uhd_tx_streamer_send/ ?
>>
>>     Master clock rate: 30.72e6
>>
>>     Sampling rate: 30.72e6
>>
>>     Carrier frequency: 3.8e9
>>
>>     We use one B210 to transmit time domain samples back to back and
>>     others to receive.
>>
>>     Log snippet:
>>
>>     Init PSS detected with lag: /4469/ (/PSS detection offset from the
>>     slot boundary/ )
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4469
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4469
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4469
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4470 à1 Ts drift
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4470
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4470
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4471 à1 Ts drift.
>>
>>     sss has been detected
>>
>>     Init PSS detected with lag: 4472à1 Ts drift
>>
>>     sss has been detected
>>
>>     Init PSS 

Re: [USRP-users] [USRP B210] Getting zero samples from received stream for 2 RX channel

[Marcus D. Leech via USRP-users]

On 08/12/2020 12:43 PM, kp...@trilcomm.com wrote:

Dear Marcus,
Any ither suggession please?


You didn't answer my questions:

Are you getting overrun indications on the console?'O' character 
being printed out

Does reducing the sample rate help?
What version of UHD are you using?
Does the 'rx_multi_samples' example application work properly?

Additionally:

What kind of computer?  What CPU?   What kind of USB controller?  Is 
this on Linux?  Under a VM or on the actual hardware?





*From:* Marcus D Leech 
*Sent:* Monday, 10 August, 2020, 10:34 pm
*To:* Prasad
*Cc:* usrp-users@lists.ettus.com; Rao Yenamandra
*Subject:* Re: [USRP-users] [USRP B210] Getting zero samples from 
received stream for 2 RX channel


What are you using to receive? Your own software? gnu Radio? UHD 
examples?


Please share the output of usrp_probe with us.



Sent from my iPhone

On Aug 10, 2020, at 12:53 PM, Prasad via USRP-users
 wrote:



Hi Everyone,

Getting zero samples from received stream, when number of RX
channel set to 2.

Bellows are the USRP setting:

Master-clock-rate: 30.72e6

Rate:

   Channel0: 30.72e6

   Channel1: 30.72e6

Gain:

   Channel0: 45

   Channel1: 45

Frequency:

   Channel0: 3.8GHz

Channel1: 3.8GHz

Thanks,

___
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 B210] Getting zero samples from received stream for 2 RX channel

[Prasad via USRP-users]

Hi Marcus,

 

Please find the below info.

 

Yes! We use our own software.

 

Usb_prob outputs: 

  _

 /

|   Device: B-Series Device

| _

|/

|   |   Mboard: B210

|   |   serial: 311B3EB

|   |   name: MyB210

|   |   product: 2

|   |   revision: 4

|   |   FW Version: 8.0

|   |   FPGA Version: 16.0

|   |   

|   |   Time sources:  none, internal, external, gpsdo

|   |   Clock sources: internal, external, gpsdo

|   |   Sensors: ref_locked

|   | _

|   |/

|   |   |   RX DSP: 0

|   |   |   

|   |   |   Freq range: -8.000 to 8.000 MHz

|   | _

|   |/

|   |   |   RX DSP: 1

|   |   |   

|   |   |   Freq range: -8.000 to 8.000 MHz

|   | _

|   |/

|   |   |   RX Dboard: A

|   |   | _

|   |   |/

|   |   |   |   RX Frontend: A

|   |   |   |   Name: FE-RX2

|   |   |   |   Antennas: TX/RX, RX2

|   |   |   |   Sensors: temp, rssi, lo_locked

|   |   |   |   Freq range: 50.000 to 6000.000 MHz

|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB

|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   | _

|   |   |/

|   |   |   |   RX Frontend: B

|   |   |   |   Name: FE-RX1

|   |   |   |   Antennas: TX/RX, RX2

|   |   |   |   Sensors: temp, rssi, lo_locked

|   |   |   |   Freq range: 50.000 to 6000.000 MHz

|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB

|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   | _

|   |   |/

|   |   |   |   RX Codec: A

|   |   |   |   Name: B210 RX dual ADC

|   |   |   |   Gain Elements: None

|   | _

|   |/

|   |   |   TX DSP: 0

|   |   |   

|   |   |   Freq range: -8.000 to 8.000 MHz

|   | _

|   |/

|   |   |   TX DSP: 1

|   |   |   

|   |   |   Freq range: -8.000 to 8.000 MHz

|   | _

|   |/

|   |   |   TX Dboard: A

|   |   | _

|   |   |/

|   |   |   |   TX Frontend: A

|   |   |   |   Name: FE-TX2

|   |   |   |   Antennas: TX/RX

|   |   |   |   Sensors: temp, lo_locked

|   |   |   |   Freq range: 50.000 to 6000.000 MHz

|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB

|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   | _

|   |   |/

|   |   |   |   TX Frontend: B

|   |   |   |   Name: FE-TX1

|   |   |   |   Antennas: TX/RX

|   |   |   |   Sensors: temp, lo_locked

|   |   |   |   Freq range: 50.000 to 6000.000 MHz

|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB

|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   | _

|   |   |/

|   |   |   |   TX Codec: A

|   |   |   |   Name: B210 TX dual DAC

|   |   |   |   Gain Elements: None

Regards,

Prasad.

 

From: Marcus D Leech [mailto:patchvonbr...@gmail.com] 
Sent: Monday, August 10, 2020 10:33 PM
To: Prasad
Cc: USRP-users@lists.ettus.com; Rao Yenamandra
Subject: Re: [USRP-users] [USRP B210] Getting zero samples from received stream 
for 2 RX channel

 

What are you using to receive? Your own software? gnu Radio? UHD examples?

 

Please share the output of usrp_probe with us. 

 

 

 

Sent from my iPhone





On Aug 10, 2020, at 12:53 PM, Prasad via USRP-users 
 wrote:

 

Hi Everyone,

 

Getting zero samples from received stream, when number of RX channel set to 2.

 

Bellows are the USRP setting:

Master-clock-rate: 30.72e6

Rate:

   Channel0: 30.72e6

   Channel1: 30.72e6

Gain: 

   Channel0: 45

   Channel1: 45

Frequency:

   Channel0: 3.8GHz

Channel1: 3.8GHz

 

Thanks,

___
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 B210] Getting zero samples from received stream for 2 RX channel

[Marcus D Leech via USRP-users]

What are you using to receive? Your own software? gnu Radio? UHD examples?

Please share the output of usrp_probe with us. 



Sent from my iPhone

> On Aug 10, 2020, at 12:53 PM, Prasad via USRP-users 
>  wrote:
> 
> 
> Hi Everyone,
>  
> Getting zero samples from received stream, when number of RX channel set to 2.
>  
> Bellows are the USRP setting:
> Master-clock-rate: 30.72e6
> Rate:
>Channel0: 30.72e6
>Channel1: 30.72e6
> Gain:
>Channel0: 45
>Channel1: 45
> Frequency:
>Channel0: 3.8GHz
> Channel1: 3.8GHz
>  
> Thanks,
> ___
> 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 B210] Very High Noise power at receiver

[Ron Economos via USRP-users]

In full duplex applications, it's very likely that you're interfering 
with yourself. Some sort of filter may be required on the receiver to 
attenuate the transmitter signal.


What kind of filter depends on the size of the duplex gap (the frequency 
span between transmit and receive). If the gap is large, then you can 
just use a high or low pass filter. For example:


https://www.minicircuits.com/WebStore/dashboard.html?model=VHF-1500%2B

Ron

On 8/1/20 23:03, Prasad via USRP-users wrote:

Soft reminder!.

Thanks!

-Original Message-
From: Prasad [mailto:kp...@trilcomm.com]
Sent: Wednesday, July 29, 2020 8:48 PM
To: 'Prasad'; 'Marcus Müller'; 'usrp-users@lists.ettus.com'
Subject: RE: [USRP-users] 1 Ts delay in USRP B210

Hi Muller/All,

Just a quick question.
During our 5G-NR integration with USRP B210, we observe very high noise
power at receiver.
Is it expected behavior ?
PBCH rsrp: -13.775554 dBm, SNR: -12.942591 dB, NOISE_POWER: -0.832963 dBm,
rssi: 1.643662dBm.

Applied gain in USRP:
Tx Gain: 45
Rx Gain: 45
Transmit power:- 0dBm.

Regards,
Prasad.


___
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 B210] Very High Noise power at receiver

[Prasad via USRP-users]

Soft reminder!.

Thanks!

-Original Message-
From: Prasad [mailto:kp...@trilcomm.com] 
Sent: Wednesday, July 29, 2020 8:48 PM
To: 'Prasad'; 'Marcus Müller'; 'usrp-users@lists.ettus.com'
Subject: RE: [USRP-users] 1 Ts delay in USRP B210

Hi Muller/All, 

Just a quick question.
During our 5G-NR integration with USRP B210, we observe very high noise
power at receiver.
Is it expected behavior ?
PBCH rsrp: -13.775554 dBm, SNR: -12.942591 dB, NOISE_POWER: -0.832963 dBm,
rssi: 1.643662dBm.

Applied gain in USRP:
Tx Gain: 45
Rx Gain: 45
Transmit power:- 0dBm.

Regards,
Prasad.


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

Re: [USRP-users] [USRP B210] Very High Noise power at receiver

[Marcus D. Leech via USRP-users]

On 07/30/2020 11:56 AM, Prasad via USRP-users wrote:

Soft reminder!.

Thanks!

-Original Message-
From: Prasad [mailto:kp...@trilcomm.com]
Sent: Wednesday, July 29, 2020 8:48 PM
To: 'Prasad'; 'Marcus Müller'; 'usrp-users@lists.ettus.com'
Subject: RE: [USRP-users] 1 Ts delay in USRP B210

Hi Muller,

Just a quick question.
During our 5G-NR integration with USRP B210, we observe very high noise
power at receiver.
Is it expected behavior ?
PBCH rsrp: -13.775554 dBm, SNR: -12.942591 dB, NOISE_POWER: -0.832963 dBm,
rssi: 1.643662dBm.

Applied gain in USRP:
Tx Gain: 45
Rx Gain: 45
Transmit power:- 0dBm.
There's no way with a B210 with a TX gain of 45, you're getting 0dBm out 
the antenna.  The device can produce a maximum of about 10dBm, and
  with the TX gain range topping out at something like 80dB, your 35dB 
below the 10dBm point.   Similarly, the RX gain range is almost 80dB, so
  you've got the gain set for about 30dB of attenuation in the RX 
path.  You're using antennae or a direct connection?





Regards,
Prasad.

-Original Message-
From: Prasad [mailto:kp...@trilcomm.com]
Sent: Wednesday, July 22, 2020 10:21 PM
To: 'Marcus Müller'; 'usrp-users@lists.ettus.com'
Subject: RE: [USRP-users] 1 Ts delay in USRP B210

Thanks! a lot Marcus M and Marcus D for your valuable information.

Thanks,

-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com]
Sent: Tuesday, July 21, 2020 11:07 PM
To: usrp-users@lists.ettus.com; Prasad
Subject: Re: [USRP-users] 1 Ts delay in USRP B210

Hello Prasad,

I second everything Marcus L said, and will add:

In your first email you said this is about the UE.

UE (user equipment) are normally things like phones. These don't have
any great clocks of their own. They derive their clocks from that of the
network.

Sure, for prototyping, reducing the frequency error makes sense, but
even if both your basestation (gNodeB in 5G jargon) and your UE have
atomic clocks, they will be unsynchronized if either moves. Doppler!

So, in the end, if you're not in the business of evaluating
synchronization algorithms, you're probably requesting the wrong thing:
Make your UE implementation extract frequency information from the
received downlink signal (there's plenty of implicit and explicit info
in LTE/5G for exactly that), and live with the oscillator you have - it
only needs to be stable for short times. I'm almost certain that any
smartphone will have a worse oscillator than your B210 has.

Best regards,
Marcus M

On 21.07.20 18:38, Marcus D. Leech via USRP-users wrote:

On 07/21/2020 12:31 PM, Prasad wrote:

Then how we can handle this drift in our 5G-NR stack by using
/uhd_rx_streamer_issue_stream_cmd/?

Or we should go with GPSDO/external clock?

Thanks,


Well, since most users on here aren't experts on 5G stacks, me included,
I can't tell you what to do to your stack to handle
   clock drift.  But I WILL say that clock drift is an inevitable issue,
and as you get better clocks, the scale of that issue becomes
   smaller as you spend more money on better clocks.

A built-in GPSDO would not be a bad investment if clock drift at a scale
of 0.8PPM is an issue for your implementation.

Many digital demodulators implement algorithms for dealing with
clock-drift and imprecision on the rx side using PLLs and the like.
   But for 5G I have no idea how that would play out.



*From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
*Sent:* Tuesday, July 21, 2020 9:56 PM
*To:* Prasad; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] 1 Ts delay in USRP B210

On 07/21/2020 12:25 PM, Prasad wrote:

 We are using internal clock, don’t use any GPSDO or external clock.

 So for internal clock is this expected?

 Thanks,

The internal clock is specced to +/- 2PPM.   You're seeing much less
than that, so it's within spec.



*From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
Behalf Of *Marcus D. Leech via USRP-users
*Sent:* Tuesday, July 21, 2020 9:49 PM
*To:* usrp-users@lists.ettus.com 
*Subject:* Re: [USRP-users] 1 Ts delay in USRP B210

On 07/21/2020 12:13 PM, Prasad via USRP-users wrote:

 Soft reminder!

 Thanks,

 *From:*Prasad [mailto:kp...@trilcomm.com]
 *Sent:* Monday, July 20, 2020 7:58 PM
 *To:* 'usrp-users@lists.ettus.com
'
 *Cc:* 'Rao Yenamandra'
 *Subject:* 1 Ts delay in USRP B210

 Dear Team.

 Hope you are doing well and safe.

 We are bringing up our NR-5G UE stack with USRP B210.

 If time permits, would you pls. reply to below concern with your
 valuable information.

 During the synchronization procedure, we observe atleast /±/1
 /Ts/ (Sampling Time) drift in rx streamer in every  ~40ms time
period.

 Are we missing any time_spec during /uhd_rx_streamer_recv/ api or
 in /uhd_tx_streamer_send/ ?

 Master clock rate: 30.72e6

 Sampling rate: 30.72e6

 Carrier frequency: 

[USRP-users] [USRP B210] Very High Noise power at receiver

[Prasad via USRP-users]

Soft reminder!.

Thanks!

-Original Message-
From: Prasad [mailto:kp...@trilcomm.com] 
Sent: Wednesday, July 29, 2020 8:48 PM
To: 'Prasad'; 'Marcus Müller'; 'usrp-users@lists.ettus.com'
Subject: RE: [USRP-users] 1 Ts delay in USRP B210

Hi Muller, 

Just a quick question.
During our 5G-NR integration with USRP B210, we observe very high noise
power at receiver.
Is it expected behavior ?
PBCH rsrp: -13.775554 dBm, SNR: -12.942591 dB, NOISE_POWER: -0.832963 dBm,
rssi: 1.643662dBm.

Applied gain in USRP:
Tx Gain: 45
Rx Gain: 45
Transmit power:- 0dBm.

Regards,
Prasad.

-Original Message-
From: Prasad [mailto:kp...@trilcomm.com] 
Sent: Wednesday, July 22, 2020 10:21 PM
To: 'Marcus Müller'; 'usrp-users@lists.ettus.com'
Subject: RE: [USRP-users] 1 Ts delay in USRP B210

Thanks! a lot Marcus M and Marcus D for your valuable information.

Thanks,

-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: Tuesday, July 21, 2020 11:07 PM
To: usrp-users@lists.ettus.com; Prasad
Subject: Re: [USRP-users] 1 Ts delay in USRP B210

Hello Prasad,

I second everything Marcus L said, and will add:

In your first email you said this is about the UE.

UE (user equipment) are normally things like phones. These don't have
any great clocks of their own. They derive their clocks from that of the
network.

Sure, for prototyping, reducing the frequency error makes sense, but
even if both your basestation (gNodeB in 5G jargon) and your UE have
atomic clocks, they will be unsynchronized if either moves. Doppler!

So, in the end, if you're not in the business of evaluating
synchronization algorithms, you're probably requesting the wrong thing:
Make your UE implementation extract frequency information from the
received downlink signal (there's plenty of implicit and explicit info
in LTE/5G for exactly that), and live with the oscillator you have - it
only needs to be stable for short times. I'm almost certain that any
smartphone will have a worse oscillator than your B210 has.

Best regards,
Marcus M

On 21.07.20 18:38, Marcus D. Leech via USRP-users wrote:
> On 07/21/2020 12:31 PM, Prasad wrote:
>>
>> Then how we can handle this drift in our 5G-NR stack by using
>> /uhd_rx_streamer_issue_stream_cmd/?
>>
>> Or we should go with GPSDO/external clock?
>>
>> Thanks,
>>
> Well, since most users on here aren't experts on 5G stacks, me included,
> I can't tell you what to do to your stack to handle
>   clock drift.  But I WILL say that clock drift is an inevitable issue,
> and as you get better clocks, the scale of that issue becomes
>   smaller as you spend more money on better clocks.
> 
> A built-in GPSDO would not be a bad investment if clock drift at a scale
> of 0.8PPM is an issue for your implementation.
> 
> Many digital demodulators implement algorithms for dealing with
> clock-drift and imprecision on the rx side using PLLs and the like.
>   But for 5G I have no idea how that would play out.
> 
> 
>> *From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
>> *Sent:* Tuesday, July 21, 2020 9:56 PM
>> *To:* Prasad; usrp-users@lists.ettus.com
>> *Subject:* Re: [USRP-users] 1 Ts delay in USRP B210
>>
>> On 07/21/2020 12:25 PM, Prasad wrote:
>>
>>     We are using internal clock, don’t use any GPSDO or external clock.
>>
>>     So for internal clock is this expected?
>>
>>     Thanks,
>>
>> The internal clock is specced to +/- 2PPM.   You're seeing much less
>> than that, so it's within spec.
>>
>>
>>
>> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>> Behalf Of *Marcus D. Leech via USRP-users
>> *Sent:* Tuesday, July 21, 2020 9:49 PM
>> *To:* usrp-users@lists.ettus.com 
>> *Subject:* Re: [USRP-users] 1 Ts delay in USRP B210
>>
>> On 07/21/2020 12:13 PM, Prasad via USRP-users wrote:
>>
>>     Soft reminder!
>>
>>     Thanks,
>>
>>     *From:*Prasad [mailto:kp...@trilcomm.com]
>>     *Sent:* Monday, July 20, 2020 7:58 PM
>>     *To:* 'usrp-users@lists.ettus.com
>> '
>>     *Cc:* 'Rao Yenamandra'
>>     *Subject:* 1 Ts delay in USRP B210
>>
>>     Dear Team.
>>
>>     Hope you are doing well and safe.
>>
>>     We are bringing up our NR-5G UE stack with USRP B210.
>>
>>     If time permits, would you pls. reply to below concern with your
>>     valuable information.
>>
>>     During the synchronization procedure, we observe atleast /±/1
>>     /Ts/ (Sampling Time) drift in rx streamer in every  ~40ms time
>> period.
>>
>>     Are we missing any time_spec during /uhd_rx_streamer_recv/ api or
>>     in /uhd_tx_streamer_send/ ?
>>
>>     Master clock rate: 30.72e6
>>
>>     Sampling rate: 30.72e6
>>
>>     Carrier frequency: 3.8e9
>>
>>     We use one B210 to transmit time domain samples back to back and
>>     others to receive.
>>
>>     Log snippet:
>>
>>     Init PSS detected with lag: /4469/ (/PSS detection offset from the
>>     slot boundary/ )
>>
>>     sss has been detected
>>
>>     Init PSS 

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] USRP B210 ERROR

[Marcus D Leech via USRP-users]

What does ‘lsusb’ show with the device plugged in?


Sent from my iPhone

> On Oct 15, 2019, at 3:50 PM, Sam Reiter via USRP-users 
>  wrote:
> 
> Khizar,
> 
> Is this still an issue for you? There's an important step in the UHD install 
> process to allow USB devices to be used by non-root users:
> 
> https://files.ettus.com/manual/page_transport.html#transport_usb_udev
> 
> Let me know if this does the trick.
> 
> Sam
> 
>> On Tue, Sep 24, 2019 at 1:10 AM Khizar Abbas via USRP-users 
>>  wrote:
>> I have tried this  /usr/local/lib/uhd/utils/uhd_images_downloader.py 
>> download the image and install it. but the error is still same no device 
>> found. Even i have tried to download the drivers again. still same error. 
>> Please suggest some solution. Below is log in the response of the command . 
>> check the error in Bold text below. 
>> Thanks
>> ncl@rasputin:~/openairinterface5g/cmake_targets/lte_build_oai/build$ sudo -E 
>> ./lte-uesoftmodem -C 262500 -r 25 --ue-rxgain 125 --ue-txgain 90 
>> --ue-scan-carrier -d
>> [CONFIG] get parameters from cmdline , debug flags: 0x0040
>> # /dev/cpu_dma_latency set to 0us
>> [CONFIG] log_config: 2/3 parameters successfully set 
>> [CONFIG] log_config: 42/42 parameters successfully set 
>> [CONFIG] log_config: 42/42 parameters successfully set 
>> [CONFIG] log_config: 15/15 parameters successfully set 
>> [CONFIG] log_config: 15/15 parameters successfully set 
>> log init done
>> Reading in command-line options
>> [CONFIG] (root): 19/22 parameters successfully set 
>> [CONFIG] (root): 4/5 parameters successfully set 
>> [ENB_APP]   nfapi running mode: MONOLITHIC
>> Running with 1 UE instances
>> [CONFIG] TTracer: 4/4 parameters successfully set 
>> CPU Freq is 3.000175 
>> ITTI init
>> [TMR]   Starting itti queue: TASK_UNKNOWN as task 0
>> [TMR]   Starting itti queue: TASK_TIMER as task 1
>> [TMR]   Starting itti queue: TASK_L2L1 as task 2
>> [TMR]   Starting itti queue: TASK_BM as task 3
>> [TMR]   Starting itti queue: TASK_PHY_ENB as task 4
>> [TMR]   Starting itti queue: TASK_MAC_ENB as task 5
>> [TMR]   Starting itti queue: TASK_RLC_ENB as task 6
>> [TMR]   Starting itti queue: TASK_RRC_ENB_NB_IoT as task 7
>> [TMR]   Starting itti queue: TASK_PDCP_ENB as task 8
>> [TMR]   Starting itti queue: TASK_DATA_FORWARDING as task 9
>> [TMR]   Starting itti queue: TASK_END_MARKER as task 10
>> [TMR]   Starting itti queue: TASK_RRC_ENB as task 11
>> [TMR]   Starting itti queue: TASK_RAL_ENB as task 12
>> [TMR]   Starting itti queue: TASK_S1AP as task 13
>> [TMR]   Starting itti queue: TASK_X2AP as task 14
>> [TMR]   Starting itti queue: TASK_SCTP as task 15
>> [TMR]   Starting itti queue: TASK_ENB_APP as task 16
>> [TMR]   Starting itti queue: TASK_FLEXRAN_AGENT as task 17
>> [TMR]   Starting itti queue: TASK_PHY_UE as task 18
>> [TMR]   Starting itti queue: TASK_MAC_UE as task 19
>> [TMR]   Starting itti queue: TASK_RLC_UE as task 20
>> [TMR]   Starting itti queue: TASK_PDCP_UE as task 21
>> [TMR]   Starting itti queue: TASK_RRC_UE as task 22
>> [TMR]   Starting itti queue: TASK_NAS_UE as task 23
>> [TMR]   Starting itti queue: TASK_RAL_UE as task 24
>> [TMR]   Starting itti queue: TASK_MSC as task 25
>> [TMR]   Starting itti queue: TASK_GTPV1_U as task 26
>> [TMR]   Starting itti queue: TASK_UDP as task 27
>> [TMR]   Starting itti queue: TASK_CU_F1 as task 28
>> [TMR]   Starting itti queue: TASK_DU_F1 as task 29
>> [CONFIG] opt: 3/3 parameters successfully set 
>> [OPT]   OPT disabled
>> [PDCP]   pdcp init,usegtp 
>> RRC control socket
>> PDCP PC5S socket
>> [RRC]   Listening to incoming connection from ProSe App 
>> reported resolution = 1 ns
>> [HW]   Version: Branch: develop Abrev. Hash: f8288afe1 Date: Wed Jul 24 
>> 23:00:59 2019 +0200
>> Card 0, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq 
>> 262500.00, rx_freq 262500.00
>> Card 0, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 0, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 0, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> [PHY]   USRP clock source not specified. defaulting to internal
>> Card 1, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq 
>> 262500.00, rx_freq 262500.00
>> Card 1, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 1, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> Card 1, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 0.00, rx_freq 0.00
>> [PHY]   USRP clock source not specified. defaulting to internal
>> Card 2, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq 
>> 262500.00, rx_freq 262500.00
>> Card 2, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq 
>> 

Re: [USRP-users] USRP B210 ERROR

[Sam Reiter via USRP-users]

Khizar,

Is this still an issue for you? There's an important step in the UHD
install process to allow USB devices to be used by non-root users:

https://files.ettus.com/manual/page_transport.html#transport_usb_udev

Let me know if this does the trick.

Sam

On Tue, Sep 24, 2019 at 1:10 AM Khizar Abbas via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have tried this  /usr/local/lib/uhd/utils/uhd_images_downloader.py
> download the image and install it. but the error is still same no device
> found. Even i have tried to download the drivers again. still same error.
> Please suggest some solution. Below is log in the response of the command .
> check the error in Bold text below.
> Thanks
> ncl@rasputin:~/openairinterface5g/cmake_targets/lte_build_oai/build$ sudo
> -E ./lte-uesoftmodem -C 262500 -r 25 --ue-rxgain 125 --ue-txgain 90
> --ue-scan-carrier -d
> [CONFIG] get parameters from cmdline , debug flags: 0x0040
> # /dev/cpu_dma_latency set to 0us
> [CONFIG] log_config: 2/3 parameters successfully set
> [CONFIG] log_config: 42/42 parameters successfully set
> [CONFIG] log_config: 42/42 parameters successfully set
> [CONFIG] log_config: 15/15 parameters successfully set
> [CONFIG] log_config: 15/15 parameters successfully set
> log init done
> Reading in command-line options
> [CONFIG] (root): 19/22 parameters successfully set
> [CONFIG] (root): 4/5 parameters successfully set
> [ENB_APP]   nfapi running mode: MONOLITHIC
> Running with 1 UE instances
> [CONFIG] TTracer: 4/4 parameters successfully set
> CPU Freq is 3.000175
> ITTI init
> [TMR]   Starting itti queue: TASK_UNKNOWN as task 0
> [TMR]   Starting itti queue: TASK_TIMER as task 1
> [TMR]   Starting itti queue: TASK_L2L1 as task 2
> [TMR]   Starting itti queue: TASK_BM as task 3
> [TMR]   Starting itti queue: TASK_PHY_ENB as task 4
> [TMR]   Starting itti queue: TASK_MAC_ENB as task 5
> [TMR]   Starting itti queue: TASK_RLC_ENB as task 6
> [TMR]   Starting itti queue: TASK_RRC_ENB_NB_IoT as task 7
> [TMR]   Starting itti queue: TASK_PDCP_ENB as task 8
> [TMR]   Starting itti queue: TASK_DATA_FORWARDING as task 9
> [TMR]   Starting itti queue: TASK_END_MARKER as task 10
> [TMR]   Starting itti queue: TASK_RRC_ENB as task 11
> [TMR]   Starting itti queue: TASK_RAL_ENB as task 12
> [TMR]   Starting itti queue: TASK_S1AP as task 13
> [TMR]   Starting itti queue: TASK_X2AP as task 14
> [TMR]   Starting itti queue: TASK_SCTP as task 15
> [TMR]   Starting itti queue: TASK_ENB_APP as task 16
> [TMR]   Starting itti queue: TASK_FLEXRAN_AGENT as task 17
> [TMR]   Starting itti queue: TASK_PHY_UE as task 18
> [TMR]   Starting itti queue: TASK_MAC_UE as task 19
> [TMR]   Starting itti queue: TASK_RLC_UE as task 20
> [TMR]   Starting itti queue: TASK_PDCP_UE as task 21
> [TMR]   Starting itti queue: TASK_RRC_UE as task 22
> [TMR]   Starting itti queue: TASK_NAS_UE as task 23
> [TMR]   Starting itti queue: TASK_RAL_UE as task 24
> [TMR]   Starting itti queue: TASK_MSC as task 25
> [TMR]   Starting itti queue: TASK_GTPV1_U as task 26
> [TMR]   Starting itti queue: TASK_UDP as task 27
> [TMR]   Starting itti queue: TASK_CU_F1 as task 28
> [TMR]   Starting itti queue: TASK_DU_F1 as task 29
> [CONFIG] opt: 3/3 parameters successfully set
> [OPT]   OPT disabled
> [PDCP]   pdcp init,usegtp
> RRC control socket
> PDCP PC5S socket
> [RRC]   Listening to incoming connection from ProSe App
> reported resolution = 1 ns
> [HW]   Version: Branch: develop Abrev. Hash: f8288afe1 Date: Wed Jul 24
> 23:00:59 2019 +0200
> Card 0, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
> 262500.00, rx_freq 262500.00
> Card 0, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 0, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 0, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> [PHY]   USRP clock source not specified. defaulting to internal
> Card 1, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
> 262500.00, rx_freq 262500.00
> Card 1, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 1, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 1, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> [PHY]   USRP clock source not specified. defaulting to internal
> Card 2, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
> 262500.00, rx_freq 262500.00
> Card 2, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 2, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> Card 2, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
> 0.00, rx_freq 0.00
> [PHY]   USRP clock source not 

[USRP-users] USRP B210 ERROR

[Khizar Abbas via USRP-users]

I have tried this  /usr/local/lib/uhd/utils/uhd_images_downloader.py
download the image and install it. but the error is still same no device
found. Even i have tried to download the drivers again. still same error.
Please suggest some solution. Below is log in the response of the command .
check the error in Bold text below.
Thanks
ncl@rasputin:~/openairinterface5g/cmake_targets/lte_build_oai/build$ sudo
-E ./lte-uesoftmodem -C 262500 -r 25 --ue-rxgain 125 --ue-txgain 90
--ue-scan-carrier -d
[CONFIG] get parameters from cmdline , debug flags: 0x0040
# /dev/cpu_dma_latency set to 0us
[CONFIG] log_config: 2/3 parameters successfully set
[CONFIG] log_config: 42/42 parameters successfully set
[CONFIG] log_config: 42/42 parameters successfully set
[CONFIG] log_config: 15/15 parameters successfully set
[CONFIG] log_config: 15/15 parameters successfully set
log init done
Reading in command-line options
[CONFIG] (root): 19/22 parameters successfully set
[CONFIG] (root): 4/5 parameters successfully set
[ENB_APP]   nfapi running mode: MONOLITHIC
Running with 1 UE instances
[CONFIG] TTracer: 4/4 parameters successfully set
CPU Freq is 3.000175
ITTI init
[TMR]   Starting itti queue: TASK_UNKNOWN as task 0
[TMR]   Starting itti queue: TASK_TIMER as task 1
[TMR]   Starting itti queue: TASK_L2L1 as task 2
[TMR]   Starting itti queue: TASK_BM as task 3
[TMR]   Starting itti queue: TASK_PHY_ENB as task 4
[TMR]   Starting itti queue: TASK_MAC_ENB as task 5
[TMR]   Starting itti queue: TASK_RLC_ENB as task 6
[TMR]   Starting itti queue: TASK_RRC_ENB_NB_IoT as task 7
[TMR]   Starting itti queue: TASK_PDCP_ENB as task 8
[TMR]   Starting itti queue: TASK_DATA_FORWARDING as task 9
[TMR]   Starting itti queue: TASK_END_MARKER as task 10
[TMR]   Starting itti queue: TASK_RRC_ENB as task 11
[TMR]   Starting itti queue: TASK_RAL_ENB as task 12
[TMR]   Starting itti queue: TASK_S1AP as task 13
[TMR]   Starting itti queue: TASK_X2AP as task 14
[TMR]   Starting itti queue: TASK_SCTP as task 15
[TMR]   Starting itti queue: TASK_ENB_APP as task 16
[TMR]   Starting itti queue: TASK_FLEXRAN_AGENT as task 17
[TMR]   Starting itti queue: TASK_PHY_UE as task 18
[TMR]   Starting itti queue: TASK_MAC_UE as task 19
[TMR]   Starting itti queue: TASK_RLC_UE as task 20
[TMR]   Starting itti queue: TASK_PDCP_UE as task 21
[TMR]   Starting itti queue: TASK_RRC_UE as task 22
[TMR]   Starting itti queue: TASK_NAS_UE as task 23
[TMR]   Starting itti queue: TASK_RAL_UE as task 24
[TMR]   Starting itti queue: TASK_MSC as task 25
[TMR]   Starting itti queue: TASK_GTPV1_U as task 26
[TMR]   Starting itti queue: TASK_UDP as task 27
[TMR]   Starting itti queue: TASK_CU_F1 as task 28
[TMR]   Starting itti queue: TASK_DU_F1 as task 29
[CONFIG] opt: 3/3 parameters successfully set
[OPT]   OPT disabled
[PDCP]   pdcp init,usegtp
RRC control socket
PDCP PC5S socket
[RRC]   Listening to incoming connection from ProSe App
reported resolution = 1 ns
[HW]   Version: Branch: develop Abrev. Hash: f8288afe1 Date: Wed Jul 24
23:00:59 2019 +0200
Card 0, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
262500.00, rx_freq 262500.00
Card 0, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 0, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 0, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
[PHY]   USRP clock source not specified. defaulting to internal
Card 1, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
262500.00, rx_freq 262500.00
Card 1, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 1, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 1, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
[PHY]   USRP clock source not specified. defaulting to internal
Card 2, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
262500.00, rx_freq 262500.00
Card 2, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 2, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 2, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
[PHY]   USRP clock source not specified. defaulting to internal
Card 3, channel 0, Setting tx_gain 90.00, rx_gain 125.00, tx_freq
262500.00, rx_freq 262500.00
Card 3, channel 1, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 3, channel 2, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
Card 3, channel 3, Setting tx_gain 0.00, rx_gain 125.00, tx_freq
0.00, rx_freq 0.00
[PHY]   USRP clock source not specified. defaulting to internal
Card 4, channel 0, 

Re: [USRP-users] USRP B210 Error

[Michael Dickens via USRP-users]

Hi Khizar - Have you tried doing what the error recommends ... executing
"/usr/local/lib/uhd/utils/uhd_images_downloader.py"? It could be that you
just need to download the images for your specific UHD install. Hope this
helps! - MLD

On Thu, Sep 19, 2019 at 4:03 AM Khizar Abbas via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
> i am using two USRP b210 device for my project. My goal is to deploy LTE
> connection . but one of my device is working properly and other one is
> showing error no device found.
> when i used the sudo uhd_usrp_probecommand. its shows error
> UHD Warning:
> EnvironmentError: IOError: Could not find path for image:
> usrp_b200_fw.hex
> Using images directory: 
> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow
> the below instructions to download the images package.
> Please run:
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
> Error: LookupError: KeyError: No devices found for ->
> Empty Device Address
>
> I have already tried many solution from internet but dont get
> success.Please suggest me any proper solution for this error.
>
> Thanks
> Khizar abbas
> Jeju national University SOuth Korea
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

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

[USRP-users] USRP B210 Error

[Khizar Abbas via USRP-users]

Dear all,
i am using two USRP b210 device for my project. My goal is to deploy LTE
connection . but one of my device is working properly and other one is
showing error no device found.
when i used the sudo uhd_usrp_probecommand. its shows error
UHD Warning:
EnvironmentError: IOError: Could not find path for image:
usrp_b200_fw.hex
Using images directory: 
Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow
the below instructions to download the images package.
Please run:
 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
Error: LookupError: KeyError: No devices found for ->
Empty Device Address

I have already tried many solution from internet but dont get
success.Please suggest me any proper solution for this error.

Thanks
Khizar abbas
Jeju national University SOuth Korea
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP B210 FPGA Amplify-forward

[Razvan-Andrei Stoica via USRP-users]

Hello,



I am working with 2 B210 units trying to realize an out-of-band amplify-forward 
wideband relay.



The signal flow is simple and was already implemented using the GNURadio blocks 
and associated UHD USRP drivers.



The input signal is DCed to BB by one of the RF ends and additionally amplified 
if need be in SW. The output is then rerouted to the second RF end on a higher 
frequency then that of the output.



The second device performs the same operations but reconverts the relayed 
signal to the initial frequency band.



This works quite okay with the host processing and control over a BW of 22 
Msps, with the occasional bursts of lost samples.



However, due to latency reasons and easier deployment I would like to 
understand if it is possible to implement this simple signal processing logic 
on the FPGA and flash this module such that it operates automatically upon the 
loading of the firmware.



Any advice or guides / tutorials on doing this would be greatly appreciated!



Best,

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

[USRP-users] USRP B210 GPS

[Davide Righini via USRP-users]

Dear all,

I'm trying to generate synchronized pulses with specific timing, based on
the GPS synchronization.

The idea is to send these pulses at approximately the "same time" from
multiple USRPs.

 

I have two B210 with an internal GPS module. 

I use this environment: GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.11.0.HEAD-0-ga1b5c4ae

The usrp are connected to a laptop with Linux virtual machine.

With this configuration I can run my code and the uhd examples without any
problem.

 

Since I need a to generate a pulse at a specific time (for example a pulse
every second), I use the following code:

 

// wait for GPS look procedure and synchronization of USRP
time to GPS time (as uhd example: sync_to_gps.cpp )

uhd::time_spec_t time_last_pps = tx_usrp->get_time_now(mboard); 

--> while (!( (time_last_pps.get_tick_count(1) < 3))) {

time_last_pps = tx_usrp->get_time_now(mboard);

}

// send pulse

 

When the usrp is running the while cycle the CPU of the connected laptop is
heavily charged and on the USB port a lot of data is flowing.

I supposed that the function get_time_now() does not need to communicate
with the laptop. 

Someone can explain why I get this flow of data between laptop and USRP
during this 'while' cycle?

 

Do you have suggestions to improve the pulse generation algorithm?

 

 

Best regards,

Davide

 



smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP B210: Calls to rx_streamer->recv() occasionally stall

[Daniel May via USRP-users]

Important info up front:
Hardware: USRP B210
Driver: Version: [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red
Hat 4.8.5-16); Boost_106700; UHD_3.11.1

I have an application that receives and transmits at the same time. The
application receives a stream of data, does some simple processing, and
transmits a response. I have three separate threads: one that gets data
from the rx_streamer and writes to an Rx buffer, one that processes data
from the Rx buffer and writes a response to a Tx buffer, and one that reads
data from the Tx buffer and writes to a tx_streamer. The Rx and Tx streams
are started using timed commands such that the Rx stream leads the Tx
stream by 1 millisecond. The blocksize I'm using for Rx and Tx is much less
than 1 millisecond and is determined by rx_streamer->get_max_num_samps().
I've profiled the processing routine, and it's about 20x faster than my
rx_streamer sample rate, so I'm confident I'm able to keep up with the
incoming data rate in the processing thread.

I'm running into an issue which is causing underflows. *Every once and a
while, my call to rx_streamer->recv() stalls for a bit, sometimes for 3-5
milliseconds.* The next several calls are very fast, like it's trying to
catch up. I don't see any overflows on the Rx side. However, the initial
stall delay is enough to starve my tx_streamer and cause underflows. Over
time, my tx_streamer incurs a significant delay with respect to my
rx_streamer.

In order to further investigate the issue, I wrote a simple,
single-threaded program that just starts an rx_stream and times the calls
to recv(). I see the occasional stalls in this program as well.

What could be causing these stalls, and are there any settings that might
minimize them? My gut is telling me it's at the USB driver level and not at
the UHD level.  I've tried "renicing" the process to a high priority in
case it's a scheduling issue, but that didn't seem to have any effect.

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

Re: [USRP-users] USRP B210 FPGA Build

[Martin Braun via USRP-users]

On 04/09/2018 02:24 AM, Yeo Jin Kuang Alvin (IA) via USRP-users wrote:
> Hi everyone,
> 
>  
> 
> I tried to build the USRP B210 FPGA for Xilinx ISE 14.7 (Windows) and I
> got this in my cmd prompt:
> 
>  
> 
> C:\Users\WORK\Desktop\fpga-maint\usrp3\top\b200>make B210 PROJECT_ONLY=1
> 
> "ISE Version: Release 14.7 - xtclsh P.20131013 (nt64)"
> 
> make -f Makefile.b200.inc proj NAME=B210 DEVICE=XC6SLX150
> EXTRA_DEFS="TARGET_B21
> 
> 0=1 "
> 
> make[1]: Entering directory
> `C:/Users/WORK/Desktop/fpga-maint/usrp3/top/b200'
> 
> make[1]: *** No rule to make target
> `C:/Users/WORK/Desktop/fpga-maint/usrp3/top/
> 
> b200/C:/Users/WORK/Desktop/fpga-maint/usrp3/lib/fifo/axi_demux4.v',
> needed by `b
> 
> uild-B210//b200.xise'.  Stop.
> 
> make[1]: Leaving directory `C:/Users/WORK/Desktop/fpga-maint/usrp3/top/b200'
> 
> make: *** [B210] Error 2
> 
>  
> 
> May I know what’s missing? The file axi_demux4.v is located there.

This looks like you didn't use the Makefiles.

-- M

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

Re: [USRP-users] USRP B210 API & FPGA

[Martin Braun via USRP-users]

On 04/16/2018 01:54 AM, Yeo Jin Kuang Alvin (IA) via USRP-users wrote:
> Hi all,
> 
>  
> 
> I have two questions regarding the USRP B210 configurations using API
> and FPGA at the same time.

For the archive: this was addressed in various other threads.

-- M

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

[USRP-users] USRP B210 API & FPGA

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi all,

I have two questions regarding the USRP B210 configurations using API and FPGA 
at the same time.


1)  USRP FPGA Source Code:
I have used the Xilinx DDS Compiler using the Coregen and generated out a chirp 
signal using 2 phase accumulator followed by a SIN_LUT. However, I don't know 
where to connect the 12 bits output at the SIN_LUT in the source code. 
Initially, I planned to connect directly to the tx_codec_d, but I noticed that 
tx_codec_d is connected to b200_io > b200_core > other modules. Can't seem to 
find a proper input at the Top module or anywhere that I can connect to.

My current plan is to connect straight to tx_codec_d and comment off the 
connection that was previously connected to tx_codec_d in the source code, not 
sure if it works?


2)  USRP API controlling AD9361:
I am planning to control the AD9361 in the USRP B210 using the C++ source code 
given by ettus,  located in uhd-maint/host/lib/usrp/common/. I am planning to 
build the ad9361_device.cpp & ad9361_ctrl.cpp & ad936x_manager.cpp to control 
the AD9361 to output my chirp signal generated by the FPGA code.

Are the steps sufficient to achieve an output or are there more configurations 
that needs to be done?

Hope someone can clarify my doubts and guide me along! Much appreciated! Thanks 
in advance!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP B210 FPGA Generating signal

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi all,

I am currently using USRP B210 and I would like to generate a chirp signal 
using DDS in the FPGA, I have uploaded the source code by ettus into ISE 14.7. 

But I am not sure which input and output pin of the code to use, as I have to 
control the input for the desired chirp signal. Any help would be nice!

Thanks in advance!

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

[USRP-users] USRP B210 FPGA Build

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi everyone,

I tried to build the USRP B210 FPGA for Xilinx ISE 14.7 (Windows) and I got 
this in my cmd prompt:

C:\Users\WORK\Desktop\fpga-maint\usrp3\top\b200>make B210 PROJECT_ONLY=1
"ISE Version: Release 14.7 - xtclsh P.20131013 (nt64)"
make -f Makefile.b200.inc proj NAME=B210 DEVICE=XC6SLX150 EXTRA_DEFS="TARGET_B21
0=1 "
make[1]: Entering directory `C:/Users/WORK/Desktop/fpga-maint/usrp3/top/b200'
make[1]: *** No rule to make target `C:/Users/WORK/Desktop/fpga-maint/usrp3/top/
b200/C:/Users/WORK/Desktop/fpga-maint/usrp3/lib/fifo/axi_demux4.v', needed by `b
uild-B210//b200.xise'.  Stop.
make[1]: Leaving directory `C:/Users/WORK/Desktop/fpga-maint/usrp3/top/b200'
make: *** [B210] Error 2

May I know what's missing? The file axi_demux4.v is located there.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi,

I am allowed to do that, but how am I able to do that using ISE 14.7 together 
with the USRP B210?

Thanks in advance!

From: Ian Buckley [i...@ionconcepts.com]
Sent: 07 April 2018 03:19
To: Yeo Jin Kuang Alvin (IA)
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210

Making a hardware DDS to generate a chirp in the FPGA is easy, extremely so if 
you reuse the Ettus code that interfaces the B210 to AD3961 with correct timing.
What is very hard in what you propose, is controlling the AD9361 from within 
the FPGA without an external host. There is a *lot* of configuration 
functionality that needs to be captured.
Are the constraints of your project such that you are not allowed to have a 
host connected to USB?


On Apr 5, 2018, at 7:57 PM, Yeo Jin Kuang Alvin (IA) via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:



From: Yeo Jin Kuang Alvin (IA)
Sent: Friday, 6 April 2018 10:55 AM
To: 'Neel Pandeya'
Subject: RE: [USRP-users] USRP B210

Hi Neel,

I am trying to output a chirp signal by creating a DDS in the FPGA using Xilinx 
ISE 14.7. The code is done from scratch and created a SPI module in the FPGA to 
control the AD9361 to output the signal. Set up the constraints file gotten 
from ettus research in git.

This are my usual steps:
1)  uhd_usrp_probe  - -args=”master_clock_rate=40e6”   (I am setting to 
40MHz as I am using the codec_main_clk in the AD9361 as my main clock, not sure 
if this is right but simulation/chipscope seems fine )
2)  Opened Xilinx ISE 14.7
3)  Generate .bit file
4)  Run on IMPACT using JTAG cable
5)  Program the file

But I couldn’t get any signal out from the transmitter, there is no software 
C++ or GNU Radio involve. Just solely on FPGA  as I am task to create a chirp 
signal using FPGA. I might have missed out something, like configuration or 
concept is not right. Just not sure where and how.

Thank you in advance!


From: Neel Pandeya [mailto:neel.pand...@ettus.com]
Sent: Friday, 6 April 2018 10:34 AM
To: Yeo Jin Kuang Alvin (IA)
Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP B210

Hello Yeo Jin Kuang Alvin:
If you're modifying the FPGA, then there will likely be a corresponding 
modification needed on the host-side, especially for something as significant 
as starting a transmit stream and/or controlling the AD9361 in some way. We'll 
need much more detail in order to be able to help further. What changes did you 
make to the FPGA? What exactly are you trying to do overall?

--​Neel Pandeya


On 5 April 2018 at 18:07, Yeo Jin Kuang Alvin (IA) via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hi everyone,

I have tried to program the Spartan 6 FPGA using Xilinx 14.7 to send out a 
signal and to control the AD9361. However, I couldn’t get an output out from 
the transmitter. Can I just solely on FPGA or must I use the API for the USRP 
B210? What are the steps and procedures I have to do to configure the board, I 
just feel that I might miss out some important steps.

Thank you in advance!

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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<mailto: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 B210

[Ian Buckley via USRP-users]

Making a hardware DDS to generate a chirp in the FPGA is easy, extremely so if 
you reuse the Ettus code that interfaces the B210 to AD3961 with correct timing.
What is very hard in what you propose, is controlling the AD9361 from within 
the FPGA without an external host. There is a *lot* of configuration 
functionality that needs to be captured.
Are the constraints of your project such that you are not allowed to have a 
host connected to USB?


> On Apr 5, 2018, at 7:57 PM, Yeo Jin Kuang Alvin (IA) via USRP-users 
> <usrp-users@lists.ettus.com> wrote:
> 
>  
>  
> From: Yeo Jin Kuang Alvin (IA) 
> Sent: Friday, 6 April 2018 10:55 AM
> To: 'Neel Pandeya'
> Subject: RE: [USRP-users] USRP B210
>  
> Hi Neel,
>  
> I am trying to output a chirp signal by creating a DDS in the FPGA using 
> Xilinx ISE 14.7. The code is done from scratch and created a SPI module in 
> the FPGA to control the AD9361 to output the signal. Set up the constraints 
> file gotten from ettus research in git.
>  
> This are my usual steps:
> 1)  uhd_usrp_probe  - -args=”master_clock_rate=40e6”   (I am setting to 
> 40MHz as I am using the codec_main_clk in the AD9361 as my main clock, not 
> sure if this is right but simulation/chipscope seems fine )
> 2)  Opened Xilinx ISE 14.7
> 3)  Generate .bit file
> 4)  Run on IMPACT using JTAG cable
> 5)  Program the file
>  
> But I couldn’t get any signal out from the transmitter, there is no software 
> C++ or GNU Radio involve. Just solely on FPGA  as I am task to create a chirp 
> signal using FPGA. I might have missed out something, like configuration or 
> concept is not right. Just not sure where and how.
>  
> Thank you in advance!
>  
>  
> From: Neel Pandeya [mailto:neel.pand...@ettus.com 
> <mailto:neel.pand...@ettus.com>] 
> Sent: Friday, 6 April 2018 10:34 AM
> To: Yeo Jin Kuang Alvin (IA)
> Cc: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] USRP B210
>  
> Hello Yeo Jin Kuang Alvin:
> 
> If you're modifying the FPGA, then there will likely be a corresponding 
> modification needed on the host-side, especially for something as significant 
> as starting a transmit stream and/or controlling the AD9361 in some way. 
> We'll need much more detail in order to be able to help further. What changes 
> did you make to the FPGA? What exactly are you trying to do overall?
> 
> --​Neel Pandeya
> 
> 
>  
> On 5 April 2018 at 18:07, Yeo Jin Kuang Alvin (IA) via USRP-users 
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
> Hi everyone,
>  
> I have tried to program the Spartan 6 FPGA using Xilinx 14.7 to send out a 
> signal and to control the AD9361. However, I couldn’t get an output out from 
> the transmitter. Can I just solely on FPGA or must I use the API for the USRP 
> B210? What are the steps and procedures I have to do to configure the board, 
> I just feel that I might miss out some important steps.
>  
> Thank you in advance!
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/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 B210

[Yeo Jin Kuang Alvin (IA) via USRP-users]

From: Yeo Jin Kuang Alvin (IA)
Sent: Friday, 6 April 2018 10:55 AM
To: 'Neel Pandeya'
Subject: RE: [USRP-users] USRP B210

Hi Neel,

I am trying to output a chirp signal by creating a DDS in the FPGA using Xilinx 
ISE 14.7. The code is done from scratch and created a SPI module in the FPGA to 
control the AD9361 to output the signal. Set up the constraints file gotten 
from ettus research in git.

This are my usual steps:

1)  uhd_usrp_probe  - -args=”master_clock_rate=40e6”   (I am setting to 
40MHz as I am using the codec_main_clk in the AD9361 as my main clock, not sure 
if this is right but simulation/chipscope seems fine )

2)  Opened Xilinx ISE 14.7

3)  Generate .bit file

4)  Run on IMPACT using JTAG cable

5)  Program the file


But I couldn’t get any signal out from the transmitter, there is no software 
C++ or GNU Radio involve. Just solely on FPGA  as I am task to create a chirp 
signal using FPGA. I might have missed out something, like configuration or 
concept is not right. Just not sure where and how.

Thank you in advance!


From: Neel Pandeya [mailto:neel.pand...@ettus.com]
Sent: Friday, 6 April 2018 10:34 AM
To: Yeo Jin Kuang Alvin (IA)
Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP B210

Hello Yeo Jin Kuang Alvin:
If you're modifying the FPGA, then there will likely be a corresponding 
modification needed on the host-side, especially for something as significant 
as starting a transmit stream and/or controlling the AD9361 in some way. We'll 
need much more detail in order to be able to help further. What changes did you 
make to the FPGA? What exactly are you trying to do overall?

--​Neel Pandeya


On 5 April 2018 at 18:07, Yeo Jin Kuang Alvin (IA) via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hi everyone,

I have tried to program the Spartan 6 FPGA using Xilinx 14.7 to send out a 
signal and to control the AD9361. However, I couldn’t get an output out from 
the transmitter. Can I just solely on FPGA or must I use the API for the USRP 
B210? What are the steps and procedures I have to do to configure the board, I 
just feel that I might miss out some important steps.

Thank you in advance!

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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 B210

[Neel Pandeya via USRP-users]

Hello Yeo Jin Kuang Alvin:

If you're modifying the FPGA, then there will likely be a corresponding
modification needed on the host-side, especially for something as
significant as starting a transmit stream and/or controlling the AD9361 in
some way. We'll need much more detail in order to be able to help further.
What changes did you make to the FPGA? What exactly are you trying to do
overall?

--​Neel Pandeya




On 5 April 2018 at 18:07, Yeo Jin Kuang Alvin (IA) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
>
>
> I have tried to program the Spartan 6 FPGA using Xilinx 14.7 to send out a
> signal and to control the AD9361. However, I couldn’t get an output out
> from the transmitter. Can I just solely on FPGA or must I use the API for
> the USRP B210? What are the steps and procedures I have to do to configure
> the board, I just feel that I might miss out some important steps.
>
>
>
> Thank you in advance!
>
> ___
> 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] USRP B210

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi everyone,

I have tried to program the Spartan 6 FPGA using Xilinx 14.7 to send out a 
signal and to control the AD9361. However, I couldn't get an output out from 
the transmitter. Can I just solely on FPGA or must I use the API for the USRP 
B210? What are the steps and procedures I have to do to configure the board, I 
just feel that I might miss out some important steps.

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

Re: [USRP-users] USRP b210 time tagging

[Derek Kozel via USRP-users]

Yes, the data is timestamped. By default it will be times relative to when
the USRP was first turned on, but the set_time_next_pps function can be
used to align the internal time with an external or GPSDO based reference.

http://files.ettus.com/manual/page_sync.html#sync_time

There are examples for transmitting and receiving at set times included
with UHD.
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/examples/rx_timed_samples.cpp#L93
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/examples/tx_timed_samples.cpp#L75

Regards,
Derek

On Thu, Mar 22, 2018 at 8:27 PM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> I am using the USRP b210 but this questions can be for all USRPs.  Do they
> provide time tagging of the data transmitted and received or is that
> something that I would have to create myself.
>
>
>
> Thanks,
>
> Daniel Cho
>
> ___
> 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] USRP b210 time tagging

[Cho, Daniel J (332C) via USRP-users]

Hello -

I am using the USRP b210 but this questions can be for all USRPs.  Do they 
provide time tagging of the data transmitted and received or is that something 
that I would have to create myself.

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

Re: [USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Derek Kozel via USRP-users]

Hello Lucas,

I'll address your last question. The limitation is a hardware one as the
FPGA is connected to the AD9361 using the CMOS interface and the bandwidth
is split between the channels. This cannot be changed on the B210.

Regards,
Derek

On Thu, Mar 15, 2018 at 11:57 AM, Lucas Val Terrón via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Over the uhd example tx_waveforms.cpp (without any modificaiton), the
> exact invocation I'm using is the following:
>
> ./tx_waveforms --rate 6144 --bw 5000 --freq 244000 --channels
> "0" --wave-type SINE --wave-freq 10 --gain 60
>
> and its output:
>
> --
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.git-208-g1da86f9c]
> [INFO] [B200] Detected Device: B210
> [INFO] [B200] Operating over USB 3.
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] pass
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] pass
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC 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.
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B210
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting TX Rate: 61.44 Msps...
> [INFO] [B200] Asking for clock rate 61.44 MHz...
> [INFO] [B200] Actually got clock rate 61.44 MHz.
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Actual TX Rate: 61.44 Msps...
>
> Setting TX Freq: 2440.00 MHz...
> Actual TX Freq: 2440.00 MHz...
>
> Setting TX Gain: 60.00 dB...
> Actual TX Gain: 60.00 dB...
>
>
> *Setting TX Bandwidth: 5000.00 MHz...Actual TX Bandwidth:
> 4000.00 MHz...*
>
>
> *[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceedsanalog
> frontend filter bandwidth (56 MHz).*
> Setting device timestamp to 0...
> Checking TX: LO: locked ...
> Press Ctrl + C to stop streaming...
> --
>
> The invocation does not produce any error, but there is a warning that
> makes believe that somewhere inside the code something is trying to set th
> BW to the same value as the sample rate. Furthermore, you can also see that
> although the BW inserted is 50MHz, the value is finally set to 40MHz...
>
>
> If you don't mind, let me take the opportunity to ask you about a doubt
> related to the sample rate and dual channel transmission. Looking in the
> documentation I found here (https://files.ettus.com/manua
> l/page_usrp_b200.html#b200_mcr), that there is a limitation of 30.72 MHz
> in the clock rate for dual-channel mode. What is this limitation related
> to? Host, UHD, FPGA, AD9361 chip? Is there any way to increase this value?
>
> [image: logo_170x100px.png] 
>
>
>
> Lucas Val Terrón
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
>
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3016
> l...@gradiant.org  |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
>
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
> 2018-03-14 10:36 GMT+01:00 Lucas Val Terrón :
>
>> Hi all,
>>
>> Working with the example "tx_waveforms.cpp" provided in the uhd, i found
>> myself with two problems trying to set the sample rate and the tx bandwith
>> of the USRP B210 (UHD_3.11.0).
>>
>> 

Re: [USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Lucas Val Terrón via USRP-users]

Over the uhd example tx_waveforms.cpp (without any modificaiton), the exact
invocation I'm using is the following:

./tx_waveforms --rate 6144 --bw 5000 --freq 244000 --channels
"0" --wave-type SINE --wave-freq 10 --gain 60

and its output:

--
[INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.11.0.git-208-g1da86f9c]
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] pass
[INFO] [B200] Performing register loopback test...
[INFO] [B200] pass
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC 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.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Using Device: Single USRP:
  Device: B-Series Device
  Mboard 0: B210
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
  RX Channel: 1
RX DSP: 1
RX Dboard: A
RX Subdev: FE-RX1
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
  TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: FE-TX1

Setting TX Rate: 61.44 Msps...
[INFO] [B200] Asking for clock rate 61.44 MHz...
[INFO] [B200] Actually got clock rate 61.44 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Actual TX Rate: 61.44 Msps...

Setting TX Freq: 2440.00 MHz...
Actual TX Freq: 2440.00 MHz...

Setting TX Gain: 60.00 dB...
Actual TX Gain: 60.00 dB...


*Setting TX Bandwidth: 5000.00 MHz...Actual TX Bandwidth:
4000.00 MHz...*


*[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceedsanalog
frontend filter bandwidth (56 MHz).*
Setting device timestamp to 0...
Checking TX: LO: locked ...
Press Ctrl + C to stop streaming...
--

The invocation does not produce any error, but there is a warning that
makes believe that somewhere inside the code something is trying to set th
BW to the same value as the sample rate. Furthermore, you can also see that
although the BW inserted is 50MHz, the value is finally set to 40MHz...


If you don't mind, let me take the opportunity to ask you about a doubt
related to the sample rate and dual channel transmission. Looking in the
documentation I found here (https://files.ettus.com/manua
l/page_usrp_b200.html#b200_mcr), that there is a limitation of 30.72 MHz in
the clock rate for dual-channel mode. What is this limitation related to?
Host, UHD, FPGA, AD9361 chip? Is there any way to increase this value?

[image: logo_170x100px.png] 



Lucas Val Terrón
Investigador - Desarrollador | Área de Comunicaciones Avanzadas

Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3016
l...@gradiant.org  |  www.gradiant.org

[image: Iconos Redes Sociales GRD Firma email-01]
  [image: Iconos Redes Sociales GRD
Firma email-02]   [image: Iconos Redes
Sociales GRD Firma email-03] 
 [image: Iconos Redes Sociales GRD Firma email-04]


Take care of the environment. Try not to print this email.
The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorized and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation.

2018-03-14 10:36 GMT+01:00 Lucas Val Terrón :

> Hi all,
>
> Working with the example "tx_waveforms.cpp" provided in the uhd, i found
> myself with two problems trying to set the sample rate and the tx bandwith
> of the USRP B210 (UHD_3.11.0).
>
> ./tx_waveforms --rate 6144 --freq 235000 --wave-type SINE
> --wave-freq 100 --gain 40 --bw 5000 (with sc16 format)
>
>
> 1. The first thing I realized is that despite the sample rate was the
> maximum available, the bandwidth is limited to 40 MHz. Furthermore, the
> following warning appears:
>
> [WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceeds
>
> So, it seems that somewhere inside the code tries to set the Tx bandwith
> to the same value as the sample rate...
>
>
> ./tx_waveforms --rate 5 --freq 235000 --wave-type SINE
> --wave-freq 100 --gain 40 --bw 

Re: [USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Marcus D. Leech via USRP-users]

On 03/14/2018 05:36 AM, Lucas Val Terrón via USRP-users wrote:

Hi all,

Working with the example "tx_waveforms.cpp" provided in the uhd, i 
found myself with two problems trying to set the sample rate and the 
tx bandwith of the USRP B210 (UHD_3.11.0).


./tx_waveforms --rate 6144 --freq 235000 --wave-type SINE 
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)



1. The first thing I realized is that despite the sample rate was the 
maximum available, the bandwidth is limited to 40 MHz.  Furthermore, 
the following warning appears:


[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceeds

So, it seems that somewhere inside the code tries to set the Tx 
bandwith to the same value as the sample rate...



./tx_waveforms --rate 5 --freq 235000 --wave-type SINE 
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)


2. With sample rates greater tham 40 MHz, I get continuous underflows 
in transmission. Does anybody knows what's happening? Is there any 
limit in the maximum sample rate transmitting only in one channel?



Thanks in advance!!
Lucas


Underflows happen because your computer isn't keeping up with the 
radio.  The radio is perfectly capable of taking in the specified 
sample-rate, but
  the computer has to be able to "keep up".   You might try playing 
with the USB buffering:


https://files.ettus.com/manual/page_transport.html#transport_usb_params

I regards to the bandwidth setting, it's generally a poor idea to have 
the analog bandwidth exceed 80% of the sample rate.


If you could share the exact invocation you used, and the complete error 
message/log output, that would be helpful.



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

[USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Lucas Val Terrón via USRP-users]

Hi all,

Working with the example "tx_waveforms.cpp" provided in the uhd, i found
myself with two problems trying to set the sample rate and the tx bandwith
of the USRP B210 (UHD_3.11.0).

./tx_waveforms --rate 6144 --freq 235000 --wave-type SINE
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)


1. The first thing I realized is that despite the sample rate was the
maximum available, the bandwidth is limited to 40 MHz. Furthermore, the
following warning appears:

[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceeds

So, it seems that somewhere inside the code tries to set the Tx bandwith to
the same value as the sample rate...


./tx_waveforms --rate 5 --freq 235000 --wave-type SINE
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)

2. With sample rates greater tham 40 MHz, I get continuous underflows in
transmission. Does anybody knows what's happening? Is there any limit in
the maximum sample rate transmitting only in one channel?


Thanks in advance!!
Lucas


--
Laptop specifications
- Processor: 8x Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
- Operating System: Ubuntu 16.04.2 LTS
- Memory: 8192 MB DDR4-2400MH
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 TX-Issues

[Jonathan B via USRP-users]

Hi Derek,

That makes sense, yeah. Thanks!

2018-02-12 23:42 GMT+01:00 Derek Kozel :

> Hello Jonathan,
>
> The gain setting in the USRPs are indexed from minimum gain. On most this
> means a gain of 0 is actually an attenuation of the signal. The N210's gain
> range is based on what amplifiers and attenuators are on the daughterboard
> that is installed. The ranges aren't calibrated to be aligned across
> different USRP products so what you are seeing is completely normal.
>
> On Feb 12, 2018 10:21 PM, "Jonathan B via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Marcus,
>
> Thanks! Didn't realise there was a larger range for the B2xx family. At
> 60dB it seems to perform as well as 20dB on the N210. Is that normal?
>
> But either way - something I can work with. Thanks.
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_3513110979629845876_m_-3868461721852336890_m_4051027392395733961_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2018-02-09 20:53 GMT+01:00 Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> On 02/09/2018 02:48 PM, Jonathan B via USRP-users wrote:
>>
>> Hi Jeff,
>>
>> Thanks for the response.
>>
>> In both cases a gain of 20dB.
>>
>> Best,
>> Jonathan
>>
>> The total gain-control range on the B2xx family is larger (80dB) than on
>> the cards used on X3xxx, N2xx, etc (typically 30.5dB)
>>
>> Try larger gain values on the B210, like 40 or 50dB.
>>
>>
>>
>> On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> What are you using for gain settings?
>>>
>>> On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:
>>>
 Hi everyone,

 I seem to be having issues with the B210 transmitting at an incredibly
 low power.

 I seem to be getting a 60db difference at the receiver (spectrum
 analyzer) between the B210 and N210 with perfectly identically configured
 transmissions using the simple uhd "tx_waveform" example program.

 Has anyone experienced such an issue. I have two B210s that seem to be
 acting the same way.

 Thanks in advance.

 Best Regards,
 Jonathan

 -

 Probe Output of the B210:

 -- Loading firmware image: C:\Program Files\GNURadio-3.7\share\uhd\i
 mages\usrp_b200_fw.hex...
 -- Detected Device: B210
 -- Loading FPGA image: C:\Program 
 Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin...
 done
 -- Operating over USB 3.
 -- Detecting internal GPSDO No GPSDO found
 -- Initialize CODEC control...
 -- Initialize Radio control...
 -- Performing register loopback test... pass
 -- Performing register loopback test... pass
 -- Performing CODEC loopback test... pass
 -- Performing CODEC loopback test... pass
 -- Setting master clock rate selection to 'automatic'.
 -- Asking for clock rate 16.00 MHz...
 -- Actually got clock rate 16.00 MHz.
 -- Performing timer loopback test... pass
 -- Performing timer loopback test... pass
_
   /
 |   Device: B-Series Device
 | _
 |/
 |   |   Mboard: B210
 |   |   revision: 4
 |   |   product: 2
 |   |   serial: 3113A66
 |   |   name: MyB210
 |   |   FW Version: 8.0
 |   |   FPGA Version: 14.0
 |   |
 |   |   Time sources:  none, internal, external, gpsdo
 |   |   Clock sources: internal, external, gpsdo
 |   |   Sensors: ref_locked
 |   | _
 |   |/
 |   |   |   RX DSP: 0
 |   |   |
 |   |   |   Freq range: -8.000 to 8.000 MHz
 |   | _
 |   |/
 |   |   |   RX DSP: 1
 |   |   |
 |   |   |   Freq range: -8.000 to 8.000 MHz
 |   | _
 |   |/
 |   |   |   RX Dboard: A
 |   |   | _
 |   |   |/
 |   |   |   |   RX Frontend: A
 |   |   |   |   Name: FE-RX2
 |   |   |   |   Antennas: TX/RX, RX2
 |   |   |   |   Sensors: temp, rssi, lo_locked
 |   |   |   |   Freq range: 50.000 to 6000.000 MHz
 |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
 |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
 |   |   |   |   Connection Type: IQ
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   RX Frontend: B
 |   

Re: [USRP-users] USRP B210 TX-Issues

[Marcus D. Leech via USRP-users]

Sounds about right. 

Sent from my iPhone

> On Feb 12, 2018, at 5:20 PM, Jonathan B  wrote:
> 
> Hi Marcus,
> 
> Thanks! Didn't realise there was a larger range for the B2xx family. At 60dB 
> it seems to perform as well as 20dB on the N210. Is that normal?
> 
> But either way - something I can work with. Thanks.
> 
>   Virus-free. www.avast.com
> 
> 2018-02-09 20:53 GMT+01:00 Marcus D. Leech via USRP-users 
> :
>>> On 02/09/2018 02:48 PM, Jonathan B via USRP-users wrote:
>>> Hi Jeff,
>>> 
>>> Thanks for the response.
>>> 
>>> In both cases a gain of 20dB.
>>> 
>>> Best,
>>> Jonathan
>> The total gain-control range on the B2xx family is larger (80dB) than on the 
>> cards used on X3xxx, N2xx, etc (typically 30.5dB)
>> 
>> Try larger gain values on the B210, like 40 or 50dB.
>> 
>> 
>>> 
 On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" 
  wrote:
 What are you using for gain settings?
 
> On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:
> Hi everyone,
> 
> I seem to be having issues with the B210 transmitting at an incredibly 
> low power.
> 
> I seem to be getting a 60db difference at the receiver (spectrum 
> analyzer) between the B210 and N210 with perfectly identically configured 
> transmissions using the simple uhd "tx_waveform" example program.
> 
> Has anyone experienced such an issue. I have two B210s that seem to be 
> acting the same way.
> 
> Thanks in advance.
> 
> Best Regards,
> Jonathan
> 
> -
> 
> Probe Output of the B210:
> 
> -- Loading firmware image: C:\Program 
> Files\GNURadio-3.7\share\uhd\images\usrp_b200_fw.hex...
> -- Detected Device: B210
> -- Loading FPGA image: C:\Program 
> Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin... done
> -- Operating over USB 3.
> -- Detecting internal GPSDO No GPSDO found
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> -- Asking for clock rate 16.00 MHz...
> -- Actually got clock rate 16.00 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
>_
>   /
> |   Device: B-Series Device
> | _
> |/
> |   |   Mboard: B210
> |   |   revision: 4
> |   |   product: 2
> |   |   serial: 3113A66
> |   |   name: MyB210
> |   |   FW Version: 8.0
> |   |   FPGA Version: 14.0
> |   |
> |   |   Time sources:  none, internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: -8.000 to 8.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: -8.000 to 8.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: B210 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/

Re: [USRP-users] USRP B210 TX-Issues

[Derek Kozel via USRP-users]

Hello Jonathan,

The gain setting in the USRPs are indexed from minimum gain. On most this
means a gain of 0 is actually an attenuation of the signal. The N210's gain
range is based on what amplifiers and attenuators are on the daughterboard
that is installed. The ranges aren't calibrated to be aligned across
different USRP products so what you are seeing is completely normal.

On Feb 12, 2018 10:21 PM, "Jonathan B via USRP-users" <
usrp-users@lists.ettus.com> wrote:

Hi Marcus,

Thanks! Didn't realise there was a larger range for the B2xx family. At
60dB it seems to perform as well as 20dB on the N210. Is that normal?

But either way - something I can work with. Thanks.


Virus-free.
www.avast.com

<#m_-3868461721852336890_m_4051027392395733961_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2018-02-09 20:53 GMT+01:00 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>:

> On 02/09/2018 02:48 PM, Jonathan B via USRP-users wrote:
>
> Hi Jeff,
>
> Thanks for the response.
>
> In both cases a gain of 20dB.
>
> Best,
> Jonathan
>
> The total gain-control range on the B2xx family is larger (80dB) than on
> the cards used on X3xxx, N2xx, etc (typically 30.5dB)
>
> Try larger gain values on the B210, like 40 or 50dB.
>
>
>
> On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>
>> What are you using for gain settings?
>>
>> On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:
>>
>>> Hi everyone,
>>>
>>> I seem to be having issues with the B210 transmitting at an incredibly
>>> low power.
>>>
>>> I seem to be getting a 60db difference at the receiver (spectrum
>>> analyzer) between the B210 and N210 with perfectly identically configured
>>> transmissions using the simple uhd "tx_waveform" example program.
>>>
>>> Has anyone experienced such an issue. I have two B210s that seem to be
>>> acting the same way.
>>>
>>> Thanks in advance.
>>>
>>> Best Regards,
>>> Jonathan
>>>
>>> -
>>>
>>> Probe Output of the B210:
>>>
>>> -- Loading firmware image: C:\Program Files\GNURadio-3.7\share\uhd\i
>>> mages\usrp_b200_fw.hex...
>>> -- Detected Device: B210
>>> -- Loading FPGA image: C:\Program 
>>> Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin...
>>> done
>>> -- Operating over USB 3.
>>> -- Detecting internal GPSDO No GPSDO found
>>> -- Initialize CODEC control...
>>> -- Initialize Radio control...
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Setting master clock rate selection to 'automatic'.
>>> -- Asking for clock rate 16.00 MHz...
>>> -- Actually got clock rate 16.00 MHz.
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>>_
>>>   /
>>> |   Device: B-Series Device
>>> | _
>>> |/
>>> |   |   Mboard: B210
>>> |   |   revision: 4
>>> |   |   product: 2
>>> |   |   serial: 3113A66
>>> |   |   name: MyB210
>>> |   |   FW Version: 8.0
>>> |   |   FPGA Version: 14.0
>>> |   |
>>> |   |   Time sources:  none, internal, external, gpsdo
>>> |   |   Clock sources: internal, external, gpsdo
>>> |   |   Sensors: ref_locked
>>> |   | _
>>> |   |/
>>> |   |   |   RX DSP: 0
>>> |   |   |
>>> |   |   |   Freq range: -8.000 to 8.000 MHz
>>> |   | _
>>> |   |/
>>> |   |   |   RX DSP: 1
>>> |   |   |
>>> |   |   |   Freq range: -8.000 to 8.000 MHz
>>> |   | _
>>> |   |/
>>> |   |   |   RX Dboard: A
>>> |   |   | _
>>> |   |   |/
>>> |   |   |   |   RX Frontend: A
>>> |   |   |   |   Name: FE-RX2
>>> |   |   |   |   Antennas: TX/RX, RX2
>>> |   |   |   |   Sensors: temp, rssi, lo_locked
>>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>>> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
>>> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
>>> |   |   |   |   Connection Type: IQ
>>> |   |   |   |   Uses LO offset: No
>>> |   |   | _
>>> |   |   |/
>>> |   |   |   |   RX Frontend: B
>>> |   |   |   |   Name: FE-RX1
>>> |   |   |   |   Antennas: TX/RX, RX2
>>> |   |   |   |   Sensors: temp, rssi, lo_locked
>>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>>> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
>>> |   |   |   |   Bandwidth range: 20.0 to 

Re: [USRP-users] USRP B210 TX-Issues

[Marcus D. Leech via USRP-users]

On 02/09/2018 02:48 PM, Jonathan B via USRP-users wrote:

Hi Jeff,

Thanks for the response.

In both cases a gain of 20dB.

Best,
Jonathan
The total gain-control range on the B2xx family is larger (80dB) than on 
the cards used on X3xxx, N2xx, etc (typically 30.5dB)


Try larger gain values on the B210, like 40 or 50dB.



On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" 
> wrote:


What are you using for gain settings?

On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:

Hi everyone,

I seem to be having issues with the B210 transmitting at an
incredibly low power.

I seem to be getting a 60db difference at the receiver
(spectrum analyzer) between the B210 and N210 with perfectly
identically configured transmissions using the simple uhd
"tx_waveform" example program.

Has anyone experienced such an issue. I have two B210s that
seem to be acting the same way.

Thanks in advance.

Best Regards,
Jonathan

-

Probe Output of the B210:

-- Loading firmware image: C:\Program
Files\GNURadio-3.7\share\uhd\images\usrp_b200_fw.hex...
-- Detected Device: B210
-- Loading FPGA image: C:\Program
Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin... done
-- Operating over USB 3.
-- Detecting internal GPSDO No GPSDO found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
   _
  /
|   Device: B-Series Device
| _
|/
|   |   Mboard: B210
|   |   revision: 4
|   |   product: 2
|   |   serial: 3113A66
|   |   name: MyB210
|   |   FW Version: 8.0
|   |   FPGA Version: 14.0
|   |
|   |   Time sources:  none, internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   
 _

|   |   |/
|   |   |   |   RX Frontend: A
|   |   |   |   Name: FE-RX2
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step
0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |   
 _

|   |   |/
|   |   |   |   RX Frontend: B
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step
0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |   
 _

|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: B210 RX dual ADC
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   TX DSP: 1
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | 

Re: [USRP-users] USRP B210 TX-Issues

[Jonathan B via USRP-users]

Hi Jeff,

Thanks for the response.

In both cases a gain of 20dB.

Best,
Jonathan

On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> What are you using for gain settings?
>
> On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:
>
>> Hi everyone,
>>
>> I seem to be having issues with the B210 transmitting at an incredibly
>> low power.
>>
>> I seem to be getting a 60db difference at the receiver (spectrum
>> analyzer) between the B210 and N210 with perfectly identically configured
>> transmissions using the simple uhd "tx_waveform" example program.
>>
>> Has anyone experienced such an issue. I have two B210s that seem to be
>> acting the same way.
>>
>> Thanks in advance.
>>
>> Best Regards,
>> Jonathan
>>
>> -
>>
>> Probe Output of the B210:
>>
>> -- Loading firmware image: C:\Program Files\GNURadio-3.7\share\uhd\i
>> mages\usrp_b200_fw.hex...
>> -- Detected Device: B210
>> -- Loading FPGA image: C:\Program 
>> Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin...
>> done
>> -- Operating over USB 3.
>> -- Detecting internal GPSDO No GPSDO found
>> -- Initialize CODEC control...
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Setting master clock rate selection to 'automatic'.
>> -- Asking for clock rate 16.00 MHz...
>> -- Actually got clock rate 16.00 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>>_
>>   /
>> |   Device: B-Series Device
>> | _
>> |/
>> |   |   Mboard: B210
>> |   |   revision: 4
>> |   |   product: 2
>> |   |   serial: 3113A66
>> |   |   name: MyB210
>> |   |   FW Version: 8.0
>> |   |   FPGA Version: 14.0
>> |   |
>> |   |   Time sources:  none, internal, external, gpsdo
>> |   |   Clock sources: internal, external, gpsdo
>> |   |   Sensors: ref_locked
>> |   | _
>> |   |/
>> |   |   |   RX DSP: 0
>> |   |   |
>> |   |   |   Freq range: -8.000 to 8.000 MHz
>> |   | _
>> |   |/
>> |   |   |   RX DSP: 1
>> |   |   |
>> |   |   |   Freq range: -8.000 to 8.000 MHz
>> |   | _
>> |   |/
>> |   |   |   RX Dboard: A
>> |   |   | _
>> |   |   |/
>> |   |   |   |   RX Frontend: A
>> |   |   |   |   Name: FE-RX2
>> |   |   |   |   Antennas: TX/RX, RX2
>> |   |   |   |   Sensors: temp, rssi, lo_locked
>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
>> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
>> |   |   |   |   Connection Type: IQ
>> |   |   |   |   Uses LO offset: No
>> |   |   | _
>> |   |   |/
>> |   |   |   |   RX Frontend: B
>> |   |   |   |   Name: FE-RX1
>> |   |   |   |   Antennas: TX/RX, RX2
>> |   |   |   |   Sensors: temp, rssi, lo_locked
>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
>> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
>> |   |   |   |   Connection Type: IQ
>> |   |   |   |   Uses LO offset: No
>> |   |   | _
>> |   |   |/
>> |   |   |   |   RX Codec: A
>> |   |   |   |   Name: B210 RX dual ADC
>> |   |   |   |   Gain Elements: None
>> |   | _
>> |   |/
>> |   |   |   TX DSP: 0
>> |   |   |
>> |   |   |   Freq range: -8.000 to 8.000 MHz
>> |   | _
>> |   |/
>> |   |   |   TX DSP: 1
>> |   |   |
>> |   |   |   Freq range: -8.000 to 8.000 MHz
>> |   | _
>> |   |/
>> |   |   |   TX Dboard: A
>> |   |   | _
>> |   |   |/
>> |   |   |   |   TX Frontend: A
>> |   |   |   |   Name: FE-TX2
>> |   |   |   |   Antennas: TX/RX
>> |   |   |   |   Sensors: temp, lo_locked
>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.3 dB
>> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
>> |   |   |   |   Connection Type: IQ
>> |   |   |   |   Uses LO offset: No
>> |   |   | _
>> |   |   |/
>> |   |   |   |   TX Frontend: B
>> |   |   |   |   Name: FE-TX1
>> |   |   |   |   Antennas: TX/RX
>> |   |   |   |   

[USRP-users] USRP B210 TX-Issues

[Jonathan B via USRP-users]

Hi everyone,

I seem to be having issues with the B210 transmitting at an incredibly low
power.

I seem to be getting a 60db difference at the receiver (spectrum analyzer)
between the B210 and N210 with perfectly identically configured
transmissions using the simple uhd "tx_waveform" example program.

Has anyone experienced such an issue. I have two B210s that seem to be
acting the same way.

Thanks in advance.

Best Regards,
Jonathan

-

Probe Output of the B210:

-- Loading firmware image: C:\Program
Files\GNURadio-3.7\share\uhd\images\usrp_b200_fw.hex...
-- Detected Device: B210
-- Loading FPGA image: C:\Program
Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin... done
-- Operating over USB 3.
-- Detecting internal GPSDO No GPSDO found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
  _
 /
|   Device: B-Series Device
| _
|/
|   |   Mboard: B210
|   |   revision: 4
|   |   product: 2
|   |   serial: 3113A66
|   |   name: MyB210
|   |   FW Version: 8.0
|   |   FPGA Version: 14.0
|   |
|   |   Time sources:  none, internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: A
|   |   |   |   Name: FE-RX2
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: B
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: B210 RX dual ADC
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   TX DSP: 1
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: A
|   |   |   |   Name: FE-TX2
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: temp, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.3 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: B
|   |   |   |   Name: FE-TX1
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: temp, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.3 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: B210 TX dual DAC
|   |   |   |   Gain Elements: None


Virus-free.
www.avast.com

Re: [USRP-users] USRP B210 ext 10MHz ref clock

[Marcus D. Leech via USRP-users]

On 12/27/2017 06:21 AM, Guillermo Gancio via USRP-users wrote:

Dear all,

I have some questions with the use of an external clock source fot the 
B210 board...


How the 10MHz signal must be in terms of amplitude and shape?

Is there a function to use with rx_samples_c.c to verify is the B210 
is using the unternal or external reference clock.


Whats the proper whay to configure the B210 to use the 10MHz external 
reference clock with rx_samples_c.c.


Thanks for your timeand a excellent 2018!



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

A   2.5-3.3V square-wave will work well.

Details on device synchronization are here:


https://files.ettus.com/manual/page_sync.html#sync_commonref
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] usrp B210- UULLUULL.... responses

[Marcus D. Leech via USRP-users]

On 12/12/2017 03:32 PM, Akeem Mufutau via USRP-users wrote:

Hi,
I am implementing openairinterface with usrp b210 and I am getting 
UULLUULL responses. I have ASMedia® USB 3.1 controller on my ASUS 
x299 motherboard and it seems to be responsible for this response. I 
am not very sure of this. Please does usrp B210 support by ASMedia® 
USB 3.1 controller? or am I missing out something?




Best Regards.

Akeem Olapade *MUFUTAU*



I believe that ASMedia were one of the ones (at least early versions of 
the controller) that were evaluated by Ettus and found to be not good.


But the "landscape" of consumer level USB controllers changes *VERY 
FREQUENTLY*, so it's not practical to maintain a list of known-good 
controllers.




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

[USRP-users] usrp B210- UULLUULL.... responses

[Akeem Mufutau via USRP-users]

Hi,
I am implementing openairinterface with usrp b210 and I am getting UULLUULL 
responses. I have ASMedia® USB 3.1 controller on my ASUS x299 motherboard and 
it seems to be responsible for this response. I am not very sure of this. 
Please does usrp B210 support by ASMedia® USB 3.1 controller? or am I missing 
out something?




Best Regards.



Akeem Olapade MUFUTAU

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

[USRP-users] USRP B210 time errors with high master clock rate

[Perelman, Nathan via USRP-users]

I've seen some odd behavior with timestamps for samples from the B210 being
off by large fractions of a second from what I expected when setting the
time to GPS time. I wrote a program (see attached) that uses
get_time_last_pps() to attempt to validate that the time is being set
correctly. I discovered that when using a master clock rate of 61.44 MHz,
the time returned is sometimes off by a quarter second (see output from
running below). At a master clock rate of 16 MHz, I don't see this issue.
Testing was done with UHD 3.10.1.0. Is my program doing something wrong or
is this is an issue with the B200?

 

time_test--args type=b200,master_clock_rate=61.44e6

linux; GNU C++ version 5.2.1 20150902 (Red Hat 5.2.1-2); Boost_106000;
UHD_003.010.001.000-0-unknown

 

 

Creating the usrp device with: type=b200,master_clock_rate=30.72e6...

-- Detected Device: B210

-- Operating over USB 3.

-- Detecting internal GPSDO Found an internal GPSDO: GPSTCXO , Firmware
Rev 0.929a

-- Initialize CODEC control...

-- Initialize Radio control...

-- Performing register loopback test... pass

-- Performing register loopback test... pass

-- Performing CODEC loopback test... pass

-- Performing CODEC loopback test... pass

-- Asking for clock rate 61.44 MHz... 

-- Actually got clock rate 61.44 MHz.

-- Performing timer loopback test... pass

-- Performing timer loopback test... pass

Using Device: Single USRP:

  Device: B-Series Device

  Mboard 0: B210

  RX Channel: 0

RX DSP: 0

RX Dboard: A

RX Subdev: FE-RX2

  RX Channel: 1

RX DSP: 1

RX Dboard: A

RX Subdev: FE-RX1

  TX Channel: 0

TX DSP: 0

TX Dboard: A

TX Subdev: FE-TX2

  TX Channel: 1

TX DSP: 1

TX Dboard: A

TX Subdev: FE-TX1

 

Time set count 4 check 1/5: ERROR: Time difference at last PPS: 0.249037

Time set count 4 check 4/5: ERROR: Time difference at last PPS: 0.24

Time set count 8 check 1/5: ERROR: Time difference at last PPS: 0.24



time_test.cpp
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com