Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. N210 Clock Drift (Dave NotTelling)
2. Re: N210 Clock Drift (mle...@ripnet.com)
3. Re: How can I be sure I am not losing even one sample in a
stream? (Martin Braun)
4. Re: N210 Clock Drift (Steven Knudsen)
5. Re: N210 Clock Drift (Dave NotTelling)
6. Re: N210 Clock Drift (Dave NotTelling)
7. Re: N210 Clock Drift (mle...@ripnet.com)
8. Re: E310: Autoboot stops working (Moritz Fischer)
9. Rx Absolute Maximum for USRP X300 with UBX Mezzanine
(Trevor Yensen)
10. Re: Rx Absolute Maximum for USRP X300 with UBX Mezzanine
(mle...@ripnet.com)
11. Re: Rx Absolute Maximum for USRP X300 with UBX Mezzanine
(Trevor Yensen)
12. Re: Rx Absolute Maximum for USRP X300 with UBX Mezzanine
(mle...@ripnet.com)
13. Re: Frequency Response of UBX-40 Low Pass Filter and USRP
N210 DDC? (Kyeong Su Shin)
14. Re: N210 Clock Drift (Michael West)
15. XCVR2450 dead alike (Vladica Sark)
16. Re: XCVR2450 dead alike (mle...@ripnet.com)
17. Re: N210 Clock Drift (Dave NotTelling)
18. Re: N210 Clock Drift (Tom Tsou)
19. Re: How can I be sure I am not losing even one sample in a
stream? (Martin Braun)
20. X310/UBX RX streaming startup transients (Rob Kossler)
21. Re: RFNoC XML (john liu)
22. Re: X310/UBX RX streaming startup transients (Michael West)
23. Re: XCVR2450 dead alike (Vladica Sark)
24. Re: Bricked X310 (Philipp Rudnik)
25. RFA or RFB (liu Jong)
26. B210 C-API dual channel (?????? 1)
27. Re: RFNoC XML (Jason Matusiak)
28. gen usrp b205mini-i ise project file (carry chen)
29. Assertion error executing usrp_energy command
(Peter-Rene Schroeter)
30. What is the time? How can we do if we want to convert to
understand it? (zhuimengren)
31. Re: X310/UBX RX streaming startup transients (Rob Kossler)
32. Re: X310/UBX RX streaming startup transients (Rob Kossler)
33. Re: XCVR2450 dead alike (mle...@ripnet.com)
34. Re: What is the time? How can we do if we want to convert to
understand it? (Steven Knudsen)
35. Re: RFA or RFB (Derek Kozel)
36. Re: Assertion error executing usrp_energy command (Derek Kozel)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Nov 2016 12:04:44 -0500
From: Dave NotTelling <dmp250...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] N210 Clock Drift
Message-ID:
<cak6gvupqnlqadfmg-tgq9wy41q3jcvnmh2t-onse__ujnji...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I noticed that over ~ 2 minutes the synchronization between time on the
USRP and my host will drift by about 1-2 milliseconds. I don't have a GPS
source and I would rather not use one. Is there a way to keep the time
sync'ed up between the host and USRP? Anyone know a good way to tell which
is falling behind / getting ahead? I am working under the assumption that
my Linux box will not be as accurate with time as the USRP. Is that
correct?
Thank you!
Here is the code I'm running:
(build and run with `g++ time.cc -o time -luhd -lboost_system
-lboost_thread && sudo ./time`)
#include <uhd/usrp/multi_usrp.hpp>
#include <stdio.h>
#include <stdlib.h>
#include <boost/thread.hpp>
#include <uhd.h>
double getTime() {
struct timeval start;
gettimeofday(&start, NULL);
return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
}
int main(){
uhd::usrp::multi_usrp::sptr usrp =
uhd::usrp::multi_usrp::make(uhd::device_addr_t("type=usrp2"));
boost::this_thread::sleep_for(boost::chrono::seconds(1));
const double offset = getTime() - usrp->get_time_now().get_real_secs();
const double maxDrift = 0.0001;
double local, remote;
while(1){
try {
local = getTime();
remote = usrp->get_time_now().get_real_secs();
const double delta = std::abs(local - remote - offset);
printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
boost::this_thread::sleep_for(boost::chrono::milliseconds(50));
}catch(uhd::runtime_error &e){
}
}
return 0;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/364bf116/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 15 Nov 2016 12:09:55 -0500
From: mle...@ripnet.com
To: Dave NotTelling <dmp250...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID: <62be8bac6eb46167a48839e990c9a...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
Is your host synched via NTP? Are you using the factory clock on your
USRP or an external source?
Computer clocks, in general, are not that good, which is why systems
like NTP and GPSD were invented.
On 2016-11-15 12:04, Dave NotTelling via USRP-users wrote:
> I noticed that over ~ 2 minutes the synchronization between time on the USRP
> and my host will drift by about 1-2 milliseconds. I don't have a GPS source
> and I would rather not use one. Is there a way to keep the time sync'ed up
> between the host and USRP? Anyone know a good way to tell which is falling
> behind / getting ahead? I am working under the assumption that my Linux box
> will not be as accurate with time as the USRP. Is that correct?
>
> Thank you!
>
> Here is the code I'm running:
>
> (build and run with `g++ time.cc -o time -luhd -lboost_system -lboost_thread
> && sudo ./time`)
>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <stdio.h>
> #include <stdlib.h>
> #include <boost/thread.hpp>
> #include <uhd.h>
>
> double getTime() {
> struct timeval start;
> gettimeofday(&start, NULL);
> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
> }
>
> int main(){
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(uhd::device_addr_t("type=usrp2"));
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>
> const double offset = getTime() - usrp->get_time_now().get_real_secs();
> const double maxDrift = 0.0001;
> double local, remote;
> while(1){
> try {
> local = getTime();
> remote = usrp->get_time_now().get_real_secs();
> const double delta = std::abs(local - remote - offset);
> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
> boost::this_thread::sleep_for(boost::chrono::milliseconds(50));
> }catch(uhd::runtime_error &e){
> }
> }
>
> return 0;
> }
>
> _______________________________________________
> USRP-users mailing list
> 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/20161115/0f9212bd/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 15 Nov 2016 09:12:21 -0800
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] How can I be sure I am not losing even one
sample in a stream?
Message-ID: <12032ce4-edef-8b1a-bf4d-99e622190...@ettus.com>
Content-Type: text/plain; charset=windows-1252
If you don't get overruns or sequence errors (dropped packets), you are
not losing samples.
Cheers,
Martin
On 11/15/2016 08:35 AM, Crozzoli Maurizio via USRP-users wrote:
> Hi!
>
> It is all written in the subject but few more details are given below.
>
> 1. We are afraid it might be a sort of a FAQ: if so, please excuse us and
> suggest us a pointer to start with.
> 2. We are using an E310 to collect samples (temporarily in a buffer, of
> course) and then save them to file. We are using a modified version of the
> sample code provided by Ettus "rx_multi_samples.cpp" where the core operation
> is "rx_stram->recv(buffer, samps_per_buffer, md, timeout);".
> 3. Then the question in the subject follows.
>
> TIA to whoever wants to help us.
>
> BR,
> Daniele and Maurizio.
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Tue, 15 Nov 2016 10:14:44 -0700
From: Steven Knudsen <ee.k...@gmail.com>
To: Dave NotTelling <dmp250...@gmail.com>
Cc: USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID: <a62ed81c-786a-4765-92a1-f242e6bc5...@gmail.com>
Content-Type: text/plain; charset="utf-8"
At the risk of being annoying, may I ask if you really need to have time sync?s
between the USRP and the Linux host?
Asking because what I do is use my Linux box to set the time one time on the
USRP and then use only relative time on the Linux host (e.g., set a timer for N
milliseconds). Whenever I need absolute time, I get it from the USRP.
I ran a bunch of tests to get the upper limit on the latency of a get time
request, then add an appropriate margin of error to that latency and make sure
that all USRP time-specified operations are executed at least that far ahead in
time.
The fact that my Linux box is 1 PPS + GPS disciplined doesn?t really matter in
the context of this response I think you?ll agree. It does matter to me because
I rely on time sync between multiple radios, but that?s another problem.
The amount of drift you see is not surprising if your Linux box is not network
time sync?d. Even it if it is, the variance in time over most time frames is
not insignificant, often on the order of 10s of milliseconds.
Does this help?
Apologies if I?m off target,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Du bist die Aufgabe. Kein Sch?ler weit und breit. - Franz Kafka
> On Nov 15, 2016, at 10:04, Dave NotTelling via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> I noticed that over ~ 2 minutes the synchronization between time on the USRP
> and my host will drift by about 1-2 milliseconds. I don't have a GPS source
> and I would rather not use one. Is there a way to keep the time sync'ed up
> between the host and USRP? Anyone know a good way to tell which is falling
> behind / getting ahead? I am working under the assumption that my Linux box
> will not be as accurate with time as the USRP. Is that correct?
>
> Thank you!
>
>
> Here is the code I'm running:
>
> (build and run with `g++ time.cc -o time -luhd -lboost_system -lboost_thread
> && sudo ./time`)
>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <stdio.h>
> #include <stdlib.h>
> #include <boost/thread.hpp>
> #include <uhd.h>
>
> double getTime() {
> struct timeval start;
> gettimeofday(&start, NULL);
> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
> }
>
> int main(){
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(uhd::device_addr_t("type=usrp2"));
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>
> const double offset = getTime() - usrp->get_time_now().get_real_secs();
> const double maxDrift = 0.0001;
> double local, remote;
> while(1){
> try {
> local = getTime();
> remote = usrp->get_time_now().get_real_secs();
> const double delta = std::abs(local - remote - offset);
> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
> boost::this_thread::sleep_for(boost::chrono::milliseconds(50));
> }catch(uhd::runtime_error &e){
> }
> }
>
> return 0;
> }
>
> _______________________________________________
> USRP-users mailing list
> 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/20161115/a0f5b540/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 15 Nov 2016 12:17:15 -0500
From: Dave NotTelling <dmp250...@gmail.com>
To: Steven Knudsen <ee.k...@gmail.com>
Cc: USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID:
<cak6gvuod+7u6kyqcmjgizkwa+uht7amfnfm_znrqzsvdknw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Steven,
I am constantly sending and receiving samples that are all timed. The
issue is that the drift over time will cause all the requests to be late at
the radio.
The latency I measured was something on the order of 80 us which is
noting so I'm not too worried about that offset.
Things go badly once the offset is > ~ 2-3 ms.
Thank you!
On Tue, Nov 15, 2016 at 12:14 PM, Steven Knudsen <ee.k...@gmail.com> wrote:
> At the risk of being annoying, may I ask if you really need to have time
> sync?s between the USRP and the Linux host?
>
> Asking because what I do is use my Linux box to set the time one time on
> the USRP and then use only relative time on the Linux host (e.g., set a
> timer for N milliseconds). Whenever I need absolute time, I get it from the
> USRP.
>
> I ran a bunch of tests to get the upper limit on the latency of a get time
> request, then add an appropriate margin of error to that latency and make
> sure that all USRP time-specified operations are executed at least that far
> ahead in time.
>
> The fact that my Linux box is 1 PPS + GPS disciplined doesn?t really
> matter in the context of this response I think you?ll agree. It does matter
> to me because I rely on time sync between multiple radios, but that?s
> another problem.
>
> The amount of drift you see is not surprising if your Linux box is not
> network time sync?d. Even it if it is, the variance in time over most time
> frames is not insignificant, often on the order of 10s of milliseconds.
>
> Does this help?
>
> Apologies if I?m off target,
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> Du bist die Aufgabe. Kein Sch?ler weit und breit. *- Franz Kafka *
>
> On Nov 15, 2016, at 10:04, Dave NotTelling via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I noticed that over ~ 2 minutes the synchronization between time on the
> USRP and my host will drift by about 1-2 milliseconds. I don't have a GPS
> source and I would rather not use one. Is there a way to keep the time
> sync'ed up between the host and USRP? Anyone know a good way to tell which
> is falling behind / getting ahead? I am working under the assumption that
> my Linux box will not be as accurate with time as the USRP. Is that
> correct?
>
> Thank you!
>
>
> Here is the code I'm running:
>
> (build and run with `g++ time.cc -o time -luhd -lboost_system
> -lboost_thread && sudo ./time`)
>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <stdio.h>
> #include <stdlib.h>
> #include <boost/thread.hpp>
> #include <uhd.h>
>
> double getTime() {
> struct timeval start;
> gettimeofday(&start, NULL);
> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
> }
>
> int main(){
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(
> uhd::device_addr_t("type=usrp2"));
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>
> const double offset = getTime() - usrp->get_time_now().get_real_
> secs();
> const double maxDrift = 0.0001;
> double local, remote;
> while(1){
> try {
> local = getTime();
> remote = usrp->get_time_now().get_real_secs();
> const double delta = std::abs(local - remote - offset);
> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
> boost::this_thread::sleep_for(boost::chrono::milliseconds(
> 50));
> }catch(uhd::runtime_error &e){
> }
> }
>
> return 0;
> }
>
> _______________________________________________
> USRP-users mailing list
> 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/20161115/a4358808/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 15 Nov 2016 12:15:33 -0500
From: Dave NotTelling <dmp250...@gmail.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID:
<CAK6GVuMxgoBYa=NwYFfhkzjipY-_VVPoVK1vf47ZOO8X=jm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
I am purposefully not running NTP. I am using just the base N210 with
the UBX-40. No changes at all to the hardware.
I can nudge the radio a little when the offset gets too far out. But
that sometimes makes things worse.
The one thing that I'm curious about is which clock should I trust as
being the most accurate. Plus, I'm still trying to find out if I should
trust the system clock of the computer or the hardware clock.
Thanks!
On Tue, Nov 15, 2016 at 12:09 PM, <mle...@ripnet.com> wrote:
> Is your host synched via NTP? Are you using the factory clock on your
> USRP or an external source?
>
> Computer clocks, in general, are not that good, which is why systems like
> NTP and GPSD were invented.
>
>
>
>
>
>
> On 2016-11-15 12:04, Dave NotTelling via USRP-users wrote:
>
> I noticed that over ~ 2 minutes the synchronization between time on the
> USRP and my host will drift by about 1-2 milliseconds. I don't have a GPS
> source and I would rather not use one. Is there a way to keep the time
> sync'ed up between the host and USRP? Anyone know a good way to tell which
> is falling behind / getting ahead? I am working under the assumption that
> my Linux box will not be as accurate with time as the USRP. Is that
> correct?
>
> Thank you!
>
>
> Here is the code I'm running:
>
> (build and run with `g++ time.cc -o time -luhd -lboost_system
> -lboost_thread && sudo ./time`)
>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <stdio.h>
> #include <stdlib.h>
> #include <boost/thread.hpp>
> #include <uhd.h>
>
> double getTime() {
> struct timeval start;
> gettimeofday(&start, NULL);
> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
> }
>
> int main(){
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(
> uhd::device_addr_t("type=usrp2"));
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>
> const double offset = getTime() - usrp->get_time_now().get_real_
> secs();
> const double maxDrift = 0.0001;
> double local, remote;
> while(1){
> try {
> local = getTime();
> remote = usrp->get_time_now().get_real_secs();
> const double delta = std::abs(local - remote - offset);
> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
> boost::this_thread::sleep_for(boost::chrono::milliseconds(
> 50));
> }catch(uhd::runtime_error &e){
> }
> }
>
> return 0;
> }
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20161115/6d7a3a7f/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 15 Nov 2016 12:30:23 -0500
From: mle...@ripnet.com
To: Dave NotTelling <dmp250...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID: <312ff1ebeb314b35b1a5d1e96208a...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
Set the time on the radio once--from your system time. The USRP will
then maintain better time than your computer, typically.
Query the time on the USRP when you need to schedule things.
But, if you need to have time that is synchronous to the rest of the
precise-time "world", then you'll need GPS and/or NTP.
On 2016-11-15 12:15, Dave NotTelling wrote:
> Marcus,
>
> I am purposefully not running NTP. I am using just the base N210 with the
> UBX-40. No changes at all to the hardware.
>
> I can nudge the radio a little when the offset gets too far out. But that
> sometimes makes things worse.
>
> The one thing that I'm curious about is which clock should I trust as being
> the most accurate. Plus, I'm still trying to find out if I should trust the
> system clock of the computer or the hardware clock.
>
> Thanks!
>
> On Tue, Nov 15, 2016 at 12:09 PM, <mle...@ripnet.com> wrote:
>
> Is your host synched via NTP? Are you using the factory clock on your USRP
> or an external source?
>
> Computer clocks, in general, are not that good, which is why systems like NTP
> and GPSD were invented.
>
> On 2016-11-15 12:04, Dave NotTelling via USRP-users wrote:
>
> I noticed that over ~ 2 minutes the synchronization between time on the USRP
> and my host will drift by about 1-2 milliseconds. I don't have a GPS source
> and I would rather not use one. Is there a way to keep the time sync'ed up
> between the host and USRP? Anyone know a good way to tell which is falling
> behind / getting ahead? I am working under the assumption that my Linux box
> will not be as accurate with time as the USRP. Is that correct?
>
> Thank you!
>
> Here is the code I'm running:
>
> (build and run with `g++ time.cc -o time -luhd -lboost_system -lboost_thread
> && sudo ./time`)
>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <stdio.h>
> #include <stdlib.h>
> #include <boost/thread.hpp>
> #include <uhd.h>
>
> double getTime() {
> struct timeval start;
> gettimeofday(&start, NULL);
> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
> }
>
> int main(){
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(uhd::device_addr_t("type=usrp2"));
> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>
> const double offset = getTime() - usrp->get_time_now().get_real_secs();
> const double maxDrift = 0.0001;
> double local, remote;
> while(1){
> try {
> local = getTime();
> remote = usrp->get_time_now().get_real_secs();
> const double delta = std::abs(local - remote - offset);
> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
> boost::this_thread::sleep_for(boost::chrono::milliseconds(50));
> }catch(uhd::runtime_error &e){
> }
> }
>
> return 0;
> }
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/e837a02f/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 15 Nov 2016 09:56:05 -0800
From: Moritz Fischer <moritz.fisc...@ettus.com>
To: ???? <r...@eng.gov.il>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E310: Autoboot stops working
Message-ID:
<CAAtXAHcUP4puVyNP50YLxFKbi=v6zfzf91f-m3zw7jx9lp-...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Roy,
On Tue, Nov 15, 2016 at 8:09 AM, ???? via USRP-users
<usrp-users@lists.ettus.com> wrote:
> In addition to what I described, I noticed that in the UHD file "pmu.c"
> (uhd/firmware/e300/battery/pmu.c) in line 693, there is a state where I
> think a "0" bit is written to the autoboot bit of the settings register.
> Could this explain why after several on-off cycles the E310 stops booting on
> AC power? Is there a way to make the default value 1?
>
> line 693 of pmu.c: eeprom_set_autoboot(fpga_get_settings() & BIT(0));
BIT(x) expands to (1 << x), so that's fine. We had a bug there in firmware
version < 2.2 but I thought it was fixed with 2.2.
I currently don't have time to look into this further
As a workaround if you have a AVR programmer, just disable the:
if (eeprom_get_autoboot())
check in Line 56 in main.c, like that it will *always* turn on.
Sorry for your trouble,
Moritz
------------------------------
Message: 9
Date: Tue, 15 Nov 2016 18:59:46 +0000
From: Trevor Yensen <trevor.yen...@allenvanguard.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Rx Absolute Maximum for USRP X300 with UBX
Mezzanine
Message-ID:
<AA915FF53B47F94E903E30AE81963BD91CA99D22@SRVNA-EX02.allenvanguard.local>
Content-Type: text/plain; charset="us-ascii"
I see from the use-group messages that the recommended maximum receiver input
level for USRPs appears to be -15dBm. This makes sense to me in front of an
unprotected front-end integrated transceiver such as in the b200mini. However,
when I look at the schematics for the X300 UBX it seems pretty conservative?
What component(s) on the UBX is going to be damaged if I go up to say 10 or
15dBm on the input? I checked the absolute maximum ratings for the LNAs
(VMMK-3603 and MGA-62563), the HMC624ALP4E attenuator, high-path LTC5510 mixer,
low-band amplifier NBB-400 and the quadrature demod ADL5380 and they seem okay?
If I wish to support higher input powers is there any special considerations
necessary for the SBX? (thermal?)
Thanks!
Trevor
IMPORTANT LEGAL NOTICE
This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and exempt
from disclosure under applicable law. If you are not the intended recipient,
you are notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this in error,
please notify the sender immediately and delete it from your system.
Communications using this system are monitored and recorded for lawful business
purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/a0fc007d/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 15 Nov 2016 14:14:50 -0500
From: mle...@ripnet.com
To: Trevor Yensen <trevor.yen...@allenvanguard.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Rx Absolute Maximum for USRP X300 with UBX
Mezzanine
Message-ID: <5f71f9f5fa3842d4e4b57265c5b0c...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
On the SBX, the MGA82563 will be damaged above +13dBm input, and will be
into compression at about +3dBm input.
My recommendation, if you want to measure higher input power, is to use
attenuators in front of these devices. These receivers are intended for
"from the air" reception from antennae, where an input power at an RX
antennae even as high as 0dBm is rather unusual.
On 2016-11-15 13:59, Trevor Yensen via USRP-users wrote:
> I see from the use-group messages that the recommended maximum receiver input
> level for USRPs appears to be -15dBm. This makes sense to me in front of an
> unprotected front-end integrated transceiver such as in the b200mini.
> However, when I look at the schematics for the X300 UBX it seems pretty
> conservative?
>
> What component(s) on the UBX is going to be damaged if I go up to say 10 or
> 15dBm on the input? I checked the absolute maximum ratings for the LNAs
> (VMMK-3603 and MGA-62563), the HMC624ALP4E attenuator, high-path LTC5510
> mixer, low-band amplifier NBB-400 and the quadrature demod ADL5380 and they
> seem okay?
>
> If I wish to support higher input powers is there any special considerations
> necessary for the SBX? (thermal?)
>
> Thanks!
>
> Trevor
>
> IMPORTANT LEGAL NOTICE
>
> This message is intended only for the use of the named addressee. It may
> contain information that is copywritten, privileged, confidential and exempt
> from disclosure under applicable law. If you are not the intended recipient,
> you are notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this in error,
> please notify the sender immediately and delete it from your system.
> Communications using this system are monitored and recorded for lawful
> business purposes.
> _______________________________________________
> USRP-users mailing list
> 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/20161115/0b5bc111/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 15 Nov 2016 19:41:52 +0000
From: Trevor Yensen <trevor.yen...@allenvanguard.com>
To: "mle...@ripnet.com" <mle...@ripnet.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Rx Absolute Maximum for USRP X300 with UBX
Mezzanine
Message-ID:
<AA915FF53B47F94E903E30AE81963BD91CA99DCF@SRVNA-EX02.allenvanguard.local>
Content-Type: text/plain; charset="utf-8"
Hi Marcus.
Thanks for the response.
I don?t actually want to measure anything at these higher powers so I?m not
concerned about compression, I?m just trying to protect the receiver front-end
during transmit activity.
I am planning to use a power amplifier after the TRX port followed by a
circulator to the antenna, with return path to the receiver (RX2). I was
trying to size my combination of attenuator/limiter appropriately to not
adversely affect my noise figure. Currently working with some Minicircuits
limiters and didn?t want to slap a 10-30dB pad after the limiter if it is not
required.
Would it be fair to say that if I am not concerned about distortion due to
compression since my receive signals are less than -15dBm and I?m primarily
protecting the receiver front-end from damage when transmitting, that a 11.5dB
limiter should suffice? (for example Minicircuits VLM-63-2W+, limits at
11.5dBm even more in the bands I will be using)
Thanks,
Trevor
From: mle...@ripnet.com [mailto:mle...@ripnet.com]
Sent: November-15-16 2:15 PM
To: Trevor Yensen
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Rx Absolute Maximum for USRP X300 with UBX Mezzanine
On the SBX, the MGA82563 will be damaged above +13dBm input, and will be into
compression at about +3dBm input.
My recommendation, if you want to measure higher input power, is to use
attenuators in front of these devices. These receivers are intended for "from
the air" reception from antennae, where an input power at an RX antennae even
as high as 0dBm is rather unusual.
On 2016-11-15 13:59, Trevor Yensen via USRP-users wrote:
I see from the use-group messages that the recommended maximum receiver input
level for USRPs appears to be -15dBm. This makes sense to me in front of an
unprotected front-end integrated transceiver such as in the b200mini. However,
when I look at the schematics for the X300 UBX it seems pretty conservative?
What component(s) on the UBX is going to be damaged if I go up to say 10 or
15dBm on the input? I checked the absolute maximum ratings for the LNAs
(VMMK-3603 and MGA-62563), the HMC624ALP4E attenuator, high-path LTC5510 mixer,
low-band amplifier NBB-400 and the quadrature demod ADL5380 and they seem okay?
If I wish to support higher input powers is there any special considerations
necessary for the SBX? (thermal?)
Thanks!
Trevor
IMPORTANT LEGAL NOTICE
This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and exempt
from disclosure under applicable law. If you are not the intended recipient,
you are notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this in error,
please notify the sender immediately and delete it from your system.
Communications using this system are monitored and recorded for lawful business
purposes.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
IMPORTANT LEGAL NOTICE
This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and exempt
from disclosure under applicable law. If you are not the intended recipient,
you are notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this in error,
please notify the sender immediately and delete it from your system.
Communications using this system are monitored and recorded for lawful business
purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/c47f4ee6/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 15 Nov 2016 14:57:46 -0500
From: mle...@ripnet.com
To: Trevor Yensen <trevor.yen...@allenvanguard.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Rx Absolute Maximum for USRP X300 with UBX
Mezzanine
Message-ID: <5b2384c3c800153831b108e81b887...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
+11dBm on input, with the step attenuator set to minimum could exceed
the maximum input power for the mixer--+15dBm.
On 2016-11-15 13:59, Trevor Yensen via USRP-users wrote:
> I see from the use-group messages that the recommended maximum receiver input
> level for USRPs appears to be -15dBm. This makes sense to me in front of an
> unprotected front-end integrated transceiver such as in the b200mini.
> However, when I look at the schematics for the X300 UBX it seems pretty
> conservative?
>
> What component(s) on the UBX is going to be damaged if I go up to say 10 or
> 15dBm on the input? I checked the absolute maximum ratings for the LNAs
> (VMMK-3603 and MGA-62563), the HMC624ALP4E attenuator, high-path LTC5510
> mixer, low-band amplifier NBB-400 and the quadrature demod ADL5380 and they
> seem okay?
>
> If I wish to support higher input powers is there any special considerations
> necessary for the SBX? (thermal?)
>
> Thanks!
>
> Trevor
>
> IMPORTANT LEGAL NOTICE
>
> This message is intended only for the use of the named addressee. It may
> contain information that is copywritten, privileged, confidential and exempt
> from disclosure under applicable law. If you are not the intended recipient,
> you are notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this in error,
> please notify the sender immediately and delete it from your system.
> Communications using this system are monitored and recorded for lawful
> business purposes.
> _______________________________________________
> USRP-users mailing list
> 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/20161115/5f3292ab/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 15 Nov 2016 12:04:45 -0800
From: Kyeong Su Shin <kss...@uw.edu>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Frequency Response of UBX-40 Low Pass Filter
and USRP N210 DDC?
Message-ID:
<CAGL0V3=uycrhgm1ko7pkdfwsduvtghafsjfv-1v_xj-0+_h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello, Marcus M?ller:
Thank you! I will look into these files. Maybe I can try simulating them.
The application will be supporting multiple effective sampling rates (up to
25MS/s). I think one option is to use the non-zero lo_offset to
intentionally move the analog filter (when aliasing is caused by a known
source). An another option is to decimate the signal with the PC using a
stronger digital filter (when I am happy with something lower than 25MS/s
and can afford to have that processing power).
Any suggestions are appreciated.
Regards,
Kyeong Su Shin
On Mon, Nov 14, 2016 at 2:49 PM, Marcus M?ller via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Kyeong Su Shin,
>
> I think the most appropriate help here is to point you at the actual
> schematic of the UBX [1]. On page 4, you'll find (from right to left) the
> elliptical 7-pole LPF, the ADC driver (U6), followed by the 3-pole RC/RLC
> filter. For the UBX-40, consider the blue component values (the red values
> for UBX-160).
>
> You're right, the digital anti-aliasing filter in the DDC is linked to the
> decimation rate ? you'll find the two selectable Halfbands and the
> adjustable CIC in the usrp2/sdr_lib/ directory within the UHD FPGA source
> code [2].
>
> Central problem here is that the decimation and filtering are
> architecturally linked in the filters we use ? so, no, without FPGA code
> modifications, you can't break that link (unless you would want to do
> something like disable the Halfband filters and just do everything with the
> CIC ? which you very likely will not want to do, because the CIC's response
> is much less flat).
>
> What are the sampling rates you're aiming for? Maybe we can come up with
> an elegant solution to your problem
>
> Best regards,
>
> Marcus
>
> [1] https://files.ettus.com/schematics/ubx/ubx.pdf
> [2]https://github.com/EttusResearch/fpga/blob/master/usrp2/sdr_lib/ddc_
> chain.v
>
> On 14.11.2016 22:07, Kyeong Su Shin via USRP-users wrote:
>
> To whom it may concern:
>
> Are there any published information regarding the 20Mhz low pass filter of
> the UBX-40 daughterboard and/or the digital low pass filter of the USRP
> N210's DDC? The application that I am working on is sensitive to aliasing,
> so I would like to know their responses but I am having a trouble in
> locating them.
>
> Also, I would like to know if there is any way to control the digital
> filter being used by the DDC. Is it uncontrollable and only depend on the
> effective sampling rate of the USRP? Or, is there any way to separate them?
>
> Regards,
> Kyeong Su Shin
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/0860a2b8/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 15 Nov 2016 12:23:10 -0800
From: Michael West <michael.w...@ettus.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: Dave NotTelling <dmp250...@gmail.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID:
<cam4xkrop17rzvnqchdnhuaznyseiqmrjteg4tcyrr9jj8pw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.
Regards,
Michael
On Tue, Nov 15, 2016 at 9:30 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Set the time on the radio once--from your system time. The USRP will then
> maintain better time than your computer, typically.
>
> Query the time on the USRP when you need to schedule things.
>
> But, if you need to have time that is synchronous to the rest of the
> precise-time "world", then you'll need GPS and/or NTP.
>
>
>
>
>
>
> On 2016-11-15 12:15, Dave NotTelling wrote:
>
> Marcus,
>
> I am purposefully not running NTP. I am using just the base N210
> with the UBX-40. No changes at all to the hardware.
>
> I can nudge the radio a little when the offset gets too far out. But
> that sometimes makes things worse.
>
> The one thing that I'm curious about is which clock should I trust as
> being the most accurate. Plus, I'm still trying to find out if I should
> trust the system clock of the computer or the hardware clock.
>
> Thanks!
>
> On Tue, Nov 15, 2016 at 12:09 PM, <mle...@ripnet.com> wrote:
>
>> Is your host synched via NTP? Are you using the factory clock on your
>> USRP or an external source?
>>
>> Computer clocks, in general, are not that good, which is why systems like
>> NTP and GPSD were invented.
>>
>>
>>
>>
>>
>>
>> On 2016-11-15 12:04, Dave NotTelling via USRP-users wrote:
>>
>> I noticed that over ~ 2 minutes the synchronization between time on the
>> USRP and my host will drift by about 1-2 milliseconds. I don't have a GPS
>> source and I would rather not use one. Is there a way to keep the time
>> sync'ed up between the host and USRP? Anyone know a good way to tell which
>> is falling behind / getting ahead? I am working under the assumption that
>> my Linux box will not be as accurate with time as the USRP. Is that
>> correct?
>>
>> Thank you!
>>
>>
>> Here is the code I'm running:
>>
>> (build and run with `g++ time.cc -o time -luhd -lboost_system
>> -lboost_thread && sudo ./time`)
>>
>> #include <uhd/usrp/multi_usrp.hpp>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <boost/thread.hpp>
>> #include <uhd.h>
>>
>> double getTime() {
>> struct timeval start;
>> gettimeofday(&start, NULL);
>> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
>> }
>>
>> int main(){
>> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(uh
>> d::device_addr_t("type=usrp2"));
>> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>>
>> const double offset = getTime() - usrp->get_time_now().get_real_
>> secs();
>> const double maxDrift = 0.0001;
>> double local, remote;
>> while(1){
>> try {
>> local = getTime();
>> remote = usrp->get_time_now().get_real_secs();
>> const double delta = std::abs(local - remote - offset);
>> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
>> boost::this_thread::sleep_for(boost::chrono::milliseconds(50
>> ));
>> }catch(uhd::runtime_error &e){
>> }
>> }
>>
>> return 0;
>> }
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/dc66e087/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 15 Nov 2016 21:53:46 +0100
From: Vladica Sark <vladicas...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] XCVR2450 dead alike
Message-ID: <02445d11-d814-2880-ab7e-de39dc73c...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
One of my XCVR2450 is dead alike. The uhd_usrp_probe gives the output
bellow. Any idea if this can be fixed?
BR,
Vladi
_____________________________________________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: a0:36:fa:25:36:73
| | ip-addr: 192.168.10.2
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: E7R16T3UP
| | 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: XCVR2450, XCVR2450 - r2.1 (0x0061)
| | | Serial: F47365
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Unknown (0xffff) - 0
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: 0.000 to 0.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | 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: XCVR2450 - r2.1 (0x0059)
| | | Serial: F47365
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Unknown (0xffff) - 0
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: 0.000 to 0.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9777
| | | | Gain Elements: None
------------------------------
Message: 16
Date: Tue, 15 Nov 2016 16:15:20 -0500
From: mle...@ripnet.com
To: Vladica Sark <vladicas...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] XCVR2450 dead alike
Message-ID: <9793431295821ad7fdfcd32879615...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
Which version of UHD are you using? Is your other XCVR2450 the same
hardware rev?
On 2016-11-15 15:53, Vladica Sark via USRP-users wrote:
> Hi,
>
> One of my XCVR2450 is dead alike. The uhd_usrp_probe gives the output bellow.
> Any idea if this can be fixed?
>
> BR,
> Vladi
>
> _____________________________________________________
> /
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: a0:36:fa:25:36:73
> | | ip-addr: 192.168.10.2
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: E7R16T3UP
> | | 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: XCVR2450, XCVR2450 - r2.1 (0x0061)
> | | | Serial: F47365
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: Unknown (0xffff) - 0
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: 0.000 to 0.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | 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: XCVR2450 - r2.1 (0x0059)
> | | | Serial: F47365
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: Unknown (0xffff) - 0
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: 0.000 to 0.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9777
> | | | | Gain Elements: None
>
> _______________________________________________
> USRP-users mailing list
> 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/20161115/22865ba9/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 15 Nov 2016 16:52:02 -0500
From: Dave NotTelling <dmp250...@gmail.com>
To: Michael West <michael.w...@ettus.com>
Cc: "Marcus D. Leech" <mle...@ripnet.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID:
<cak6gvumzr7up+y82t8+hgqspqvfx1rc+no_nxt2ebn_3fle...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Michael,
I was a bit worried about the latency issue. After some testing I saw
that the time deltas for the calls was something on the order of 80 us
which was low enough to be very usable.
Sadly I do not have the ability to use GPS or NTP. I was hoping to
find something akin to the clocktamer that could output a 1 PPS and 10 MHz
signal for the N210 but not require GPS. Seems like a bit of a tall
order. Even if the 1 PPS or 10 MHz clocks are not super stable, it's still
a common time between the radio and the host which is (as far as I know)
the important bit.
Does anyone know of such a device that does not require GPS?
Thank you all!
On Tue, Nov 15, 2016 at 3:23 PM, Michael West <michael.w...@ettus.com>
wrote:
> 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.
>
> Regards,
> Michael
>
> On Tue, Nov 15, 2016 at 9:30 AM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Set the time on the radio once--from your system time. The USRP will
>> then maintain better time than your computer, typically.
>>
>> Query the time on the USRP when you need to schedule things.
>>
>> But, if you need to have time that is synchronous to the rest of the
>> precise-time "world", then you'll need GPS and/or NTP.
>>
>>
>>
>>
>>
>>
>> On 2016-11-15 12:15, Dave NotTelling wrote:
>>
>> Marcus,
>>
>> I am purposefully not running NTP. I am using just the base N210
>> with the UBX-40. No changes at all to the hardware.
>>
>> I can nudge the radio a little when the offset gets too far out.
>> But that sometimes makes things worse.
>>
>> The one thing that I'm curious about is which clock should I trust
>> as being the most accurate. Plus, I'm still trying to find out if I should
>> trust the system clock of the computer or the hardware clock.
>>
>> Thanks!
>>
>> On Tue, Nov 15, 2016 at 12:09 PM, <mle...@ripnet.com> wrote:
>>
>>> Is your host synched via NTP? Are you using the factory clock on your
>>> USRP or an external source?
>>>
>>> Computer clocks, in general, are not that good, which is why systems
>>> like NTP and GPSD were invented.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2016-11-15 12:04, Dave NotTelling via USRP-users wrote:
>>>
>>> I noticed that over ~ 2 minutes the synchronization between time on the
>>> USRP and my host will drift by about 1-2 milliseconds. I don't have a GPS
>>> source and I would rather not use one. Is there a way to keep the time
>>> sync'ed up between the host and USRP? Anyone know a good way to tell which
>>> is falling behind / getting ahead? I am working under the assumption that
>>> my Linux box will not be as accurate with time as the USRP. Is that
>>> correct?
>>>
>>> Thank you!
>>>
>>>
>>> Here is the code I'm running:
>>>
>>> (build and run with `g++ time.cc -o time -luhd -lboost_system
>>> -lboost_thread && sudo ./time`)
>>>
>>> #include <uhd/usrp/multi_usrp.hpp>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <boost/thread.hpp>
>>> #include <uhd.h>
>>>
>>> double getTime() {
>>> struct timeval start;
>>> gettimeofday(&start, NULL);
>>> return (double) start.tv_sec + ((double) start.tv_usec / 1000000);
>>> }
>>>
>>> int main(){
>>> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(uh
>>> d::device_addr_t("type=usrp2"));
>>> boost::this_thread::sleep_for(boost::chrono::seconds(1));
>>>
>>> const double offset = getTime() - usrp->get_time_now().get_real_
>>> secs();
>>> const double maxDrift = 0.0001;
>>> double local, remote;
>>> while(1){
>>> try {
>>> local = getTime();
>>> remote = usrp->get_time_now().get_real_secs();
>>> const double delta = std::abs(local - remote - offset);
>>> printf("l:%0.6f r:%0.6f d:%0.9f\n", local, remote, delta);
>>> boost::this_thread::sleep_for(boost::chrono::milliseconds(50
>>> ));
>>> }catch(uhd::runtime_error &e){
>>> }
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/e6761e71/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 15 Nov 2016 14:56:38 -0800
From: Tom Tsou <tom.t...@ettus.com>
To: Dave NotTelling <dmp250...@gmail.com>
Cc: "Marcus D. Leech" <mle...@ripnet.com>,
"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 Clock Drift
Message-ID:
<cagniu+cdcvo5rlgr9nhrs4+8vkbnjgdoo+r13_-9giks85p...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Nov 15, 2016 at 9:15 AM, Dave NotTelling via USRP-users
<usrp-users@lists.ettus.com> wrote:
> The one thing that I'm curious about is which clock should I trust as
> being the most accurate. Plus, I'm still trying to find out if I should
> trust the system clock of the computer or the hardware clock.
N210 internal TCXO clock stability is rated at 2.5 ppm. Unless there
is evidence that host side accuracy is greater than that, then the
device should be the more 'trusted' clock source.
Now, If host-device synchronization is the concern, which seems like
the case, then which source is more accurate is not particularly
relevant - drift of two independent clocks is inevitable.
If physical synchronization through 10 MHz and PPS is not an option,
then the host can synchronize indirectly through timestamps on a
receive stream - 'clock indications' in cellular terminology. In other
words, you setup a low bandwidth receive stream to deliver timestamped
samples to the host. The timestamps are used to update a virtual host
clock and drive the transmit chain. Actual samples received from the
device are discarded. That will allow submission of transmit bursts to
be synchronized to the device regardless of local host side clocking.
-TT
------------------------------
Message: 19
Date: Tue, 15 Nov 2016 16:47:49 -0800
From: Martin Braun <martin.br...@ettus.com>
To: Crozzoli Maurizio <maurizio.crozz...@telecomitalia.it>
Cc: Disco Daniele <daniele.di...@telecomitalia.it>,
"'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] How can I be sure I am not losing even one
sample in a stream?
Message-ID: <7fa98254-c7f8-7a2d-5518-374dbc26c...@ettus.com>
Content-Type: text/plain; charset=utf-8
Your rx_metadata_t object will have appropriate flag asserted. See here:
http://files.ettus.com/manual/structuhd_1_1rx__metadata__t.html#ae3a42ad2414c4f44119157693fe27639
Note that both share an error code for legacy reasons.
If you're watching the screen, you will see either "D" or "O" messages.
Cheers,
Martin
On 11/15/2016 04:33 PM, Crozzoli Maurizio wrote:
> Martin,
> I know it's obvious for you bu how can I tell I "don't get overruns or
> sequence errors (dropped packets)"?
>
> TIA!
>
> BR,
> Maurizio and Daniele.
>
>
> If you don't get overruns or sequence errors (dropped packets), you are
> not losing samples.
>
> Cheers,
> Martin
>
> On 11/15/2016 08:35 AM, Crozzoli Maurizio via USRP-users wrote:
>> Hi!
>>
>> It is all written in the subject but few more details are given below.
>>
>> 1. We are afraid it might be a sort of a FAQ: if so, please excuse us
> and suggest us a pointer to start with.
>> 2. We are using an E310 to collect samples (temporarily in a buffer,
> of course) and then save them to file. We are using a modified version
> of the sample code provided by Ettus "rx_multi_samples.cpp
> <http://samples.cpp>" where the core operation is
> "rx_stram->recv(buffer, samps_per_buffer, md, timeout);".
>> 3. Then the question in the subject follows.
>>
>> TIA to whoever wants to help us.
>>
>> BR,
>> Daniele and Maurizio.
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised.
> If you are not the intended recipient, please delete this message and
> any attachments and advise the sender by return e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non
> ? necessario.*
>
------------------------------
Message: 20
Date: Tue, 15 Nov 2016 20:37:09 -0500
From: Rob Kossler <rkoss...@nd.edu>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] X310/UBX RX streaming startup transients
Message-ID:
<cab__httv_ttg7fj8ghy+x6dzg3lmcksjbdayh9hnwvf05rb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I recently used several X310s in an OTA multichannel radar measurement.
For this measurement, the TX signal was a 100usec long chirp that was
repeated throughout the RX data capture which lasted 10 seconds. My
question involves the very long (IMO) startup transients that I notice in
my captured signals, the longest of which is 264 msecs. I am wondering
what is causing this behavior.
The attached figure (x310_startup.png) illustrates the issue. This figure
shows the RX power level (averaged over 100 usec blocks) throughout the
capture. There were 4 RX channels at 2.4GHz using UBX daughterboards and 4
RX channels at 5.8 GHz using TwinRX daughterboards. The four UBX channels
(red, blue, yellow purple) all show discrete jumps in power level.
- For channel 0 (blue), jumps occur at 47 and 180 msec
- For channel 1 (red), jumps occur at 62 and 91 msec
- For channel 2 (yellow), jumps occur at 41 and 264 msec
- For channel 3 (purple), there is a single jump at 0.4 msec
Note that the other 4 channels shown in the figure (representing the 5.8
GHz captures using the TwinRx daughterboards) show no such transients.
Also, note that if you look at the other attached figure
(x310_startup_10s.png) which is the exact same data set but simply
displayed for a longer duration, you will see that the power level remains
stable after the previously mentioned startup transients.
I could go into more details of my specific setup if needed, but at a high
level this measurement involved two synchronized 2x4 measurements, one at
2.4GHz and the other at 5.8GHz. All Tx and Rx channels for this
measurement were synchronized by PPS such that all streaming would begin at
a specified start time. I believe that the transients are related to RX
rather than TX because there were only 2 TX signals at 2.4GHz but yet the
transients shown in the RX data occur at independent times on the 4 RX
channels.
A couple more noteworthy items...
- The UBX Rx channels (and incidentally, all of the TX channels) were
operated using 003.009.005-34-g7a7308cc. The TwinRx Rx channels were
operated using a very recent 3.10 version (I would need to check which
one). The application software was my own custom C++ based on Ettus
examples.
- I looked back at previous posts and noticed similar startup issues
related to Tx and "powersave" options. I have not changed this option from
the default which I believe is performance mode.
- Also, I noticed previous posts indicating that bugs were fixed at some
point which appears to have been prior to the 3.9.5 release that I used.
So, as far as I know, there were no fixes of this type after this release.
If this is incorrect, please let me know.
- The TX and RX channels in my 2x4 measurement systems are from
independent X310s. That is, the 2 TX channels come from one X310 while the
four RX channels come from two additional X310s.
- The TX and RX streaming rates were all 100 MS/s for all channels.
There were no underruns/overflows or other error indications.
Thanks for considering this very long email.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/f7ef2ae3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x310_startup.png
Type: image/png
Size: 41501 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/f7ef2ae3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x310_startup_10s.png
Type: image/png
Size: 38654 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161115/f7ef2ae3/attachment-0003.png>
------------------------------
Message: 21
Date: Wed, 16 Nov 2016 10:35:54 +0800
From: john liu <johncorad1...@gmail.com>
To: Sugandha Gupta <sugandha.gu...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC XML
Message-ID:
<CAF6NnTJaSw69VLrs8N3YmshMjo5ciPccBaw2=zhwfgyankp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I follow the https://kb.ettus.com/Getting_Started_with_RFNoC_Development
method,
and successful installation of my rfnoc module.Then run uhd_usrp_probe:
> > -- * 0/Radio_0
> > -- * 0/Radio_1
> > -- * 0/AddSub_0
> > -- * 0/FIR_0
> > -- * 0/FFT_0
> > -- * 0/Window_0
> > -- * 0/NullSrcSink_0
> > -- * 0/LogPwr_0
> > -- * 0/MovingAverage_0
> > -- * 0/VectorIIR_0
> > -- * 0/KeepOneInN_0
> > -- * 0/CtrlDac_0
> > -- * 0/FIFO_0
the ctrlDac is my rfnoc module.
then next steps:
sudo rfnocmodtool newmod test
cd rfnoc-test
sudo rfnocmodtool add CtrlDac
//========================= log ==========================
huofeng@huofeng:~/Usrp/rfnoc-test$ sudo rfnocmodtool add CtrlDac
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_004.000.000.rfnoc-641-g8773fb2c
RFNoC module name identified: test
Block/code identifier: CtrlDac
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n] n
Add C++ QA code? [Y/n] n
Block NoC ID (Hexadecimal): CDAC
Skip Block Controllers Generation? [UHD block ctrl files] [y/N] y
Skip Block interface files Generation? [GRC block ctrl files] [y/N] y
Editing swig/test_swig.i...
Adding file 'grc/test_CtrlDac.xml'...
Adding file 'rfnoc/blocks/CtrlDac.xml'...
Adding file 'rfnoc/fpga-src/noc_block_CtrlDac.v'...
rfnoc/testbenches/noc_block_CtrlDac_tb folder created
Adding file
'rfnoc/testbenches/noc_block_CtrlDac_tb/noc_block_CtrlDac_tb.sv'...
Adding file 'rfnoc/testbenches/noc_block_CtrlDac_tb/Makefile'...
Adding file 'rfnoc/testbenches/noc_block_CtrlDac_tb/CMakeLists.txt'...
//===================== end =============================
sudo mkdir build
sudo cmake ../
sudo make
sudo make install
and in the gnuradio-companion can also appear my module. But there is a
problem when I run the program, the program is wrong, the information is as
follows:
Traceback (most recent call last):
File "/home/huofeng/Usrp/block_test/ctrlDac_test/ctrlDac_test.py", line
122, in <module>
main()
File "/home/huofeng/Usrp/block_test/ctrlDac_test/ctrlDac_test.py", line
110, in main
tb = top_block_cls()
File "/home/huofeng/Usrp/block_test/ctrlDac_test/ctrlDac_test.py", line
65, in __init__
self.test_CtrlDac_0 = test.CtrlDac(
AttributeError: 'module' object has no attribute 'CtrlDac'
Need i to do some other steps?
thank you for your help.
best regards
Jong
On Mon, Nov 14, 2016 at 8:57 AM, john liu <johncorad1...@gmail.com> wrote:
> thank you so much.I will read these example.
>
> On Sat, Nov 12, 2016 at 1:49 AM, Sugandha Gupta <sugandha.gu...@ettus.com>
> wrote:
>
>> Hey John
>>
>> 'check' is to make sure that no illegal values are written in the GRC.
>> Here in your example, in noc_block_fft, SPP ($spp) must be Greater than
>> or Equal (GE) to 16 and Less than or Equal (LE) to 4096.
>> <check_message> is the error message that will be displayed if the above
>> check fails.
>> No, it is not compulsory to add <check> to your xml.
>>
>> <action> is the actual register write into the settings reg in the
>> design. So FFT_SIZE_LOG2 is a register in noc_block_fft and will be
>> programmed to a value LOG2($spp) along with the register AXIS_CONFIG_BUS.
>> So you can program your registers in your rfnoc block using this.
>>
>> All the xml files in the same directory can be used as examples.
>>
>> Hope that helps.
>>
>> Thanks
>>
>>
>> On Fri, Nov 11, 2016 at 1:38 AM, john liu via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dear all,
>>> When we wrote a RFNoC block,we must describe it in XML file.We found the
>>> RFNoC xml file in /uhd/host/include/uhd/rfnoc/blocks.But we are not
>>> quite understand the like as below:
>>> <check>GE($spp, 16) AND LE($spp, 4096) AND
>>> IS_PWR_OF_2($spp)</check>
>>> <check_message>FFT size must be in [16, 4096] and a power of
>>> two.</check_message>
>>> <action>SR_WRITE("FFT_SIZE_LOG2", LOG2($spp)) AND
>>> SR_WRITE("AXIS_CONFIG_BUS", ADD(873472, LOG2($spp)))</action>
>>>
>>> we also must write this?what is function of check<> and action<>?There
>>> are some examples of what we can refer to?
>>> thank you ?
>>>
>>> best regards
>>> John
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> Sugandha Gupta
>> Staff Software Engineer
>> Ettus Research
>>
>
>
On Mon, Nov 14, 2016 at 8:57 AM, john liu <johncorad1...@gmail.com> wrote:
> thank you so much.I will read these example.
>
> On Sat, Nov 12, 2016 at 1:49 AM, Sugandha Gupta <sugandha.gu...@ettus.com>
> wrote:
>
>> Hey John
>>
>> 'check' is to make sure that no illegal values are written in the GRC.
>> Here in your example, in noc_block_fft, SPP ($spp) must be Greater than
>> or Equal (GE) to 16 and Less than or Equal (LE) to 4096.
>> <check_message> is the error message that will be displayed if the above
>> check fails.
>> No, it is not compulsory to add <check> to your xml.
>>
>> <action> is the actual register write into the settings reg in the
>> design. So FFT_SIZE_LOG2 is a register in noc_block_fft and will be
>> programmed to a value LOG2($spp) along with the register AXIS_CONFIG_BUS.
>> So you can program your registers in your rfnoc block using this.
>>
>> All the xml files in the same directory can be used as examples.
>>
>> Hope that helps.
>>
>> Thanks
>>
>>
>> On Fri, Nov 11, 2016 at 1:38 AM, john liu via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dear all,
>>> When we wrote a RFNoC block,we must describe it in XML file.We found the
>>> RFNoC xml file in /uhd/host/include/uhd/rfnoc/blocks.But we are not
>>> quite understand the like as below:
>>> <check>GE($spp, 16) AND LE($spp, 4096) AND
>>> IS_PWR_OF_2($spp)</check>
>>> <check_message>FFT size must be in [16, 4096] and a power of
>>> two.</check_message>
>>> <action>SR_WRITE("FFT_SIZE_LOG2", LOG2($spp)) AND
>>> SR_WRITE("AXIS_CONFIG_BUS", ADD(873472, LOG2($spp)))</action>
>>>
>>> we also must write this?what is function of check<> and action<>?There
>>> are some examples of what we can refer to?
>>> thank you ?
>>>
>>> best regards
>>> John
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> Sugandha Gupta
>> Staff Software Engineer
>> Ettus Research
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/be4dc783/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 15 Nov 2016 19:39:48 -0800
From: Michael West <michael.w...@ettus.com>
To: Rob Kossler <rkoss...@nd.edu>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310/UBX RX streaming startup transients
Message-ID:
<cam4xkrpcnk5rzfe3hwxvesz64ks53vauexkkzdpup1gh4z7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
To test if it is TX or RX, transmit a constant tone that starts well (i.e.
1 sec) before the RX and see if you still see the transients in the capture.
This may be warm up time for the LNA. There are 2 LNAs on the UBX and the
split is at 1.5 GHz. The UBX tunes to 10 MHz during initialization, so the
low band LNA is powered up. After tuning to the high band, it may take
some time for the other LNA to warm up. If that is the case, any
subsequent captures should reach full power right away.
Regards,
Michael
On Tue, Nov 15, 2016 at 5:37 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I recently used several X310s in an OTA multichannel radar measurement.
> For this measurement, the TX signal was a 100usec long chirp that was
> repeated throughout the RX data capture which lasted 10 seconds. My
> question involves the very long (IMO) startup transients that I notice in
> my captured signals, the longest of which is 264 msecs. I am wondering
> what is causing this behavior.
>
> The attached figure (x310_startup.png) illustrates the issue. This figure
> shows the RX power level (averaged over 100 usec blocks) throughout the
> capture. There were 4 RX channels at 2.4GHz using UBX daughterboards and 4
> RX channels at 5.8 GHz using TwinRX daughterboards. The four UBX channels
> (red, blue, yellow purple) all show discrete jumps in power level.
>
> - For channel 0 (blue), jumps occur at 47 and 180 msec
> - For channel 1 (red), jumps occur at 62 and 91 msec
> - For channel 2 (yellow), jumps occur at 41 and 264 msec
> - For channel 3 (purple), there is a single jump at 0.4 msec
>
> Note that the other 4 channels shown in the figure (representing the 5.8
> GHz captures using the TwinRx daughterboards) show no such transients.
> Also, note that if you look at the other attached figure
> (x310_startup_10s.png) which is the exact same data set but simply
> displayed for a longer duration, you will see that the power level remains
> stable after the previously mentioned startup transients.
>
> I could go into more details of my specific setup if needed, but at a high
> level this measurement involved two synchronized 2x4 measurements, one at
> 2.4GHz and the other at 5.8GHz. All Tx and Rx channels for this
> measurement were synchronized by PPS such that all streaming would begin at
> a specified start time. I believe that the transients are related to RX
> rather than TX because there were only 2 TX signals at 2.4GHz but yet the
> transients shown in the RX data occur at independent times on the 4 RX
> channels.
>
> A couple more noteworthy items...
>
> - The UBX Rx channels (and incidentally, all of the TX channels) were
> operated using 003.009.005-34-g7a7308cc. The TwinRx Rx channels were
> operated using a very recent 3.10 version (I would need to check which
> one). The application software was my own custom C++ based on Ettus
> examples.
> - I looked back at previous posts and noticed similar startup issues
> related to Tx and "powersave" options. I have not changed this option from
> the default which I believe is performance mode.
> - Also, I noticed previous posts indicating that bugs were fixed at
> some point which appears to have been prior to the 3.9.5 release that I
> used. So, as far as I know, there were no fixes of this type after this
> release. If this is incorrect, please let me know.
> - The TX and RX channels in my 2x4 measurement systems are from
> independent X310s. That is, the 2 TX channels come from one X310 while the
> four RX channels come from two additional X310s.
> - The TX and RX streaming rates were all 100 MS/s for all channels.
> There were no underruns/overflows or other error indications.
>
> Thanks for considering this very long email.
> Rob
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20161115/dc0381ee/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 16 Nov 2016 08:37:35 +0100
From: Vladica Sark <vladicas...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] XCVR2450 dead alike
Message-ID: <3e0ccaa2-ac54-3702-b5b2-301fcc618...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
UHD_003.011.000.git-78-gf70dd85d
The both boards are rev 2.0. The broken one does not have the U14, but
just a bridge wire.
BR,
Vladica
On 15.11.2016 22:15, mle...@ripnet.com wrote:
> Which version of UHD are you using? Is your other XCVR2450 the same
> hardware rev?
>
>
>
>
>
>
>
> On 2016-11-15 15:53, Vladica Sark via USRP-users wrote:
>
>> Hi,
>>
>> One of my XCVR2450 is dead alike. The uhd_usrp_probe gives the output
>> bellow. Any idea if this can be fixed?
>>
>>
>> BR,
>> Vladi
>>
>> _____________________________________________________
>> /
>> | Device: USRP2 / N-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: N210r4
>> | | hardware: 2577
>> | | mac-addr: a0:36:fa:25:36:73
>> | | ip-addr: 192.168.10.2
>> | | subnet: 255.255.255.255
>> | | gateway: 255.255.255.255
>> | | gpsdo: none
>> | | serial: E7R16T3UP
>> | | 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: XCVR2450, XCVR2450 - r2.1 (0x0061)
>> | | | Serial: F47365
>> | | | _____________________________________________________
>> | | | /
>> | | | | RX Frontend: 0
>> | | | | Name: Unknown (0xffff) - 0
>> | | | | Antennas:
>> | | | | Sensors:
>> | | | | Freq range: 0.000 to 0.000 MHz
>> | | | | Gain Elements: None
>> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | 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: XCVR2450 - r2.1 (0x0059)
>> | | | Serial: F47365
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Frontend: 0
>> | | | | Name: Unknown (0xffff) - 0
>> | | | | Antennas:
>> | | | | Sensors:
>> | | | | Freq range: 0.000 to 0.000 MHz
>> | | | | Gain Elements: None
>> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>> | | | | Connection Type: IQ
>> | | | | Uses LO offset: No
>> | | | _____________________________________________________
>> | | | /
>> | | | | TX Codec: A
>> | | | | Name: ad9777
>> | | | | Gain Elements: None
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 24
Date: Wed, 16 Nov 2016 09:17:29 +0100
From: Philipp Rudnik <rup2pr...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Bricked X310
Message-ID:
<CADk_VqFKuiFASNZFSr7hTV6ghTs4w=ssO58GffBN26O2YrTQ=g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus!
That was quite easy, thanks a lot!
Regards,
Philipp
2016-11-14 12:43 GMT+01:00 Marcus M?ller via USRP-users <
usrp-users@lists.ettus.com>:
> Hi Philipp,
>
> sorry to hear you've got trouble!
>
> So, we generally recommend impact because it's less Gigabytes to
> install... but in this case:
>
> 1. Get the free Vivado 2015.4 version.
> 2. install it, by default it ends up in /opt/Xilinx
> 3. sudo /opt/Xilinx/Vivado/2015.4/data/xicom/cable_drivers/
> lin64/install_script/install_drivers/install_digilent.sh
> 4. sudo udevadm control --reload ## To reload the new udev rules that
> tell your linux system to make the JTAG adapter available to normal users
> 5. run Vivado, go to hardware manager, connect your X310 and power it
> up
> 6. Tools->Autoconnect
> 7. Right-click on the FPGA in the hardware "list", program device,
> select the appropriate .bit from UHD (typically:
> /usr/share/uhd/images/usrp_
> x310_fpga_HG.bit)
>
> Hope that helps! Notice that we also have a script so you don't have to
> actually start Vivado in graphical mode, but you'd have to checkout UHD's
> FPGA source code and set up a few paths for that to work (and still would
> have to download & install Vivado), so I don't think that would be overly
> much of a simplification for you. In any case, especially if future readers
> wonder: Instead of doing step 5ff above, you'd "source
> /path/to/uhd/fpga-src/usrp3_rfnoc/top/x300/setupenv.sh" and run
> "viv_jtag_program x300_image_file.bit".
>
> Best regards,
>
> Marcus
> On 14.11.2016 08:46, Philipp Rudnik via USRP-users wrote:
>
> Hi!
>
> I have a bricked X310, caused by loss of connection during the FPGA image
> update. I got the iMPACT tool from xilinx and the fpga jtag programmer
> script (UHD tools). I tried connecting it via the JTAG-USB connector to my
> PC and ran:
> sudo -s.....
> root@sputnik-Schleppi:~/Downloads$ ./usrp_x3xx_fpga_jtag_programmer.sh
> --impact-path=/home/sputnik/xilinx/14.3/LabTools/LabTools/bin/lin64/impact
> --fpga-path=/usr/share/uhd/images/usrp_x310_fpga_HGS.bit
>
> The Output is: (please apologize any german language)
> =======================================
> Copyright 2014 Ettus Research LLC
>
> JTAG Programming Tool
> =======================================
>
> ==== Generating impact batch file xR4WcYhm.impact.cmd...
> ==== Running impact -- loading /usr/share/uhd/images/usrp_x310_fpga_HGS.bit
> into the FPGA...
> WARNING: de_DE is not supported as a language. Using usenglish.
> Release 14.3 - iMPACT P.40xd (lin64)
> Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
> Preference Table
> Name Setting
> StartupClock Auto_Correction
> AutoSignature False
> KeepSVF False
> ConcurrentMode False
> UseHighz False
> ConfigOnFailure Stop
> UserLevel Novice
> MessageLevel Detailed
> svfUseTime false
> SpiByteSwap Auto_Correction
> AutoInfer false
> SvfPlayDisplayComments false
> AutoDetecting cable. Please wait.
> *** WARNING ***: When port is set to auto detect mode, cable speed is set
> to
> default 6 MHz regardless of explicit arguments supplied for setting the
> baud
> rates
> If you are using the Platform Cable USB, please refer to the USB Cable
> Installation Guide (UG344) to install the libusb package.
> Connecting to cable (Usb Port - USB21).
> Checking cable driver.
> Linux release = 4.4.0-45-generic.
> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable
> drivers. See Answer Record 22648.
> Cable connection failed.
> INFO:Cse - The fxload application is not installed. This application is
> required
> when using the Platform Cable USB. This warning should be ignored if
> you are
> using the Parallel Cable III or Parallel Cable IV. Please download and
> install the fxload-2002_04_11 package. Note that root access is
> required to
> perform the installation.
> Connecting to cable (Parallel Port - parport0).
> Linux release = 4.4.0-45-generic.
> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable
> drivers. See Answer Record 22648.
> Cable connection failed.
> Connecting to cable (Parallel Port - parport1).
> Linux release = 4.4.0-45-generic.
> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable
> drivers. See Answer Record 22648.
> Cable connection failed.
> Connecting to cable (Parallel Port - parport2).
> Linux release = 4.4.0-45-generic.
> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable
> drivers. See Answer Record 22648.
> Cable connection failed.
> Connecting to cable (Parallel Port - parport3).
> Linux release = 4.4.0-45-generic.
> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable
> drivers. See Answer Record 22648.
> Cable connection failed.
> Cable autodetection failed.
> ERROR: Programming failed. Check output above for hints. Maybe you forgot
> to use sudo?
>
>
> I followed the instructions by xilinx AR and ran:
> root@sputnik-Schleppi:/opt/install_script/install_drivers#
> ./install_drivers
>
> which gave me the following output:
>
> --Install log = ./install_drivers
> --Installing cable drivers.
> --Driver versions in this package: windrvr=1301, xpc4drvr=1041
> --Script name = ./install_drivers
> --HostName = sputnik-Schleppi
> --Current working dir = /opt/install_script/install_drivers
> --Script location = /opt/install_script/install_drivers
> --No script argument.
> --Kernel version = 4.4.0-45-generic.
> --Arch = x86_64.
> --Installer version = 1100
> --Unsetting ARCH environment variable.
> --User has root permission.
> --File /lib/modules/misc/install_windrvr6 does not exist.
> --Installing USB drivers------------------------------------------
> --File /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 0000.
> --Updating xusbdfwu.hex file.
> --File /etc/hotplug/usb/xusbdfwu.fw/xusb_xlp.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusb_xlp.hex = 0000.
> --Updating xusb_xlp.hex file.
> --File /etc/hotplug/usb/xusbdfwu.fw/xusb_emb.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusb_emb.hex = 0000.
> --Updating xusb_emb.hex file.
> --File /etc/hotplug/usb/xusbdfwu.fw/xusb_xpr.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusb_xpr.hex = 0000.
> --Updating xusb_xpr.hex file.
> --File /etc/hotplug/usb/xusbdfwu.fw/xusb_xup.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusb_xup.hex = 0000.
> --Updating xusb_xup.hex file.
> --File /etc/hotplug/usb/xusbdfwu.fw/xusb_xp2.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusb_xp2.hex = 0000.
> --Updating xusb_xp2.hex file.
> --File /etc/hotplug/usb/xusbdfwu.fw/xusb_xse.hex does not exist.
> --File version of /etc/hotplug/usb/xusbdfwu.fw/xusb_xse.hex = 0000.
> --Updating xusb_xse.hex file.
> cat: /etc/hotplug/usb.usermap: Datei oder Verzeichnis nicht gefunden
> --Adding Product ID 0007 to the usermap.
> --Adding Product ID 0009 to the usermap.
> --Adding Product ID 000d to the usermap.
> --Adding Product ID 000f to the usermap.
> --Adding Product ID 0013 to the usermap.
> --Adding Product ID 0015 to the usermap.
> --Adding Product ID 0008 to the usermap.
> --Installing windrvr6---------------------------------------------
> --Checking version.
> --File /lib/modules/4.4.0-45-generic/kernel/drivers/misc/windrvr6.ko does
> not exist.
> --File LINUX.4.4.0-45-generic.x86_64/windrvr6.ko does not exist.
> --Setting source version to 1301.
> --File LINUX.4.4.0-45-generic.x86_64/windrvr6.ko is newer than the
> destination file.
> USE_KBUILD = no
> hello.c:1:26: fatal error: linux/config.h: Datei oder Verzeichnis nicht
> gefunden
> compilation terminated.
> checking for cpu architecture... x86_64
> checking for WinDriver root directory... /opt/install_script/install_
> drivers/linux_drivers/windriver64
> checking for linux kernel source... found at /lib/modules/4.4.0-45-generic/
> build
> not found
> configure.wd: error: please install the kernel source or specify alternate
> location
> make -f makefile.wd clean
> make[1]: Verzeichnis
> ?/opt/install_script/install_drivers/linux_drivers/windriver64/windrvr?
> wird betreten
> make[1]: makefile.wd: Datei oder Verzeichnis nicht gefunden
> make[1]: *** Keine Regel, um ?makefile.wd? zu erstellen. Schluss.
> make[1]: Verzeichnis
> ?/opt/install_script/install_drivers/linux_drivers/windriver64/windrvr?
> wird verlassen
> makefile:28: die Regel f?r Ziel ?clean? scheiterte
> make: *** [clean] Fehler 2
> make -f makefile.wd
> make[1]: Verzeichnis
> ?/opt/install_script/install_drivers/linux_drivers/windriver64/windrvr?
> wird betreten
> make[1]: makefile.wd: Datei oder Verzeichnis nicht gefunden
> make[1]: *** Keine Regel, um ?makefile.wd? zu erstellen. Schluss.
> make[1]: Verzeichnis
> ?/opt/install_script/install_drivers/linux_drivers/windriver64/windrvr?
> wird verlassen
> makefile:21: die Regel f?r Ziel ?all? scheiterte
> make: *** [all] Fehler 2
> make -f makefile.wd
> make[1]: Verzeichnis
> ?/opt/install_script/install_drivers/linux_drivers/windriver64/windrvr?
> wird betreten
> make[1]: makefile.wd: Datei oder Verzeichnis nicht gefunden
> make[1]: *** Keine Regel, um ?makefile.wd? zu erstellen. Schluss.
> make[1]: Verzeichnis
> ?/opt/install_script/install_drivers/linux_drivers/windriver64/windrvr?
> wird verlassen
> makefile:21: die Regel f?r Ziel ?all? scheiterte
> make: *** [all] Fehler 2
> --make windrvr install rc= 2
> --install_windrvr6 rc = 2
> --Module windrvr6 is not running.
> --Module xpc4drvr is not running.
> --Note: By default, the file permission of /dev/windrvr6 is enabled for
> the root user only
> and must be changed to allow access to other users.
>
> --real rc=2
>
> --Driver installation failed.
>
> --Digilent Return code = 0
> --Xilinx Return code = 1
> --Return code = 1
>
> I also tried some code fixes, shown in this forum, which helped with the
> xpc4drvr, but not with the windrvr6: https://forums.xilinx.com/t5/
> Installation-and-Licensing/ISE14-3-device-driver-intall-
> failed-on-Ubuntu-12-04/td-p/272544
>
> I hope somebody can help me out with that problem,
>
> Thanks,
> - Philipp
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/0f8e6858/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 16 Nov 2016 17:21:56 +0800
From: liu Jong <jongliu1...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] RFA or RFB
Message-ID:
<CAEui2n3BKNCmO8=c=Ojsqu-THqy=vd8x5g-q2c7m1hxokn3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
We found that USRP B200 contains two types,.one of the previous is the SMA
interface in RFA, and the later one is in RFB. So from now on,the SMA
interface will be always in RFB?
best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/7c272e06/attachment-0001.html>
------------------------------
Message: 26
Date: Wed, 16 Nov 2016 12:59:06 +0300
From: ?????? 1 <andrew4...@rambler.ru>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] B210 C-API dual channel
Message-ID: <1479290346.171156.1272.47...@mail.rambler.ru>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi
Sory accidentally erased.
That full text.
int main(int argc, char* argv[])
{
int option = 0;
double freq = 500e6;
double freqR = 500e6;
double rate = 1e6;
double gain = 5.0;
char* device_args = "";
size_t channel;
char* filename = "out.dat";
size_t n_samples = 1000;//000;
bool verbose = false;
int return_code = EXIT_SUCCESS;
bool custom_filename = false;
char error_string[512];
uhd_usrp_handle usrp;
uhd_rx_streamer_handle rx_streamer;
uhd_rx_metadata_handle md;
uhd_tune_request_t tune_request;
uhd_tune_result_t tune_result;
uhd_stream_args_t stream_args;
uhd_stream_cmd_t stream_cmd;
uhd_rx_metadata_error_code_t error_code;
size_t samps_per_buff;
void **buffs_ptr = NULL;
FILE *fp = NULL;
size_t num_acc_samps = 0;
size_t i;
UHD_API uhd_error Status;
size_t mboard=0;
uhd_subdev_spec_handle subdev=NULL;
uhd_subdev_spec_pair_t subdev1={"A","A:A A:B"};
uhd_subdev_spec_pair_t subdev2={"A","A:A A:B"};
char markup[256]={0,0,0};
time_t full_secs=1;
double frac_secs=0.5;
size_t count_channel=2; //!!!
size_t channel_list[2];
float *buff = NULL;
float *buff1= NULL;
float *buffers[2];
memset((void*)&tune_request,0,sizeof(tune_request));
channel_list[0]=0;
channel_list[1]=1;
if(uhd_set_thread_priority(uhd_default_thread_priority, true)){
fprintf(stderr, "Unable to set thread priority. Continuing anyway.\n");
}
// Create USRP
fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
if(uhd_usrp_make(&usrp, device_args)!=UHD_ERROR_NONE)
goto free_option_strings;
if(subdev==NULL)
Status=uhd_subdev_spec_make(&subdev, markup );
if(subdev)
{
//! Get the RX frontend specification for the given device
Status=uhd_usrp_get_rx_subdev_spec(usrp, mboard, subdev);
//! Check how many subdevice specifications are in this list
Status=uhd_subdev_spec_size(subdev,&i);
if(i>=2)
{
//! Get a string representation of the given list
Status=uhd_subdev_spec_to_pp_string(subdev, markup, sizeof(markup) );
//! Get the subdevice specification at the given index
Status=uhd_subdev_spec_at(subdev,0,&subdev1);
Status=uhd_subdev_spec_at(subdev,1,&subdev2);
}
else Status=uhd_subdev_spec_push_back(subdev,"A:A A:B");
//! Map the given device's RX frontend to a channel
Status=uhd_usrp_set_rx_subdev_spec(usrp, (uhd_subdev_spec_handle)subdev,
mboard);
//! Get a string representation of the given list
Status=uhd_subdev_spec_to_pp_string(subdev, markup, sizeof(markup) );
fprintf(stderr, "Setting subdev: %s...\n", markup);
}
// Create RX streamer
if(uhd_rx_streamer_make(&rx_streamer)!=UHD_ERROR_NONE)
goto free_usrp;
// Create RX metadata
if(uhd_rx_metadata_make(&md)!=UHD_ERROR_NONE)
goto free_rx_streamer;
// Create other necessary structs
tune_request.target_freq = freq;
tune_request.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
tune_request.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
for(channel=0;channel<count_channel;channel++)
{
fprintf(stderr, " Setting Channel%d\n",channel);
// Set rate
fprintf(stderr, "Setting RX Rate: %f...\n", rate);
if(uhd_usrp_set_rx_rate(usrp, rate, channel)!=UHD_ERROR_NONE)
goto free_rx_metadata;
// See what rate actually is
if(uhd_usrp_get_rx_rate(usrp, channel, &rate)!=UHD_ERROR_NONE)
goto free_rx_metadata;
fprintf(stderr, "Actual RX Rate: %f...\n", rate);
// Set gain
fprintf(stderr, "Setting RX Gain: %f dB...\n", gain);
if(uhd_usrp_set_rx_gain(usrp, gain, channel, "")!=UHD_ERROR_NONE)
goto free_rx_metadata;
// See what gain actually is
if(uhd_usrp_get_rx_gain(usrp, channel, "", &gain)!=UHD_ERROR_NONE)
goto free_rx_metadata;
fprintf(stderr, "Actual RX Gain: %f...\n", gain);
// Set frequency
fprintf(stderr, "Setting RX frequency: %f MHz...\n", freq/1e6);
if(uhd_usrp_set_rx_freq(usrp, &tune_request, channel,
&tune_result)!=UHD_ERROR_NONE)
goto free_rx_metadata;
// See what frequency actually is
if(uhd_usrp_get_rx_freq(usrp, channel, &freqR)!=UHD_ERROR_NONE)
goto free_rx_metadata;
fprintf(stderr, "Actual RX frequency: %f MHz...\n", freqR / 1e6);
}
// Set up streamer
stream_args.cpu_format = "fc32";
stream_args.otw_format = "sc16";
stream_args.args = "";
stream_args.channel_list = &channel_list[0];
stream_args.n_channels = count_channel;
if(uhd_usrp_get_rx_stream(usrp, &stream_args, rx_streamer)!=UHD_ERROR_NONE)
goto free_rx_streamer;
// Set up buffer
if(uhd_rx_streamer_max_num_samps(rx_streamer, &samps_per_buff)!=UHD_ERROR_NONE)
goto free_rx_streamer;
fprintf(stderr, "Buffer size in samples: %zu\n", samps_per_buff);
buff = malloc(samps_per_buff * 2 * sizeof(float));
buff1 = malloc(samps_per_buff * 2 * sizeof(float));
buffers[0]=buff;
buffers[1]=buff1;
buffs_ptr = (void**)buffers;
stream_cmd.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE;
stream_cmd.num_samps = n_samples;
stream_cmd.stream_now =true;
//stream_cmd.stream_now =false; //With multiple devices false;
stream_cmd.time_spec_full_secs=full_secs; //time_t //! If not now, then full
seconds into future to stream
stream_cmd.time_spec_frac_secs=frac_secs; //timeout; //! If not now, then
fractional seconds into future to stream
Status=uhd_usrp_set_time_now(usrp,full_secs, frac_secs, 0); // Status=10 ???
// Issue stream command
fprintf(stderr, "Issuing stream command.\n");
if(uhd_rx_streamer_issue_stream_cmd(rx_streamer, &stream_cmd)!=UHD_ERROR_NONE)
goto free_buffer;
// Set up file output
fp = fopen(filename, "wb");
// Actual streaming
while (num_acc_samps < n_samples) {
size_t num_rx_samps = 0;
if(uhd_rx_streamer_recv(rx_streamer, buffs_ptr, samps_per_buff, &md, 3.0, false,
&num_rx_samps)!=UHD_ERROR_NONE)
goto close_file;
if(uhd_rx_metadata_error_code(md, &error_code)!=UHD_ERROR_NONE)
goto close_file;
if(error_code != UHD_RX_METADATA_ERROR_CODE_NONE){
fprintf(stderr, "Error code 0x%x was returned during streaming. Aborting.\n",
error_code);//return_code);
goto close_file;
}
// Handle data
fwrite(buff, sizeof(float) * 2, num_rx_samps, fp);
fwrite(buff1, sizeof(float) * 2, num_rx_samps, fp);
if (verbose) {
time_t full_secs;
double frac_secs;
uhd_rx_metadata_time_spec(md, &full_secs, &frac_secs);
fprintf(stderr, "Received packet: %zu samples, %zu full secs, %f frac secs\n",
num_rx_samps,
full_secs,
frac_secs);
}
num_acc_samps += num_rx_samps;
}
// Cleanup
close_file:
fclose(fp);
free_buffer:
if(buff){
if(verbose){
fprintf(stderr, "Freeing buffer_0.\n");
}
free(buff);
}
buff = NULL;
if(buff1){
if(verbose){
fprintf(stderr, "Freeing buffer_1.\n");
}
free(buff1);
}
buff1 = NULL;
buffs_ptr = NULL;
free_rx_streamer:
if(verbose){
fprintf(stderr, "Cleaning up RX streamer.\n");
}
uhd_rx_streamer_free(&rx_streamer);
free_rx_metadata:
if(verbose){
fprintf(stderr, "Cleaning up RX metadata.\n");
}
uhd_rx_metadata_free(&md);
free_usrp:
if(verbose){
fprintf(stderr, "Cleaning up USRP.\n");
}
if(return_code != EXIT_SUCCESS && usrp != NULL){
uhd_usrp_last_error(usrp, error_string, 512);
fprintf(stderr, "USRP reported the following error: %s\n", error_string);
}
uhd_usrp_free(&usrp);
free_option_strings:
if(strcmp(device_args,"")){
free(device_args);
}
if(custom_filename){
free(filename);
}
if(subdev) uhd_subdev_spec_free(&subdev);
subdev=NULL;
fprintf(stderr, (return_code ? "Failure\n" : "Success\n"));
return return_code;
}
Regards,
Andrew.
---------- ??????????? ????????? ----------
?? ????: (mle...@ripnet.com)
????: 15.11.2016, 17:48:07
????: Re: [USRP-users] B210 C-API dual channel
????: ?????? 1 (andrew4...@rambler.ru)
Re: [USRP-users] B210 C-API dual channel
I don't see anywhere in the attached code where you actually call
uhd_usrp_set_rx_subdev_spec()
On 2016-11-14 10:39, ?????? 1 via USRP-users wrote:
Hello
In that code I'm trying to get phase-aligned 2-channel RX
In that code something is wrong becose after uhd_usrp_set_time_now have
an error and num_rx_samps = 0
int main(int argc, char* argv[])
{
int option = 0;
double freq = 500e6;
double freqR = 500e6;
double rate = 1e6;
double gain = 5.0;
char* device_args = "";
size_t channel;
char* filename = "out.dat";
size_t n_samples = 1000;//000;
bool verbose = false;
int return_code = EXIT_SUCCESS;
bool custom_filename = false;
char error_string[512];
uhd_usrp_handle usrp;
uhd_rx_streamer_handle rx_streamer;
uhd_rx_metadata_handle md;
uhd_tune_request_t tune_request;
uhd_tune_result_t tune_result;
uhd_stream_args_t stream_args;
uhd_stream_cmd_t stream_cmd;
uhd_rx_metadata_error_code_t error_code;
size_t samps_per_buff;
void **buffs_ptr = NULL;
FILE *fp = NULL;
size_t num_acc_samps = 0;
size_t i;
UHD_API uhd_error Status;
uhd_subdev_spec_handle subdev=NULL;
uhd_subdev_spec_pair_t subdev1={"A","A:A A:B"};
uhd_subdev_spec_pair_t subdev2={"A","A:A A:B"};
char markup[256]={0,0,0};
time_t full_secs=1;
double frac_secs=0.5;
size_t count_channel=2; //!!!
size_t channel_list[2];
float *buff = NULL;
float *buff1= NULL;
float *buffers[2];
memset((void*)&tune_request,0,sizeof(tune_request));
channel_list[0]=0;
channel_list[1]=1;
if(uhd_set_thread_priority(uhd_default_thread_priority, true)){
fprintf(stderr, "Unable to set thread priority. Continuing anyway.\n");
}
// Create USRP
fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
if(uhd_usrp_make(&usrp, device_args)!=UHD_ERROR_NONE)
goto free_option_strings;
if(subdev==NULL)
Status=uhd_subdev_spec_make(&subdev, markup );
if(subdev)
{
//! Check how many subdevice specifications are in this list
Status=uhd_subdev_spec_size(subdev,&i);
markup[0]=0;
if(i) //! Get the subdevice specification at the given index
{
//! Get a string representation of the given list
Status=uhd_subdev_spec_to_pp_string(subdev, markup, sizeof(markup) );
//! Get the subdevice specification at the given index
Status=uhd_subdev_spec_at(subdev,0,&subdev1);
if(i>1)
Status=uhd_subdev_spec_at(subdev,1,&subdev2);
}
//! Add a subdevice specification to this list
//if(strstr(markup,"A:A A:B")==0)
// Status=uhd_subdev_spec_push_back(subdev,"A:A A:B"); //Only One Channel
after uhd_subdev_spec_to_pp_string
if(strstr(markup,"A:A")==0)
Status=uhd_subdev_spec_push_back(subdev,"A:A");
if(strstr(markup,"A:B")==0)
Status=uhd_subdev_spec_push_back(subdev,"A:B");
//! Get a string representation of the given list
Status=uhd_subdev_spec_to_pp_string(subdev, markup, sizeof(markup) );
fprintf(stderr, "Setting subdev: %s...\n", markup);
}
// Create RX streamer
if(uhd_rx_streamer_make(&rx_streamer)!=UHD_ERROR_NONE)
goto free_usrp;
// Create RX metadata
if(uhd_rx_metadata_make(&md)!=UHD_ERROR_NONE)
goto free_rx_streamer;
// Create other necessary structs
tune_request.target_freq = freq;
tune_request.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
tune_request.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
for(channel=0;channel<count_channel;channel++)
{
fprintf(stderr, " Setting Channel%d\n",channel);
// Set rate
fprintf(stderr, "Setting RX Rate: %f...\n", rate);
if(uhd_usrp_set_rx_rate(usrp, rate, channel)!=UHD_ERROR_NONE)
goto free_rx_metadata;
// See what rate actually is
if(uhd_usrp_get_rx_rate(usrp, channel, &rate)!=UHD_ERROR_NONE)
goto free_rx_metadata;
fprintf(stderr, "Actual RX Rate: %f...\n", rate);
// Set gain
fprintf(stderr, "Setting RX Gain: %f dB...\n", gain);
if(uhd_usrp_set_rx_gain(usrp, gain, channel, "")!=UHD_ERROR_NONE)
goto free_rx_metadata;
// See what gain actually is
if(uhd_usrp_get_rx_gain(usrp, channel, "", &gain)!=UHD_ERROR_NONE)
goto free_rx_metadata;
fprintf(stderr, "Actual RX Gain: %f...\n", gain);
// Set frequency
fprintf(stderr, "Setting RX frequency: %f MHz...\n", freq/1e6);
if(uhd_usrp_set_rx_freq(usrp, &tune_request, channel,
&tune_result)!=UHD_ERROR_NONE)
goto free_rx_metadata;
// See what frequency actually is
if(uhd_usrp_get_rx_freq(usrp, channel, &freqR)!=UHD_ERROR_NONE)
goto free_rx_metadata;
fprintf(stderr, "Actual RX frequency: %f MHz...\n", freqR / 1e6);
}
// Set up streamer
stream_args.cpu_format = "fc32";
stream_args.otw_format = "sc16";
stream_args.args = "";
stream_args.channel_list = &channel_list[0];
stream_args.n_channels = count_channel;
if(uhd_usrp_get_rx_stream(usrp, &stream_args,
rx_streamer)!=UHD_ERROR_NONE)
goto free_rx_streamer;
// Set up buffer
if(uhd_rx_streamer_max_num_samps(rx_streamer,
&samps_per_buff)!=UHD_ERROR_NONE)
goto free_rx_streamer;
fprintf(stderr, "Buffer size in samples: %zu\n", samps_per_buff);
buff = malloc(samps_per_buff * 2 * sizeof(float));
buff1 = malloc(samps_per_buff * 2 * sizeof(float));
buffers[0]=buff;
buffers[1]=buff1;
buffs_ptr = (void**)buffers;
stream_cmd.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE;
stream_cmd.num_samps = n_samples;
//stream_cmd.stream_now =true;
stream_cmd.stream_now =false; //With multiple devices false;
stream_cmd.time_spec_full_secs=full_secs; //time_t //! If not now, then
full seconds into future to stream
stream_cmd.time_spec_frac_secs=frac_secs; //timeout; //! If not now, then
fractional seconds into future to stream
Status=uhd_usrp_set_time_now(usrp,full_secs, frac_secs, 0); // Status=10
???
// Issue stream command
fprintf(stderr, "Issuing stream command.\n");
if(uhd_rx_streamer_issue_stream_cmd(rx_streamer,
&stream_cmd)!=UHD_ERROR_NONE)
goto free_buffer;
// Set up file output
fp = fopen(filename, "wb");
// Actual streaming
while (num_acc_samps < n_samples) {
size_t num_rx_samps = 0;
if(uhd_rx_streamer_recv(rx_streamer, buffs_ptr, samps_per_buff, &md, 3.0,
false, &num_rx_samps)!=UHD_ERROR_NONE)
goto close_file;
if(uhd_rx_metadata_error_code(md, &error_code)!=UHD_ERROR_NONE)
goto close_file;
if(error_code != UHD_RX_METADATA_ERROR_CODE_NONE){
fprintf(stderr, "Error code 0x%x was returned during streaming.
Aborting.\n", error_code);//return_code);
goto close_file;
}
// Handle data
fwrite(buff, sizeof(float) * 2, num_rx_samps, fp);
fwrite(buff1, sizeof(float) * 2, num_rx_samps, fp);
if (verbose) {
time_t full_secs;
double frac_secs;
uhd_rx_metadata_time_spec(md, &full_secs, &frac_secs);
fprintf(stderr, "Received packet: %zu samples, %zu full secs, %f frac
secs\n",
num_rx_samps,
full_secs,
frac_secs);
}
num_acc_samps += num_rx_samps;
}
// Cleanup
close_file:
fclose(fp);
free_buffer:
if(buff){
if(verbose){
fprintf(stderr, "Freeing buffer_0.\n");
}
free(buff);
}
buff = NULL;
if(buff1){
if(verbose){
fprintf(stderr, "Freeing buffer_1.\n");
}
free(buff1);
}
buff1 = NULL;
buffs_ptr = NULL;
free_rx_streamer:
if(verbose){
fprintf(stderr, "Cleaning up RX streamer.\n");
}
uhd_rx_streamer_free(&rx_streamer);
free_rx_metadata:
if(verbose){
fprintf(stderr, "Cleaning up RX metadata.\n");
}
uhd_rx_metadata_free(&md);
free_usrp:
if(verbose){
fprintf(stderr, "Cleaning up USRP.\n");
}
if(return_code != EXIT_SUCCESS && usrp != NULL){
uhd_usrp_last_error(usrp, error_string, 512);
fprintf(stderr, "USRP reported the following error: %s\n", error_string);
}
uhd_usrp_free(&usrp);
free_option_strings:
if(strcmp(device_args,"")){
free(device_args);
}
if(custom_filename){
free(filename);
}
if(subdev) uhd_subdev_spec_free(&subdev); //Exception!!!
subdev=NULL;
fprintf(stderr, (return_code ? "Failure\n" : "Success\n"));
return return_code;
}
Regards,
Andrew.
---------- ??????????? ????????? ----------
?? ????: (mle...@ripnet.com)
????: 11.11.2016, 18:06:02
????: Re: [USRP-users] B210 C-API dual channel
????: ?????? 1 (andrew4...@rambler.ru)
Re: [USRP-users] B210 C-API dual channel
I think we're going to need to see the entirety of the part of your
code that sets up the USRP to help spot the problem.
On 2016-11-11 09:19, ?????? 1 via USRP-users wrote:
Hello
I call uhd_usrp_set_rx_subdev_spec after uhd_usrp_make with this
arguments
uhd_subdev_spec_pair_t subdev={"0","A:A A:B"};
Status=uhd_usrp_set_rx_subdev_spec(usrp,
(uhd_subdev_spec_handle*)&subdev, mboard);
and have status = 0.
But before this call i had
get_rx_num_channels return num_channel = 2
after uhd_usrp_set_rx_subdev_spec i have num_channel = 1
Is it right for a phase-aligned channels rx with a single B210 ?
Regards,
Andrew.
---------- ??????????? ????????? ----------
?? ????: (mle...@ripnet.com)
????: 10.11.2016, 18:03:07
????: Re: [USRP-users] B210 C-API dual channel
????: ?????? 1 (andrew4...@rambler.ru)
Re: [USRP-users] B210 C-API dual channel
You'll also need to specify subdev of "A:A A:B"
On 2016-11-10 09:18, ?????? 1 via USRP-users wrote:
Hello
I using C-API and rx_samples_c example by start point for
write dual channel receiver(B210).
I set size_t channels[2] = {0,1};
uhd_stream_args_t stream_args = {
.cpu_format = "fc32",
.otw_format = "sc16",
.args = "",
.channel_list = &channels,
.n_channels = 2
};
and setup frequency and gain in channels.
But when I call uhd_rx_streamer_recv I have num_rx_samps
= 0
What other settings are needed to dual mode received
except changes in the structure of stream_args.
Regards,
Andrew
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
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/20161116/c6299352/attachment-0001.html>
------------------------------
Message: 27
Date: Wed, 16 Nov 2016 06:55:31 -0500
From: Jason Matusiak <ja...@gardettoengineering.com>
To: usrp-users@lists.ettus.com, johncorad1...@gmail.com
Subject: Re: [USRP-users] RFNoC XML
Message-ID:
<5e888c67-1b47-b2c8-0c32-3269ba25e...@gardettoengineering.com>
Content-Type: text/plain; charset=utf-8; format=flowed
>>AttributeError: 'module' object has no attribute 'CtrlDac'
In my experiance, that usually means that something is wrong with one of
your XML files. The blockname is showing up correct, so your UHD XML is
probably fine, but what about your GNURadio XML? Is it located where it
should be? Also, did you run sudo ldconfig and then refresh GR?
~Jason
------------------------------
Message: 28
Date: Wed, 16 Nov 2016 09:40:30 +0000
From: carry chen <artestp...@outlook.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] gen usrp b205mini-i ise project file
Message-ID:
<sg2pr06mb0805245d8348cfd647b0ca24dd...@sg2pr06mb0805.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have buy usrp b205mini-i, and need to do some modify on fpga code.
But I install ise on linux fail. only ise 14.7 run on windows! (May be
it can not gen on windows)
can any body send me b205mini fpga project fie? or have some other
methon to build on windows?
thank you very much!
carry
------------------------------
Message: 29
Date: Wed, 16 Nov 2016 14:18:46 +0100
From: Peter-Rene Schroeter <schroe...@tkn.tu-berlin.de>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Assertion error executing usrp_energy command
Message-ID:
<20161116141846.horde.5jpqz58ackp66ldayaiu...@webmail.tu-berlin.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Dear all,
when I execute ./build/usrp_energy -o "dump.out" -b 1 -a
"serial=F517C5" -f 2412e6 -r 1e6 -g 0 -t 2
I get following error message:
Initializing USRP device
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
terminate called after throwing an instance of 'uhd::assertion_error'
what(): AssertionError: block_def
in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
size_t, size_t, const uhd::sid_t&, uhd::device_addr_t,
uhd::endianness_t)
at /build/uhd-SfT4TV/uhd-3.10.0.0/host/lib/usrp/device3/device3_impl.cpp:148
I use the current image for my x300 usrp.
Thank you in advance for your help.
Best regards,
Peter
------------------------------
Message: 30
Date: Wed, 16 Nov 2016 22:27:07 +0800 (CST)
From: zhuimengren <bjc...@163.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] What is the time? How can we do if we want to
convert to understand it?
Message-ID: <f48f7e6.12391.1586d88bda3.coremail.bjc...@163.com>
Content-Type: text/plain; charset="gbk"
In the attachment, this is rxtime.grc.
We use it to display the time of tags of received signal, and this is USRP's
time?
In result.png, there is
Offset: 0 Source: gr uhd usrp source1 Key: rx_time Value: {0 0.956504}
We can not understand it, what is it?
If we want to get the time is 141757.00(UTC time or GPS time), how can we do?
As detailed as possible? thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/8b10fabe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: result.png
Type: image/png
Size: 192989 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/8b10fabe/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rxtime.grc
Type: application/octet-stream
Size: 30355 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/8b10fabe/attachment-0001.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: result.png
Type: image/png
Size: 192989 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/8b10fabe/attachment-0003.png>
------------------------------
Message: 31
Date: Wed, 16 Nov 2016 09:34:56 -0500
From: Rob Kossler <rkoss...@nd.edu>
To: Michael West <michael.w...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310/UBX RX streaming startup transients
Message-ID:
<CAB__hTQ=ocuwam5e-7gv0ezqog4c4fkv3ky5dtl6s_o3a6s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Thanks for the reply. I will try to run another experiment, but it might
be a while before I have the opportunity. That's the reason I sent the OTA
results from my experiment rather than a more controlled lab setup
involving cabled connections.
Regarding warmup, this particular measurement was not the first measurement
of the day. There were several previous measurements. None of the
settings such as frequency, lo offset, or gain were changed in between
measurements. Just streaming stopped / restarted.
Rob
On Tue, Nov 15, 2016 at 10:39 PM, Michael West <michael.w...@ettus.com>
wrote:
> Hi Rob,
>
> To test if it is TX or RX, transmit a constant tone that starts well (i.e.
> 1 sec) before the RX and see if you still see the transients in the capture.
>
> This may be warm up time for the LNA. There are 2 LNAs on the UBX and the
> split is at 1.5 GHz. The UBX tunes to 10 MHz during initialization, so the
> low band LNA is powered up. After tuning to the high band, it may take
> some time for the other LNA to warm up. If that is the case, any
> subsequent captures should reach full power right away.
>
> Regards,
> Michael
>
> On Tue, Nov 15, 2016 at 5:37 PM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> I recently used several X310s in an OTA multichannel radar measurement.
>> For this measurement, the TX signal was a 100usec long chirp that was
>> repeated throughout the RX data capture which lasted 10 seconds. My
>> question involves the very long (IMO) startup transients that I notice in
>> my captured signals, the longest of which is 264 msecs. I am wondering
>> what is causing this behavior.
>>
>> The attached figure (x310_startup.png) illustrates the issue. This
>> figure shows the RX power level (averaged over 100 usec blocks) throughout
>> the capture. There were 4 RX channels at 2.4GHz using UBX daughterboards
>> and 4 RX channels at 5.8 GHz using TwinRX daughterboards. The four UBX
>> channels (red, blue, yellow purple) all show discrete jumps in power level.
>>
>>
>> - For channel 0 (blue), jumps occur at 47 and 180 msec
>> - For channel 1 (red), jumps occur at 62 and 91 msec
>> - For channel 2 (yellow), jumps occur at 41 and 264 msec
>> - For channel 3 (purple), there is a single jump at 0.4 msec
>>
>> Note that the other 4 channels shown in the figure (representing the 5.8
>> GHz captures using the TwinRx daughterboards) show no such transients.
>> Also, note that if you look at the other attached figure
>> (x310_startup_10s.png) which is the exact same data set but simply
>> displayed for a longer duration, you will see that the power level remains
>> stable after the previously mentioned startup transients.
>>
>> I could go into more details of my specific setup if needed, but at a
>> high level this measurement involved two synchronized 2x4 measurements, one
>> at 2.4GHz and the other at 5.8GHz. All Tx and Rx channels for this
>> measurement were synchronized by PPS such that all streaming would begin at
>> a specified start time. I believe that the transients are related to RX
>> rather than TX because there were only 2 TX signals at 2.4GHz but yet the
>> transients shown in the RX data occur at independent times on the 4 RX
>> channels.
>>
>> A couple more noteworthy items...
>>
>> - The UBX Rx channels (and incidentally, all of the TX channels) were
>> operated using 003.009.005-34-g7a7308cc. The TwinRx Rx channels were
>> operated using a very recent 3.10 version (I would need to check which
>> one). The application software was my own custom C++ based on Ettus
>> examples.
>> - I looked back at previous posts and noticed similar startup issues
>> related to Tx and "powersave" options. I have not changed this option
>> from
>> the default which I believe is performance mode.
>> - Also, I noticed previous posts indicating that bugs were fixed at
>> some point which appears to have been prior to the 3.9.5 release that I
>> used. So, as far as I know, there were no fixes of this type after this
>> release. If this is incorrect, please let me know.
>> - The TX and RX channels in my 2x4 measurement systems are from
>> independent X310s. That is, the 2 TX channels come from one X310 while
>> the
>> four RX channels come from two additional X310s.
>> - The TX and RX streaming rates were all 100 MS/s for all channels.
>> There were no underruns/overflows or other error indications.
>>
>> Thanks for considering this very long email.
>> Rob
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> 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/20161116/baffe1aa/attachment-0001.html>
------------------------------
Message: 32
Date: Wed, 16 Nov 2016 09:57:15 -0500
From: Rob Kossler <rkoss...@nd.edu>
To: Michael West <michael.w...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310/UBX RX streaming startup transients
Message-ID:
<cab__htqzz-0wqne0vn3h4xv+n8wfnng8so5uqaqap-nd70o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
One more thing.... You mentioned that the issue may involve warmup time for
the LNA. Looking at my figure, I determined that the large power level
increases are in the range of approx 23-26 dB and the last of these occurs
at 62 msec after start of streaming. Then for 3 of the 4 channels, there
is an additional approx 3 dB increase and the last of these occurs at 264
msec. I'm guessing that the LNA could be the initial jump but wondering
what the 3 dB jump might be.
Rob
On Wed, Nov 16, 2016 at 9:34 AM, Rob Kossler <rkoss...@nd.edu> wrote:
> Hi Michael,
> Thanks for the reply. I will try to run another experiment, but it might
> be a while before I have the opportunity. That's the reason I sent the OTA
> results from my experiment rather than a more controlled lab setup
> involving cabled connections.
>
> Regarding warmup, this particular measurement was not the first
> measurement of the day. There were several previous measurements. None of
> the settings such as frequency, lo offset, or gain were changed in between
> measurements. Just streaming stopped / restarted.
> Rob
>
>
> On Tue, Nov 15, 2016 at 10:39 PM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Rob,
>>
>> To test if it is TX or RX, transmit a constant tone that starts well
>> (i.e. 1 sec) before the RX and see if you still see the transients in the
>> capture.
>>
>> This may be warm up time for the LNA. There are 2 LNAs on the UBX and
>> the split is at 1.5 GHz. The UBX tunes to 10 MHz during initialization, so
>> the low band LNA is powered up. After tuning to the high band, it may take
>> some time for the other LNA to warm up. If that is the case, any
>> subsequent captures should reach full power right away.
>>
>> Regards,
>> Michael
>>
>> On Tue, Nov 15, 2016 at 5:37 PM, Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>> I recently used several X310s in an OTA multichannel radar measurement.
>>> For this measurement, the TX signal was a 100usec long chirp that was
>>> repeated throughout the RX data capture which lasted 10 seconds. My
>>> question involves the very long (IMO) startup transients that I notice in
>>> my captured signals, the longest of which is 264 msecs. I am wondering
>>> what is causing this behavior.
>>>
>>> The attached figure (x310_startup.png) illustrates the issue. This
>>> figure shows the RX power level (averaged over 100 usec blocks) throughout
>>> the capture. There were 4 RX channels at 2.4GHz using UBX daughterboards
>>> and 4 RX channels at 5.8 GHz using TwinRX daughterboards. The four UBX
>>> channels (red, blue, yellow purple) all show discrete jumps in power level.
>>>
>>>
>>> - For channel 0 (blue), jumps occur at 47 and 180 msec
>>> - For channel 1 (red), jumps occur at 62 and 91 msec
>>> - For channel 2 (yellow), jumps occur at 41 and 264 msec
>>> - For channel 3 (purple), there is a single jump at 0.4 msec
>>>
>>> Note that the other 4 channels shown in the figure (representing the 5.8
>>> GHz captures using the TwinRx daughterboards) show no such transients.
>>> Also, note that if you look at the other attached figure
>>> (x310_startup_10s.png) which is the exact same data set but simply
>>> displayed for a longer duration, you will see that the power level remains
>>> stable after the previously mentioned startup transients.
>>>
>>> I could go into more details of my specific setup if needed, but at a
>>> high level this measurement involved two synchronized 2x4 measurements, one
>>> at 2.4GHz and the other at 5.8GHz. All Tx and Rx channels for this
>>> measurement were synchronized by PPS such that all streaming would begin at
>>> a specified start time. I believe that the transients are related to RX
>>> rather than TX because there were only 2 TX signals at 2.4GHz but yet the
>>> transients shown in the RX data occur at independent times on the 4 RX
>>> channels.
>>>
>>> A couple more noteworthy items...
>>>
>>> - The UBX Rx channels (and incidentally, all of the TX channels)
>>> were operated using 003.009.005-34-g7a7308cc. The TwinRx Rx
>>> channels were operated using a very recent 3.10 version (I would need to
>>> check which one). The application software was my own custom C++ based
>>> on
>>> Ettus examples.
>>> - I looked back at previous posts and noticed similar startup issues
>>> related to Tx and "powersave" options. I have not changed this option
>>> from
>>> the default which I believe is performance mode.
>>> - Also, I noticed previous posts indicating that bugs were fixed at
>>> some point which appears to have been prior to the 3.9.5 release that I
>>> used. So, as far as I know, there were no fixes of this type after this
>>> release. If this is incorrect, please let me know.
>>> - The TX and RX channels in my 2x4 measurement systems are from
>>> independent X310s. That is, the 2 TX channels come from one X310 while
>>> the
>>> four RX channels come from two additional X310s.
>>> - The TX and RX streaming rates were all 100 MS/s for all channels.
>>> There were no underruns/overflows or other error indications.
>>>
>>> Thanks for considering this very long email.
>>> Rob
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> 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/20161116/bfc76953/attachment-0001.html>
------------------------------
Message: 33
Date: Wed, 16 Nov 2016 10:10:23 -0500
From: mle...@ripnet.com
To: Vladica Sark <vladicas...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] XCVR2450 dead alike
Message-ID: <8b9d29b307ca1d9d0f1c1034f5295...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
Could you perhaps post a photo of the broken board, with emphasis on
U14?
On 2016-11-16 02:37, Vladica Sark via USRP-users wrote:
> Hi,
>
> UHD_003.011.000.git-78-gf70dd85d
>
> The both boards are rev 2.0. The broken one does not have the U14, but just a
> bridge wire.
>
> BR,
> Vladica
>
> On 15.11.2016 22:15, mle...@ripnet.com wrote: Which version of UHD are you
> using? Is your other XCVR2450 the same
> hardware rev?
>
> On 2016-11-15 15:53, Vladica Sark via USRP-users wrote:
>
> Hi,
>
> One of my XCVR2450 is dead alike. The uhd_usrp_probe gives the output
> bellow. Any idea if this can be fixed?
>
> BR,
> Vladi
>
> _____________________________________________________
> /
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: a0:36:fa:25:36:73
> | | ip-addr: 192.168.10.2
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: E7R16T3UP
> | | 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: XCVR2450, XCVR2450 - r2.1 (0x0061)
> | | | Serial: F47365
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: Unknown (0xffff) - 0
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: 0.000 to 0.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | 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: XCVR2450 - r2.1 (0x0059)
> | | | Serial: F47365
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: Unknown (0xffff) - 0
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: 0.000 to 0.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9777
> | | | | Gain Elements: None
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161116/3a519176/attachment-0001.html>
------------------------------
Message: 34
Date: Wed, 16 Nov 2016 09:20:43 -0700
From: Steven Knudsen <ee.k...@gmail.com>
To: zhuimengren <bjc...@163.com>
Cc: USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] What is the time? How can we do if we want
to convert to understand it?
Message-ID: <e8562c71-2a64-42ef-bda3-d6b11515a...@gmail.com>
Content-Type: text/plain; charset="utf-8"
Hope this helps.
Offset : 0 indicates the first sample output by the USRP source
Key : ?rx_time? is the tag key identifying it as a receive time tag
Value : {0, 0,956504} is the time value from the SDR associated with the USRP
source. The time is 0.956504 seconds and is derived from the SDR?s internal
clock.
You can either determine the host?s time and use rx_time as the initial offset
(i.e., add the two together) and then count samples and calculate the sample
time based on the sample rate.
Or you can set the SDR?s time. That will require either modifying the USRP
source block code to accept a UHD set time command via the control port,
syncing to the PC?s time, or creating a block that can access the USRP source
block at runtime to set the time, or modifying the generated python for the
flowgraph to set time. There are various emails on the list describing some of
those approaches.
There is no (AFAIK) ?easy? way to set the time to UTC or some other value.
Good luck,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist zu
erreichen. - Franz Kafka
> On Nov 16, 2016, at 07:27, zhuimengren via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> In the attachment, this is rxtime.grc.
> We use it to display the time of tags of received signal, and this is USRP's
> time?
> In result.png, there is
> Offset: 0 Source: gr uhd usrp source1 Key: rx_time Value: {0 0.956504}
> We can not understand it, what is it?
> If we want to get the time is 141757.00(UTC time or GPS time), how can we
> do?<result.png>
> As detailed as possible? thank you!
>
>
>
>
>
>
>
>
>
>
>
>
>
> <rxtime.grc><result.png>_______________________________________________
> USRP-users mailing list
> 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/20161116/0b3595fa/attachment-0001.html>
------------------------------
Message: 35
Date: Wed, 16 Nov 2016 08:30:20 -0800
From: Derek Kozel <derek.ko...@ettus.com>
To: liu Jong <jongliu1...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFA or RFB
Message-ID:
<CAA+K=ts=UgUk0b2vyOJ=evnyjwcvsqnmjsfor+3oqai_8nw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jon,
Yes, The B200 had a hardware change in which the side of the two RF
connectors was changed. There is no functional difference between the two
revisions.
Regards,
Derek
On Wed, Nov 16, 2016 at 1:21 AM, liu Jong via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear all,
> We found that USRP B200 contains two types,.one of the previous is the SMA
> interface in RFA, and the later one is in RFB. So from now on,the SMA
> interface will be always in RFB?
>
> best regards
> Jon
>
> _______________________________________________
> USRP-users mailing list
> 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/20161116/084d7e00/attachment-0001.html>
------------------------------
Message: 36
Date: Wed, 16 Nov 2016 08:32:26 -0800
From: Derek Kozel <derek.ko...@ettus.com>
To: Peter-Rene Schroeter <schroe...@tkn.tu-berlin.de>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Assertion error executing usrp_energy
command
Message-ID:
<CAA+K=ttu+uxlk3dcbxto+sjm3ywqxe1zehwkw0wwqyms4f3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Peter,
This is a bug which was present in the 3.10.0.0 release on Ubuntu, which it
appears you are using. Can you please try updating to UHD 3.10.1.0?
Thank you,
Derek
On Wed, Nov 16, 2016 at 5:18 AM, Peter-Rene Schroeter via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
> Dear all,
>
>
>
> when I execute ./build/usrp_energy -o "dump.out" -b 1 -a "serial=F517C5"
> -f 2412e6 -r 1e6 -g 0 -t 2
>
> I get following error message:
>
> Initializing USRP device
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 1472 bytes.
>
> -- Setup basic communication...
>
> -- Loading values from EEPROM...
>
> -- Setup RF frontend clocking...
>
> -- Radio 1x clock:200
>
> terminate called after throwing an instance of 'uhd::assertion_error'
>
> what(): AssertionError: block_def
>
> in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t, size_t,
> size_t, const uhd::sid_t&, uhd::device_addr_t, uhd::endianness_t)
>
> at /build/uhd-SfT4TV/uhd-3.10.0.0/host/lib/usrp/device3/device3
> _impl.cpp:148
>
>
>
> I use the current image for my x300 usrp.
>
>
>
> Thank you in advance for your help.
>
>
>
> Best regards,
>
> Peter
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20161116/b0992dea/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 75, Issue 15
******************************************
