Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. X310 power button (liu Jong)
2. Re: Ettus UBX-160 vs SBX-120 (Simon Olvhammar)
3. Re: Ettus UBX-160 vs SBX-120 (Kyeong Su Shin)
4. Re: Ettus UBX-160 vs SBX-120 (Marcus M?ller)
5. Re: sdimage version for RFNoc (Nicolas Cuervo)
6. Re: Different streaming modes at the same time with same USRP
hardware (Felipe Augusto Pereira de Figueiredo)
7. Tune Request for B210 (altu? kaya)
8. Re: Build RFNoC environment (Nicolas Cuervo)
9. Re: Tune Request for B210 (Marcus M?ller)
10. Re: Tune Request for B210 (altu? kaya)
11. Re: Tune Request for B210 (Marcus M?ller)
12. Re: Ettus UBX-160 vs SBX-120 (Kyeong Su Shin)
13. Two questions on X310@200MSps RX (Leandro Echevarr?a)
14. Re: X310 power button (Leandro Echevarr?a)
15. PL2303 USB to serial adapter not recognized (Boris Isakanov)
16. Re: PL2303 USB to serial adapter not recognized (Marcus D. Leech)
17. calibration on Wifi bands for X310/UBX (Sanjoy Basak)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Jul 2017 15:28:58 +0800
From: liu Jong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 power button
Message-ID:
<CAEui2n3V5wqtvuxJFRxNpBKg0=axjvk+hzcgif7mt8m+hf7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,all,
Because of the power button of X310 was broken,and we want to replace
it.Could you tell us the part number of usrp X310 power button?
best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/3f4a8a9b/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 3 Jul 2017 10:35:25 +0200
From: Simon Olvhammar <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I am not sure if I understand correctly.
How are the ADC to slow if I use a master clock rate of 120 MHz and
sampling rate of 120 MHz on a UBX-160? I don't need 160 MHz bandwidth
only 120 MHz.
Regards
Simon
On 06/28/2017 04:12 PM, Sylvain Munaut wrote:
> Hi,
>
>
>> We currently running a system with a Ettus x310 and a SBX-120.
>> We also a have UBX-160 daughter board.
>>
>> For several reasons, mainly due to computer performance limitations, we can
>> only run with a complex sampling rate of 120 MHz.
>> My question is if I will see any improvement in performance, e.g. filter
>> characteristics, if I instead use the UBX-160 and run it at 120 MHz compared
>> to SBX-120 at 120 MHz or are they similar?
> You can't do that.
>
> If you have the master clock-rate at 120 MHz and use a 160 MHz wide
> daugtherboard, you will get aliasing because the ADC are too slow.
> You'd have to go to a 100 MHz samplerate for it to work. (200 MHz
> sampled by the ADC then HW decimated by 2 to 100 Msps).
>
> Cheers,
>
> Sylvain
------------------------------
Message: 3
Date: Mon, 3 Jul 2017 01:52:19 -0700
From: Kyeong Su Shin <[email protected]>
To: Simon Olvhammar <[email protected]>, Sylvain Munaut
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID:
<CAGL0V3=2fvgl5qq6nontquyyfhz2r+kfd9boxkomrun4c8g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To whom it may concern:
You don't need 160MHz, but that is the filter bandwidth of the
daughterboard. It WILL give you 160MHz of signal (=120MHz + 40MHz worth of
aliasing), even if though all you want is 120MHz of bandwidth.
I don't use X3x0 series, so I am not sure what configurable true sampling
rates are out there, but if you set your sampling rate to 160MHz or higher
and decimate the data to lower rates using hardware decimators in your
x310, this problem does not happen (the digital decimator will apply low
pass filters). That is why you can do 100MS/s (sample at 200MS/s ->
decimate to 100MS/s).
Regards,
Kyeong Su Shin
On Mon, Jul 3, 2017 at 1:35 AM, Simon Olvhammar via USRP-users <
[email protected]> wrote:
> Hi,
>
> I am not sure if I understand correctly.
> How are the ADC to slow if I use a master clock rate of 120 MHz and
> sampling rate of 120 MHz on a UBX-160? I don't need 160 MHz bandwidth only
> 120 MHz.
>
> Regards
> Simon
>
> On 06/28/2017 04:12 PM, Sylvain Munaut wrote:
>
>> Hi,
>>
>>
>> We currently running a system with a Ettus x310 and a SBX-120.
>>> We also a have UBX-160 daughter board.
>>>
>>> For several reasons, mainly due to computer performance limitations, we
>>> can
>>> only run with a complex sampling rate of 120 MHz.
>>> My question is if I will see any improvement in performance, e.g. filter
>>> characteristics, if I instead use the UBX-160 and run it at 120 MHz
>>> compared
>>> to SBX-120 at 120 MHz or are they similar?
>>>
>> You can't do that.
>>
>> If you have the master clock-rate at 120 MHz and use a 160 MHz wide
>> daugtherboard, you will get aliasing because the ADC are too slow.
>> You'd have to go to a 100 MHz samplerate for it to work. (200 MHz
>> sampled by the ADC then HW decimated by 2 to 100 Msps).
>>
>> Cheers,
>>
>> Sylvain
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/a50120a3/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 3 Jul 2017 11:12:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Kyeong Su Shin!
Exactly that's what's happening; the 160 MHz wide low pass filter is
insufficient to function for a (complex) ADC running at 120 MHz.
Thank you for the excellent answer,
Marcus
On 07/03/2017 10:52 AM, Kyeong Su Shin via USRP-users wrote:
> To whom it may concern:
>
> You don't need 160MHz, but that is the filter bandwidth of the
> daughterboard. It WILL give you 160MHz of signal (=120MHz + 40MHz
> worth of aliasing), even if though all you want is 120MHz of bandwidth.
>
> I don't use X3x0 series, so I am not sure what configurable true
> sampling rates are out there, but if you set your sampling rate to
> 160MHz or higher and decimate the data to lower rates using hardware
> decimators in your x310, this problem does not happen (the digital
> decimator will apply low pass filters). That is why you can do 100MS/s
> (sample at 200MS/s -> decimate to 100MS/s).
>
> Regards,
> Kyeong Su Shin
>
> On Mon, Jul 3, 2017 at 1:35 AM, Simon Olvhammar via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi,
>
> I am not sure if I understand correctly.
> How are the ADC to slow if I use a master clock rate of 120 MHz
> and sampling rate of 120 MHz on a UBX-160? I don't need 160 MHz
> bandwidth only 120 MHz.
>
> Regards
> Simon
>
> On 06/28/2017 04:12 PM, Sylvain Munaut wrote:
>
> Hi,
>
>
> We currently running a system with a Ettus x310 and a SBX-120.
> We also a have UBX-160 daughter board.
>
> For several reasons, mainly due to computer performance
> limitations, we can
> only run with a complex sampling rate of 120 MHz.
> My question is if I will see any improvement in
> performance, e.g. filter
> characteristics, if I instead use the UBX-160 and run it
> at 120 MHz compared
> to SBX-120 at 120 MHz or are they similar?
>
> You can't do that.
>
> If you have the master clock-rate at 120 MHz and use a 160 MHz
> wide
> daugtherboard, you will get aliasing because the ADC are too slow.
> You'd have to go to a 100 MHz samplerate for it to work. (200 MHz
> sampled by the ADC then HW decimated by 2 to 100 Msps).
>
> Cheers,
>
> Sylvain
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> 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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/d1dbc0c0/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 3 Jul 2017 12:39:55 +0200
From: Nicolas Cuervo <[email protected]>
To: Hu Chaoran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] sdimage version for RFNoc
Message-ID:
<caoupcvjgjwdrqvak6pouli5wuic+pdlahc2ye+j_mpbv9or...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Hu Chaoran,
The precompiled SD images do not contain as of now a suitable set up for
RFNoC right out of the box. The reason behind this is the constant and
rapid change/improvement that RFNoC is undergoing. In order to have a SD
image for RFNoC you have to compile it yourself. We are putting together
the documentation that covers this whole process, which will be soon part
of our applications notes. Attached to this email you will find the
step-by-step process that you can follow in order to build the image with
RFNoC successfully.
Regards,
- Nicolas
On Sun, Jul 2, 2017 at 10:00 AM, Hu Chaoran via USRP-users <
[email protected]> wrote:
> Hello,
>
> I'm a new user of the usrp e312, I want to use the RFNoc function, but on
> here http://files.ettus.com/e3xx_images/ there are many sdimage versins
> ,I read the document ' README', but I still can't know which image can
> support the RFNoc well, and is the image already build rfnoc and ettus or I
> need to build them by myself.
> files.ettus.com:/e3xx_images/ <http://files.ettus.com/e3xx_images/>
> files.ettus.com
> files.ettus.com/e3xx_images/ Name Last modified Size Description
>
> Thank u.
> <http://files.ettus.com/e3xx_images/>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/293e0cb2/attachment-0001.html>
-------------- next part --------------
Switch your default shell on the host computer from Dash to Bash. In some Linux
distributions (e.g. Ubuntu) dash is set as default shell, which may cause some
issues. It is recommended to set the shell to bash by running the following
commands in the terminal. Choose <No> when prompted by the first command and
the second command will validate the that bash will be used.
$ sudo dpkg-reconfigure dash
Verify Bash is the default shell.
$ ll /bin/sh
Expected Output:
lrwxrwxrwx 1 root root 4 Apr 2 22:00 /bin/sh -> bash*
Make a working directory on host computer. This is where we will clone,
download, cross compile and install all files.
$ mkdir -p ~/e300
Make a src/ directory within the working directory.
$ mkdir -p ~/e300/src
Download the OE SDK for the E31x release into the src/ directory:
$ cd ~/e300/src
$ wget
http://files.ettus.com/e3xx_images/e3xx-release-4/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
Next, install the SDK to the ~/e300 directory. Enter "~/e300" for the
installation directory when prompted.
$ bash oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
Expected Output:
Enter target directory for SDK (default: /usr/local/oecore-x86_64): ~/e300
You are about to install the SDK to "/home/user/e300". Proceed[Y/n]?y
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.
Your "~/e300" directory should have a structure such as below:
$ ls ~/e300
environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi src
version-armv7ahf-vfp-neon-oe-linux-gnueabi
site-config-armv7ahf-vfp-neon-oe-linux-gnueabi sysroots
Source the environment setup file:
$ cd ~/e300
$ source ./environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
Verify the environment has been setup correctly.
$ echo $CC
Expected Output:
arm-oe-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon
--sysroot=/home/user/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi
* Note: If you open a new terminal at any point, you will need to re-run the
source command above to initialize the environment. The compiling environment
setup is only needed for terminals that are cross compiling the sources. The
terminals used later in this application note which are using SSH to connect to
other devices do not need to have the compiling environment initialized.
Next, download the rfnoc-devel branch of UHD, v3.7.10.2 GNU Radio, and master
branch of gr-ettus:
$ cd ~/e300/src
$ git clone -b rfnoc-devel https://github.com/EttusResearch/uhd.git
$ git clone -b master https://github.com/EttusResearch/gr-ettus.git
$ git clone -b v3.7.10.2 --recursive https://github.com/gnuradio/gnuradio.git
Next, we will cross compile the rfnoc-devel branch of UHD.
$ cd uhd/host
$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
$ make -j4
$ make install DESTDIR=~/e300
$ make install DESTDIR=~/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
Next, we will create an environment setup file that will set the correct system
variables to point to our new installation when ran on the E31x.
$ cd ~/e300
$ touch setup_env.sh
$ nano setup_env.sh
Add the following lines to setup_env.sh
LOCALPREFIX=~/newinstall/usr
export PATH=$LOCALPREFIX/bin:$PATH
export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
Next, we will need to SSH into the E31x and will mount the ~/e300 folder using
SSHFS in order to test our new installation.
* Note: This tutorial assumes you're using the default IP address of
192.168.10.2 for your E31x device, and that your host has the IP address of
192.168.10.1. If you're using different IP addresses, the commands below will
need to be updated to reflect the correct IPs.
Open a new terminal and verify that you can ping the E31x:
$ ping 192.168.10.2
Next, SSH into the E31x.
$ ssh [email protected]
For this next step, your host computer will need to have OpenSSH Server
installed.
Open a third terminal window on the host and run:
$ sudo apt-get install openssh-server
Returning to the terminal which you're connected to the E31x via SSH, mount the
~/e300 folder onto the E31x.
First create a directory to mount the remote folder to with (running these
commands on the E31x):
$ mkdir -p ~/newinstall
$ sshfs [email protected]:e300 newinstall/
* Note: The "username" in the above command needs to be updated to reflect your
user on the host machine.
When prompted, enter the password of your user to complete the mounting of the
remote file system.
Verify the mount was successful, your directory structure should match ~/e300
on the host machine.
$ ls ~/newinstall/
Expected output:
environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
setup_env.sh
site-config-armv7ahf-vfp-neon-oe-linux-gnueabi
src
sysroots
usr
version-armv7ahf-vfp-neon-oe-linux-gnueabi
Next, we will need to setup the system environment on the E31x to use the newly
compiled version of UHD.
We will first verify that the E31x is using the existing UHD installation,
using the "which" command:
$ which uhd_usrp_probe
Expected output:
/usr/bin/uhd_usrp_probe
Next, source the setup_env.sh file:
$ cd ~/newinstall
$ source ./setup_env.sh
Now we will verify that the newly compiled UHD is being used, again using the
"which" command:
$ which uhd_usrp_probe
Expected output:
/home/root/newinstall/usr/bin/uhd_usrp_probe
Next, we must download the correct FPGA images for the new installation. Run
the utility "uhd_images_downloader", since the E3xx is not connected to the
internet, this will throw an error:
$ uhd_images_downloader
Expected output:
UHD_IMAGES_DIR environment variable is set.
Default install location: /home/root/newinstall/usr/share/uhd/images
Images destination: /home/root/newinstall/usr/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip
Downloading images to:
/tmp/tmpS1uIFt/uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip
Downloader raised an unhandled exception: ('Connection aborted.', gaierror(-2,
'Name or service not known'))
You can run this again with the '--verbose' flag to see more information
If the problem persists, please email the output to: [email protected]
Note the URL to the FPGA images package which is trying to access. Copy this
URL and return to a terminal that is on your host machine and download it into
the ~/e300/src folder.
On the host machine run:
$ cd ~/e300/src
$ wget
http://files.ettus.com/binaries/images/uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip
* Note, This FPGA image package will vary depending upon the current version of
UHD you are using. You must use the URL that is shown in the above output when
trying to run uhd_images_downloader.
Next, decompress this file:
$ unzip uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip
Note, the URL/paths may be slightly different than what is shown above due to
different versions, however the process is the same.
Next we must create the folder for the FPGA images.
Navigate to the folder on your host machine:
$ cd ~/e300/usr/share/uhd/
$ mkdir -p images
$ cd images/
Verify your directory with the pwd command:
$ pwd
Expected output:
/home/user/e300/usr/share/uhd/images
Now, copy the FPGA images from the decompressed FPGA zip package:
$ cp -R
~/e300/src/uhd-images_4.0.0.rfnoc-devel-238-g39a41476/share/uhd/images/* .
Verify the copy was successful:
$ ls
Expected Output:
$ ls
4.0.0.rfnoc-devel.tag usrp_b200_fpga.bin usrp_n200_fw.bin
usrp_x300_fpga_RFNOC_XG.bit
bit usrp_b200_fw.hex usrp_n200_r2_fpga.bin
usrp_x300_fpga_RFNOC_XG.lvbitx
LICENSE usrp_b200mini_fpga.bin usrp_n200_r3_fpga.bin
usrp_x300_fpga_XG.bit
octoclock_bootloader.hex usrp_b205mini_fpga.bin usrp_n200_r4_fpga.bin
usrp_x300_fpga_XG.lvbitx
octoclock_r4_fw.hex usrp_b210_fpga.bin usrp_n210_fw.bin
usrp_x310_fpga_HG.bit
usrp1_fpga_4rx.rbf usrp_e100_fpga_v2.bin usrp_n210_r2_fpga.bin
usrp_x310_fpga_HG.lvbitx
usrp1_fpga.rbf usrp_e110_fpga.bin usrp_n210_r3_fpga.bin
usrp_x310_fpga_RFNOC_HG.bit
usrp1_fw.ihx usrp_e310_fpga.bit usrp_n210_r4_fpga.bin
usrp_x310_fpga_RFNOC_HG.lvbitx
usrp2_fpga.bin usrp_e310_fpga_RFNOC.bit usrp_n230_fpga.bit
usrp_x310_fpga_RFNOC_XG.bit
usrp2_fw.bin usrp_e310_fpga_RFNOC_sg3.bit usrp_x300_fpga_HG.bit
usrp_x310_fpga_RFNOC_XG.lvbitx
usrp_b100_fpga_2rx.bin usrp_e310_fpga_sg3.bit
usrp_x300_fpga_HG.lvbitx usrp_x310_fpga_XG.bit
usrp_b100_fpga.bin usrp_e3xx_fpga_idle.bit
usrp_x300_fpga_RFNOC_HG.bit usrp_x310_fpga_XG.lvbitx
usrp_b100_fw.ihx usrp_e3xx_fpga_idle_sg3.bit
usrp_x300_fpga_RFNOC_HG.lvbitx winusb_driver
Next, in order to save space on the E31x when we transfer this build to the
E31x, delete all non-E31x FPGA images.
$ rm -v usrp1_f*
$ rm -v usrp2_f*
$ rm -v usrp_b*
$ rm -v usrp_n2*
$ rm -v usrp_x3*
$ rm -v usrp_e1*
$ rm -v octoclock_*
$ rm -vrf winusb_driver/
$ rm -vrf bit/
Verify the folder structure:
$ ls
Expected Output:
4.0.0.rfnoc-devel.tag usrp_e310_fpga.bit usrp_e310_fpga_RFNOC_sg3.bit
usrp_e3xx_fpga_idle.bit
LICENSE usrp_e310_fpga_RFNOC.bit usrp_e310_fpga_sg3.bit
usrp_e3xx_fpga_idle_sg3.bit
Next, return to the terminal which is connected via SSH to the E31x and run
uhd_usrp_probe:
$ uhd_usrp_probe
Expect output:
[INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-devel-369-g1908672f]
[INFO] [E300] Loading FPGA image:
/home/root/newinstall/usr/share/uhd/images/usrp_e310_fpga_sg3.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Initializing core control (global registers)...
[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input ports
[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] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
_____________________________________________________
/
| Device: E-Series Device
| _____________________________________________________
| /
| | Mboard: E3XX
| | product: 30675
| | revision: 6
| | serial: xxxxxxx
| | mac-addr: 00:00:00:00:00:00
| | FPGA Version: 255.0
| | FPGA git hash: f764326-dirty
| | RFNoC capable: Yes
| |
| | Time sources: none, internal, external
| | Clock sources: internal
| | Sensors: temp, ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | |
| | | Freq range: 0.000 to 0.000 MHz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | |
| | | Freq range: 0.000 to 0.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: E310 MIMO XCVR (0x0110)
| | | Serial: xxxxxx
| | | _____________________________________________________
| | | /
| | | | 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: 200000.0 to 56000000.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: 200000.0 to 56000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: E3x0 RX dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | |
| | | Freq range: 0.000 to 0.000 MHz
| | _____________________________________________________
| | /
| | | TX DSP: 1
| | |
| | | Freq range: 0.000 to 0.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: E310 MIMO XCVR (0x0110)
| | | Serial: xxxxxx
| | | _____________________________________________________
| | | /
| | | | 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: 200000.0 to 56000000.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: 200000.0 to 56000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: E3x0 TX dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Radio_0
| | | * FIFO_0
| | | * Window_0
| | | * FFT_0
| | | * fosphor_0
| | | * FIFO_1
| | | * FIR_0
* Note, you may see additional errors when the idle FPGA image is loaded, this
is a bug that will be resolved in an upcoming rfnoc-devel release.
At this point, it's possible to run the included UHD example programs with the
newly compiled UHD.
$ cd ~/newinstall/usr/lib/uhd/examples/
$ ./rx_samples_to_file --freq 100e6 --gain 0 --ant TX/RX --rate 1e6 --null
Press CTRL+C to exit the program.
Next, we will build and install GNU Radio.
On the host computer, navigate to the ~/e300/src/gnuradio directory, and build
GNU Radio:
$ cd ~/e300/src/gnuradio
$ mkdir build
$ cd build
$ cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake
-DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
-DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
$ make -j4
$ make install DESTDIR=~/e300/
$ make install DESTDIR=~/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
Next, verify your GNU Radio installation was successful. On the E31x terminal,
run the command:
$ gnuradio-config-info --version
Expected output:
3.7.10.2
Next, we will build gr-ettus. On the host machine, navigate to
~/e300/src/gr-ettus:
$ cd ~/e300/src/gr-ettus
$ mkdir build
$ cd build
$ cmake
-DCMAKE_TOOLCHAIN_FILE=~/e300/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr ..
$ make -j4
$ make install DESTDIR=~/e300/
At this point you should have a fully functional UHD RFNoC, GNU Radio and
gr-ettus installation. However being that the compiled sources are not located
on the E31x we will need to transfer the files to the E31x.
On the host machine navigate to your home directory:
Next, create a folder on the E31x, "localinstall"
$ mkdir -p ~/localinstall
Next, copy the etc/, setup_env.sh and usr/ folder to this new local folder:
$ cd ~/localinstall
$ cp -Rv ~/newinstall/setup_env.sh .
$ cp -Rv ~/newinstall/etc .
$ cp -Rv ~/newinstall/usr .
Verify the folder contents:
$ ls ~/localinstall
Expected Output:
etc/
setup_env.sh
usr/
Next, we will need to update the "setup_env.sh" file that is located within the
~/localinstall/ folder.
Verify your directory location with the pwd command:
$ pwd
Expected Output:
/home/root/localinstall
Edit the setup_env.sh file to update the PATH variable to point to your new
installation location (/home/root/localinstall):
$ sed -i 's/newinstall/localinstall/g' setup_env.sh
Verify your edit was successful with the command "cat":
$ cat setup_env.sh
Expected Output:
LOCALPREFIX=~/localinstall/usr
export PATH=$LOCALPREFIX/bin:$PATH
export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
Note, the LOCALPREFIX variable has been updated to the new location.
This setup_env.sh file needs to be source in order to utilize the new
~/localinstall location.
$ source ./setup_env.sh
Verify that the environment is setup correctly:
$ which uhd_usrp_probe
Expected Output:
/home/root/localinstall/usr/bin/uhd_usrp_probe
We can now dismount the remotely connected SSHFS folder. On the E31x, run the
command:
$ umount ~/newinstall
------------------------------
Message: 6
Date: Mon, 3 Jul 2017 12:58:07 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Different streaming modes at the same time
with same USRP hardware
Message-ID:
<ca+abmwkk83nwnwagcwv1c7qo82acwdbsdcvrko0e+sgnc5n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Michael,
I've followed your suggestion and hacked the rx_samples_c.c example.
It seems to be working but I'm not sure if that is the right way of doing
that.
Could you please have a quick look and tell me if that is the correct way
of creating 2 different RX streams.
Thanks and Kind Regards,
Felipe Augusto
/*
* Copyright 2015 Ettus Research LLC
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <uhd.h>
#include "getopt.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define EXECUTE_OR_GOTO(label, ...) \
if(__VA_ARGS__){ \
return_code = EXIT_FAILURE; \
goto label; \
}
void print_help(void){
fprintf(stderr, "rx_samples_c - A simple RX example using UHD's C
API\n\n"
"Options:\n"
" -a (device args)\n"
" -f (frequency in Hz)\n"
" -r (sample rate in Hz)\n"
" -g (gain)\n"
" -n (number of samples to receive)\n"
" -o (output filename, default = \"out.dat\")\n"
" -v (enable verbose prints)\n"
" -h (print this help message)\n");
};
int main(int argc, char* argv[])
{
if(uhd_set_thread_priority(uhd_default_thread_priority, true)){
fprintf(stderr, "Unable to set thread priority. Continuing
anyway.\n");
}
int option = 0;
double freq = 2.4e9;
double rate = 10e6;
double gain = 5.0;
char* device_args = "";
size_t channel[2] = {0,1};
char *filename0 = "out0.dat", *filename1 = "out1.dat";
size_t n_samples = 1000000;
bool verbose = false;
int return_code = EXIT_SUCCESS;
bool custom_filename0 = false, custom_filename1 = false;
char error_string[512];
// Process options
while((option = getopt(argc, argv, "a:f:r:g:n:o:O:vh")) != -1){
switch(option){
case 'a':
device_args = strdup(optarg);
break;
case 'f':
freq = atof(optarg);
break;
case 'r':
rate = atof(optarg);
break;
case 'g':
gain = atof(optarg);
break;
case 'n':
n_samples = atoi(optarg);
break;
case 'o':
filename0 = strdup(optarg);
custom_filename0 = true;
break;
case 'O':
filename1 = strdup(optarg);
custom_filename1 = true;
break;
case 'v':
verbose = true;
break;
case 'h':
print_help();
goto free_option_strings;
default:
print_help();
return_code = EXIT_FAILURE;
goto free_option_strings;
}
}
// Create USRP
uhd_usrp_handle usrp;
fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
EXECUTE_OR_GOTO(free_option_strings,
uhd_usrp_make(&usrp, device_args)
)
// Create RX streamer #0.
uhd_rx_streamer_handle rx_streamer0;
EXECUTE_OR_GOTO(free_usrp,
uhd_rx_streamer_make(&rx_streamer0)
)
// Create RX metadata #0.
uhd_rx_metadata_handle md0;
EXECUTE_OR_GOTO(free_rx_streamer0,
uhd_rx_metadata_make(&md0)
)
// Create RX streamer #1.
uhd_rx_streamer_handle rx_streamer1;
EXECUTE_OR_GOTO(free_usrp,
uhd_rx_streamer_make(&rx_streamer1)
)
// Create RX metadata #1.
uhd_rx_metadata_handle md1;
EXECUTE_OR_GOTO(free_rx_streamer1,
uhd_rx_metadata_make(&md1)
)
// Create other necessary structs
uhd_tune_request_t tune_request = {
.target_freq = freq,
.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
};
uhd_tune_result_t tune_result;
uhd_stream_args_t stream_args = {
.cpu_format = "fc32",
.otw_format = "sc16",
.args = "",
.channel_list = &channel,
.n_channels = 2
};
size_t samps_per_buff0, samps_per_buff1;
float *buff0 = NULL, *buff1 = NULL;
void **buffs_ptr0 = NULL, **buffs_ptr1 = NULL;
FILE *fp0 = NULL, *fp1 = NULL;
size_t num_acc_samps0 = 0, num_acc_samps1 = 0;
// Set rate for stream #0
fprintf(stderr, "Setting RX Rate 0: %f...\n", rate);
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_set_rx_rate(usrp, rate, channel[0])
)
// Set rate for stream #1
// Stream number 1 should have a different sampling rate.
rate = 2*rate;
fprintf(stderr, "Setting RX Rate 1: %f...\n", rate);
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_set_rx_rate(usrp, rate, channel[1])
)
// See what rate is actually set for stream #0
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_get_rx_rate(usrp, channel[0], &rate)
)
fprintf(stderr, "Actual RX Rate 0: %f...\n", rate);
// See what rate is actually set for stream #1
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_get_rx_rate(usrp, channel[1], &rate)
)
fprintf(stderr, "Actual RX Rate 1: %f...\n", rate);
// Set gain for stream #0
fprintf(stderr, "Setting RX Gain 0: %f dB...\n", gain);
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_set_rx_gain(usrp, gain, channel[0], "")
)
// Set gain for stream #1
fprintf(stderr, "Setting RX Gain 1: %f dB...\n", gain);
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_set_rx_gain(usrp, gain, channel[1], "")
)
// See what gain is actually set for stream #0
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_get_rx_gain(usrp, channel[0], "", &gain)
)
fprintf(stderr, "Actual RX Gain 0: %f...\n", gain);
// See what gain is actually set for stream #1
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_get_rx_gain(usrp, channel[1], "", &gain)
)
fprintf(stderr, "Actual RX Gain 1: %f...\n", gain);
// Set frequency for stream #0
fprintf(stderr, "Setting RX frequency 0: %f MHz...\n", freq/1e6);
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_set_rx_freq(usrp, &tune_request, channel[0], &tune_result)
)
// Set frequency for stream #1
freq = 3e9;
tune_request.target_freq = freq;
fprintf(stderr, "Setting RX frequency 1: %f MHz...\n", freq/1e6);
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_set_rx_freq(usrp, &tune_request, channel[1], &tune_result)
)
// See what frequency is actually set fro stream #0
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_get_rx_freq(usrp, channel[0], &freq)
)
fprintf(stderr, "Actual RX frequency 0: %f MHz...\n", freq / 1e6);
// See what frequency is actually set fro stream #1
EXECUTE_OR_GOTO(free_rx_metadata,
uhd_usrp_get_rx_freq(usrp, channel[1], &freq)
)
fprintf(stderr, "Actual RX frequency 1: %f MHz...\n", freq / 1e6);
// Set up streamer #0.
printf("Try to get RX Stream #0\n");
stream_args.channel_list = &channel[0];
stream_args.n_channels = 1;
EXECUTE_OR_GOTO(free_rx_streamer0,
uhd_usrp_get_rx_stream(usrp, &stream_args, rx_streamer0)
)
printf("Got RX Stream #0\n");
// Set up streamer #1.
printf("Try to get RX Stream #1\n");
stream_args.channel_list = &channel[1];
stream_args.n_channels = 1;
EXECUTE_OR_GOTO(free_rx_streamer1,
uhd_usrp_get_rx_stream(usrp, &stream_args, rx_streamer1)
)
printf("Got RX Stream #1\n");
// Set up buffer for stream #0.
EXECUTE_OR_GOTO(free_rx_streamer0,
uhd_rx_streamer_max_num_samps(rx_streamer0, &samps_per_buff0)
)
printf("Buffer size in samples for stream #0: %zu\n", samps_per_buff0);
buff0 = malloc(samps_per_buff0 * 2 * sizeof(float));
buffs_ptr0 = (void**)&buff0;
// Set up buffer for stream #1.
EXECUTE_OR_GOTO(free_rx_streamer1,
uhd_rx_streamer_max_num_samps(rx_streamer1, &samps_per_buff1)
)
printf("Buffer size in samples for stream #1: %zu\n", samps_per_buff1);
buff1 = malloc(samps_per_buff1 * 2 * sizeof(float));
buffs_ptr1 = (void**)&buff1;
// Stream command for stream #0.
uhd_stream_cmd_t stream_cmd0 = {
.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE,
.num_samps = n_samples,
.stream_now = false,
.time_spec_full_secs = 2,
.time_spec_frac_secs = 0
};
// Issue stream command for stream #0.
fprintf(stderr, "Issuing stream command for stream #0.\n");
EXECUTE_OR_GOTO(free_buffer0,
uhd_rx_streamer_issue_stream_cmd(rx_streamer0, &stream_cmd0)
)
// Stream command for stream #1.
uhd_stream_cmd_t stream_cmd1 = {
.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE,
.num_samps = n_samples,
.stream_now = false,
.time_spec_full_secs = 4,
.time_spec_frac_secs = 0
};
// Issue stream command for stream #1.
fprintf(stderr, "Issuing stream command for stream #1.\n");
EXECUTE_OR_GOTO(free_buffer1,
uhd_rx_streamer_issue_stream_cmd(rx_streamer1, &stream_cmd1)
)
// Set up file output for stream #0.
fp0 = fopen(filename0, "wb");
// Set up file output for stream #1.
fp1 = fopen(filename1, "wb");
// Actual streaming
while (num_acc_samps0 < n_samples) {
size_t num_rx_samps0 = 0;
EXECUTE_OR_GOTO(close_file0,
uhd_rx_streamer_recv(rx_streamer0, buffs_ptr0, samps_per_buff0,
&md0, 3.0, false, &num_rx_samps0)
)
size_t num_rx_samps1 = 0;
EXECUTE_OR_GOTO(close_file1,
uhd_rx_streamer_recv(rx_streamer1, buffs_ptr1, samps_per_buff1,
&md1, 3.0, false, &num_rx_samps1)
)
uhd_rx_metadata_error_code_t error_code0;
EXECUTE_OR_GOTO(close_file0,
uhd_rx_metadata_error_code(md0, &error_code0)
)
if(error_code0 != UHD_RX_METADATA_ERROR_CODE_NONE){
fprintf(stderr, "Error code 0x%x was returned during streaming.
Aborting: 0x%x.\n", return_code,error_code0);
goto close_file0;
}
uhd_rx_metadata_error_code_t error_code1;
EXECUTE_OR_GOTO(close_file1,
uhd_rx_metadata_error_code(md1, &error_code1)
)
if(error_code1 != UHD_RX_METADATA_ERROR_CODE_NONE){
fprintf(stderr, "Error code 0x%x was returned during streaming.
Aborting: 0x%x.\n", return_code,error_code1);
goto close_file1;
}
// Handle data for stream #0.
fwrite(buff0, sizeof(float) * 2, num_rx_samps0, fp0);
if (verbose) {
time_t full_secs;
double frac_secs;
uhd_rx_metadata_time_spec(md0, &full_secs, &frac_secs);
fprintf(stderr, "Received packet: %zu samples, %.f full secs,
%f frac secs\n",
num_rx_samps0,
difftime(full_secs, (time_t) 0),
frac_secs);
}
num_acc_samps0 += num_rx_samps0;
// Handle data for stream #1.
fwrite(buff1, sizeof(float) * 2, num_rx_samps1, fp1);
if (verbose) {
time_t full_secs;
double frac_secs;
uhd_rx_metadata_time_spec(md1, &full_secs, &frac_secs);
fprintf(stderr, "Received packet: %zu samples, %.f full secs,
%f frac secs\n",
num_rx_samps1,
difftime(full_secs, (time_t) 0),
frac_secs);
}
num_acc_samps1 += num_rx_samps1;
}
printf("Finished.\n");
// Cleanup
close_file0:
fclose(fp0);
close_file1:
fclose(fp1);
free_buffer0:
if(buff0){
if(verbose){
fprintf(stderr, "Freeing buffer #0.\n");
}
free(buff0);
}
buff0 = NULL;
buffs_ptr0 = NULL;
free_buffer1:
if(buff1){
if(verbose){
fprintf(stderr, "Freeing buffer #1.\n");
}
free(buff1);
}
buff1 = NULL;
buffs_ptr1 = NULL;
free_rx_streamer0:
if(verbose){
fprintf(stderr, "Cleaning up RX streamer #0.\n");
}
uhd_rx_streamer_free(&rx_streamer0);
free_rx_streamer1:
if(verbose){
fprintf(stderr, "Cleaning up RX streamer #1.\n");
}
uhd_rx_streamer_free(&rx_streamer1);
free_rx_metadata:
if(verbose){
fprintf(stderr, "Cleaning up RX metadata.\n");
}
uhd_rx_metadata_free(&md0);
free_usrp:
if(verbose){
fprintf(stderr, "Cleaning up USRP.\n");
}
if(return_code != EXIT_SUCCESS && usrp != NULL){
uhd_usrp_last_error(usrp, error_string, 512);
fprintf(stderr, "USRP reported the following error: %s\n",
error_string);
}
uhd_usrp_free(&usrp);
free_option_strings:
if(strcmp(device_args,"")){
free(device_args);
}
if(custom_filename0){
free(filename0);
}
if(custom_filename1){
free(filename1);
}
fprintf(stderr, (return_code ? "Failure\n" : "Success\n"));
return return_code;
}
On Sat, Jul 1, 2017 at 6:36 PM, Michael West <[email protected]> wrote:
> Hi Felipe,
>
> Both the multi_usrp API and the RFNoC API support it. And yes, you need
> to create two different stream objects.
>
> Regards,
> Michael
>
> On Sat, Jul 1, 2017 at 2:45 AM, Felipe Augusto Pereira de Figueiredo <
> [email protected]> wrote:
>
>> Dear Michael,
>>
>> Some more questions follows inline.
>>
>> Thanks and Kind Regards,
>>
>> Felipe Augusto
>>
>> On Sat, Jul 1, 2017 at 2:16 AM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Felipe,
>>>
>>> 1) Yes, that is supported.
>>>
>>
>> When you say that is supported, do you mean with legacy UHD API or with
>> RFNoC one? Even though I have a x310 I'm still using the legacy API.
>>
>>>
>>> 2) There is no example, but it is pretty easy. Just set the
>>> uhd::stream_args_t::channels value correctly for each streamer object.
>>>
>>
>> Do I need to create two different stream objects?
>>
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, Jun 30, 2017 at 12:00 PM, Felipe Augusto Pereira de Figueiredo <
>>> [email protected]> wrote:
>>>
>>>> Dear Michael,
>>>>
>>>> Thanks for the reply.
>>>>
>>>> Given your answer, I've got two additional questions:
>>>>
>>>> 1) Does it mean I can create a RX stream to read RXed samples from the
>>>> RF chain 0 (I think you call DSP0) and another RX stream to read samples
>>>> from RF chain 1 (DSP1)? I'd like to have a SISO physical layer running
>>>> (TX/RX) on the RF chain 0 at frequency X and sample rate Y and a spectrum
>>>> sensing module with different sampling rate Z at frequency W on the RF
>>>> chain 1.
>>>>
>>>> 2) Is there any example on how to create different streamers to
>>>> receive/transmit using different RF Chains?
>>>>
>>>> Many Thanks and Kind Regards,
>>>>
>>>> Felipe Augusto
>>>>
>>>> On Fri, Jun 30, 2017 at 8:32 PM, Michael West <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Felipe,
>>>>>
>>>>> Yes. If you create different streamers, each with a different set of
>>>>> channels, each streamer can be configured independently.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Tue, Jun 27, 2017 at 7:28 AM, Felipe Augusto Pereira de Figueiredo
>>>>> via USRP-users <[email protected]> wrote:
>>>>>
>>>>>> Dear folks,
>>>>>>
>>>>>> I've got a x310 and I'd like to know if it is possible to open two
>>>>>> streams with different streaming modes at the same time in the same USRP
>>>>>> hardware.
>>>>>>
>>>>>> For example, the first RF chain would be configures as
>>>>>>
>>>>>> *UHD_STREAM_MODE_START_CONTINUOUS*
>>>>>>
>>>>>> and the second one would be set to
>>>>>>
>>>>>> *UHD_STREAM_MODE_NUM_SAMPS_AND_DONE*
>>>>>>
>>>>>> Is is possible?
>>>>>>
>>>>>> Thanks and Kind regards,
>>>>>>
>>>>>> Felipe Augusto
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/a90ed297/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_samples_c.c
Type: text/x-csrc
Size: 13551 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/a90ed297/attachment-0001.c>
------------------------------
Message: 7
Date: Mon, 3 Jul 2017 13:01:41 +0200
From: altu? kaya <[email protected]>
To: [email protected]
Subject: [USRP-users] Tune Request for B210
Message-ID:
<CAHq6UV8K_ExGhK_xuzNWU3Fv7WVhG=gkhdxv2c3b39pqmtz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I would like to tune the DDC Chain of my B210. When I search the net and
ask to this forum, I learned that I have to equate the sampling rate to the
master clock in order to by-pass the filters and I have to eliminate the
CORDIC in order to add/subtract 0 Degrees from IQ data. Changing the
sampling rate is rather easy, as it is done from cmd by entering an
additional parameter. However, I did not understand how to manipulate
CORDIC.
In the MailArchive of USRP[1], I found the explanation below:
> A tune request similar to this will disable the CORDIC:
> uhd::tune_request_t tune_req(target_frequency_in_hz, desired_lo_offset);
> tune_req.dsp_freq_policy = tune_request_t::POLICY_MANUAL;
> tune_req.dsp_freq = 0.0;
>
> But, I really cannot figure out where to put these. Should I write a C++
code and include tune_request.hpp?
I am looking forward to your reply,
Altug
[1]https://www.mail-archive.com/[email protected]/msg01105.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/08d1101a/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 3 Jul 2017 13:04:54 +0200
From: Nicolas Cuervo <[email protected]>
To: ??? <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Build RFNoC environment
Message-ID:
<caoupcvi7sfgwfajm9rcmnun+xgfdz33v_z8lv9ntqtju1rx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Kim,
Are you still facing this problem while trying a pybombs installation?
While looking at the previous commits from pybombs, there were a couple
ruamel related that might have had something to do with API changes [1].
There have been changes in PyBombs since then. So, if you are still facing
this, could you please update your pybombs:
$ [sudo] pip install [--upgrade] git+https://github.com/gnuradio/pybombs.git
and try again?
If you try this, please let us know if the issue persists as well.
Regards,
- Nicolas
[1] Not completely sure, but might have to do with your specific issue:
https://github.com/gnuradio/pybombs/commit/635a69c69109febcf9c800d6b5aaffa310712026
https://github.com/gnuradio/pybombs/commit/62b6a01b841845ff34ba0e3d69d3248c7322e841
On Fri, Jun 9, 2017 at 12:24 PM, ??? via USRP-users <
[email protected]> wrote:
> Hi all.
>
>
>
> I installed GRC on Ubuntu 16.04 with <Software Development on the E310 and
> E312> procedure.
>
> after that I tried <Getting Started with RFNoC Development> procedure, and
> fail.
>
> I reinstall ubuntu and <Getting Started with RFNoC Development> again.
>
>
>
> I got this error message on "pybombs prefix init ~/rfnoc -R rfnoc -a
> rfnoc" step.
>
> I hope someone guide me to right procedure, or teach me what am i missing.
>
>
>
>
>
> Exception ruamel.yaml.constructor.ConstructorError: ConstructorError() in
> <generator object construct_undefined at 0x7fd5261ba0a0> ignored
> Traceback (most recent call last):
> File "/usr/local/bin/pybombs", line 9, in <module>
> load_entry_point('PyBOMBS==2.3.1a0', 'console_scripts', 'pybombs')()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> 542, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> 2569, in load_entry_point
> return ep.load()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> 2229, in load
> return self.resolve()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> 2235, in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
> File "/usr/local/lib/python2.7/dist-packages/pybombs/main.py", line 26,
> in <module>
> from pybombs.commands import dispatch
> File "/usr/local/lib/python2.7/dist-packages/pybombs/commands/__init__.py",
> line 23, in <module>
> from .base import CommandBase, SubCommandBase, dispatch
> File "/usr/local/lib/python2.7/dist-packages/pybombs/commands/base.py",
> line 27, in <module>
> from pybombs.config_manager import config_manager
> File "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 654, in <module>
> config_manager = ConfigManager()
> File "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 330, in __init__
> self.load(select_prefix)
> File "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 370, in load
> if self._append_cfg_from_file(self.local_cfg):
> File "/usr/local/lib/python2.7/dist-packages/pybombs/config_manager.py",
> line 446, in _append_cfg_from_file
> cfg_data = PBConfigFile(cfg_filename).get()
> File "/usr/local/lib/python2.7/dist-packages/pybombs/config_file.py",
> line 42, in __init__
> raise PBException("Error loading {0}: {1}".format(filename, str(e)))
> pybombs.pb_exception.PBException: Error loading
> /home/duck4985/.pybombs/config.yml:
> could not determine a constructor for the tag '!!python/tuple'
> in "<byte string>", line 3, column 3:
> - !!python/tuple []
> ^ (line: 3)
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/d586b03d/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 3 Jul 2017 14:52:43 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Tune Request for B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
You can do this with uhd.tune_request_t in python, if you're writing GNU
Radio Python code, but otherwise, yes, that should be part of your C++
UHD program; see the examples that ship with UHD [1] under host/examples.
Anyway, as I tried to illustrate before, I don't think you're chasing
the right problem, but I might still be misunderstanding you. Could you
maybe explain why you think setting the DSP frequency to zero solves
your problem, and what exactly that problem is, and why it is a problem?
Thanks!
Best regards,
Marcus
[1] https://github.com/EttusResearch/uhd
On 07/03/2017 01:01 PM, altu? kaya via USRP-users wrote:
> Hello everyone,
>
> I would like to tune the DDC Chain of my B210. When I search the net
> and ask to this forum, I learned that I have to equate the sampling
> rate to the master clock in order to by-pass the filters and I have to
> eliminate the CORDIC in order to add/subtract 0 Degrees from IQ data.
> Changing the sampling rate is rather easy, as it is done from cmd by
> entering an additional parameter. However, I did not understand how to
> manipulate CORDIC.
>
> In the MailArchive of USRP[1], I found the explanation below:
>
> A tune request similar to this will disable the CORDIC:
> uhd::tune_request_t tune_req(target_frequency_in_hz, desired_lo_offset);
> tune_req.dsp_freq_policy = tune_request_t::POLICY_MANUAL;
> tune_req.dsp_freq = 0.0;
>
> But, I really cannot figure out where to put these. Should I write a
> C++ code and include tune_request.hpp?
>
> I am looking forward to your reply,
> Altug
>
> [1]https://www.mail-archive.com/[email protected]/msg01105.html
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/36745409/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 3 Jul 2017 15:06:51 +0200
From: altu? kaya <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Tune Request for B210
Message-ID:
<cahq6uv_+hbxwqpweoeynjnlxpc4t54u2_5qqtsuqvvxz57a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
Thank you for your answer.
There is a transmitter and I try to receive the transmitted signal with two
antennas of the B210. As the signal is transmitted from the same source, I
would expect same signals at the receiver side. Nevertheless, at the output
(after the DSP part of the FPGA) these two very same signals become
phase-shifted. Thus, I want to by-pass the DDC Chain in order to observe
weather phase-shift is caused by DSP modules or not.
If you have any suggestions, I would keen to hear them.
Best regards,
Altug
On Mon, Jul 3, 2017 at 2:52 PM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> You can do this with uhd.tune_request_t in python, if you're writing GNU
> Radio Python code, but otherwise, yes, that should be part of your C++ UHD
> program; see the examples that ship with UHD [1] under host/examples.
>
> Anyway, as I tried to illustrate before, I don't think you're chasing the
> right problem, but I might still be misunderstanding you. Could you maybe
> explain why you think setting the DSP frequency to zero solves your
> problem, and what exactly that problem is, and why it is a problem? Thanks!
>
> Best regards,
>
> Marcus
>
> [1] https://github.com/EttusResearch/uhd
>
> On 07/03/2017 01:01 PM, altu? kaya via USRP-users wrote:
>
> Hello everyone,
>
> I would like to tune the DDC Chain of my B210. When I search the net and
> ask to this forum, I learned that I have to equate the sampling rate to the
> master clock in order to by-pass the filters and I have to eliminate the
> CORDIC in order to add/subtract 0 Degrees from IQ data. Changing the
> sampling rate is rather easy, as it is done from cmd by entering an
> additional parameter. However, I did not understand how to manipulate
> CORDIC.
>
> In the MailArchive of USRP[1], I found the explanation below:
>
>> A tune request similar to this will disable the CORDIC:
>> uhd::tune_request_t tune_req(target_frequency_in_hz, desired_lo_offset);
>> tune_req.dsp_freq_policy = tune_request_t::POLICY_MANUAL;
>> tune_req.dsp_freq = 0.0;
>>
>> But, I really cannot figure out where to put these. Should I write a C++
> code and include tune_request.hpp?
>
> I am looking forward to your reply,
> Altug
>
> [1]https://www.mail-archive.com/[email protected]/msg01105.html
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/597ab4b3/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 3 Jul 2017 15:13:53 +0200
From: Marcus M?ller <[email protected]>
To: altu? kaya <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Tune Request for B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Altug,
> There is a transmitter and I try to receive the transmitted signal
> with two antennas of the B210. As the signal is transmitted from the
> same source, I would expect same signals at the receiver side.
> Nevertheless, at the output (after the DSP part of the FPGA) these two
> very same signals become phase-shifted.
That can have multiple reasons, among these:
* different distances between the transmitter and the phase center of
the receive antennas
* physically different phase length of cables, connectors, and the
analog part of the receiver.
These would be a static offset, and totally normal, and also,
inevitable. You'll need to calibrate these out.
The DSP tuning part would only exhibit a different phase if the first
DSP chain was tuned at a different time than the second. You can avoid
that by always using timed commands for tuning. The actual frequency you
tune to, be it 0 Hz Offset or not, doesn't matter, as the two CORDICs
are absolutely identical and will stay identical if started with the
same phase at the same time.
Best regards,
Marcus
On 07/03/2017 03:06 PM, altu? kaya wrote:
> Dear Marcus,
>
> Thank you for your answer.
>
> There is a transmitter and I try to receive the transmitted signal
> with two antennas of the B210. As the signal is transmitted from the
> same source, I would expect same signals at the receiver side.
> Nevertheless, at the output (after the DSP part of the FPGA) these two
> very same signals become phase-shifted. Thus, I want to by-pass the
> DDC Chain in order to observe weather phase-shift is caused by DSP
> modules or not.
>
> If you have any suggestions, I would keen to hear them.
>
> Best regards,
> Altug
>
> On Mon, Jul 3, 2017 at 2:52 PM, Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> You can do this with uhd.tune_request_t in python, if you're
> writing GNU Radio Python code, but otherwise, yes, that should be
> part of your C++ UHD program; see the examples that ship with UHD
> [1] under host/examples.
>
> Anyway, as I tried to illustrate before, I don't think you're
> chasing the right problem, but I might still be misunderstanding
> you. Could you maybe explain why you think setting the DSP
> frequency to zero solves your problem, and what exactly that
> problem is, and why it is a problem? Thanks!
>
> Best regards,
>
> Marcus
>
> [1] https://github.com/EttusResearch/uhd
> <https://github.com/EttusResearch/uhd>
>
>
> On 07/03/2017 01:01 PM, altu? kaya via USRP-users wrote:
>> Hello everyone,
>>
>> I would like to tune the DDC Chain of my B210. When I search the
>> net and ask to this forum, I learned that I have to equate the
>> sampling rate to the master clock in order to by-pass the filters
>> and I have to eliminate the CORDIC in order to add/subtract 0
>> Degrees from IQ data. Changing the sampling rate is rather easy,
>> as it is done from cmd by entering an additional parameter.
>> However, I did not understand how to manipulate CORDIC.
>>
>> In the MailArchive of USRP[1], I found the explanation below:
>>
>> A tune request similar to this will disable the CORDIC:
>> uhd::tune_request_t tune_req(target_frequency_in_hz,
>> desired_lo_offset);
>> tune_req.dsp_freq_policy = tune_request_t::POLICY_MANUAL;
>> tune_req.dsp_freq = 0.0;
>>
>> But, I really cannot figure out where to put these. Should I
>> write a C++ code and include tune_request.hpp?
>> I am looking forward to your reply,
>> Altug
>> [1]https://www.mail-archive.com/[email protected]/msg01105.html
>> <https://www.mail-archive.com/[email protected]/msg01105.html>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> 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 [email protected]
> <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/05d0ce9b/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 3 Jul 2017 06:18:40 -0700
From: Kyeong Su Shin <[email protected]>
To: Simon Olvhammar <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID:
<CAGL0V3nnxhLbt235J=flobzbfrs4ragxfuvwkifmurav_bv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Simon Olvhammar:
Just one more note:
A relevant e-mail thread achieve, since you are apparently using ADC
sampling rate of 120MS/s on SBX-120 daughterboards:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-February/018075.html
To get better data quality, you may want to sample faster and then do
digital filtering -> decimation (USRP will do that for you, if you are fine
with integer decimators). This may prevent you from using the 120MHz
bandwidth, but improve the overall data quality.
Regards,
Kyeong Su Shin
On Mon, Jul 3, 2017 at 1:35 AM, Simon Olvhammar via USRP-users <
[email protected]> wrote:
> Hi,
>
> I am not sure if I understand correctly.
> How are the ADC to slow if I use a master clock rate of 120 MHz and
> sampling rate of 120 MHz on a UBX-160? I don't need 160 MHz bandwidth only
> 120 MHz.
>
> Regards
> Simon
>
> On 06/28/2017 04:12 PM, Sylvain Munaut wrote:
>
>> Hi,
>>
>>
>> We currently running a system with a Ettus x310 and a SBX-120.
>>> We also a have UBX-160 daughter board.
>>>
>>> For several reasons, mainly due to computer performance limitations, we
>>> can
>>> only run with a complex sampling rate of 120 MHz.
>>> My question is if I will see any improvement in performance, e.g. filter
>>> characteristics, if I instead use the UBX-160 and run it at 120 MHz
>>> compared
>>> to SBX-120 at 120 MHz or are they similar?
>>>
>> You can't do that.
>>
>> If you have the master clock-rate at 120 MHz and use a 160 MHz wide
>> daugtherboard, you will get aliasing because the ADC are too slow.
>> You'd have to go to a 100 MHz samplerate for it to work. (200 MHz
>> sampled by the ADC then HW decimated by 2 to 100 Msps).
>>
>> Cheers,
>>
>> Sylvain
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/fd6bf24c/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 03 Jul 2017 13:53:02 +0000
From: Leandro Echevarr?a <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Two questions on X310@200MSps RX
Message-ID:
<CALEOA2i8HTj0-UUJs_ORbMeX+dZ=mbnx-vbuqtktq6actqm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I'm working on a system where the transmitted samples are provided by the
FPGA, and not by the host (actually, they're loaded on DRAM in an
initializing step). And I've got two questions about this approach:
1. We're planning on dropping the DMA FIFO block entirely, to gain
exclusive access to the DRAM controller. I've read here [1] that the DMA
FIFO is necessary when transmitting using samples coming from the host, due
to Ethernet latency. But is this also true for receiving? Should I be able
to stream samples @ 200 MSps from the radio core to the host without using
a DMA FIFO in the middle?
2. We're using two 10 Gbps SFP+ Ethernet cables to connect the board to the
host. Given we will not transmit out of the host, is it safe to say we'll
be able to receive two 200 MSps streams from two daughterboards, one
through each Ethernet connection?
Thanks a lot!
Leo
[1]
https://kb.ettus.com/RFNoC#When_do_I_use_an_RFNoC_FIFO_in_my_flowgraph_and_which_kind_if_any.3F
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/64aaaef6/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 03 Jul 2017 14:15:57 +0000
From: Leandro Echevarr?a <[email protected]>
To: liu Jong <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] X310 power button
Message-ID:
<caleoa2gcondw-fxryxm0opkyvomibpt4nzexy-tpxqh_ftu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Jon,
The ELUM-EE-TH-Q-7-C12 [1] is the one that appears in the X310 schematic,
page 14 [2]. It seems to be a rather conventional SPDT switch with an LED
light to indicate power on.
Regards,
Leo.
[1]
https://www.avnet.com/shop/emea/p/switches-and-relays/switches/push-button-switch/c-k/elum-ee-th-q-7-c12-3074457345629465963/
[2] http://files.ettus.com/schematics/x300/x3xx.pdf
On Mon, Jul 3, 2017 at 4:30 AM liu Jong via USRP-users <
[email protected]> wrote:
> Hi,all,
> Because of the power button of X310 was broken,and we want to replace
> it.Could you tell us the part number of usrp X310 power button?
>
> best regards
> Jon
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/20baa0f5/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 03 Jul 2017 14:22:51 +0000
From: Boris Isakanov <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] PL2303 USB to serial adapter not recognized
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am trying to use PL2303 USB to serial adapter with USRP E310.
It is recognized as [ 3540.398720] usb 1-1.1: new full-speed USB device number
11 using zynq-ehci.
But not as USB Serial Device, no ttyUSB driver is attached to it.
dmesg | grep tty
[ 0.000000] Kernel command line: console=ttyPS0,115200 root=/dev/mmcblk0p2
rootwait ro earlyprintk
[ 0.244709] e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud
= 6249999) is a xuartps
[ 0.838132] console [ttyPS0] enabled
[ 0.842122] e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud
= 6249999) is a xuartps
Could you give me instructions how to recognize use PL2303 USB to serial
adapter.
Thanks,
Boris Isakhanov
Software Engineer
Ha'marpe 5, Har Hozvim
P.O.B. 45102, Jerusalem,
9777405 Israel
Tel: +972-2-5868330
Fax: +972-2-5868550
E-mail: [email protected]<mailto:[email protected]>
[cid:[email protected]]<http://www.accubeat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/86a86ffe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3846 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/86a86ffe/attachment-0001.jpg>
------------------------------
Message: 16
Date: Mon, 03 Jul 2017 11:32:06 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] PL2303 USB to serial adapter not recognized
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 07/03/2017 10:22 AM, Boris Isakanov via USRP-users wrote:
>
> Hello,
>
> I am trying to use PL2303 USB to serial adapter with USRP E310.
>
> It is recognized as [ 3540.398720] usb 1-1.1: new full-speed USB
> device number 11 using zynq-ehci.
>
> But not as USB Serial Device, no ttyUSB driver is attached to it.
>
> dmesg | grep tty
>
> [ 0.000000] Kernel command line: console=ttyPS0,115200
> root=/dev/mmcblk0p2 rootwait ro earlyprintk
>
> [ 0.244709] e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59,
> base_baud = 6249999) is a xuartps
>
> [ 0.838132] console [ttyPS0] enabled
>
> [ 0.842122] e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82,
> base_baud = 6249999) is a xuartps
>
> Could you give me instructions how to recognize use PL2303 USB to
> serial adapter.
>
> Thanks,
>
>
It may manifest as /dev/ttyACM0
For some reason, Linux has two different driver naming schemes for USB
serial devices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/3e3348ca/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 3 Jul 2017 17:46:08 +0200
From: Sanjoy Basak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] calibration on Wifi bands for X310/UBX
Message-ID:
<CAJPQ1a1P368Ra2j4+X3PyHMOk=-k=akczzjstmkmpon8ne_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Experts,
I am trying to calibrate X310/UBX on the whole wifi bands (the complete 2.4
GHz band).
2.412,2.417,2.422,....,2.484 GHz
I am doing direction finding tests and need to calibrate 4 channels of 2
X310s on the specified frequencies. Both X310s are connected with
Octoclock. However, I could only have calibration on 2.4 GHz, 2.45 GHz, 2.5
GHz. For other bands, calibration does not remain after retuning. Is there
any specific reason why the calibration only works for every 50 Mhz channel
after retuning. I tested with different sampling rates, but the result is
the same. Calibration does not remain after retuning.
I am using UHD_003.009.002 (installed from synaptic) and ubuntu 16.04. Is
there any specific way how I can make it work?
Best regards
Sanjoy Basak
<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&[email protected]&idSignature=22>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170703/21dc6e7e/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 83, Issue 3
*****************************************
