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. Re: [RFNOC][UHD] Error in uhd_usrp_probe (Jonathon Pendlum)
2. Re: Probably bug in USRP stream commands (Paul Elijah)
3. Re: X310/UBX Retuning Performance (Dave NotTelling)
4. Re: UBX-160: Receiver with 160MHz bandwidth (Rob Kossler)
5. FW: Connecting two X310 by cable (Tiexing Wang)
6. Re: FW: Connecting two X310 by cable (Marcus D. Leech)
7. Re: FW: Connecting two X310 by cable (Tiexing Wang)
8. [RFNOC][GNURADIO] Blocks errors (Rub?n Vogel)
9. Re: [RFNOC][GNURADIO] Blocks errors (Jonathon Pendlum)
10. Setting up N210 on virtual machine (Jithesh Joshy)
11. Re: Setting up N210 on virtual machine (Fernando)
12. How to make sure 10 MHz ref port works or not (David Yu ( III ))
13. Can gr-doa be used with B210 ? (Patrick Sathyanathan)
14. Re: Can gr-doa be used with B210 ? (Nicolas Cuervo)
15. Re: Setting up N210 on virtual machine (Marcus D. Leech)
16. Re: How to make sure 10 MHz ref port works or not
(Marcus D. Leech)
17. Re: Can gr-doa be used with B210 ? (Patrick Sathyanathan)
18. Device Synchronization in USRP (Nikita Airee)
19. Re: Device Synchronization in USRP (Marcus D. Leech)
20. GNURadio (Ettus build) doesnt load osmosdr and rtlsdr
(Jithesh Joshy)
21. Re: Device Synchronization in USRP (Nikita Airee)
22. Re: GNURadio (Ettus build) doesnt load osmosdr and rtlsdr
(Marcus D. Leech)
23. Re: Device Synchronization in USRP (Marcus D. Leech)
24. N210's networked through Ethernet switch ([email protected])
25. Re: N210's networked through Ethernet switch (Dan CaJacob)
26. Re: N210's networked through Ethernet switch (Nate Temple)
27. Re: N210's networked through Ethernet switch
([email protected])
28. Re: N210's networked through Ethernet switch
([email protected])
29. RF component behaviour during tx/rx in Ettus B210 (Rini John)
30. "Sample Rate" is the Nyquist frequency or the transmission
rate of the data stream? (Bob)
31. Re: "Sample Rate" is the Nyquist frequency or the
transmission rate of the data stream? (Julian Arnold)
32. Re: Probably bug in USRP stream commands (Paul Elijah)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Mar 2017 10:59:04 -0600
From: Jonathon Pendlum <[email protected]>
To: Rub?n Vogel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNOC][UHD] Error in uhd_usrp_probe
Message-ID:
<cagdo0urcxa-ast63q239a61d-nkj_ejgs1mquq0vvnpbmzh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have made an issue in our bug tracker for that. While it is an error, it
actually doesn't appear to prevent you from running any UHD apps or GNU
Radio RFNoC flowgraphs.
Jonathon
On Mon, Mar 6, 2017 at 9:55 AM, Rub?n Vogel via USRP-users <
[email protected]> wrote:
> 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.
>
> _______________________________________________
> 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/40da324c/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 6 Mar 2017 20:11:30 +0300
From: Paul Elijah <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Probably bug in USRP stream commands
Message-ID:
<CAJ8gL+Hz7xR5kLy5j_=7op9oi483qxghy-bngkgb_sfa6at...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Here example without using "zero" stream command. Yes, with another
duration of receiving but bursts are also shifted.
2017-03-06 19:53 GMT+03:00 Paul Elijah <[email protected]>:
> 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/piperma
> il/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/9804ac5c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shifted_bursts2.png
Type: image/png
Size: 97317 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/9804ac5c/attachment-0001.png>
------------------------------
Message: 3
Date: Mon, 6 Mar 2017 12:37:43 -0500
From: Dave NotTelling <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX Retuning Performance
Message-ID:
<CAK6GVuMVcEO+R1Tx8ZyeGNrp0FFr3cKHuWjx+VAPGa6=woa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*bump*
On Fri, Mar 3, 2017 at 10:27 AM, Dave NotTelling <[email protected]>
wrote:
> Can performance mode help with the > 100ms tuning time between the two
> bands? I seem to recall the performance mode setting relating to when the
> unused PA is powered off. Also, is the long tuning time something that the
> UHD code causes or is that just a number that the developer should keep in
> mind when switching bands?
>
> Thanks!
>
> On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling <[email protected]>
> wrote:
>
>> Thanks!
>>
>> On Fri, Feb 24, 2017 at 3:32 PM, Marcus M?ller via USRP-users <
>> [email protected]> wrote:
>>
>>> Largely: Yes; the UBX160 and UBX40 only differ in their baseband
>>> filters' passive component values (see the schematics).
>>>
>>> There's a bit of a difference on how you can clock the UBX on N210, but
>>> that won't change behaviour all that much. Also, due to the 100 MHz instead
>>> of X3xx's 200 MHz master clock rate, your timing granularity is twice as
>>> bad :)
>>>
>>> Best regards,
>>>
>>> Marcus
>>> On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
>>>
>>> Do these tuning/settling times also hold true for the UBX-40 in an N210?
>>>
>>> On Fri, Feb 24, 2017 at 2:47 PM, Derek Kozel via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> If you use the set_command_time function to cause the tune to occur at
>>>> a specific time then you can use the in-band timestamps from the recv call
>>>> to identify the sample when the tune action started. The 500us of samples
>>>> following that timestamp are the ones you would want to discard.
>>>>
>>>> An example of setting the execution time for a command:
>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>> es/test_timed_commands.cpp#L96
>>>>
>>>> An example of starting streaming at a set time:
>>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>>> es/test_timed_commands.cpp#L129
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>>
>>>> On Fri, Feb 24, 2017 at 11:27 AM, Jason Roehm via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> On 02/24/2017 01:24 PM, Michael West via USRP-users wrote:
>>>>>
>>>>>> Hi Devin,
>>>>>>
>>>>>> I have measured the UBX tune time. The SPI writes to tune the LO
>>>>>> take ~30-60us and the LO lock time is 400us. I recommend discarding at
>>>>>> least 500us of samples after the LO tune. I also recommend continuous
>>>>>> streaming of samples so the frontend components are not switched on and
>>>>>> off, which can cause long transients. For the UBX-160, set the
>>>>>> dboard_clock_rate to 20e6 and tune the LO in steps of 160 MHz. If using
>>>>>> a
>>>>>> sample rate <200 Msps, use DSP tuning (which takes < 1us) for the
>>>>>> frequencies between the 160MHz steps. With that, you should be able to
>>>>>> tune across the full 6GHz in ~18ms in theory. There is one caveat. There
>>>>>> are 2 LNAs on the UBX, one for <1.5 GHz and one for above. Only one can
>>>>>> be
>>>>>> powered on at a time and the warm up time is significant (in the 100s of
>>>>>> milliseconds for the low band LNA and 10s of milliseconds for the high
>>>>>> band
>>>>>> LNA),, so you would be best suited using one daughterboard for the low
>>>>>> band
>>>>>> and one for the high band for the fastest sweep time.
>>>>>>
>>>>>> Unfortunately, I do not have the same experience with the TwinRX, so
>>>>>> i cannot advise on it.
>>>>>>
>>>>>
>>>>> Not to hijack this thread, but do you have any recommendations on the
>>>>> most effective way to properly time the "discard 500us of samples after
>>>>> the
>>>>> LO tune?" One of the drawbacks of using the USRP family for applications
>>>>> that require fast retuning is that there isn't (from what I can tell) any
>>>>> in-band indication of what center frequency the radio is tuned to. The
>>>>> control interface (e.g. through multi_usrp::set_rx_center_freq()) is
>>>>> completely separate from the data streaming interface, so if I call
>>>>> set_rx_center_freq() at time T, I have no way of accurately estimating
>>>>> when
>>>>> the tune will actually be complete in the data stream.
>>>>>
>>>>> This seems to be a disadvantage of the CHDR protocol that contemporary
>>>>> USRPs use; they seem to carry data samples and timetags, but nothing else.
>>>>> VITA 49 is nice in that it can provide full context in timetagged packets,
>>>>> so you can get updates as to the radio state (e.g. frequency, gain) that
>>>>> are aligned as closely as possible with the associated samples from the
>>>>> SDR.
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [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
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170306/1f677fad/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 6 Mar 2017 12:50:02 -0500
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Kyeong Su Shin <[email protected]>, Ettus mail list
<[email protected]>
Subject: Re: [USRP-users] UBX-160: Receiver with 160MHz bandwidth
Message-ID:
<CAB__hTRdtpzU7p752s0XO=hknfmcm4d1zqcvkmvhq1xagaf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ali,
For Receive bandwidth, I don't think it matters whether you use the Tx/Rx
path or the Rx2 path. You should get the same bandwidth in each case. For
center frequencies below 500 MHz, you already noted the Rx bandwidth
limitation. For frequencies above 500 MHz, You should be able to get the
full 160 MHz bandwidth. Note that this limitation for center frequencies
under 500 MHz is specific to UBX160 daughterboards. For the SBX120,
CBX120, and WBX120 daughterboards, there is no such limitation on on
bandwidth related to center frequencies such that you should be able to
receive 120 MHz bandwidth over the full frequency range of the respective
daughterboard.
You mentioned that you are using the PCIe interface. This Gen 1 x4
interface can only support one stream at 200 MS/s so if you have 2 UBX160
daughterboards in your X310, you will not be able to receive two streams at
200 MS/s over this interface. However, you could receive two streams at 200
MS/s if you use the dual 10Gbe interfaces instead.
Rob
On Mon, Mar 6, 2017 at 11:46 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> 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
>>>
>>>
> _______________________________________________
> USRP-users mailing list
> [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/20170306/6c1a4956/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 6 Mar 2017 20:09:39 +0000
From: Tiexing Wang <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FW: Connecting two X310 by cable
Message-ID:
<by1pr0101mb103093246790425a64fd0cb7b5...@by1pr0101mb1030.prod.exchangelabs.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We are now trying to design transmitter and receiver on two X310. Since
transmitting and receiving signals by antennas brings many unpredictable issues
in indoor environment, we plan to connect the two X310 directly by cable. As
the output power of X310 could be higher than the input power limit, is there
any additional equipment that is needed besides the cable?
Looking forward to your response and many thanks in advance.
Tiexing Wang
Department Electrical Engineering
and Computer Science
Syracuse University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/f4bffce8/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 06 Mar 2017 15:14:32 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FW: Connecting two X310 by cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 03/06/2017 03:09 PM, Tiexing Wang via USRP-users wrote:
>
> Hi all,
>
> We are now trying to design transmitter and receiver on two X310.
> Since transmitting and receiving signals by antennas brings many
> unpredictable issues in indoor environment, we plan to connect the two
> X310 directly by cable. As the output power of X310 could be higher
> than the input power limit, is there any additional equipment that is
> needed besides the cable?
>
> Looking forward to your response and many thanks in advance.
>
> Tiexing Wang
>
> Department Electrical Engineering
>
> and Computer Science
>
> Syracuse University
>
>
Insert at least 40dB of attenuation in your cables. The maximum
recommended input power on Ettus receiver cards is about -15dBm.
Exceeding those levels can damage the sensitive low-noise amplifiers
in the front-end.
The maximum power output of most cards is in the +10 to +20dBm range.
So you need to attenuate any signals into the range that is
more "natural" for a receiver that is intended to be connected to an
antenna, rather than directly to a transmitter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/011061e3/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 6 Mar 2017 20:20:41 +0000
From: Tiexing Wang <[email protected]>
To: "Marcus D. Leech via USRP-users" <[email protected]>
Subject: Re: [USRP-users] FW: Connecting two X310 by cable
Message-ID:
<by1pr0101mb10307eee3847db41fd7bd35cb5...@by1pr0101mb1030.prod.exchangelabs.com>
Content-Type: text/plain; charset="big5"
Thanks for your quick response. That helps a lot.
Tiexing Wang
From: Marcus D. Leech via USRP-users<mailto:[email protected]>
Sent: Monday, March 6, 2017 3:15 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] FW: Connecting two X310 by cable
On 03/06/2017 03:09 PM, Tiexing Wang via USRP-users wrote:
Hi all,
We are now trying to design transmitter and receiver on two X310. Since
transmitting and receiving signals by antennas brings many unpredictable issues
in indoor environment, we plan to connect the two X310 directly by cable. As
the output power of X310 could be higher than the input power limit, is there
any additional equipment that is needed besides the cable?
Looking forward to your response and many thanks in advance.
Tiexing Wang
Department Electrical Engineering
and Computer Science
Syracuse University
Insert at least 40dB of attenuation in your cables. The maximum recommended
input power on Ettus receiver cards is about -15dBm.
Exceeding those levels can damage the sensitive low-noise amplifiers in the
front-end.
The maximum power output of most cards is in the +10 to +20dBm range. So you
need to attenuate any signals into the range that is
more "natural" for a receiver that is intended to be connected to an antenna,
rather than directly to a transmitter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/019132e4/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 6 Mar 2017 18:21:16 -0300
From: Rub?n Vogel <[email protected]>
To: [email protected]
Subject: [USRP-users] [RFNOC][GNURADIO] Blocks errors
Message-ID:
<cam7gm7a5u4fhw6jz9geudk5+fpqjc2ywaolbsugfmvackjg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi again,
This is my Ettus system:
root@ettus-e3xx-sg1:~# *gnuradio-config-info -v *
3.7.9.3
root@ettus-e3xx-sg1:~# *uhd_usrp_probe *
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Radio_0
| | | * FIFO_0
| | | * Window_0
| | | * FFT_0
| | | * fosphor_0
| | | * FIFO_1
| | | * FIR_0
- When I run the gr-ettus example "rfnoc_fosphor.grc", in
gnuradio-companion, I get the following error:
Traceback (most recent call last):
File "/home/root/examples/rfnoc/rfnoc_fosphor.py", line 364, in <module>
main()
File "/home/root/examples/rfnoc/rfnoc_fosphor.py", line 352, in main
tb = top_block_cls()
File "/home/root/examples/rfnoc/rfnoc_fosphor.py", line 190, in __init__
"DmaFIFO", -1, -1,
File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 2445, in
make
return _ettus_swig.rfnoc_generic_make(*args, **kwargs)
*RuntimeError: Cannot find a block for ID: DmaFIFO*
1) This error is because DmaFIFO isn't a RfnoC block on this device?. If
this is true, how could I install all the rfnoc blocks in the Ettus?. Is
there any manual method, or do I have to generate a new image for fpga?
2) Another question, when running gnuradio-companion, fails to load the
module "canberra-gtk-module", why this?
*root@ettus-e3xx-sg1:~# gnuradio-companion *
** (process:996): WARNING **: Trying to register gtype 'GMountMountFlags'
as enum when in fact it is of type 'GFlags'
** (process:996): WARNING **: Trying to register gtype 'GDriveStartFlags'
as enum when in fact it is of type 'GFlags'
** (process:996): WARNING **: Trying to register gtype 'GSocketMsgFlags' as
enum when in fact it is of type 'GFlags'
*Gtk-Message: Failed to load module "canberra-gtk-module"*
*Warning: XML parsing failed:*
* Key "in_type" already exists in params*
* Ignoring: /usr/share/gnuradio/grc/blocks/uhd_rfnoc_streamer.xml*
*Warning: Block key "uhd_rfnoc_streamer" not found when loading category
tree.*
*Warning: Block key "uhd_rfnoc_siggen" not found when loading category
tree.*
*Warning: Block key "uhd_rfnoc_dma_fifo" not found when loading category
tree.*
<<< Welcome to GNU Radio Companion 3.7.9.3 >>>
Preferences file: /home/root/.gnuradio/grc.conf
Block paths:
/usr/local/share/gnuradio/grc/blocks
/home/root/.grc_gnuradio
/usr/share/gnuradio/grc/blocks
Showing: ""
3) When gnuradio-companion is open it shows the following branches, where
some rfnoc blocks are outside the UHD branch, is it correct?
*| > UHD*
*| | > RFNOC*
| | | > RFNoC: Adder / Subtractor
| | | > RFNoC: DDC
| | | > RFNoC: Digital Gain
| | | > RFNoC: DUC
| | | > RFNoC: FFT
| | | > RFNoC: FIFO
| | | > RFNoC: FIR
| | | > RFNoC: fosphor
| | | > RFNoC: QT fosphor display
| | | > RFNoC: Keep 1 in N
| | | > RFNoC: Log Power
| | | > RFNoC: Moving Average
| | | > RFNoC: OFDM Constellation Demap
| | | > RFNoC: OFDM Equalizer
| | | > RFNoC: Radio
| | | > RFNoC: OFDM Sync
| | | > RFNoC: Split Stream
| | | > RFNoC: Vector IIR
| | | > RFNoC: Windows
*| > [NONE]*
*| | > RFNoC: DmaFIFO*
*| | > RFNoC: Packet Resizer*
*| | > RFNoC: SigGen*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/429c84e7/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 6 Mar 2017 16:08:16 -0600
From: Jonathon Pendlum <[email protected]>
To: Rub?n Vogel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNOC][GNURADIO] Blocks errors
Message-ID:
<CAGdo0uSdSMUBbmhn-BK0d6m28VW=bsbr94fmm9ir5fa_n_q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
> 1) This error is because DmaFIFO isn't a RfnoC block on this device?. If
> this is true, how could I install all the rfnoc blocks in the Ettus?. Is
> there any manual method, or do I have to generate a new image for fpga?
>
Adding the DmaFIFO RFNoC to the E310 is not as trivial as it is for other
RFNoC blocks. Besides the normal connections to the crossbar, it also has
an AXI4 bus you need to hook up. If you look at the implementation on the
X310, you can see it uses Xilinx's MIG tool to generate a DRAM controller
that has a AXI4 interface. You would have to follow the same path on the
E310. Luckily, there is a DRAM controller that already exists, it just
hasn't been wired up to a DmaFIFO block.
> 2) Another question, when running gnuradio-companion, fails to load the
> module "canberra-gtk-module", why this?
>
Are you running GRC locally on the E310 with X forwarding?
> 3) When gnuradio-companion is open it shows the following branches, where
> some rfnoc blocks are outside the UHD branch, is it correct?
>
Minor issue with how blocks are getting categorized by GRC. That is an
easy fix.
Jonathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/8b775cdb/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 6 Mar 2017 23:12:34 +0000
From: Jithesh Joshy <[email protected]>
To: [email protected]
Subject: [USRP-users] Setting up N210 on virtual machine
Message-ID:
<CAO41PoJL5kU7TsY8HP0qqzsdc5g4E=WN=EL2-=nhz2_adrr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am stuck with getting the N210 to work on GNU radio
I searched for this issue on the forum and couldn't find an answer and
hence requesting your support so that I can get it started
My set up is as described below:
GNU radio 3.7.1.0 on Ubuntu 16.04 Desktop running on Parallels virtual
machine on a Mac Pro (15 inch , 2016)
1. I am able to ping the N210 over 192.168.10.2 and the packets are
received back from the N210.
2. But other commands such as 'uhd_usrp_probe' and 'uhd_find_devices'
return negative responses
I am using Wifi for internet on the MAC (and VMs) and a dedicated USB C to
Ethernet adaptor from Belkin solely for the Comms with N210
I have added more details below that would help you help me ! and I would
really appreciate your help in this regard to get me started with the two
N210s I have got.
Many thanks in advance
======================
parallels@ubuntu:~$ ifconfig
enp0s5 Link encap:Ethernet HWaddr 00:1c:42:d9:d2:0d
inet addr:10.211.55.3 Bcast:10.211.55.255 Mask:255.255.255.0
inet6 addr: fe80::4c8b:dcaf:8b50:e8c7/64 Scope:Link
inet6 addr: fdb2:2c26:f4e4:0:d86f:c205:7dcc:8eb/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:95 errors:0 dropped:0 overruns:0 frame:0
TX packets:144 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14520 (14.5 KB) TX bytes:17031 (17.0 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:339 errors:0 dropped:0 overruns:0 frame:0
TX packets:339 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:25475 (25.4 KB) TX bytes:25475 (25.4 KB)
parallels@ubuntu:~$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=128 time=1.91 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=128 time=1.72 ms
64 bytes from 192.168.10.2: icmp_seq=3 ttl=128 time=1.73 ms
64 bytes from 192.168.10.2: icmp_seq=4 ttl=128 time=1.74 ms
^C
--- 192.168.10.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3008ms
rtt min/avg/max/mdev = 1.722/1.779/1.917/0.085 ms
parallels@ubuntu:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
0.0.0.0 10.211.55.1 0.0.0.0 UG 0 0 0
enp0s5
10.211.55.0 0.0.0.0 255.255.255.0 U 0 0 0
enp0s5
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
enp0s5
parallels@ubuntu:~$ uhd_find_devices
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-release
No UHD Devices Found
parallels@ubuntu:~$ uhd_usrp_probe --args="addr=192.168.10.2"
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-release
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
_____________________________________________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: 00:80:2f:27:41:03
| | ip-addr: 192.168.10.2
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: 30F7028
| | FW Version: 12.4
| | FPGA Version: 11.1
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: mimo_locked, ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | |
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | |
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: LF RX (0x000f)
| | | Serial: 30DDEFC
| | | _____________________________________________________
| | | /
| | | | RX Frontend: AB
| | | | Name: LFRX (AB)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: BA
| | | | Name: LFRX (BA)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: A
| | | | Name: LFRX (A)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
| | | | Connection Type: I
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: B
| | | | Name: LFRX (B)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
| | | | Connection Type: Q
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p44
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | |
| | | Freq range: -50.000 to 50.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: LF TX (0x000e)
| | | Serial: 30F5BAD
| | | _____________________________________________________
| | | /
| | | | TX Frontend: AB
| | | | Name: LFTX (AB)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: BA
| | | | Name: LFTX (BA)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: A
| | | | Name: LFTX (A)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
| | | | Connection Type: I
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: B
| | | | Name: LFTX (B)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: -32.000 to 32.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
| | | | Connection Type: Q
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9777
| | | | Gain Elements: None
parallels@ubuntu:~$ uhd_usrp_probe
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-release
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
parallels@ubuntu:~$
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/d5fc89b6/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 7 Mar 2017 00:42:22 +0100
From: Fernando <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Setting up N210 on virtual machine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
El 07/03/17 a las 00:12, Jithesh Joshy via USRP-users escribi?:
> Hi,
> I am stuck with getting the N210 to work on GNU radio
>
> I searched for this issue on the forum and couldn't find an answer and
> hence requesting your support so that I can get it started
>
> My set up is as described below:
> GNU radio 3.7.1.0 on Ubuntu 16.04 Desktop running on Parallels virtual
> machine on a Mac Pro (15 inch , 2016)
>
> 1. I am able to ping the N210 over 192.168.10.2 and the packets are
> received back from the N210.
>
> 2. But other commands such as 'uhd_usrp_probe' and 'uhd_find_devices'
> return negative responses
>
> I am using Wifi for internet on the MAC (and VMs) and a dedicated USB
> C to Ethernet adaptor from Belkin solely for the Comms with N210
>
> I have added more details below that would help you help me ! and I
> would really appreciate your help in this regard to get me started
> with the two N210s I have got.
>
> Many thanks in advance
>
> ======================
>
> parallels@ubuntu:~$ ifconfig
> enp0s5 Link encap:Ethernet HWaddr 00:1c:42:d9:d2:0d
> inet addr:10.211.55.3 Bcast:10.211.55.255 Mask:255.255.255.0
>
>
> parallels@ubuntu:~$ netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window
> irtt Iface
> 0.0.0.0 10.211.55.1 0.0.0.0 UG 0 0
> 0 enp0s5
> 10.211.55.0 0.0.0.0 255.255.255.0 U 0 0
> 0 enp0s5
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0
> 0 enp0s5
>
> | | ip-addr: 192.168.10.2
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | |
I think the USRP network is bad configured
192.168.10.2 is a class C network with mask 255.255.255.0 and you
should configure a gateway
Maybe you should use othenr network configuration in your vm different
to NAT, if possible (it is possible with vmware) you can set the vm not
to use nat and instead use a ip in the same network as the host computer
and the USRP.
regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/63a097b5/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 7 Mar 2017 08:09:55 +0800
From: "David Yu \( III \)" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] How to make sure 10 MHz ref port works or not
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Ettus Team:
We used 10 MHz ref on USRP B200 mini.
Spectrum analyzer can make sure input 10 MHz is correct.
But how to make sure if 10 MHz ref port works normally on b200 mini ? Does any
tool can test it?
David
------------------------------
Message: 13
Date: Tue, 7 Mar 2017 00:21:42 +0000
From: Patrick Sathyanathan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Can gr-doa be used with B210 ?
Message-ID:
<bn3pr1001mb105978b6a18c6c8451052726ae...@bn3pr1001mb1059.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Hi,
I just found the below about direction finding using GNUradio. Can the package
be modified to work with the B210 using the two RX channels ?
Also any other GNUradio modules with similar functionality ?
https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
Direction Finding with the USRP? X-Series and TwinRX
...<https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2>
kb.ettus.com
Abstract. This application note covers using the USRP? TwinRX? daughterboard in
a direction find application using the MUSIC algorithm. Introduction
Thanks for any info,
--Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/b4b0659e/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 7 Mar 2017 02:00:42 +0100
From: Nicolas Cuervo <[email protected]>
To: Patrick Sathyanathan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Can gr-doa be used with B210 ?
Message-ID:
<CAOuPCvji2v9NixFmDa-Wu0eG=8lul7_hdrgr6729n6n1yjt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Patrick,
This specific example requires four phase-coherent channels and the way it
was written is device specific, being the X300/X310 with two TwinRX
daughterboards required. It might be modified to make use of different
daughterboards that are compatible with the X3X0 devices. However, the b210
lacks of the capability of providing the four phase coherent channels
required to have a successful measure in this case.
Regards,
-Nicolas
On Tue, Mar 7, 2017 at 1:21 AM, Patrick Sathyanathan via USRP-users <
[email protected]> wrote:
>
> Hi,
>
>
> I just found the below about direction finding using GNUradio. Can the
> package be modified to work with the B210 using the two RX channels ?
>
>
> Also any other GNUradio modules with similar functionality ?
>
>
>
> https://kb.ettus.com/Direction_Finding_with_the_
> USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
>
> Direction Finding with the USRP? X-Series and TwinRX ...
> <https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2>
> kb.ettus.com
> Abstract. This application note covers using the USRP? TwinRX?
> daughterboard in a direction find application using the MUSIC algorithm.
> Introduction
>
> Thanks for any info,
>
>
> --Patrick
>
>
> _______________________________________________
> 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/20170307/b004e3e8/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 06 Mar 2017 20:35:58 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Setting up N210 on virtual machine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 03/06/2017 06:12 PM, Jithesh Joshy via USRP-users wrote:
> Hi,
> I am stuck with getting the N210 to work on GNU radio
>
> I searched for this issue on the forum and couldn't find an answer and
> hence requesting your support so that I can get it started
>
> My set up is as described below:
> GNU radio 3.7.1.0 on Ubuntu 16.04 Desktop running on Parallels virtual
> machine on a Mac Pro (15 inch , 2016)
>
> 1. I am able to ping the N210 over 192.168.10.2 and the packets are
> received back from the N210.
>
> 2. But other commands such as 'uhd_usrp_probe' and 'uhd_find_devices'
> return negative responses
>
> I am using Wifi for internet on the MAC (and VMs) and a dedicated USB
> C to Ethernet adaptor from Belkin solely for the Comms with N210
>
> I have added more details below that would help you help me ! and I
> would really appreciate your help in this regard to get me started
> with the two N210s I have got.
>
> Many thanks in advance
>
> ======================
> parallels@ubuntu:~$ ifconfig
> enp0s5 Link encap:Ethernet HWaddr 00:1c:42:d9:d2:0d
> inet addr:10.211.55.3 Bcast:10.211.55.255 Mask:255.255.255.0
> inet6 addr: fe80::4c8b:dcaf:8b50:e8c7/64 Scope:Link
> inet6 addr: fdb2:2c26:f4e4:0:d86f:c205:7dcc:8eb/64 Scope:Global
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:95 errors:0 dropped:0 overruns:0 frame:0
> TX packets:144 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:14520 (14.5 KB) TX bytes:17031 (17.0 KB)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:65536 Metric:1
> RX packets:339 errors:0 dropped:0 overruns:0 frame:0
> TX packets:339 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1
> RX bytes:25475 (25.4 KB) TX bytes:25475 (25.4 KB)
>
> parallels@ubuntu:~$ ping 192.168.10.2
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=1 ttl=128
> time=1.91 ms
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=2 ttl=128
> time=1.72 ms
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=3 ttl=128
> time=1.73 ms
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=4 ttl=128
> time=1.74 ms
> ^C
> --- 192.168.10.2 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3008ms
> rtt min/avg/max/mdev = 1.722/1.779/1.917/0.085 ms
>
> parallels@ubuntu:~$ netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 0.0.0.0 10.211.55.1 0.0.0.0 UG 0 0 0 enp0s5
> 10.211.55.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s5
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 enp0s5
>
> parallels@ubuntu:~$ uhd_find_devices
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.001-release
>
> No UHD Devices Found
> parallels@ubuntu:~$ uhd_usrp_probe --args="addr=192.168.10.2"
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.001-release
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> _____________________________________________________
> /
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: 00:80:2f:27:41:03
> | | ip-addr: 192.168.10.2
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: 30F7028
> | | FW Version: 12.4
> | | FPGA Version: 11.1
> | |
> | | Time sources: none, external, _external_, mimo
> | | Clock sources: internal, external, mimo
> | | Sensors: mimo_locked, ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | |
> | | | Freq range: -50.000 to 50.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX DSP: 1
> | | |
> | | | Freq range: -50.000 to 50.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | ID: LF RX (0x000f)
> | | | Serial: 30DDEFC
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: AB
> | | | | Name: LFRX (AB)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: BA
> | | | | Name: LFRX (BA)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
> | | | | Connection Type: QI
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: A
> | | | | Name: LFRX (A)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
> | | | | Connection Type: I
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: B
> | | | | Name: LFRX (B)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
> | | | | Connection Type: Q
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: ads62p44
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | |
> | | | Freq range: -50.000 to 50.000 MHz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | ID: LF TX (0x000e)
> | | | Serial: 30F5BAD
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: AB
> | | | | Name: LFTX (AB)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: BA
> | | | | Name: LFTX (BA)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
> | | | | Connection Type: QI
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: A
> | | | | Name: LFTX (A)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
> | | | | Connection Type: I
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: B
> | | | | Name: LFTX (B)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: -32.000 to 32.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
> | | | | Connection Type: Q
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9777
> | | | | Gain Elements: None
>
> parallels@ubuntu:~$ uhd_usrp_probe
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.001-release
>
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
> parallels@ubuntu:~$
>
It looks to me like when you specify an explicit device address, you can
"see" your device--this isn't unexpected. Many systems firewall
modules block the broadcast traffic that is required for UHD to
automatically "find" a USRP device. But if you specify the device
address (as you did above) explicitly, it doesn't go through that code.
Just use the device address. Once you have more than one device on a
system, you'll have to anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/a69e535b/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 06 Mar 2017 20:42:25 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to make sure 10 MHz ref port works or
not
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/06/2017 07:09 PM, David Yu ( III ) via USRP-users wrote:
> Hi Ettus Team:
> We used 10 MHz ref on USRP B200 mini.
> Spectrum analyzer can make sure input 10 MHz is correct.
> But how to make sure if 10 MHz ref port works normally on b200 mini ? Does
> any tool can test it?
>
> David
>
>
You can query the "ref_locked" motherboard sensor.
------------------------------
Message: 17
Date: Tue, 7 Mar 2017 02:00:58 +0000
From: Patrick Sathyanathan <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Can gr-doa be used with B210 ?
Message-ID:
<bn3pr1001mb1059b2b2ab84be8d8b74c714ae...@bn3pr1001mb1059.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Thanks for the info, Nicholas. The page says the requirements for MUSIC are:
the number of plane-wave signals, D is known,
* the number of antenna elements, N is at least equal to D+1 and
* the inputs received across the antenna array for the purpose of DoA
estimation are phase-synchronous.
If D = 1 then it should be possible to use the B210, correct ? Can I modify the
code for this case ?
Thanks,
--Patrick
________________________________
From: Nicolas Cuervo <[email protected]>
Sent: Monday, March 6, 2017 5:00 PM
To: Patrick Sathyanathan
Cc: [email protected]
Subject: Re: [USRP-users] Can gr-doa be used with B210 ?
Hello Patrick,
This specific example requires four phase-coherent channels and the way it was
written is device specific, being the X300/X310 with two TwinRX daughterboards
required. It might be modified to make use of different daughterboards that are
compatible with the X3X0 devices. However, the b210 lacks of the capability of
providing the four phase coherent channels required to have a successful
measure in this case.
Regards,
-Nicolas
On Tue, Mar 7, 2017 at 1:21 AM, Patrick Sathyanathan via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I just found the below about direction finding using GNUradio. Can the package
be modified to work with the B210 using the two RX channels ?
Also any other GNUradio modules with similar functionality ?
https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2
Direction Finding with the USRP? X-Series and TwinRX
...<https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2>
kb.ettus.com<http://kb.ettus.com>
Abstract. This application note covers using the USRP? TwinRX? daughterboard in
a direction find application using the MUSIC algorithm. Introduction
Thanks for any info,
--Patrick
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170307/0644a7ea/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 7 Mar 2017 07:56:57 +0530
From: Nikita Airee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Device Synchronization in USRP
Message-ID:
<CAOT=ST=RRqY6qNKUU6eej9chh=rck4_or0znhq8khz573m9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I would like to time synchronize two x310s with CBX40MHz.
Going through the UHD manual(https://files.ettus.com/manual/page_sync.html)
and the Application Notes
(https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf)
I understand that:
1) Both USRPs should have a common REF clock
2) Both should have a common PPS
My questions are:
1) Do the USRPs necessarily have to be connected to the same host? What if
I wanted to daisy chain them?
2) If I understand correctly, phase alignment is not a necessity for time
synchronization?
3) For USRP Sink, what should I select as the Sync option if besides time
synchronization, I'm also using time tags (tx_time) and why?
I'm somewhat confused here and would really appreciate any help.
Bests,
Nikita Airee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/f1c417b4/attachment-0001.html>
------------------------------
Message: 19
Date: Mon, 06 Mar 2017 22:13:10 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Device Synchronization in USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/06/2017 09:26 PM, Nikita Airee via USRP-users wrote:
> Hello everyone,
>
> I would like to time synchronize two x310s with CBX40MHz.
>
> Going through the UHD
> manual(https://files.ettus.com/manual/page_sync.html) and the
> Application Notes
> (https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
> <%28https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf>)
>
> I understand that:
>
> 1) Both USRPs should have a common REF clock
> 2) Both should have a common PPS
>
> My questions are:
> 1) Do the USRPs necessarily have to be connected to the same host?
> What if I wanted to daisy chain them?
> 2) If I understand correctly, phase alignment is not a necessity for
> time synchronization?
> 3) For USRP Sink, what should I select as the Sync option if besides
> time synchronization, I'm also using time tags (tx_time) and why?
>
> I'm somewhat confused here and would really appreciate any help.
>
> Bests,
> Nikita Airee
>
If you don't care about phase coherence, this is doable. You'll have to
make sure that you have some way for your two programs to
agree on what time they're going to set in the two X310s at the next
PPS pulse.
Normally, when UHD has a number of USRPs in a "coherence
collection/group", it will make sure that each "member" of the group will
agree on the current time of day at the next 1PPS, and with a common
10MHz reference, they will all "tick" together after that point.
But UHD has *no* concept of doing this across hosts, and it will be up
to you to use set_time_next_pps() calls appropriately in a way that
your two separate program instances agree on what time they will set,
and when. This can be somewhat tricky.
------------------------------
Message: 20
Date: Tue, 7 Mar 2017 03:36:22 +0000
From: Jithesh Joshy <[email protected]>
To: [email protected]
Subject: [USRP-users] GNURadio (Ettus build) doesnt load osmosdr and
rtlsdr
Message-ID:
<cao41polrzah09pw2oqny+xgxyfutz4odxmmnv_9txr_28dy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
The GNU radio build used is from the link below on Ubuntu 16.04
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
UHD works fien but cant get the rtl sdr and osmocom sdr to work.
1. They are listed under (no module specified) category in the block list
in gnu radio
2. Shows errors (*terminate called after throwing an instance of
'std::invalid_argument'*
* what(): port number 0 exceeds max of (none)*)which I cant understand
when using the osmocom source and time/frequency sink jsut to test !
3. I tried making and installing rtl sdr and osmocom sdr separately. but no
luck
Please help , logs below
========
<<< Welcome to GNU Radio Companion 3.7.10.1 >>>
Block paths:
/home/jj/.grc_gnuradio
/usr/local/share/gnuradio/grc/blocks
Loading: "/home/jj/Test_1.grc"
>>> Done
Loading: "/home/jj/untitled.grc"
>>> Done
Generating: '/home/jj/top_block.py'
Executing: /usr/bin/python2 -u /home/jj/top_block.py
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.009.000-0-gcd88f80f
gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.10.1
built-in source types: file fcd rtl rtl_tcp uhd rfspace redpitaya
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
terminate called after throwing an instance of 'std::invalid_argument'
what(): port number 0 exceeds max of (none)
>>> Done (return code -6)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/0abd9b9b/attachment-0001.html>
------------------------------
Message: 21
Date: Tue, 7 Mar 2017 09:14:25 +0530
From: Nikita Airee <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Device Synchronization in USRP
Message-ID:
<CAOT=STk=W-SHoxBUsOChDHWnN6P7=9+ph3m9w92wycnhdhd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for this information Marcus.
What if the two hosts were locked to gps independently and agreed on a time
somewhere in the future?
Also, I understand the significance of Time and Clock Source in Uhd Sink,
but what does Sync actually do?
Bests,
Nikita
On Tue, Mar 7, 2017 at 8:43 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 03/06/2017 09:26 PM, Nikita Airee via USRP-users wrote:
>
>> Hello everyone,
>>
>> I would like to time synchronize two x310s with CBX40MHz.
>>
>> Going through the UHD manual(https://files.ettus.com
>> /manual/page_sync.html) and the Application Notes (
>> https://www.ettus.com/content/files/kb/mimo_and_sync_with_
>> usrp_updated.pdf <%28https://www.ettus.com/cont
>> ent/files/kb/mimo_and_sync_with_usrp_updated.pdf>) I understand that:
>>
>> 1) Both USRPs should have a common REF clock
>> 2) Both should have a common PPS
>>
>> My questions are:
>> 1) Do the USRPs necessarily have to be connected to the same host? What
>> if I wanted to daisy chain them?
>> 2) If I understand correctly, phase alignment is not a necessity for time
>> synchronization?
>> 3) For USRP Sink, what should I select as the Sync option if besides time
>> synchronization, I'm also using time tags (tx_time) and why?
>>
>> I'm somewhat confused here and would really appreciate any help.
>>
>> Bests,
>> Nikita Airee
>>
>> If you don't care about phase coherence, this is doable. You'll have to
> make sure that you have some way for your two programs to
> agree on what time they're going to set in the two X310s at the next PPS
> pulse.
>
> Normally, when UHD has a number of USRPs in a "coherence
> collection/group", it will make sure that each "member" of the group will
> agree on the current time of day at the next 1PPS, and with a common
> 10MHz reference, they will all "tick" together after that point.
>
> But UHD has *no* concept of doing this across hosts, and it will be up to
> you to use set_time_next_pps() calls appropriately in a way that
> your two separate program instances agree on what time they will set,
> and when. This can be somewhat tricky.
>
>
>
>
>
> _______________________________________________
> 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/20170307/f3e8193b/attachment-0001.html>
------------------------------
Message: 22
Date: Mon, 06 Mar 2017 22:45:18 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GNURadio (Ettus build) doesnt load osmosdr
and rtlsdr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 03/06/2017 10:36 PM, Jithesh Joshy via USRP-users wrote:
> Hello,
>
> The GNU radio build used is from the link below on Ubuntu 16.04
>
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>
> UHD works fien but cant get the rtl sdr and osmocom sdr to work.
>
> 1. They are listed under (no module specified) category in the block
> list in gnu radio
> 2. Shows errors (*terminate called after throwing an instance of
> 'std::invalid_argument'*
> * what(): port number 0 exceeds max of (none)*)which I cant
> understand when using the osmocom source and time/frequency sink jsut
> to test !
>
> 3. I tried making and installing rtl sdr and osmocom sdr separately.
> but no luck
>
> Please help , logs below
>
> ========
>
> <<< Welcome to GNU Radio Companion 3.7.10.1 >>>
>
> Block paths:
> /home/jj/.grc_gnuradio
> /usr/local/share/gnuradio/grc/blocks
>
> Loading: "/home/jj/Test_1.grc"
> >>> Done
>
> Loading: "/home/jj/untitled.grc"
> >>> Done
>
> Generating: '/home/jj/top_block.py'
>
> Executing: /usr/bin/python2 -u /home/jj/top_block.py
>
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.009.000-0-gcd88f80f
>
> gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.10.1
> built-in source types: file fcd rtl rtl_tcp uhd rfspace redpitaya
> Using device #0 Realtek RTL2838UHIDIR SN: 00000001
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> Exact sample rate is: 1000000.026491 Hz
> [R82XX] PLL not locked!
> terminate called after throwing an instance of 'std::invalid_argument'
> what(): port number 0 exceeds max of (none)
>
> >>> Done (return code -6)
>
Since your question has nothing to do with USRP hardware and UHD driver
software, a better venue would be the discuss-gnuradio
mailing list. gr-osmosdr is NOT a produce of Ettus Research, but an
OOT module developed by the Gnu Radio community.
Granted, you got the "how to build this Gnu Radio + Friends" information
from an Ettus knowledge-base article, but the underlying issue
has nothing to do with Ettus drivers and/or hardware.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170306/5129f473/attachment-0001.html>
------------------------------
Message: 23
Date: Mon, 06 Mar 2017 22:55:41 -0500
From: "Marcus D. Leech" <[email protected]>
To: Nikita Airee <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Device Synchronization in USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 03/06/2017 10:44 PM, Nikita Airee wrote:
> Thanks for this information Marcus.
>
> What if the two hosts were locked to gps independently and agreed on a
> time somewhere in the future?
That could work, as long as the time they agree on is the same, and it's
far enough in the future that slight differences in local system
time (sub-millisecond scale) won't make a difference.
>
> Also, I understand the significance of Time and Clock Source in Uhd
> Sink, but what does Sync actually do?
It controls the mechanism for time-setting on the hardware.
"Dont Sync" -- exactly what it says. Make no attempt to
set the time-of-day clock on the hardware
"PC Clock" -- set the time on the hardware to be the same
as the PC clock, but without using a PPS trigger signal.
For multi-USRP UHD sources, this
will end up with the USRP hardware only "very loosely" synchronized.
The uncertainty will be proportional
to round-trip command times across the inteface, and OS scheduling
latency. This can *sometimes* (but
not often, TBH) be "good enough".
"Unknown PPS" -- set the time on the hardware to be the same as
the PC clock, but using the external PPS trigger.
In this case, it waits for a 1PPS
trigger before sending the trigger time to all the devices in the "group".
>
> Bests,
> Nikita
>
> On Tue, Mar 7, 2017 at 8:43 AM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 03/06/2017 09:26 PM, Nikita Airee via USRP-users wrote:
>
> Hello everyone,
>
> I would like to time synchronize two x310s with CBX40MHz.
>
> Going through the UHD
> manual(https://files.ettus.com/manual/page_sync.html
> <https://files.ettus.com/manual/page_sync.html>) and the
> Application Notes
>
> (https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>
> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf>
>
> <%28https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>
> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf>>)
> I understand that:
>
> 1) Both USRPs should have a common REF clock
> 2) Both should have a common PPS
>
> My questions are:
> 1) Do the USRPs necessarily have to be connected to the same
> host? What if I wanted to daisy chain them?
> 2) If I understand correctly, phase alignment is not a
> necessity for time synchronization?
> 3) For USRP Sink, what should I select as the Sync option if
> besides time synchronization, I'm also using time tags
> (tx_time) and why?
>
> I'm somewhat confused here and would really appreciate any help.
>
> Bests,
> Nikita Airee
>
> If you don't care about phase coherence, this is doable. You'll
> have to make sure that you have some way for your two programs to
> agree on what time they're going to set in the two X310s at the
> next PPS pulse.
>
> Normally, when UHD has a number of USRPs in a "coherence
> collection/group", it will make sure that each "member" of the
> group will
> agree on the current time of day at the next 1PPS, and with a
> common 10MHz reference, they will all "tick" together after that
> point.
>
> But UHD has *no* concept of doing this across hosts, and it will
> be up to you to use set_time_next_pps() calls appropriately in a
> way that
> your two separate program instances agree on what time they will
> set, and when. This can be somewhat tricky.
>
>
>
>
>
> _______________________________________________
> 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/20170306/73b57c8c/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 7 Mar 2017 01:56:33 -0500
From: <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] N210's networked through Ethernet switch
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi. We bought 40 N210?s assuming they could be network together via a
dedicated Ethernet Switch. We plan to buy even more if they can be networked.
I tried changing ip's, subnets on the N210 accordingly and while each N210
works fine with a direct Ethernet connection from a PC to an N210, the N210 has
a dead connection (no lights) when connected to an Ethernet Switch. From what
I?m reading, the N210 prefers a direct PC connection and no one can get them to
connect through an Ethernet Switch to a PC. Is it possible and how? For now
I?m not concerned about performance but just getting them connected through a
switch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/e4f4c4f3/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 07 Mar 2017 07:02:28 +0000
From: Dan CaJacob <[email protected]>
To: [email protected], "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] N210's networked through Ethernet switch
Message-ID:
<camomjobcekjlbkuzrj-9pcuxfnvgxd7gy8srhjx3upoh4aj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have done it before. I believe you need to set their IPs statically.
However, it is unlikely that you have a network switch that can support the
traffic from 40 N210s at any meaningful data rate.
On Tue, Mar 7, 2017 at 1:57 AM engineer1357 via USRP-users <
[email protected]> wrote:
> Hi. We bought 40 N210?s assuming they could be network together via a
> dedicated Ethernet Switch. We plan to buy even more if they can be
> networked. I tried changing ip's, subnets on the N210 accordingly and
> while each N210 works fine with a direct Ethernet connection from a PC to
> an N210, the N210 has a dead connection (no lights) when connected to an
> Ethernet Switch. From what I?m reading, the N210 prefers a direct PC
> connection and no one can get them to connect through an Ethernet Switch to
> a PC. Is it possible and how? For now I?m not concerned about performance
> but just getting them connected through a switch.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/ee0d3ef3/attachment-0001.html>
------------------------------
Message: 26
Date: Mon, 6 Mar 2017 23:11:22 -0800
From: Nate Temple <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210's networked through Ethernet switch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Engineer1357,
Is the switch a 100mbit switch? The N210 must be connected via 1Gb, it does not
support 100mbit speeds.
Regards,
Nate Temple
> On Mar 6, 2017, at 10:56 PM, engineer1357 via USRP-users
> <[email protected]> wrote:
>
> Hi. We bought 40 N210?s assuming they could be network together via a
> dedicated Ethernet Switch. We plan to buy even more if they can be
> networked. I tried changing ip's, subnets on the N210 accordingly and while
> each N210 works fine with a direct Ethernet connection from a PC to an N210,
> the N210 has a dead connection (no lights) when connected to an Ethernet
> Switch. From what I?m reading, the N210 prefers a direct PC connection and
> no one can get them to connect through an Ethernet Switch to a PC. Is it
> possible and how? For now I?m not concerned about performance but just
> getting them connected through a switch.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 27
Date: Tue, 7 Mar 2017 02:22:27 -0500
From: <[email protected]>
To: Dan CaJacob <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] N210's networked through Ethernet switch
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi. I already have static ip?s. Oops, I think I found the problem. The
switch I?m using is a very common Netgear FS108 switch for starters, but it's
only spec?d for 100Mbps while I?ve read a 1Gbps connection is required. I?ll
try it on a 1Gbps switch. Thanks for getting me thinking knowing you got it
working.
From: Dan CaJacob
Sent: Tuesday, March 7, 2017 2:02 AM
To: [email protected]; [email protected]
Subject: Re: [USRP-users] N210's networked through Ethernet switch
I have done it before.? I believe you need to set their IPs statically.?
However, it is unlikely that you have a network switch that can support the
traffic from 40 N210s at any meaningful data rate.
On Tue, Mar 7, 2017 at 1:57 AM engineer1357 via USRP-users
<[email protected]> wrote:
Hi.? We bought 40 N210?s assuming they could be network together via a
dedicated Ethernet Switch.? We plan to buy even more if they can be networked.?
I tried changing ip's, subnets on the N210 accordingly and while each N210
works fine with a direct Ethernet connection from a PC to an N210, the N210 has
a dead connection (no lights) when connected to an Ethernet Switch.? From what
I?m reading, the N210 prefers a direct PC connection and no one can get them to
connect through an Ethernet Switch to a PC.? Is it possible and how?? For now
I?m not concerned about performance but just getting them connected through a
switch.
?
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/a61c38e4/attachment-0001.html>
------------------------------
Message: 28
Date: Tue, 7 Mar 2017 02:23:37 -0500
From: <[email protected]>
To: Nate Temple <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210's networked through Ethernet switch
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Right, I just read the spec on the switch, I think that?s the problem. Thanks.
From: Nate Temple
Sent: Tuesday, March 7, 2017 2:11 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] N210's networked through Ethernet switch
Hi Engineer1357,
Is the switch a 100mbit switch? The N210 must be connected via 1Gb, it does not
support 100mbit speeds.
Regards,
Nate Temple
> On Mar 6, 2017, at 10:56 PM, engineer1357 via USRP-users
> <[email protected]> wrote:
>
> Hi. We bought 40 N210?s assuming they could be network together via a
> dedicated Ethernet Switch. We plan to buy even more if they can be
> networked. I tried changing ip's, subnets on the N210 accordingly and while
> each N210 works fine with a direct Ethernet connection from a PC to an N210,
> the N210 has a dead connection (no lights) when connected to an Ethernet
> Switch. From what I?m reading, the N210 prefers a direct PC connection and
> no one can get them to connect through an Ethernet Switch to a PC. Is it
> possible and how? For now I?m not concerned about performance but just
> getting them connected through a switch.
>
> _______________________________________________
> 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/20170307/647926f3/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 07 Mar 2017 12:22:13 +0200
From: "Rini John" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] RF component behaviour during tx/rx in Ettus
B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Good day
We are currently using an Ettus B210 to transmit in bursts and receive
continuously. During Tx, we noticed that there is a "glitch" at the beginning
of each Tx burst similar to what is described in this post,
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-January/012270.html
We tried the 2 solutions mentioned in the post. Padding with zeros did not
help, but changing the b200_impl.cpp file and recompiling the uhd library did.
The unwanted spike at the beginning of each burst did disappear.
However, the effect of this is that the LO clock now does not switch off in
idle state(between tx bursts) , which saturates the receive side.
Is there a way to get rid of the effect of components switching on and off for
transmission without also affecting the LO?
We can use an RF switch to get rid of the unwanted spike but wanted to know if
there is another approach?
Kind Regards
Rini John
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/66b7ad7b/attachment-0001.html>
------------------------------
Message: 30
Date: Tue, 7 Mar 2017 21:35:12 +0800 (GMT+08:00)
From: Bob <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] "Sample Rate" is the Nyquist frequency or the
transmission rate of the data stream?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
Hi,
We use the USRP B210 to receive RF signals, such as 162 MHz, and send it to the
PC by USB. In finally, the frequency of the signal is 20 kHz, and then use GNU
Radio to process it (20 kHz low IF signal), we need to set the parameters of
the block, such as we need to set " Sample Rate " in the "WX GUI Scope Sink ",
"Sample Rate" refers to the Nyquist frequency(for example 40 kHz, the sampling
rate must be twice the highest frequency)? Or we can set 32 kHz or 20 kHz?
In a word, how can we set the "Sample Rate" in the block? It needs to meet any
criteria?
Thank you very much for your answers. I am looking forward to your reply as
soon as possible and as detailed as possible.
Thanks!
Regards,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170307/bf11884a/attachment-0001.html>
------------------------------
Message: 31
Date: Tue, 7 Mar 2017 15:44:18 +0100
From: Julian Arnold <[email protected]>
To: Bob <[email protected]>, usrp-users <[email protected]>
Subject: Re: [USRP-users] "Sample Rate" is the Nyquist frequency or
the transmission rate of the data stream?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Bob,
the "Sample Rate" parameter in the "Scope Sink" is only used to scale
the frequency axis of the plot.
You would normally set this to the sample rate of the input data stream.
That is, the sample rate you set in the UHD source block if
you do not have any rate changing blocks in between.
As we are dealing with complex samples, in theory, you only need a
sample rate of 20 kHz to sample your 20kHz wide RF signal properly.
However, the USRP must support this rate. So you would pick something
equal to or above 20kHz that is supported by the USRP as your sample rate.
Cheers,
On 03/07/2017 02:35 PM, Bob via USRP-users wrote:
> Hi,
>
> We use the USRP B210 to receive RF signals, such as 162 MHz, and send
> it to the PC by USB. In finally, the frequency of the signal is 20
> kHz, and then use GNU Radio to process it (20 kHz low IF signal), we
> need to set the parameters of the block, such as we need to set "
> Sample Rate " in the "WX GUI Scope Sink ", "Sample Rate" refers to the
> Nyquist frequency(for example 40 kHz, the sampling rate must be twice
> the highest frequency)? Or we can set 32 kHz or 20 kHz?
> In a word, how can we set the "Sample Rate" in the block? It needs to
> meet any criteria?
>
> Thank you very much for your answers. I am looking forward to your reply as
> soon as possible and as detailed as possible.
> Thanks!
>
> Regards,
> Bob
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 32
Date: Tue, 7 Mar 2017 19:31:42 +0300
From: Paul Elijah <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Probably bug in USRP stream commands
Message-ID:
<caj8gl+f8zja94h90xokyxkwoh3wt0mrr8mchzf+ys9fcicb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Oh, I am sorry. Version of GNU Radio is 3.7.10.
2017-03-06 20:11 GMT+03:00 Paul Elijah <[email protected]>:
> Here example without using "zero" stream command. Yes, with another
> duration of receiving but bursts are also shifted.
>
> 2017-03-06 19:53 GMT+03:00 Paul Elijah <[email protected]>:
>
>> 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/piperma
>> il/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/20170307/943d6c84/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 79, Issue 7
*****************************************
