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. USRP N210 with Osmocom source and UHD USRP source. Setting
signal gain and probability of damage to hardware (Fernando)
2. Re: USRP N210 with Osmocom source and UHD USRP source.
Setting signal gain and probability of damage to hardware
(Kyeong Su Shin)
3. UBX-160: Receiver with 160MHz bandwidth (do ber)
4. GNURadio flowgraph taking a long time, might be USRP problem?
(Thomas Wright)
5. [RFNOC][UHD] Error in uhd_usrp_probe (Rub?n Vogel)
6. Re: UBX-160: Receiver with 160MHz bandwidth (Kyeong Su Shin)
7. Re: UBX-160: Receiver with 160MHz bandwidth (Kyeong Su Shin)
8. Re: UBX-160: Receiver with 160MHz bandwidth ([email protected])
9. Probably bug in USRP stream commands (Paul Elijah)
----------------------------------------------------------------------
Message: 1
Date: Sun, 5 Mar 2017 13:58:02 +0100
From: Fernando <[email protected]>
To: Ettus mail list <[email protected]>
Subject: [USRP-users] USRP N210 with Osmocom source and UHD USRP
source. Setting signal gain and probability of damage to hardware
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi.
I am using N210 (actually NI-USRP-2920) to receive a FM signal, I
generating the signal with a hackrf in GRC with the diagram attached.
When using osmocom source as receptor the reception is very bad, sound
is hardly recognized. But using UHD source it works fine.
I guess the problem is that when I am using osmocom source, it is not
setting the gain, so the SNR is very bad, and when using USRP the gain
is set properly. ?Am I correct? Then ?how can I set the gain using
osmocom?
The second question: I have seen that using HackRF or BladeRF with
osmocon to receive signal, if you set a high gain (in RF) and you
receive a high power signal, you can damage your hardware (the RF
amplifier). ?does this apply to USRP too?
regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NBFM-TX-HackRF-RX-USRP.grc-OK.png
Type: image/png
Size: 84774 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170305/69aa0cd5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NBFM-TX-HackRF-RX-USRP.grc-BAD.png
Type: image/png
Size: 93052 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170305/69aa0cd5/attachment-0003.png>
------------------------------
Message: 2
Date: Sun, 5 Mar 2017 18:16:34 -0800
From: Kyeong Su Shin <[email protected]>
To: Ettus mail list <[email protected]>
Subject: Re: [USRP-users] USRP N210 with Osmocom source and UHD USRP
source. Setting signal gain and probability of damage to hardware
Message-ID:
<cagl0v3k9psnqq0tapeoc5ueezficoh_26tam5ie1528wq-u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To Whom it may concern:
-I am not sure if the gain level of the signal is the root of your problem,
but if I recall correctly, "RF Gain" parameter is the right one in this
case (for Osmocom Source + WBX daughterboard combination). IF Gain / BB
Gain probably won't work.
-Yes, you can damage USRPs by overloading the RF frontends. I don't
remember the maximum power level for the WBX daughterboard, but I see a few
related mail archives from past (
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=wbx+max+input+power&*
). I usually use attenuators in such situations.
Regards,
Kyeong Su Shin
On Sun, Mar 5, 2017 at 4:58 AM, Fernando via USRP-users <
[email protected]> wrote:
> Hi.
>
>
> I am using N210 (actually NI-USRP-2920) to receive a FM signal, I
> generating the signal with a hackrf in GRC with the diagram attached.
> When using osmocom source as receptor the reception is very bad, sound
> is hardly recognized. But using UHD source it works fine.
>
> I guess the problem is that when I am using osmocom source, it is not
> setting the gain, so the SNR is very bad, and when using USRP the gain
> is set properly. ?Am I correct? Then ?how can I set the gain using
> osmocom?
>
> The second question: I have seen that using HackRF or BladeRF with
> osmocon to receive signal, if you set a high gain (in RF) and you
> receive a high power signal, you can damage your hardware (the RF
> amplifier). ?does this apply to USRP too?
>
>
> regards
>
>
>
>
>
> _______________________________________________
> 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/20170305/c60bef8b/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 6 Mar 2017 16:01:06 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: [USRP-users] UBX-160: Receiver with 160MHz bandwidth
Message-ID:
<cabldf_fn_k-_nsbdveutk8twookjqf0dhek_smz97m-vwoi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi to all,
When I buy UBX-160, I thought that I can receive signals with 160MHz
bandwidth. I am using GNURadio and USRP X310. And the data is coming over
PCIe connection. When I used the RX port of the daughterboard, I couldn't
correctly receive signals wider than 80MHz. Then I saw on the page:
The UBX 160 transmitter path has 160 MHz of bandwidth throughout the full
frequency range of the device; the receiver path has 84 MHz of bandwidth
for center frequencies from 10 MHz to 500 MHz.
I have questions related to this statement:
* If I use te TX/RX for the receiving, can I use 160 MHz bandwidth?
* For the receiver path other than 10 MHz to 500 MHz what is the max.
receiver bandwidth? My signal's center freq. is ~1.5GHz.
In short, can I take samples from a signal with 160MHz bandwidth by using
UBX-160 and X310? What about WBX120? Can I use this daughterboard with
signals having 120MHz bandwidth?
Best regards,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/106f5c7e/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 6 Mar 2017 08:23:54 -0500
From: Thomas Wright <[email protected]>
To: [email protected]
Subject: [USRP-users] GNURadio flowgraph taking a long time, might be
USRP problem?
Message-ID:
<CAB=D6PiZHYwJs09Hpio0pnWj0xXL=ugf4gbhsytc7qbkwdf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I have a simple flowgraph:
usrp n210 -> low pass filter -> stream to vector decimator -> msg queue sink
with important parameters:
sample rate = .195312 MSps
vector length = 128
decimation rate = 16
msg queue length = 1
and my application is trying to capture samples of a given signal as fast
as possible. I'm using a GRC generated python script that I'm editing, and
looking at time stamps I'm creating with datetime.now(). My general code is:
TIMESTAMP1
flowgraph.usrp.set_center_freq(center freq)
TIMESTAMP2
flowgraph.set_sample_rate(samplerate) #does usrp, filter, etc.
TIMESTAMP3
flowgraph.start()
TIMESTAMP4
flowgraph.msg_queue.delete_head() #waits for there to be data in the queue
TIMESTAMP5
flowgraph.stop()
average difference between timestamps:
1 -> 2 = .5ms
2 -> 3 = 1ms
3 -> 4 = 4ms
4 -> 5 = 80ms
My issue is that I think the time between timestamps 4 and 5 should take
about 10ms:
128 samp/vector * 16 vector * (1second / 195312 samp) =~ 10ms.
My questions that arise from this:
How much overhead SWIG/python introduce, could that be significantly
hampering performance? Would a c++ version perform significantly better?
Would a higher end usrp perform significantly better?
How close I can expect to get to the theoretical minimum?
I appreciate any information anyone could provide. Thanks very much.
-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/bcb89642/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 6 Mar 2017 12:55:32 -0300
From: Rub?n Vogel <[email protected]>
To: [email protected]
Subject: [USRP-users] [RFNOC][UHD] Error in uhd_usrp_probe
Message-ID:
<CAM7GM7Du3nMkF0i=rDwL+WN=zm9aYoSL=9-7u-9razcooq7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I trying to cross-compile UHD + GNURADIO + GR_ETTUS to USRP E310. The
versions of each one are:
UHD: UHD_4.0.0.rfnoc-0-unknown
GNURADIO: 3.7.9.3
GR_ETTUS: branch master/
I use the next script to compile it:
---------------------------------------------------------------------------------------
#!/bin/bash
cd ~/e310
source environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
echo $CC
echo ###### BUILDING UHD ###########
cd ~/e310/sources/uhd-rfnoc-devel/host/build
cmake -Wno-dev
-DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=False -DENABLE_E300=ON ..
make
echo ###### INSTALLING UHD ###########
make install DESTDIR=~/e310/sshfs
make install DESTDIR=~/e310/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
echo ###### BUILDING GNURADIO ###########
cd ~/e310/sources/gnuradio-3.7.9.3/build
cmake -Wno-dev
-DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_GR_VOCODER=OFF -DENABLE_GR_ATSC=OFF
-DENABLE_GR_WXGUI=OFF -DENABLE_GR_DTV=OFF -DENABLE_DOXYGEN=False
-DENABLE_GR_AUDIO=ON -DENABLE_GR_BLOCKS=ON -DENABLE_GR_DIGITAL=ON
-DENABLE_GR_FEC=ON -DENABLE_GR_FFT=ON -DENABLE_GR_FILTER=ON
-DENABLE_GR_QTGUI=ON -DENABLE_GR_UHD=ON -DENABLE_PYTHON=ON -DENABLE_VOLK=ON
-DENABLE_GRC=ON ..
make
echo ###### INSTALLING GNURADIO ###########
make install DESTDIR=~/e310/sshfs
make install DESTDIR=~/e310/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
echo ###### BUILDING GR-ETTUS ###########
cd ~/e310/sources/gr-ettus-master/build
cmake -Wno-dev
-DCMAKE_TOOLCHAIN_FILE=../../gnuradio-3.7.9.3/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF ..
make
echo ###### INSTALLING GR-ETTUS ###########
make install DESTDIR=~/e310/sshfs
make install DESTDIR=~/e310/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
---------------------------------------------------------------------------------------
*The sshfs directory was used to clone the Ettus file system, and the files
were installed directly on this directory. *
*The process was successful!!*
In Ettus, the images were downloaded and checked the gnuradio version and
executed the "uhd_usrp_probe" command.
root@ettus-e3xx-sg1:~# *gnuradio-config-info -v *
3.7.9.3
root@ettus-e3xx-sg1:~# *uhd_usrp_probe *
[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-0-unknown
[INFO] [E300] Loading FPGA image:
/usr/share/uhd/images/usrp_e310_fpga.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: 30674
| | revision: 4
| | serial: 30B013E
| | mac-addr: 00:80:2f:23:05:5a
| | 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: 30A717F
| | | _____________________________________________________
| | | /
| | | | 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: 30A717F
| | | _____________________________________________________
| | | /
| | | | 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
[INFO] [E300] Loading FPGA image:
/usr/share/uhd/images/usrp_e3xx_fpga_idle.bit...
[INFO] [E300] FPGA image loaded
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr<uhd::transport::managed_send_buffer>]
at
/home/localadmin/e310/sources/uhd-rfnoc-devel/host/lib/usrp/e300/e300_fifo_config.cpp:244
The rfnoc blocks are loaded correctly, and the examples can be executed
correctly in gnuradio, but "uhd_usrp_probe" throws an error and I don't
know what could be the reason.
Thank you for the time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/35a3352d/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 6 Mar 2017 08:18:28 -0800
From: Kyeong Su Shin <[email protected]>
To: Ettus mail list <[email protected]>
Subject: Re: [USRP-users] UBX-160: Receiver with 160MHz bandwidth
Message-ID:
<cagl0v3mos36927pjhjflscbvtvxe24xs7rwugydvednapgn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To Whom it may concern:
I never used X3x0s (only uses N2x0 and B2x0), so I am probably not the best
person to answer this, but this is how I understand:
-That 160MHz is for the low pass filter bandwidth (3dB point) of the
daughterboard. Has nothing to do with the effective sampling rate of the
system.
-X3x0s can theoretically do 200MS/s with the PCI-e bus. I am not sure how
realistic that is, but in theory, you can do 160MS/s alright (if the
program is well-optimized and your computer can take it).
-During the decimation process, DDC (in USRP) will low-pass your signal to
prevent aliasing. So, if you ask for 80MS/s of effective sampling rate (on
the PC side; post-decimation), you will get 80MHz of bandwidth. You can
modify the FPGA image to increase the filter bandwidth beyond the sampling
rate, but that's probably not what you want. (Unless you *want* aliasing).
-RX2 / RX/TX antenna port has nothing to do with the usable bandwidth. UBX
daughterboards internally switch their RF frontend circuits at 500MHz and
1.5GHz. It seems like UBX160 has lower RX bandwidth when you are between
10-500MHz. This should be true for both RX2 and RX/TX antenna port.
Regards,
Kyeong Su Shin
On Mon, Mar 6, 2017 at 5:01 AM, do ber via USRP-users <
[email protected]> wrote:
> Hi to all,
>
> When I buy UBX-160, I thought that I can receive signals with 160MHz
> bandwidth. I am using GNURadio and USRP X310. And the data is coming over
> PCIe connection. When I used the RX port of the daughterboard, I couldn't
> correctly receive signals wider than 80MHz. Then I saw on the page:
>
> The UBX 160 transmitter path has 160 MHz of bandwidth throughout the full
> frequency range of the device; the receiver path has 84 MHz of bandwidth
> for center frequencies from 10 MHz to 500 MHz.
>
> I have questions related to this statement:
>
> * If I use te TX/RX for the receiving, can I use 160 MHz bandwidth?
>
> * For the receiver path other than 10 MHz to 500 MHz what is the max.
> receiver bandwidth? My signal's center freq. is ~1.5GHz.
>
> In short, can I take samples from a signal with 160MHz bandwidth by using
> UBX-160 and X310? What about WBX120? Can I use this daughterboard with
> signals having 120MHz bandwidth?
>
> Best regards,
> Ali
>
>
>
> _______________________________________________
> 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/20170306/bb185b0e/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 6 Mar 2017 08:29:21 -0800
From: Kyeong Su Shin <[email protected]>
To: Ettus mail list <[email protected]>
Subject: Re: [USRP-users] UBX-160: Receiver with 160MHz bandwidth
Message-ID:
<CAGL0V3ktizuo+iVFSPrGfZyU4SCUu0kFSSTqMnkioqpg=y0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To Whom it may concern:
OOps, one mistake:
-You probably cannot use 160MS/s because it is not an integer fraction of
the master clock. Maybe you have a better luck with 200MS/s.
Regards,
Kyeong Su Shin
On Mon, Mar 6, 2017 at 8:18 AM, Kyeong Su Shin <[email protected]> wrote:
> To Whom it may concern:
>
> I never used X3x0s (only uses N2x0 and B2x0), so I am probably not the
> best person to answer this, but this is how I understand:
>
> -That 160MHz is for the low pass filter bandwidth (3dB point) of the
> daughterboard. Has nothing to do with the effective sampling rate of the
> system.
> -X3x0s can theoretically do 200MS/s with the PCI-e bus. I am not sure how
> realistic that is, but in theory, you can do 160MS/s alright (if the
> program is well-optimized and your computer can take it).
> -During the decimation process, DDC (in USRP) will low-pass your signal to
> prevent aliasing. So, if you ask for 80MS/s of effective sampling rate (on
> the PC side; post-decimation), you will get 80MHz of bandwidth. You can
> modify the FPGA image to increase the filter bandwidth beyond the sampling
> rate, but that's probably not what you want. (Unless you *want* aliasing).
> -RX2 / RX/TX antenna port has nothing to do with the usable bandwidth. UBX
> daughterboards internally switch their RF frontend circuits at 500MHz and
> 1.5GHz. It seems like UBX160 has lower RX bandwidth when you are between
> 10-500MHz. This should be true for both RX2 and RX/TX antenna port.
>
> Regards,
> Kyeong Su Shin
>
> On Mon, Mar 6, 2017 at 5:01 AM, do ber via USRP-users <
> [email protected]> wrote:
>
>> Hi to all,
>>
>> When I buy UBX-160, I thought that I can receive signals with 160MHz
>> bandwidth. I am using GNURadio and USRP X310. And the data is coming over
>> PCIe connection. When I used the RX port of the daughterboard, I couldn't
>> correctly receive signals wider than 80MHz. Then I saw on the page:
>>
>> The UBX 160 transmitter path has 160 MHz of bandwidth throughout the full
>> frequency range of the device; the receiver path has 84 MHz of bandwidth
>> for center frequencies from 10 MHz to 500 MHz.
>>
>> I have questions related to this statement:
>>
>> * If I use te TX/RX for the receiving, can I use 160 MHz bandwidth?
>>
>> * For the receiver path other than 10 MHz to 500 MHz what is the max.
>> receiver bandwidth? My signal's center freq. is ~1.5GHz.
>>
>> In short, can I take samples from a signal with 160MHz bandwidth by using
>> UBX-160 and X310? What about WBX120? Can I use this daughterboard with
>> signals having 120MHz bandwidth?
>>
>> Best regards,
>> Ali
>>
>>
>>
>> _______________________________________________
>> 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/20170306/b03de9b1/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 06 Mar 2017 11:46:22 -0500
From: [email protected]
To: Kyeong Su Shin <[email protected]>
Cc: Ettus mail list <[email protected]>
Subject: Re: [USRP-users] UBX-160: Receiver with 160MHz bandwidth
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'll point out that at 200Msps, you need a *VERY* capable computer to
"keep up" with the sample stream.
On 2017-03-06 11:29, Kyeong Su Shin via USRP-users wrote:
> To Whom it may concern:
>
> OOps, one mistake:
>
> -You probably cannot use 160MS/s because it is not an integer fraction of the
> master clock. Maybe you have a better luck with 200MS/s.
>
> Regards,
> Kyeong Su Shin
>
> On Mon, Mar 6, 2017 at 8:18 AM, Kyeong Su Shin <[email protected]> wrote:
>
> To Whom it may concern:
>
> I never used X3x0s (only uses N2x0 and B2x0), so I am probably not the best
> person to answer this, but this is how I understand:
>
> -That 160MHz is for the low pass filter bandwidth (3dB point) of the
> daughterboard. Has nothing to do with the effective sampling rate of the
> system.
> -X3x0s can theoretically do 200MS/s with the PCI-e bus. I am not sure how
> realistic that is, but in theory, you can do 160MS/s alright (if the program
> is well-optimized and your computer can take it).
> -During the decimation process, DDC (in USRP) will low-pass your signal to
> prevent aliasing. So, if you ask for 80MS/s of effective sampling rate (on
> the PC side; post-decimation), you will get 80MHz of bandwidth. You can
> modify the FPGA image to increase the filter bandwidth beyond the sampling
> rate, but that's probably not what you want. (Unless you want aliasing).
> -RX2 / RX/TX antenna port has nothing to do with the usable bandwidth. UBX
> daughterboards internally switch their RF frontend circuits at 500MHz and
> 1.5GHz. It seems like UBX160 has lower RX bandwidth when you are between
> 10-500MHz. This should be true for both RX2 and RX/TX antenna port.
>
> Regards,
> Kyeong Su Shin
>
> On Mon, Mar 6, 2017 at 5:01 AM, do ber via USRP-users
> <[email protected]> wrote:
>
> Hi to all,
>
> When I buy UBX-160, I thought that I can receive signals with 160MHz
> bandwidth. I am using GNURadio and USRP X310. And the data is coming over
> PCIe connection. When I used the RX port of the daughterboard, I couldn't
> correctly receive signals wider than 80MHz. Then I saw on the page:
>
> The UBX 160 transmitter path has 160 MHz of bandwidth throughout the full
> frequency range of the device; the receiver path has 84 MHz of bandwidth for
> center frequencies from 10 MHz to 500 MHz.
>
> I have questions related to this statement:
>
> * If I use te TX/RX for the receiving, can I use 160 MHz bandwidth?
>
> * For the receiver path other than 10 MHz to 500 MHz what is the max.
> receiver bandwidth? My signal's center freq. is ~1.5GHz.
>
> In short, can I take samples from a signal with 160MHz bandwidth by using
> UBX-160 and X310? What about WBX120? Can I use this daughterboard with
> signals having 120MHz bandwidth?
>
> Best regards,
> Ali
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1] 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/20170306/0ac8b7d1/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 6 Mar 2017 19:53:53 +0300
From: Paul Elijah <[email protected]>
To: [email protected]
Subject: [USRP-users] Probably bug in USRP stream commands
Message-ID:
<CAJ8gL+H8=afx3lyuwrpoooavn-mresvvfmzs8gdrkaoiu21...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello
For my project I am using:
HW: two USRP B210 with last available FPGA images
SW: GNU Radio 3.9.10 with UHD 3.9.4
One device peridiocally transmit bursts/pulses while another receives them.
Both USRP are connected to a common PPS source for time synchronization.
I am using stream commands for receiving pulses (issue_stream_cmd).
Receiving of pulse begins after some time offset (half of pulse duration)
relative to the pulse's transmission start.
Before starting pulse exchange my application issues "zero" stream command
in order to exclude a problem with a big enough time delay (at least for my
project) for the first stream command (this problem has already been
described here http://lists.ettus.com/pipermail/usrp-users_lists.
ettus.com/2015-October/016134.html). So application firstly receives some
noise data as "zero" burst.
Problem:
In the head of next burst USRP also puts some noise data (~20 samples for
sample rate 195312Hz; probably from first burst) shifting tail of the
received pulse's samples to the second burst. And remaining samples from
second burst are shifted to the third and so on. You can an exmaple of this
situation in the attached image. What's wrong with it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/7b45981d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shifted_bursts.png
Type: image/png
Size: 122475 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/7b45981d/attachment-0001.png>
------------------------------
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 79, Issue 6
*****************************************
