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. PA with the B200 mini (Jason Matusiak)
2. Re: PPS get_time_last_pps() (Dave NotTelling)
3. Re: PPS get_time_last_pps() (Dave NotTelling)
4. Using a multi_usrp device over multiple functions? (Jacob Knoles)
5. Understanding tx_burst.cpp (Sumit Kumar)
6. Re: PPS get_time_last_pps() (Dave NotTelling)
7. Re: Using a multi_usrp device over multiple functions?
(Dave NotTelling)
8. Re: Using a multi_usrp device over multiple functions?
(Jacob Knoles)
9. Re: How to connect E312 to internet? (Philip Balister)
10. Re: Using a multi_usrp device over multiple functions?
(Dave NotTelling)
11. Re: Using a multi_usrp device over multiple functions?
(Jacob Knoles)
12. Re: Using a multi_usrp device over multiple functions?
(Dave NotTelling)
13. Re: Using a multi_usrp device over multiple functions?
(Jacob Knoles)
14. [UHD] Introducing the Python API (Martin Braun)
15. set command time blocking?? (Jacob Knoles)
16. rfnoc-ofdm (Walter Maguire)
17. Re: PA with the B200 mini (Ian Buckley)
18. Re: Understanding tx_burst.cpp (Sumit Kumar)
19. By-Pass DDC Chain in B210 for Reading Raw Data (altu? kaya)
20. Re: By-Pass DDC Chain in B210 for Reading Raw Data (Marcus M?ller)
21. Re: set command time blocking?? (Francisco Paisana)
22. Re: By-Pass DDC Chain in B210 for Reading Raw Data (altu? kaya)
23. problems about using rfnoc on e310 (Hu Chaoran)
24. X310, 2 Basic RX and quad DDC (gwenhael.goavec)
25. Adding 10 MHz permanently to B210? (Ralph A. Schmid, dk5ras)
26. Re: set command time blocking?? (Jacob Knoles)
27. Re: Adding 10 MHz permanently to B210? ([email protected])
28. Re: Adding 10 MHz permanently to B210? (Derek Kozel)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Jun 2017 12:52:56 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] PA with the B200 mini
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Is there a way to control a PA from the B200 mini? I am looking to turn
the PA on/off depending on whether we were transmitting or not.
From this Ettus app note
(https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf):
*Transceiver Antenna Selection ? Half-Duplex vs. Full Duplex*
If the application requires the USRP device to operate in half-duplex
mode with a single antenna (per USRP), the TX/RX connector can be used
for transmission and reception. In this mode, automatic transmit-receive
(ATR) logic switches the TX/RX port to the transmit path when the host
is streaming samples. When transmit streaming stops, a state-machine in
the FPGA will automatically switch the TX/RX port to the receive path.
This functionality can be overridden with UHD API calls to control the
transmit/receive switches through GPIO.
So is there any reason not to attempt to route the ATR to the GPIO
connector J5? Is there an easier way of doing this besides mucking with
Ettus' FPGA code that I missed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/fcbae3b9/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 28 Jun 2017 12:57:57 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PPS get_time_last_pps()
Message-ID:
<CAK6GVuPfBcWywsrFJ9A4A8khjKoaR4Q2xEcx=detvxvjfnb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Also, I updated to UHD_003.010.001.HEAD-0-gc705922a and got the same issue
of the time being off by ~ 14 us every second.
On Wed, Jun 28, 2017 at 9:04 AM, Dave NotTelling <[email protected]>
wrote:
> I just recently hooked my N210 up to a 1 PPS source and was expecting that
> calls to radio->get_time_last_pps() would return a number really close to 1
> second from the previous call. Instead I get the following:
>
> [output]
>
> $ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
>
> -- 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
> 0.000012
> 0.000024
> 0.000035
> 0.000047
> 0.000059
> 0.000071
> 0.000083
> 0.000094
> 0.000106
> 0.000118
> 0.000130
> 0.000142
> 0.000153
> 0.000165
> 0.000177
> 0.000189
>
> [/output]
>
> The drift is fairly constant at ~ 11-12 us per second. It should be noted
> that I am not using a 10 MHz reference. Just the 1 PPS.
>
> Here is the code I'm using:
>
> [code]
>
> #include <boost/thread.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
>
> int main(){
> uhd::usrp::multi_usrp::sptr radio = uhd::usrp::multi_usrp::make(
> std::string("addr=192.168.12.2"));
> radio->set_time_source("external");
> radio->set_time_next_pps(uhd::time_spec_t(0, 0));
> boost::this_thread::sleep_for(boost::chrono::seconds(2));
>
> while(1){
> uhd::time_spec_t t = radio->get_time_last_pps();
> fprintf(stderr, "%0.6f\n", t.get_frac_secs());
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
> }
> }
>
> [/code]
>
> And here is the output of the test_pps_input command:
>
> [output]
>
> $ /tmp/test_pps_input --args addr=192.168.12.2
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
>
>
> 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
>
> Creating the usrp device with: addr=192.168.12.2...
> -- 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
> Using Device: Single USRP:
> Device: USRP2 / N-Series Device
> Mboard 0: N210r4
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>
>
> Attempt to detect the PPS and set the time...
>
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
>
> Success!
>
> [/output]
>
> Am I doing something wrong?
>
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/fa373238/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 28 Jun 2017 13:16:19 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PPS get_time_last_pps()
Message-ID:
<CAK6GVuMRqCyF+Lo_8KhvPA5Kj_Hn=_1o169p4N=vy4eqkvu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Just ran across an old version of this same question I asked a while back
(sorry for the dupe)
[post]
To add to the comments, the USRP clock is virtually guaranteed to drift
away from the host system time if the time is set once and the clocks on
the host and USRP are left to run on their own oscillators with no PLL
between them. To keep a USRP synchronized in time takes a 10 MHz reference
to which the USRP can use to lock the PLL and a PPS to make sure the time
on the USRP is set at a precise moment. Some USRPs (B2xxmini and E3xx) can
lock the PLL to the PPS, so the 10 MHz is not necessary, but they are far
less accurate. Unless your host system can put out a 10 MHz and PPS, the
times will be off. This is why a GPSDO is commonly used to synchronize
devices that are not close to each other and a common 10 MHz and PPS (i.e.
distributed by an Octoclock) is used to synchronize devices that are close
to each other.
Also, the calls to getTime() and usrp->get_time_now() are not synchronous
or atomic and will have varying amounts of latency between the return
values so the accuracy of the measurement is probably not very good at
trying to measure something less than a few milliseconds.
[/post]
Seems that I completely goofed and I need *both* 10 MHz and 1 PPS :(
On Wed, Jun 28, 2017 at 12:57 PM, Dave NotTelling <[email protected]>
wrote:
> Also, I updated to UHD_003.010.001.HEAD-0-gc705922a and got the same
> issue of the time being off by ~ 14 us every second.
>
> On Wed, Jun 28, 2017 at 9:04 AM, Dave NotTelling <[email protected]>
> wrote:
>
>> I just recently hooked my N210 up to a 1 PPS source and was expecting
>> that calls to radio->get_time_last_pps() would return a number really close
>> to 1 second from the previous call. Instead I get the following:
>>
>> [output]
>>
>> $ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
>>
>> -- 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
>> 0.000012
>> 0.000024
>> 0.000035
>> 0.000047
>> 0.000059
>> 0.000071
>> 0.000083
>> 0.000094
>> 0.000106
>> 0.000118
>> 0.000130
>> 0.000142
>> 0.000153
>> 0.000165
>> 0.000177
>> 0.000189
>>
>> [/output]
>>
>> The drift is fairly constant at ~ 11-12 us per second. It should be
>> noted that I am not using a 10 MHz reference. Just the 1 PPS.
>>
>> Here is the code I'm using:
>>
>> [code]
>>
>> #include <boost/thread.hpp>
>> #include <uhd/usrp/multi_usrp.hpp>
>>
>> int main(){
>> uhd::usrp::multi_usrp::sptr radio = uhd::usrp::multi_usrp::make(st
>> d::string("addr=192.168.12.2"));
>> radio->set_time_source("external");
>> radio->set_time_next_pps(uhd::time_spec_t(0, 0));
>> boost::this_thread::sleep_for(boost::chrono::seconds(2));
>>
>> while(1){
>> uhd::time_spec_t t = radio->get_time_last_pps();
>> fprintf(stderr, "%0.6f\n", t.get_frac_secs());
>> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>> }
>> }
>>
>> [/code]
>>
>> And here is the output of the test_pps_input command:
>>
>> [output]
>>
>> $ /tmp/test_pps_input --args addr=192.168.12.2
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
>>
>>
>> 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
>>
>> Creating the usrp device with: addr=192.168.12.2...
>> -- 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
>> Using Device: Single USRP:
>> Device: USRP2 / N-Series Device
>> Mboard 0: N210r4
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: UBX RX
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: UBX TX
>>
>>
>> Attempt to detect the PPS and set the time...
>>
>> -- 1) catch time transition at pps edge
>> -- 2) set times next pps (synchronously)
>>
>> Success!
>>
>> [/output]
>>
>> Am I doing something wrong?
>>
>>
>> Thanks!
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/01ac2c20/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 28 Jun 2017 10:53:17 -0700
From: Jacob Knoles <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<ca+z4yfhpdgmh2k9pr6aqyllmj4yfbpvgqfbsjb6sb-p_+ra...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have several functions that play different signals using the usrp, right
now I create a usrp device (using multi_usrp::make() ) in each function
every time a function is run.
My application requires that each of these functions will be run many times
in succession, therefore I would like to create a single usrp device, which
will be held by the class object and which can be referenced by the
different functions.
This seems like it shouldn't be an issue but I am noticing this pattern:
On the first function call everything works perfectly, but on all
subsequent calls in the same application instance I get a sequence error
from recv_async_msg() and the first chunk of my signal is missing.
This behavior does not happen if I create a new usrp device every time.
What is happening that could cause a packet loss error here?
Is it possible/plausible to utilize a single usrp device in the way I have
described?
Is there some command I need to issue after transmitting to properly clean
up but not destroy the usrp device?
Additionally, is it possible to have multiple usrp sptrs active at one
time? For example a device that only utilizes one daughterboard and a
second that utilizes both daughterboards.
Thank you!
-----------------------------
Jacob Knoles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/528f6ab0/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 28 Jun 2017 19:55:45 +0200
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Understanding tx_burst.cpp
Message-ID:
<caoextcq0iknewvqgzmvlratpgsde39m7rvz8ct+nwt370j4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am trying to understand the timed commands. I ran tx_burst in the uhd
examples with --repeat option and observed the same on a signal
analyzer(SA).
In the beginning, I see a spike but after that I don't see any activity on
the SA. However in the terminal I see that messages are getting printed
about successful bursts. Even the transmit LED keep glowing RED (B210).
Am I missing something obvious.
Regards
Sumit
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/bdc22a41/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 28 Jun 2017 14:03:11 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PPS get_time_last_pps()
Message-ID:
<cak6gvunru_zaofsq8qo+8o-5c20kcdurwnmrt8peg01alkv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I still think it's odd that the radio is drifting at 12-14 us per second
when using the PPS to sample the time. Am I incorrect in my assumption
that calls to get_time_last_pps() will work with just the PPS input and no
10 MHz reference? If that does work, and my 1 PPS reference is stable and
accurate, then I would expect to see a very slow drift. In my mind the
clock on the radio should be almost as accurate as my timing reference that
is generating the 1 PPS output. Meaning that calls to get_time_last_pps()
should be almost exactly 1 second apart and should show a time that is
almost 1 second ahead of the last call. Granted, in the long run the time
will be wonky since there is no 10 MHz reference to keep time rolling at an
accurate rate, but in the short term (< 1 minute) I feel like things should
be pretty spot on.
On Wed, Jun 28, 2017 at 1:16 PM, Dave NotTelling <[email protected]>
wrote:
> Just ran across an old version of this same question I asked a while back
> (sorry for the dupe)
>
> [post]
> To add to the comments, the USRP clock is virtually guaranteed to drift
> away from the host system time if the time is set once and the clocks on
> the host and USRP are left to run on their own oscillators with no PLL
> between them. To keep a USRP synchronized in time takes a 10 MHz reference
> to which the USRP can use to lock the PLL and a PPS to make sure the time
> on the USRP is set at a precise moment. Some USRPs (B2xxmini and E3xx) can
> lock the PLL to the PPS, so the 10 MHz is not necessary, but they are far
> less accurate. Unless your host system can put out a 10 MHz and PPS, the
> times will be off. This is why a GPSDO is commonly used to synchronize
> devices that are not close to each other and a common 10 MHz and PPS (i.e.
> distributed by an Octoclock) is used to synchronize devices that are close
> to each other.
>
> Also, the calls to getTime() and usrp->get_time_now() are not synchronous
> or atomic and will have varying amounts of latency between the return
> values so the accuracy of the measurement is probably not very good at
> trying to measure something less than a few milliseconds.
> [/post]
>
> Seems that I completely goofed and I need *both* 10 MHz and 1 PPS :(
>
>
> On Wed, Jun 28, 2017 at 12:57 PM, Dave NotTelling <[email protected]>
> wrote:
>
>> Also, I updated to UHD_003.010.001.HEAD-0-gc705922a and got the same
>> issue of the time being off by ~ 14 us every second.
>>
>> On Wed, Jun 28, 2017 at 9:04 AM, Dave NotTelling <[email protected]>
>> wrote:
>>
>>> I just recently hooked my N210 up to a 1 PPS source and was expecting
>>> that calls to radio->get_time_last_pps() would return a number really close
>>> to 1 second from the previous call. Instead I get the following:
>>>
>>> [output]
>>>
>>> $ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
>>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
>>>
>>> -- 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
>>> 0.000012
>>> 0.000024
>>> 0.000035
>>> 0.000047
>>> 0.000059
>>> 0.000071
>>> 0.000083
>>> 0.000094
>>> 0.000106
>>> 0.000118
>>> 0.000130
>>> 0.000142
>>> 0.000153
>>> 0.000165
>>> 0.000177
>>> 0.000189
>>>
>>> [/output]
>>>
>>> The drift is fairly constant at ~ 11-12 us per second. It should be
>>> noted that I am not using a 10 MHz reference. Just the 1 PPS.
>>>
>>> Here is the code I'm using:
>>>
>>> [code]
>>>
>>> #include <boost/thread.hpp>
>>> #include <uhd/usrp/multi_usrp.hpp>
>>>
>>> int main(){
>>> uhd::usrp::multi_usrp::sptr radio = uhd::usrp::multi_usrp::make(st
>>> d::string("addr=192.168.12.2"));
>>> radio->set_time_source("external");
>>> radio->set_time_next_pps(uhd::time_spec_t(0, 0));
>>> boost::this_thread::sleep_for(boost::chrono::seconds(2));
>>>
>>> while(1){
>>> uhd::time_spec_t t = radio->get_time_last_pps();
>>> fprintf(stderr, "%0.6f\n", t.get_frac_secs());
>>> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>>> }
>>> }
>>>
>>> [/code]
>>>
>>> And here is the output of the test_pps_input command:
>>>
>>> [output]
>>>
>>> $ /tmp/test_pps_input --args addr=192.168.12.2
>>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
>>>
>>>
>>> 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
>>>
>>> Creating the usrp device with: addr=192.168.12.2...
>>> -- 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
>>> Using Device: Single USRP:
>>> Device: USRP2 / N-Series Device
>>> Mboard 0: N210r4
>>> RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: UBX RX
>>> TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: UBX TX
>>>
>>>
>>> Attempt to detect the PPS and set the time...
>>>
>>> -- 1) catch time transition at pps edge
>>> -- 2) set times next pps (synchronously)
>>>
>>> Success!
>>>
>>> [/output]
>>>
>>> Am I doing something wrong?
>>>
>>>
>>> Thanks!
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/eef5348b/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 28 Jun 2017 14:16:39 -0400
From: Dave NotTelling <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<CAK6GVuP87pJPrZpkAqisWGAL9RYnZUahZ7c=orvbpczun3s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Since the uhd::usrp::multi_usrp::sptr is a boost::shared_ptr under the
hood, you can just pass that around to whatever functions need to use it.
This is assuming that you have one main method that creates the handle and
then hands the handle off to other threads/methods. My apologies if I'm
missing something entirely :)
On Wed, Jun 28, 2017 at 1:53 PM, Jacob Knoles via USRP-users <
[email protected]> wrote:
> I have several functions that play different signals using the usrp, right
> now I create a usrp device (using multi_usrp::make() ) in each function
> every time a function is run.
>
> My application requires that each of these functions will be run many
> times in succession, therefore I would like to create a single usrp device,
> which will be held by the class object and which can be referenced by the
> different functions.
>
> This seems like it shouldn't be an issue but I am noticing this pattern:
> On the first function call everything works perfectly, but on all
> subsequent calls in the same application instance I get a sequence error
> from recv_async_msg() and the first chunk of my signal is missing.
>
> This behavior does not happen if I create a new usrp device every time.
>
> What is happening that could cause a packet loss error here?
> Is it possible/plausible to utilize a single usrp device in the way I have
> described?
> Is there some command I need to issue after transmitting to properly clean
> up but not destroy the usrp device?
>
> Additionally, is it possible to have multiple usrp sptrs active at one
> time? For example a device that only utilizes one daughterboard and a
> second that utilizes both daughterboards.
>
> Thank you!
>
> -----------------------------
> Jacob Knoles
>
>
> _______________________________________________
> 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/20170628/4e4f9d12/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 28 Jun 2017 11:21:29 -0700
From: Jacob Knoles <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<CA+z4yFG83PH=Om2PpKrC=jrh+6a5+xdosaygkfoy-8yyclp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dave,
That is exactly what I figured and am trying to do. I have a class which
implements all the functions I need and in that class constructor I make
the sptr, which is stored as a private variable in the class.
What I don't understand is when I use this method I get a sequence error on
any subsequent function call unless I create a whole new sptr? That does
not make any sense to me.
I am wondering if I am missing some close or flush command, I am creating a
new tx_streamer object every function call.
-----------------------------
Jacob Knoles
On Wed, Jun 28, 2017 at 11:16 AM, Dave NotTelling <[email protected]>
wrote:
> Since the uhd::usrp::multi_usrp::sptr is a boost::shared_ptr under the
> hood, you can just pass that around to whatever functions need to use it.
> This is assuming that you have one main method that creates the handle and
> then hands the handle off to other threads/methods. My apologies if I'm
> missing something entirely :)
>
> On Wed, Jun 28, 2017 at 1:53 PM, Jacob Knoles via USRP-users <
> [email protected]> wrote:
>
>> I have several functions that play different signals using the usrp,
>> right now I create a usrp device (using multi_usrp::make() ) in each
>> function every time a function is run.
>>
>> My application requires that each of these functions will be run many
>> times in succession, therefore I would like to create a single usrp device,
>> which will be held by the class object and which can be referenced by the
>> different functions.
>>
>> This seems like it shouldn't be an issue but I am noticing this pattern:
>> On the first function call everything works perfectly, but on all
>> subsequent calls in the same application instance I get a sequence error
>> from recv_async_msg() and the first chunk of my signal is missing.
>>
>> This behavior does not happen if I create a new usrp device every time.
>>
>> What is happening that could cause a packet loss error here?
>> Is it possible/plausible to utilize a single usrp device in the way I
>> have described?
>> Is there some command I need to issue after transmitting to properly
>> clean up but not destroy the usrp device?
>>
>> Additionally, is it possible to have multiple usrp sptrs active at one
>> time? For example a device that only utilizes one daughterboard and a
>> second that utilizes both daughterboards.
>>
>> Thank you!
>>
>> -----------------------------
>> Jacob Knoles
>>
>>
>> _______________________________________________
>> 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/20170628/518be120/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 28 Jun 2017 14:29:07 -0400
From: Philip Balister <[email protected]>
To: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] How to connect E312 to internet?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/28/2017 07:52 AM, Marcus M?ller wrote:
> Hey Phil :)
>
> I'd do that, too! But:
>
> Well, you do have both the build infrastructure ready and experience on
> how to use OE.
>
> But people that never done that first have to go through getting a VM
> with a GCC version that works for this build, then follow the
> instructions on the wiki, do a 2h plain build to see whether it really
> works without modifications, then learn how to integrate a layer into OE
> and in which place, and then do another build, and then integrate
> whatever they've already got on data and configs on the E312 into that
> image.
Even if you are going to cross compile some utility for the E300, read
the recipe to see if their are any quirks.
Philip
>
> I agree, it's the cleaner and easier-to-long-term-maintain solution, but
> meh, economics of effort say: that's why OE folks/you go through the
> effort of getting the SDK as a side product of an OE build, isn't it?
>
> Cheers,
> Marcus
>
>
> On 28.06.2017 13:46, Philip Balister wrote:
>> On 06/28/2017 07:04 AM, Marcus M?ller via USRP-users wrote:
>>> Dear Xingjian,
>>>
>>>
>>> the E312 is an embedded device. While you can just connect it to any
>>> network like you could connect any other Linux computer, it is not meant
>>> to be used in a manner like e.g. a Ubuntu PC.
>>>
>>>
>>> You can save yourself the effort of getting tmux if you're just as
>>> comfortable using "screen" instead, which is a very similar (albeit
>>> somewhat older) piece of software, already included in your SD Card image.
>>>
>>>
>>> You'll need to cross-compile the software you want to use on the E312
>>> and transfer it onto the E312 yourself. There's two approaches here:
>>>
>>>
>>> * use the SDK (recommended): The SDK contains all compilers that were
>>> used to build the SD card image you're using on the E312. That
>>> means: you just get the TMUX source code and build it using the SDK.
>>> If tmux has dependencies that aren't already part of the SD card
>>> image, and hence, the SDK, you'll have to build these dependencies
>>> first, and then build tmux. However, I think tmux only needs
>>> libevent and ncurses, and both should be included already.
>>> * build your own SD Card image (more work, more complications): use
>>> the OpenEmbedded system that we use to build the E312 SD Card
>>> images, but modify it to include a "recipe" (or "layer") for the
>>> software you want (in this case, tmux). If someone from the
>>> OpenEmbedded/Yocto community has already taken the effort to write
>>> such an addition, that modification should be straightforward, and
>>> all you have to do is set up a VM to build in, follow the
>>> instructions, start the bitbake and sit back and relax for >>1h.
>>>
>>> As said, in your use case, I'd recommend taking the SDK route. Both
>>> methods are described in
>> And I'd just build anew image :)
>>
>> Checking the layer index shows that there is a tmux recipe (for the
>> jethro release) in meta-oe, so it should be fairly straightforward to add.
>>
>> http://layers.openembedded.org/layerindex/branch/jethro/recipes/?q=tmux
>>
>> Philip
>>
>>>
>>> https://files.ettus.com/manual/page_usrp_e3x0.html
>>>
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 28.06.2017 11:36, Xingjian Chen via USRP-users wrote:
>>>> Hi,
>>>>
>>>> Does any one know how to make an USRP E312 internet accessible? I
>>>> would like to download and install some package such as tmux in it.
>>>> Thank you.
>>>>
>>>>
>>>> Microwave Remote Sensing Laboratory
>>>>
>>>> Electrical and Computer Engineering
>>>>
>>>> Univeristy of Massachusetts, Amherst
>>>>
>>>> PhD Student
>>>>
>>>> Xingjian Chen
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>
------------------------------
Message: 10
Date: Wed, 28 Jun 2017 14:31:13 -0400
From: Dave NotTelling <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<CAK6GVuNaNe=zgs-dzonfyhf5qfxdckeup7iu8ko1lspv65g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm not sure if you need to create a new streamer each time. The streamers
are also boost::shared_ptr objects, so they should be passable. I have
done things where I have a thread that handles all of the samples and is
separate from the main thread. In that case I just pass the
uhd::rx_streamer::sptr to whatever function needs to receive samples. Not
sure if the class is thread safe, so be careful about that.
On Wed, Jun 28, 2017 at 2:21 PM, Jacob Knoles <[email protected]> wrote:
> Dave,
>
> That is exactly what I figured and am trying to do. I have a class which
> implements all the functions I need and in that class constructor I make
> the sptr, which is stored as a private variable in the class.
>
> What I don't understand is when I use this method I get a sequence error
> on any subsequent function call unless I create a whole new sptr? That does
> not make any sense to me.
>
> I am wondering if I am missing some close or flush command, I am creating
> a new tx_streamer object every function call.
>
> -----------------------------
> Jacob Knoles
>
>
> On Wed, Jun 28, 2017 at 11:16 AM, Dave NotTelling <[email protected]>
> wrote:
>
>> Since the uhd::usrp::multi_usrp::sptr is a boost::shared_ptr under the
>> hood, you can just pass that around to whatever functions need to use it.
>> This is assuming that you have one main method that creates the handle and
>> then hands the handle off to other threads/methods. My apologies if I'm
>> missing something entirely :)
>>
>> On Wed, Jun 28, 2017 at 1:53 PM, Jacob Knoles via USRP-users <
>> [email protected]> wrote:
>>
>>> I have several functions that play different signals using the usrp,
>>> right now I create a usrp device (using multi_usrp::make() ) in each
>>> function every time a function is run.
>>>
>>> My application requires that each of these functions will be run many
>>> times in succession, therefore I would like to create a single usrp device,
>>> which will be held by the class object and which can be referenced by the
>>> different functions.
>>>
>>> This seems like it shouldn't be an issue but I am noticing this pattern:
>>> On the first function call everything works perfectly, but on all
>>> subsequent calls in the same application instance I get a sequence error
>>> from recv_async_msg() and the first chunk of my signal is missing.
>>>
>>> This behavior does not happen if I create a new usrp device every time.
>>>
>>> What is happening that could cause a packet loss error here?
>>> Is it possible/plausible to utilize a single usrp device in the way I
>>> have described?
>>> Is there some command I need to issue after transmitting to properly
>>> clean up but not destroy the usrp device?
>>>
>>> Additionally, is it possible to have multiple usrp sptrs active at one
>>> time? For example a device that only utilizes one daughterboard and a
>>> second that utilizes both daughterboards.
>>>
>>> Thank you!
>>>
>>> -----------------------------
>>> Jacob Knoles
>>>
>>>
>>> _______________________________________________
>>> 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/20170628/1ab95295/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 28 Jun 2017 11:38:19 -0700
From: Jacob Knoles <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<ca+z4yffaabsbzxxprdqzzdndtu5udp2dsjgbn88mhheqftp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Well, whatever the issue was this has fixed it.
By creating a usrp sptr and a tx_streamer sptr in my constructor and using
them in my functions the sequence error is gone and the functions perform
much faster! Thanks for the suggestion!
Still curious about why the issue was there.... But I like this solution.
Any thoughts about have multiple sptrs for different configurations at the
same time? For example streaming to one daughterboard or both
daughterboards?
-----------------------------
Jacob Knoles
Compliance Engineer / Software Developer
MiCOM Labs Inc.
Pleasanton, CA
On Wed, Jun 28, 2017 at 11:31 AM, Dave NotTelling <[email protected]>
wrote:
> I'm not sure if you need to create a new streamer each time. The
> streamers are also boost::shared_ptr objects, so they should be passable.
> I have done things where I have a thread that handles all of the samples
> and is separate from the main thread. In that case I just pass the
> uhd::rx_streamer::sptr to whatever function needs to receive samples. Not
> sure if the class is thread safe, so be careful about that.
>
> On Wed, Jun 28, 2017 at 2:21 PM, Jacob Knoles <[email protected]> wrote:
>
>> Dave,
>>
>> That is exactly what I figured and am trying to do. I have a class which
>> implements all the functions I need and in that class constructor I make
>> the sptr, which is stored as a private variable in the class.
>>
>> What I don't understand is when I use this method I get a sequence error
>> on any subsequent function call unless I create a whole new sptr? That does
>> not make any sense to me.
>>
>> I am wondering if I am missing some close or flush command, I am creating
>> a new tx_streamer object every function call.
>>
>> -----------------------------
>> Jacob Knoles
>>
>>
>> On Wed, Jun 28, 2017 at 11:16 AM, Dave NotTelling <[email protected]>
>> wrote:
>>
>>> Since the uhd::usrp::multi_usrp::sptr is a boost::shared_ptr under the
>>> hood, you can just pass that around to whatever functions need to use it.
>>> This is assuming that you have one main method that creates the handle and
>>> then hands the handle off to other threads/methods. My apologies if I'm
>>> missing something entirely :)
>>>
>>> On Wed, Jun 28, 2017 at 1:53 PM, Jacob Knoles via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I have several functions that play different signals using the usrp,
>>>> right now I create a usrp device (using multi_usrp::make() ) in each
>>>> function every time a function is run.
>>>>
>>>> My application requires that each of these functions will be run many
>>>> times in succession, therefore I would like to create a single usrp device,
>>>> which will be held by the class object and which can be referenced by the
>>>> different functions.
>>>>
>>>> This seems like it shouldn't be an issue but I am noticing this
>>>> pattern:
>>>> On the first function call everything works perfectly, but on all
>>>> subsequent calls in the same application instance I get a sequence error
>>>> from recv_async_msg() and the first chunk of my signal is missing.
>>>>
>>>> This behavior does not happen if I create a new usrp device every time.
>>>>
>>>>
>>>> What is happening that could cause a packet loss error here?
>>>> Is it possible/plausible to utilize a single usrp device in the way I
>>>> have described?
>>>> Is there some command I need to issue after transmitting to properly
>>>> clean up but not destroy the usrp device?
>>>>
>>>> Additionally, is it possible to have multiple usrp sptrs active at one
>>>> time? For example a device that only utilizes one daughterboard and a
>>>> second that utilizes both daughterboards.
>>>>
>>>> Thank you!
>>>>
>>>> -----------------------------
>>>> Jacob Knoles
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20170628/0b112a82/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 28 Jun 2017 14:46:53 -0400
From: Dave NotTelling <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<cak6gvum-divtoofpdbcr0gnqal64gbhxvqv35wgzadegugw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Since the entire radio is consumed by one connection, you are forced to use
a single multi_usrp::sptr instance for both daughtercards. For example,
you cannot use the two network connections on an X310 separately with the
hopes of connecting once instance of multi_usrp to the first network
interface and daughtercard. I was really hoping for a situation like that
to stream 200 MSPS off of each UBX-160 in an X310, but no dice. The first
connection consumes the main board and the second connection fails.
On Wed, Jun 28, 2017 at 2:38 PM, Jacob Knoles <[email protected]> wrote:
> Well, whatever the issue was this has fixed it.
>
> By creating a usrp sptr and a tx_streamer sptr in my constructor and using
> them in my functions the sequence error is gone and the functions perform
> much faster! Thanks for the suggestion!
>
> Still curious about why the issue was there.... But I like this solution.
>
> Any thoughts about have multiple sptrs for different configurations at the
> same time? For example streaming to one daughterboard or both
> daughterboards?
>
> -----------------------------
> Jacob Knoles
> Compliance Engineer / Software Developer
> MiCOM Labs Inc.
> Pleasanton, CA
>
> On Wed, Jun 28, 2017 at 11:31 AM, Dave NotTelling <[email protected]>
> wrote:
>
>> I'm not sure if you need to create a new streamer each time. The
>> streamers are also boost::shared_ptr objects, so they should be passable.
>> I have done things where I have a thread that handles all of the samples
>> and is separate from the main thread. In that case I just pass the
>> uhd::rx_streamer::sptr to whatever function needs to receive samples. Not
>> sure if the class is thread safe, so be careful about that.
>>
>> On Wed, Jun 28, 2017 at 2:21 PM, Jacob Knoles <[email protected]> wrote:
>>
>>> Dave,
>>>
>>> That is exactly what I figured and am trying to do. I have a class which
>>> implements all the functions I need and in that class constructor I make
>>> the sptr, which is stored as a private variable in the class.
>>>
>>> What I don't understand is when I use this method I get a sequence error
>>> on any subsequent function call unless I create a whole new sptr? That does
>>> not make any sense to me.
>>>
>>> I am wondering if I am missing some close or flush command, I am
>>> creating a new tx_streamer object every function call.
>>>
>>> -----------------------------
>>> Jacob Knoles
>>>
>>>
>>> On Wed, Jun 28, 2017 at 11:16 AM, Dave NotTelling <[email protected]>
>>> wrote:
>>>
>>>> Since the uhd::usrp::multi_usrp::sptr is a boost::shared_ptr under the
>>>> hood, you can just pass that around to whatever functions need to use it.
>>>> This is assuming that you have one main method that creates the handle and
>>>> then hands the handle off to other threads/methods. My apologies if I'm
>>>> missing something entirely :)
>>>>
>>>> On Wed, Jun 28, 2017 at 1:53 PM, Jacob Knoles via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> I have several functions that play different signals using the usrp,
>>>>> right now I create a usrp device (using multi_usrp::make() ) in each
>>>>> function every time a function is run.
>>>>>
>>>>> My application requires that each of these functions will be run many
>>>>> times in succession, therefore I would like to create a single usrp
>>>>> device,
>>>>> which will be held by the class object and which can be referenced by the
>>>>> different functions.
>>>>>
>>>>> This seems like it shouldn't be an issue but I am noticing this
>>>>> pattern:
>>>>> On the first function call everything works perfectly, but on all
>>>>> subsequent calls in the same application instance I get a sequence error
>>>>> from recv_async_msg() and the first chunk of my signal is missing.
>>>>>
>>>>> This behavior does not happen if I create a new usrp device every
>>>>> time.
>>>>>
>>>>> What is happening that could cause a packet loss error here?
>>>>> Is it possible/plausible to utilize a single usrp device in the way I
>>>>> have described?
>>>>> Is there some command I need to issue after transmitting to properly
>>>>> clean up but not destroy the usrp device?
>>>>>
>>>>> Additionally, is it possible to have multiple usrp sptrs active at one
>>>>> time? For example a device that only utilizes one daughterboard and a
>>>>> second that utilizes both daughterboards.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> -----------------------------
>>>>> Jacob Knoles
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20170628/330d921a/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 28 Jun 2017 12:10:03 -0700
From: Jacob Knoles <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using a multi_usrp device over multiple
functions?
Message-ID:
<CA+z4yFEWYViKq9F=bgi-hrssabztmi11igrnvcroyzxzq1u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Great! Thanks for the info Dave.
-----------------------------
Jacob Knoles
On Wed, Jun 28, 2017 at 11:46 AM, Dave NotTelling <[email protected]>
wrote:
> Since the entire radio is consumed by one connection, you are forced to
> use a single multi_usrp::sptr instance for both daughtercards. For
> example, you cannot use the two network connections on an X310 separately
> with the hopes of connecting once instance of multi_usrp to the first
> network interface and daughtercard. I was really hoping for a situation
> like that to stream 200 MSPS off of each UBX-160 in an X310, but no dice.
> The first connection consumes the main board and the second connection
> fails.
>
> On Wed, Jun 28, 2017 at 2:38 PM, Jacob Knoles <[email protected]> wrote:
>
>> Well, whatever the issue was this has fixed it.
>>
>> By creating a usrp sptr and a tx_streamer sptr in my constructor and
>> using them in my functions the sequence error is gone and the functions
>> perform much faster! Thanks for the suggestion!
>>
>> Still curious about why the issue was there.... But I like this solution.
>>
>> Any thoughts about have multiple sptrs for different configurations at
>> the same time? For example streaming to one daughterboard or both
>> daughterboards?
>>
>> -----------------------------
>> Jacob Knoles
>> Compliance Engineer / Software Developer
>> MiCOM Labs Inc.
>> Pleasanton, CA
>>
>> On Wed, Jun 28, 2017 at 11:31 AM, Dave NotTelling <[email protected]>
>> wrote:
>>
>>> I'm not sure if you need to create a new streamer each time. The
>>> streamers are also boost::shared_ptr objects, so they should be passable.
>>> I have done things where I have a thread that handles all of the samples
>>> and is separate from the main thread. In that case I just pass the
>>> uhd::rx_streamer::sptr to whatever function needs to receive samples. Not
>>> sure if the class is thread safe, so be careful about that.
>>>
>>> On Wed, Jun 28, 2017 at 2:21 PM, Jacob Knoles <[email protected]>
>>> wrote:
>>>
>>>> Dave,
>>>>
>>>> That is exactly what I figured and am trying to do. I have a class
>>>> which implements all the functions I need and in that class constructor I
>>>> make the sptr, which is stored as a private variable in the class.
>>>>
>>>> What I don't understand is when I use this method I get a sequence
>>>> error on any subsequent function call unless I create a whole new sptr?
>>>> That does not make any sense to me.
>>>>
>>>> I am wondering if I am missing some close or flush command, I am
>>>> creating a new tx_streamer object every function call.
>>>>
>>>> -----------------------------
>>>> Jacob Knoles
>>>>
>>>>
>>>> On Wed, Jun 28, 2017 at 11:16 AM, Dave NotTelling <[email protected]>
>>>> wrote:
>>>>
>>>>> Since the uhd::usrp::multi_usrp::sptr is a boost::shared_ptr under the
>>>>> hood, you can just pass that around to whatever functions need to use it.
>>>>> This is assuming that you have one main method that creates the handle and
>>>>> then hands the handle off to other threads/methods. My apologies if I'm
>>>>> missing something entirely :)
>>>>>
>>>>> On Wed, Jun 28, 2017 at 1:53 PM, Jacob Knoles via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> I have several functions that play different signals using the usrp,
>>>>>> right now I create a usrp device (using multi_usrp::make() ) in each
>>>>>> function every time a function is run.
>>>>>>
>>>>>> My application requires that each of these functions will be run many
>>>>>> times in succession, therefore I would like to create a single usrp
>>>>>> device,
>>>>>> which will be held by the class object and which can be referenced by the
>>>>>> different functions.
>>>>>>
>>>>>> This seems like it shouldn't be an issue but I am noticing this
>>>>>> pattern:
>>>>>> On the first function call everything works perfectly, but on all
>>>>>> subsequent calls in the same application instance I get a sequence error
>>>>>> from recv_async_msg() and the first chunk of my signal is missing.
>>>>>>
>>>>>> This behavior does not happen if I create a new usrp device every
>>>>>> time.
>>>>>>
>>>>>> What is happening that could cause a packet loss error here?
>>>>>> Is it possible/plausible to utilize a single usrp device in the way I
>>>>>> have described?
>>>>>> Is there some command I need to issue after transmitting to properly
>>>>>> clean up but not destroy the usrp device?
>>>>>>
>>>>>> Additionally, is it possible to have multiple usrp sptrs active at
>>>>>> one time? For example a device that only utilizes one daughterboard and a
>>>>>> second that utilizes both daughterboards.
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> -----------------------------
>>>>>> Jacob Knoles
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20170628/822a9b5e/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 28 Jun 2017 15:36:23 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] [UHD] Introducing the Python API
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi all,
some people have already heard the rumour that we're working on a Python
API for UHD that does not involve gr-uhd. And yes, it's true. A minute
ago, I published our current development branch on github:
https://github.com/EttusResearch/uhd/tree/python-api
We'll be doing some more development on this branch before we're merging
it, but most importantly, we'd like to get some feedback from the
greater community.
The biggest thing missing is more documentation, but it already includes
some examples. It's definitely ready for testing!
If you have feedback, post it either in this thread, or on github:
https://github.com/EttusResearch/uhd/issues/105
I've tried to preempt some questions:
- Does it support Python 2 and 3? Yes.
- Does it use SWIG? No, it uses Boost.Python. We didn't want to add
another dependency to UHD (i.e., SWIG) and Boost was already a
dependency of UHD. It also doesn't require the C API.
- How does this relate to the Python API in gr-uhd? It serves an
entirely different purpose. This Python API is for people writing
standalone applications for USRPs that *don't* use GNU Radio. gr-uhd is
staying the way it is, and is going nowhere. If you're using GNU Radio,
you probably don't care about this.
- Are the UHD Python API and the gr-uhd Python API compatible? Short
answer: No. Long answer: There are very few cases where it makes sense
to mix these APIs, so no. However, this means that a TimeSpec from the
Boost.Python API is not convertible into a time_spec_t from the gr-uhd API.
- When will it be released? TBD, but if we hear a lot of encouragement
that'll drive things along faster. It'll go into master branch whenever
it's considered stable enough, and then in the first major release after
that merge.
- Does it support RFNoC API? Not yet, but it's not hard to add. We
wanted to get the basics (i.e. multi_usrp API) right first.
- What's the streaming performance? Worse than straight C++. Better than
I would have thought, thanks to numpy. We have no benchmarks yet.
Overall, recv() calls are pretty efficient if you've preallocated a
numpy array, because we can cast that to a straight pointer (and also
skip any type checking!!!!!!) and then it's not that different from a
recv() call in a C++ app. However, consuming the data is limited by how
fast you can handle that in Python.
We're really looking forward to feedback from the community.
Cheers,
Martin
------------------------------
Message: 15
Date: Wed, 28 Jun 2017 16:31:25 -0700
From: Jacob Knoles <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] set command time blocking??
Message-ID:
<CA+z4yFFoVSw9AbfCFaBc-B99kbXUabU0vtjQDojRZVNf=wa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
So it is my understanding that the USRP devices, specifically a x300, has a
command buffer that can be loaded with timed commands to execute in the
future.
It is also my understanding that I can load this buffer as such:
usrp->set_command_time( uhd::time_spec_t( ref_time + 0.1) );
usrp->set_tx_freq( my_tune_request );
And this command would be queued, then executed when the time came,
meanwhile the thread would continue executing.
However in my current testing it seems that this sequence is blocking my
main thread. Why?
I have a while loop that simply issues this sequence of commands multiple
times and outputs the specified time and the current USRP time for each
iteration. Here are the first three lines of output:
Specified Time: 0.102991 Current time: 0.0000165515
Specified Time: 0.105884 Current time: 0.103282
Specified Time: 0.108887 Current time: 0.106285
As can be seen there is a huge jump in the current time, and by the second
iteration the time has already passed the next target time.
What am I missing here?
If this is an unavoidable issue then how do I implement a Frequency Hopper?
-----------------------------
Jacob Knoles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/3ff16e79/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 29 Jun 2017 12:55:12 +1000
From: Walter Maguire <[email protected]>
To: [email protected]
Subject: [USRP-users] rfnoc-ofdm
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
Really just looking for clarification on this one.
I am trying to locate the up to date files which support the GNU Radio
Conference Tutorial 2015 tutorial
"Building an OFDM Receiver with RFNoC".
The reason I ask is that up to now I have been working with the
rfnoc-devel branch which uses Vivado 2015.4. I don't see any available
ofdm noc blocks in the usrp3_rfnoc/lib directory. If I checkout the
rfnoc-ofdm I do see the following fpga files in the lib/rfnoc directory
noc_block_ofdm_constellation_demapper_tb
noc_block_ofdm_constellation_demapper.v
noc_block_ofdm_tb
ofdm_constellation_demapper.v
ofdm_peak_detector.v
ofdm_plateau_detector.v
However the associated build environment seems to require the Vivado
2014.4 build system installed. The tutorial shows blocks for OFDM Sync
and OFDM Equalizer. These don't appear to be present in the lib/rfnoc
directory.
I would be grateful if someone would clarify the build files and tools
required.
Regards
Walter
------------------------------
Message: 17
Date: Wed, 28 Jun 2017 23:04:27 -0700
From: Ian Buckley <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PA with the B200 mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Simple Answer:
Yes there is a potential reason not to attempt to do this via an FPGA
modification, but you have to decide which is best route for you:
A) The FPGA has two identical GPIO peripherals, one of which is connected to
the user connector you see on the board, the other drives PCB nets that
controls LED?s, RF switches and the on-board PA.
By programming the GPIO peripheral associated with the user connector
appropriately you can therefore create duplicates (electrically separated but
identical timing) of the signals that control the on board RF switches and PA
and use that to control your external PA. This requires you to invest a little
time in understanding the GPIO programming registers and the UHD API that can
access them and to look how UHD programs the captive GPIO controller that
controls the PCB logic.
B) You do change the FPGA by simply connecting the GPIO signals that control
the PCB logic also to the FPGA pins that drive the GPIO user connector so you
have a version of the signals that UHD already provides to control the on board
PA or RX/TX switch. You don?t have to write any new software, you do have to
rebuild the FPGA and be careful to not break existing functionality.
Less simple answer depends on your application?the gist of it is:
The FPGA GPIO state machines transition with a fixed time offset from the
actual signal you see on the SMA?s, the delay being attributable to the many
DSP elements in the signal chain that are programable and have group delay.
This has the potential to give you challenges if you are designing for an
application where you have to meet a tightly controlled spectral mask etc as PA
transitions may not be perfectly synchronized with signal transitions. If thats
important to you then it?s very solvable but it?s beyond the scope of the
simple solutions suggested above.
-Ian
> On Jun 28, 2017, at 9:52 AM, Jason Matusiak via USRP-users
> <[email protected]> wrote:
>
> Is there a way to control a PA from the B200 mini? I am looking to turn the
> PA on/off depending on whether we were transmitting or not.
>
> From this Ettus app note
> (https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf
>
> <https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf>):
> Transceiver Antenna Selection ? Half-Duplex vs. Full Duplex
> If the application requires the USRP device to operate in half-duplex mode
> with a single antenna (per USRP), the TX/RX connector can be used for
> transmission and reception. In this mode, automatic transmit-receive (ATR)
> logic switches the TX/RX port to the transmit path when the host is streaming
> samples. When transmit streaming stops, a state-machine in the FPGA will
> automatically switch the TX/RX port to the receive path. This functionality
> can be overridden with UHD API calls to control the transmit/receive switches
> through GPIO.
>
> So is there any reason not to attempt to route the ATR to the GPIO connector
> J5? Is there an easier way of doing this besides mucking with Ettus' FPGA
> code that I missed?
>
> _______________________________________________
> 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/20170628/c5107b61/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 29 Jun 2017 11:00:01 +0200
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Understanding tx_burst.cpp
Message-ID:
<CAOExtcSvcfSFs5CyfJo9JsKRNHLY=ksx-kyfuagfaluvvfm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I got it , it was a setting issue in my signal analyzer :D
I see the bursts clearly now.
On Wed, Jun 28, 2017 at 7:55 PM, Sumit Kumar <[email protected]> wrote:
>
> Hello,
>
> I am trying to understand the timed commands. I ran tx_burst in the uhd
> examples with --repeat option and observed the same on a signal
> analyzer(SA).
>
> In the beginning, I see a spike but after that I don't see any activity on
> the SA. However in the terminal I see that messages are getting printed
> about successful bursts. Even the transmit LED keep glowing RED (B210).
>
> Am I missing something obvious.
>
> Regards
> Sumit
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/d0dc726e/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 29 Jun 2017 11:25:05 +0200
From: altu? kaya <[email protected]>
To: [email protected]
Subject: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw Data
Message-ID:
<cahq6uv-d+ps6ccmc4rrbbehet-vnz-ti2ejkdg-bthwmdxk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I would like to read the raw (unprocessed) data, namely I and Q, of B210. I
think if I by-pass the DDC chain module (located in Radio Legacy Module),
then I should read the raw data. However, the input of the DDC chain is
11-bit (interleaved I and Q data) and the output is 32-bit. This prevents
me to short circuit the input and the output.
How can I get the unprocessed data? Should I leave DDC chain and search for
other solutions?
I am looking forward to your reply,
Altug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/b02fab8d/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 29 Jun 2017 11:32:00 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Altug,
how much more unprocessed than simply padded with zeros to 16 bit in
case you choose master clock rate == sampling rate do you need?
Generally, if our DSP is bug-free, Nyquist says what you get after all
the DDC is mathematically equivalent to the unprocessed signal, and
thus, especially, contains 100% of the original information; so,
typically, you won't win anything by *not* using the DSP chain for any
given bandwidth==sample rate.
I feel this is kind of an XY problem[1], where you ask for a solution to
a bit of a weird problem in expectation it'll solve another, more
complex problem, which you forget to mention. But: Maybe we have a
solution to that original problem, if you could elaborate on what you're
trying to achieve with the raw data?
Best regards,
Marcus
[1] http://xyproblem.info
On 29.06.2017 11:25, altu? kaya via USRP-users wrote:
> Hello everyone,
>
> I would like to read the raw (unprocessed) data, namely I and Q, of
> B210. I think if I by-pass the DDC chain module (located in Radio
> Legacy Module), then I should read the raw data. However, the input of
> the DDC chain is 11-bit (interleaved I and Q data) and the output is
> 32-bit. This prevents me to short circuit the input and the output.
>
> How can I get the unprocessed data? Should I leave DDC chain and
> search for other solutions?
>
> I am looking forward to your reply,
> Altug
>
>
> _______________________________________________
> 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/20170629/42e10bc3/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 29 Jun 2017 11:11:13 +0100
From: Francisco Paisana <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] set command time blocking??
Message-ID:
<CAJJnpWuR6NiO4ZZfcfy7T7M5=mico0ucpgbpo096w1nzkxw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Jacob,
I am not that informed about this usrp feature but could it be that you can
only queue one command at a time? In such case, the usrp command call locks
until the previous command is finished
Regards,
Francisco
On 29 June 2017 at 00:31, Jacob Knoles via USRP-users <
[email protected]> wrote:
> So it is my understanding that the USRP devices, specifically a x300, has
> a command buffer that can be loaded with timed commands to execute in the
> future.
>
> It is also my understanding that I can load this buffer as such:
>
> usrp->set_command_time( uhd::time_spec_t( ref_time + 0.1) );
> usrp->set_tx_freq( my_tune_request );
>
> And this command would be queued, then executed when the time came,
> meanwhile the thread would continue executing.
>
> However in my current testing it seems that this sequence is blocking my
> main thread. Why?
> I have a while loop that simply issues this sequence of commands multiple
> times and outputs the specified time and the current USRP time for each
> iteration. Here are the first three lines of output:
>
> Specified Time: 0.102991 Current time: 0.0000165515
> Specified Time: 0.105884 Current time: 0.103282
> Specified Time: 0.108887 Current time: 0.106285
>
> As can be seen there is a huge jump in the current time, and by the second
> iteration the time has already passed the next target time.
>
> What am I missing here?
> If this is an unavoidable issue then how do I implement a Frequency Hopper?
>
> -----------------------------
> Jacob Knoles
>
>
> _______________________________________________
> 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/20170629/b28a8138/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 29 Jun 2017 12:17:17 +0200
From: altu? kaya <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID:
<CAHq6UV9pt9-3ZOCGPXoO5D9fvm9MkWcMk91==wrfnssm3d0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
Thank you for your comment. I respect your answer, but I would like to ask
how can be the output is an unprocessed data? In the DDC chain, there are
several modules that are responsible from adding/clipping bits?
The problem X is as the following. During the operation of the device a
non-determined frequency offset in between the two inputs deteriorates the
reception quality of signals and complicates the synchronization process.
I am looking forward to your reply,
Altug
On Thu, Jun 29, 2017 at 11:32 AM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi Altug,
>
> how much more unprocessed than simply padded with zeros to 16 bit in case
> you choose master clock rate == sampling rate do you need? Generally, if
> our DSP is bug-free, Nyquist says what you get after all the DDC is
> mathematically equivalent to the unprocessed signal, and thus, especially,
> contains 100% of the original information; so, typically, you won't win
> anything by *not* using the DSP chain for any given bandwidth==sample rate.
>
> I feel this is kind of an XY problem[1], where you ask for a solution to a
> bit of a weird problem in expectation it'll solve another, more complex
> problem, which you forget to mention. But: Maybe we have a solution to that
> original problem, if you could elaborate on what you're trying to achieve
> with the raw data?
>
> Best regards,
>
> Marcus
>
> [1] http://xyproblem.info
>
> On 29.06.2017 11:25, altu? kaya via USRP-users wrote:
>
> Hello everyone,
>
> I would like to read the raw (unprocessed) data, namely I and Q, of B210.
> I think if I by-pass the DDC chain module (located in Radio Legacy Module),
> then I should read the raw data. However, the input of the DDC chain is
> 11-bit (interleaved I and Q data) and the output is 32-bit. This prevents
> me to short circuit the input and the output.
>
> How can I get the unprocessed data? Should I leave DDC chain and search
> for other solutions?
>
> I am looking forward to your reply,
> Altug
>
>
> _______________________________________________
> 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/20170629/ec8be0b2/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 29 Jun 2017 07:05:56 +0000
From: Hu Chaoran <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] problems about using rfnoc on e310
Message-ID:
<bn3pr03mb1464df74bcd54e1c3302ac1383...@bn3pr03mb1464.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="gb2312"
Hello,
I want to use the rfnoc block DUC and Siggen on e310, but when I run them I got
the error : 'RuntimeError: Cannot find a block for ID: DUC'.
Then I found that on my device there are only these blocks as fellows.
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Radio_0
| | | * FIFO_0
| | | * Window_0
| | | * FFT_0
| | | * fosphor_0
| | | * FIFO_1
| | | * FIR_0
on the document ' Getting started with RFNoC Development '
(http://kb.ettus.com/Getting_Started_with_RFNoC_Development) I find something
about image building, but I think that method is only for PC, because I didn't
found files such as 'uhd_image_builder.py' on my e310 device. Then how can I
update the image on my e310 device to support the DDC, Duc, siggen or other
blocks?
Thanks a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/43f8bfb3/attachment-0001.html>
------------------------------
Message: 24
Date: Thu, 29 Jun 2017 10:09:24 +0200
From: "gwenhael.goavec" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310, 2 Basic RX and quad DDC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Hi,
I use an x310 with 2 basic RX daughterboard.
Currently I inject one "real" signal in channelA for side A and a
second "real" signal in channelA for side B. Now I wish to inject 4
"real" signals in my USRP and receiving 4 demodulated/filtered IQ
dataflow on my computer. It's theorically possible because BasicRx
daughterboard do nothing.
I've read the Vivado design for this USRP and I've seen in x300_core.v
(in fact rfnoc_ce_default_inst_x310.v) 2 x noc_block_ddc : I suppose
(I'm wrong ?) each of them receive 2 dataflow of one ADC (chanA and
chanB).
In this module 2 DDC are instanciated. Consequently It's seems to have
4 demodulation using cordic24 and 4 CIC.
Consequently, I suppose my need is possible with official X310 firmware
but I'm don't know how to configure, through uhd or gnuradio, my USRP
to provide I0Q0I1Q1I2Q2I3Q3 (this order is not mandatory).
My assumption is true (or not)? If it's possible someone here could
help me for this configuration?
Thank you very much
Gwen
------------------------------
Message: 25
Date: Thu, 29 Jun 2017 16:20:24 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Adding 10 MHz permanently to B210?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
As far as I understand I have to enable external 10 MHz clock source before
the PLL locks onto it and syncs the 40 MHz internal master clock, is this
right? When I look into the circuit diagram I see a switch, choosing between
external clock and GPSDO. What input is selected by default, without
specifying anything? GPSDO?
And is the PLL active all the time, meens, normally running free, and when
it sees a 10 MHz reference it automagically locks?
The idea is, connecting a 0.something ppm TCXO to one of those inputs, to
achieve something better than 10 KHz error at 5.5 GHz without having to turn
this on all the time :)
Ralph, dk5ras.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
[email protected]
http://www.bclog.de/
------------------------------
Message: 26
Date: Thu, 29 Jun 2017 07:39:08 -0700
From: Jacob Knoles <[email protected]>
To: Francisco Paisana <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] set command time blocking??
Message-ID:
<CA+z4yFELUWXcuy1x__DbPr5nF4=w8n8Eq8m8SB0ST+ut3b_F=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Francisco,
>From other mailing list emails I've seen and some previous research it was
my understanding that you could queue up to 16 commands if the device is
capable. I can run the test_timed_commands example with no issues so it
seems that my device is capable.
It also seems like the idea of timed commands is wasted if you can only
send one at a time.
But at this point I have no idea.
Regards.
Jacob
On Jun 29, 2017 3:11 AM, "Francisco Paisana" <[email protected]> wrote:
Hey Jacob,
I am not that informed about this usrp feature but could it be that you can
only queue one command at a time? In such case, the usrp command call locks
until the previous command is finished
Regards,
Francisco
On 29 June 2017 at 00:31, Jacob Knoles via USRP-users <
[email protected]> wrote:
> So it is my understanding that the USRP devices, specifically a x300, has
> a command buffer that can be loaded with timed commands to execute in the
> future.
>
> It is also my understanding that I can load this buffer as such:
>
> usrp->set_command_time( uhd::time_spec_t( ref_time + 0.1) );
> usrp->set_tx_freq( my_tune_request );
>
> And this command would be queued, then executed when the time came,
> meanwhile the thread would continue executing.
>
> However in my current testing it seems that this sequence is blocking my
> main thread. Why?
> I have a while loop that simply issues this sequence of commands multiple
> times and outputs the specified time and the current USRP time for each
> iteration. Here are the first three lines of output:
>
> Specified Time: 0.102991 Current time: 0.0000165515
> Specified Time: 0.105884 Current time: 0.103282
> Specified Time: 0.108887 Current time: 0.106285
>
> As can be seen there is a huge jump in the current time, and by the second
> iteration the time has already passed the next target time.
>
> What am I missing here?
> If this is an unavoidable issue then how do I implement a Frequency Hopper?
>
> -----------------------------
> Jacob Knoles
>
>
> _______________________________________________
> 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/20170629/f84fb044/attachment-0001.html>
------------------------------
Message: 27
Date: Thu, 29 Jun 2017 10:57:53 -0400
From: [email protected]
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Adding 10 MHz permanently to B210?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The default state is to use the internal reference clock, unless there's
a GPSDO, in which case, it will select the GPSDO.
Your application can request external clocking during application
initialization.
On 2017-06-29 10:20, Ralph A. Schmid, dk5ras via USRP-users wrote:
> Hi,
>
> As far as I understand I have to enable external 10 MHz clock source before
> the PLL locks onto it and syncs the 40 MHz internal master clock, is this
> right? When I look into the circuit diagram I see a switch, choosing between
> external clock and GPSDO. What input is selected by default, without
> specifying anything? GPSDO?
>
> And is the PLL active all the time, meens, normally running free, and when
> it sees a 10 MHz reference it automagically locks?
>
> The idea is, connecting a 0.something ppm TCXO to one of those inputs, to
> achieve something better than 10 KHz error at 5.5 GHz without having to turn
> this on all the time :)
>
> Ralph, dk5ras.
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 F?rth
> +49-171-3631223
> [email protected]
> http://www.bclog.de/
>
> _______________________________________________
> 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/20170629/e79aa606/attachment-0001.html>
------------------------------
Message: 28
Date: Thu, 29 Jun 2017 08:05:47 -0700
From: Derek Kozel <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Adding 10 MHz permanently to B210?
Message-ID:
<CAA+K=tvk4CLdNPZ0-Myy=4aFTzepStJCjDHMF=5jmbz1nbk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hallo Ralph,
The default source is internal which does not use the GPSDO or external
source. This is the 40 MHz TCXO. I'm not certain which state the switch is
initialized in but it can probabt
If you want to permanently supply a 10 MHz external reference it should be
connected to the external connector. It is required to select the external
reference every time a session is made with the B210, there is no way to
set the external as the default without modifying UHD.
Viele Gr??e,
Derek
On Thu, Jun 29, 2017 at 7:20 AM, Ralph A. Schmid, dk5ras via USRP-users <
[email protected]> wrote:
> Hi,
>
> As far as I understand I have to enable external 10 MHz clock source before
> the PLL locks onto it and syncs the 40 MHz internal master clock, is this
> right? When I look into the circuit diagram I see a switch, choosing
> between
> external clock and GPSDO. What input is selected by default, without
> specifying anything? GPSDO?
>
> And is the PLL active all the time, meens, normally running free, and when
> it sees a 10 MHz reference it automagically locks?
>
> The idea is, connecting a 0.something ppm TCXO to one of those inputs, to
> achieve something better than 10 KHz error at 5.5 GHz without having to
> turn
> this on all the time :)
>
> Ralph, dk5ras.
>
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 F?rth
> +49-171-3631223
> [email protected]
> http://www.bclog.de/
>
>
>
>
>
> _______________________________________________
> 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/20170629/e78c02e7/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 82, Issue 28
******************************************
