Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: nirio_quirks.h:39: bad for loop ? (Michael Dickens)
2. Detecting if USRP contended via USB 2.0 or USB 3.0.
(Weaver, Tyler)
3. Sample rates and bandwidths on B210? (Weaver, Tyler)
4. Re: Detecting if USRP contended via USB 2.0 or USB 3.0.
(Marcus M?ller)
5. Detecting if USRP contended via USB 2.0 or USB 3.0.
(Weaver, Tyler)
6. Re: Sample rates and bandwidths on B210? (Ian Buckley)
7. Re: Detecting if USRP contended via USB 2.0 or USB 3.0.
(Marcus M?ller)
8. Re: sample shift on x310 two channel synchronized receive (hanwen)
9. Re: TX Image rejection B210 (Ian Buckley)
10. Clock selection between external and GPSDO clocks (hanwen)
11. Re: ERROR: USRP E310 Network mode (Xinke Zhang)
12. USRP UHD Library Release suggestion (hossein talaiee)
13. Re: Phase offset drift over time for two x310
([email protected])
14. Re: Clock selection between external and GPSDO clocks
(Marcus M?ller)
15. Re: Clock selection between external and GPSDO clocks
(Piotr Krysik)
16. N200 stability (Dan Sego)
17. Re: USRP UHD Library Release suggestion (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Apr 2015 14:07:48 -0400
From: Michael Dickens <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] nirio_quirks.h:39: bad for loop ?
Message-ID:
<1429207668.1926667.254723513.68fbf...@webmail.messagingengine.com>
Content-Type: text/plain
Hi David - Thanks for the pointer. We're working on getting a fix for
this into UHD. - MLD
On Fri, Apr 10, 2015, at 02:26 AM, David Binderman via USRP-users wrote:
> uhd-release_003_008_002/host/include/uhd/transport/nirio/nirio_quirks.h:39:38:
> warning: sizeof on array function parameter will return size of 'const
> uint32_t *' (aka 'const unsigned int *') instead of 'const uint32_t []'
> [-Wsizeof-array-argument]
> for (size_t i = 0; i <
> sizeof(tx_stream_indices)/sizeof(*tx_stream_indices); i++) {
------------------------------
Message: 2
Date: Thu, 16 Apr 2015 15:38:49 +0000
From: "Weaver, Tyler" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Detecting if USRP contended via USB 2.0 or USB
3.0.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
My application requires sample rates that are only available if my B210
connects via USB 3.0. How can I determine through UHD how I?m connected? I
realize that when I run the method make on my usrp it prints one of these two
messages to stdout. Is there a way I can query to see how I?m connected?
- -- Operating over USB 2.
- -- Operating over USB 3.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJVL9eIAAoJED34NDp4cyE82+MH/A/FEn9XAxwVTjhuPhuel/UC
lXptPp3Fra+wgHEYPQfOko4KF4wduQJhcs5rU83Ljom7E1GQHjKB4dnvUKipfRH/
G02puyZVd2U7mygFYi3Bsn6JZaBzH8o5GNh7g5XWmf8EUMBSN908l55SoUr8X5eM
WTz8x63kt+ossZiGe9HzwnysrrDc5fm0xjeNON15Ixu0la40S9uBI6K4G0Yir0Nt
iy30BG0H++kzJ1JA+Dy+30vQSPk/xGkX4uO/u7K7/8a0aVOWqt04EUTzSoazNDdP
eSKiekmNIsZeAnFn5Exa2O7txpNwq9nwRRei5k+kUiCywdtmidZeIJeLeCvLVLk=
=0MW6
-----END PGP SIGNATURE-----
------------------------------
Message: 3
Date: Thu, 16 Apr 2015 17:23:54 +0000
From: "Weaver, Tyler" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Sample rates and bandwidths on B210?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
When I run get_rx_rates on my b210 I get values that seem to be integer
decimations of 64 MS/s vs the 61.44 MS/s value that I see in the documentation.
It also seems that the minimum decimation is 2 as the maximum value is 32e6
(64/2). Is the correct? Is there an up sampling stage in the B210 similar to
to the N210 after the ADC?
Also when I run get_x_bandwidth_range there are only two values 200e3 and 56e6
that are output. Are these my only two options for filters before the 64/61.44
MS/s ADC?
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJVL/AqAAoJED34NDp4cyE8sA4H/iFtKRUVaPh11xzBqkdAQ2Yc
qA2TCQz889tIqifE0JHmUz3eQbMHAC5ea7Wx6cY2fH5bD6FVYz6mFofsUnp77EKL
m5jpo5+sOPMrozMyQ9FvthuD33JyxfbxnDu1qquFyE6ERlF8oALu6dP1jMBC/ROG
5Wgvx1cdW+ighQqW+byKuHyMRTEDJoeFYBmdCn5OeGEMnnvN57LU8X+4mjgHhJZR
DSVtwSBrOX5c2ZKqVQzKp0wdTf1qxiDET9LTkCTXT8sMgEycXN004Vu11v7b3DTR
NkpMMePqHmvD0q6/63meSGUxSVH3bhakxMEi9wHiapi0GWlBn5fN5yjjYXX/MB0=
=QSxF
-----END PGP SIGNATURE-----
------------------------------
Message: 4
Date: Thu, 16 Apr 2015 21:03:42 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Detecting if USRP contended via USB 2.0 or
USB 3.0.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Tyler,
the easiest way is most probably by means of asking your operating system.
If you're on linux, try
lsusb -v -d 2500:0020|grep bcdUSB
if the value is 2.10, you're on USB3.
Generally, if you want to now that in a UHD program, get yourself your
device object, and do a query on the property tree; something like
double max_rate =
my_multi_usrp->get_device()->get_tree()->access<double>("/mboards/0/link_max_rate").get();
will tell you the maximum transferable rate.
Greetings,
Marcus
On 04/16/2015 05:38 PM, Weaver, Tyler via USRP-users wrote:
> My application requires sample rates that are only available if my
> B210 connects via USB 3.0. How can I determine through UHD how I?m
> connected? I realize that when I run the method make on my usrp it
> prints one of these two messages to stdout. Is there a way I can
> query to see how I?m connected?
>
> -- Operating over USB 2.
> -- Operating over USB 3.
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/9d30ecc9/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 16 Apr 2015 19:18:52 +0000
From: "Weaver, Tyler" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Detecting if USRP contended via USB 2.0 or USB
3.0.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Marcus,
Thank you for the help. I need to access it through a UHD application. Using
your method I got these two results when connecting:
usb 2: 3.2e+07
usb 3: 5e+08
The question I have relates to the usb 2 rate. I?ve read that the greatest
sample rate under usb 2 is 8 MS/s. Are these numbers in bytes/s? If so that
would make sense that you need 32e6 bytes/s to transfer 8e6 2x16bit complex
values. Is this correct?
tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/c92feee0/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 16 Apr 2015 12:20:11 -0700
From: Ian Buckley <[email protected]>
To: "Weaver, Tyler" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sample rates and bandwidths on B210?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tyler,
(If you care about the internals of the radio then ADI's document UG-570
"AD9361 Reference Manual" is recommended reading though it still leaves a lot
to be guessed.)
In short:
The 61.44MHz maximum value is a limit on the sample rate of data fed to the
Radio IC (31.72MHz in 2x2 MIMO mode). Ettus research call this the
master_clock_rate, in contrast to the sample_rate, which is the sample clock
between host computer and USRP. The actual radio IC contains a lot of
configurable digital filters and the converters use a sigma-delta design style
that typically runs at 100's of MHz. In addition the FPGA offers more
configurable digital filtering. The decimation/interpolation range in the FPGA
ranges from 1 through 512, however certain values should be avoided (Generally
all odd values except 1) . The Radio IC has decimation/interpolation between 1
and 48 ( typical values is around 8->16 for sample rates commonly used). Every
decimation/interpolation stage includes filtration thats as close to the
Nyquist limit as practically possible. In addition there are 2 stages of analog
baseband filter which are programmable with fine granularity, and these are
what is being
referred to via the "*_bandwidth" API calls. Until recently get_rx_bandwidth
always returned a hardcoded 56e6, but now returns the actual programmed
bandwidth..you are advised to work with recent versions of UHD with the B2x0.
-Ian
On Apr 16, 2015, at 10:23 AM, "Weaver, Tyler via USRP-users"
<[email protected]> wrote:
> Signed PGP part
> When I run get_rx_rates on my b210 I get values that seem to be integer
> decimations of 64 MS/s vs the 61.44 MS/s value that I see in the
> documentation. It also seems that the minimum decimation is 2 as the maximum
> value is 32e6 (64/2). Is the correct? Is there an up sampling stage in the
> B210 similar to to the N210 after the ADC?
>
> Also when I run get_x_bandwidth_range there are only two values 200e3 and
> 56e6 that are output. Are these my only two options for filters before the
> 64/61.44 MS/s ADC?
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/6a0be02c/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 16 Apr 2015 21:34:35 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Detecting if USRP contended via USB 2.0 or
USB 3.0.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello,
Those are Bytes/s. So your calculation is correct. I don't really know
why the USB2 limit is 32MB/s, but it's the same as for the old USRP1, so
that would make sense.
I'm still going to just playfully adjust that value, because I thought
8MS/s was the maximum for USRP1 because two things had to be fulfilled:
a) the sampling rate * 32 bit must fit through USB2, and
b) the sampling rate must be an integer fraction of the fixed USRP1
master_clock_rate, which is 64MHz
a) still applies, but I'm not so sure about b), since the B2x0 has a
variable master clock rate, so rates 44MHz/4 would actually be o.k.
Greetings,
Marcus
On 04/16/2015 09:18 PM, Weaver, Tyler via USRP-users wrote:
> Hello Marcus,
>
> Thank you for the help. I need to access it through a UHD
> application. Using your method I got these two results when connecting:
>
> usb 2: 3.2e+07
> usb 3: 5e+08
>
> The question I have relates to the usb 2 rate. I?ve read that the
> greatest sample rate under usb 2 is 8 MS/s. Are these numbers in
> bytes/s? If so that would make sense that you need 32e6 bytes/s to
> transfer 8e6 2x16bit complex values. Is this correct?
>
> tyler
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/65aaa288/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 16 Apr 2015 22:54:02 +0200
From: hanwen <[email protected]>
To: Sanjoy <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] sample shift on x310 two channel
synchronized receive
Message-ID:
<cabjuse16w5fzj4c0iao1jth87uw1zpssf-mbyc7vyo6sbiu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
This issue is solved by removing a usrp->set_time_now(0.0) call in my
program. It seems that for synchronized multiple channels, the safe way of
resetting the time is via PPS. Don't explicitly reset it immediately via
set_time_now()!
Cheers,
Hanwen
2015-04-10 14:29 GMT+02:00 Sanjoy via USRP-users <[email protected]
>:
> Hi Hanwen Cao,
> I am using 2 x310s and for transmitting and receiving both I am using
> set_start_time(future_time); where future time is same for tx and rx; so
> theoritically I should get rx signal to be time synced with tx signal; but
> I
> am not getting that; there is always a shift.
> Can you tell me how did you fix your problem and one more thing can you
> tell
> me how to know the streaming time of tx and rx?
>
> thanks in advance.
>
> regads
> Sanjoy
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/3092b5de/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 16 Apr 2015 17:10:08 -0700
From: Ian Buckley <[email protected]>
To: Sebastian Held <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] TX Image rejection B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Sebastian,
We have a handle on this bug now, the AD9361's internal IQ Quadrature imbalance
routine is not getting run at the correct time. The problem manifests in more
than just this application and it will take a little time for us to push a full
bug fix to UHD. Meantime if anyone feels this bug is affecting them then a
workaround is to add a tune_request immediately before starting streaming to an
LO frequency that differs by > 100MHz than the previous tune request, which
will force the IQ Quad Cal to re-run. When I try that workaround in
tx_waveforms I see the image drop from -25dBc to > -40dBc in your 5.9GHz case,
and > -50dBc when run at 4.9GHz.
-Ian
diff --git a/host/examples/tx_waveforms.cpp b/host/examples/tx_waveforms.cpp
index 7e63326..eb64d7b 100644
--- a/host/examples/tx_waveforms.cpp
+++ b/host/examples/tx_waveforms.cpp
@@ -170,11 +170,11 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
}
for(size_t ch = 0; ch < channel_nums.size(); ch++) {
- std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6)
<< std::endl;
- uhd::tune_request_t tune_request(freq);
- if(vm.count("int-n")) tune_request.args =
uhd::device_addr_t("mode_n=integer");
- usrp->set_tx_freq(tune_request, channel_nums[ch]);
- std::cout << boost::format("Actual TX Freq: %f MHz...") %
(usrp->get_tx_freq(channel_nums[ch])/1e6) << std::endl << std::endl;
+ // std::cout << boost::format("Setting TX Freq: %f MHz...") %
(freq/1e6) << std::endl;
+ // uhd::tune_request_t tune_request(freq);
+ // if(vm.count("int-n")) tune_request.args =
uhd::device_addr_t("mode_n=integer");
+ // usrp->set_tx_freq(tune_request, channel_nums[ch]);
+ // std::cout << boost::format("Actual TX Freq: %f MHz...") %
(usrp->get_tx_freq(channel_nums[ch])/1e6) << std::endl << std::endl;
//set the rf gain
if (vm.count("gain")){
@@ -255,6 +255,10 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
UHD_ASSERT_THROW(ref_locked.to_bool());
}
+ uhd::tune_request_t tune_request(freq);
+ if(vm.count("int-n")) tune_request.args =
uhd::device_addr_t("mode_n=integer");
+ usrp->set_tx_freq(tune_request, channel_nums[0]);
+
std::signal(SIGINT, &sig_int_handler);
std::cout << "Press Ctrl + C to stop streaming..." << std::endl;
On Apr 13, 2015, at 11:08 PM, Sebastian Held <[email protected]> wrote:
> Dear Ian,
>
>> I'm going to suggest that there is something in this UHD example thats less
>> than ideal. I note that the code as supplied by Ettus has no "--lo_off"
>> argument, so perhaps Sebastian has edited this example? Regardless I see the
>> issue in the factory code and I'm going to file a bug.
> Yes, I modified the code code to include support for LO offset modification
> (changed three lines or so - copied from an other example). I did this, to
> nail down the cause of my problem.
>> To the observation that you are seeing improved improved spectral mask
>> conformance with an OFDM signal?I suspect this is mostly because the recent
>> update you did from maint caused you to pick up the new FPGA images that
>> were published last week. These have specific filter changes to improve
>> performance with exactly this kind of wideband signal.
> Yes, you are right. By the way I'm on release_003_008_002-40-gf23e7bc.
>> The discussion of what is the ideal master_clock_rate vs what is merely an
>> OK one is a very broad topic and differs between USRP's. If you want to give
>> some specifics of your signal then I can give some suggestions.
> My original problem was the violation of the spectrum mask for 802.11p
> signals. I generate the IQ representation with a sample rate of 10 MHz. Older
> UHD versions indicated a problem with the sample rate - from that point on I
> used a fixed 10 MHz or 20 MHz master clock to further invetigate the problem.
>
>
> Back to my testcase: The sinusoids do not change if I modify the master
> clock. There is certainly a problem with image suppression.
> FYI: I attached the patch with the lo_off parameter. I could also file a pull
> request if you wish.
>
> Thanks
> Sebastian
>
>
>
> --
> Sebastian Held (Dipl.-Ing.)
> IMST GmbH
> Softwareentwickler
>
> Carl-Friedrich-Gauss-Str. 2-4
> 47475 Kamp-Lintfort
> Tel: +49 2842 981-418
> Fax: +49 2842 981-199
> E-mail: mailto:[email protected]
> Internet: http://www.imst.de
>
> http://webshop.imst.de
>
> Gesch?ftsf?hrer:
> Prof. Dr.-Ing. Ingo Wolff
> Dr. Peter Waldow
> Amtsgericht Kleve HRB 6737
> USt.-ID: DE 811348335
>
> Wir weisen darauf hin, dass rechtsverbindliche Erkl?rungen namens unseres
> Hauses grunds?tzlich der Unterschriften zweier ausreichend bevollm?chtigter
> Vertreter unseres Hauses bed?rfen. Wir verschicken daher keine
> rechtsverbindlichen Erkl?rungen per E-Mail an Dritte. Demgem?? nehmen wir per
> E-Mail auch keine rechtsverbindlichen Erkl?rungen oder Auftr?ge von Dritten
> entgegen. Diese E-Mail dient einzig dem unverbindlichen Informationsaustausch
> zwischen Sender und Empf?nger. Sie entfaltet keine Rechtswirksamkeit.
> Diese E-Mail ist vertraulich zu behandeln. Sollten Sie nicht der vorgesehene
> Empf?nger sein, bitten wir Sie, den Versender zu informieren und die
> Nachricht zu l?schen. Die Weitergabe sowie Vervielf?ltigung, Verwertung und
> Mitteilung seines Inhalts ist nur mit unserer ausdr?cklichen Genehmigung
> gestattet. Alle Rechte vorbehalten, insbesondere f?r den Fall der
> Schutzrechtsanmeldung.
> This document has to be treated confidentially. If you are not the intended
> recipient, please immediately notify the sender and delete this message. Its
> contents are not to be passed on, duplicated, exploited or disclosed without
> our expressed permission. All rights reserved, especially the right to apply
> for protective rights.
>
> <0001-added-lo_off-parameter-to-tx_waveforms-example.patch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/6ec1bcee/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 17 Apr 2015 07:30:34 +0200
From: hanwen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Clock selection between external and GPSDO
clocks
Message-ID:
<CABjUSe3oLXWeBm3e67BdWhH3TfbR7gnqLR5mhvP26-R7Kh=z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have some N210 with GPSDO inside. In UHD API, how I can select between
external 10MH/1PPS from OctoClockG and the internal clock signals from
GPSDO? I didn?t find any API that I could explicitly switch between the
external and the GPSDO clocks.
Cheers,
Hanwen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/3d61350e/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 17 Apr 2015 15:07:49 +0800 (GMT+08:00)
From: "Xinke Zhang" <[email protected]>
To: "Philip Balister" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Philip & Moritz,
Thanks for your kindly help. with your suggestions, the problem has been solved.
Best Regards,
Xinke
> -----Original Messages-----
> From: "Philip Balister" <[email protected]>
> Sent Time: Thursday, April 16, 2015
> To: "Xinke Zhang" <[email protected]>, "Moritz Fischer"
> <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
>
> On 04/15/2015 09:34 PM, Xinke Zhang via USRP-users wrote:
> >
> > Hi Moritz,
> >
> > Thank you.
> >
> > I used the e310 sdk toolchain to build the uhd source codes in the host pc,
> > and then transfer the built binary to the e310 device. However, i need to
> > copy the seperate built binary into its corresponding directory. is there
> > any automatic solution to update the uhd in the e310 device? Thanks.
>
> UHD on the latest set of test images is uhd-3.8.3-rc1. You do not need
> to update it.
>
> You do need to install 3.8.3-rc1 on the PC you are running network mode
> from.
>
> Philip
>
> >
> > Best Regards,
> >
> > Xinke
> >
> >> -----Original Messages-----
> >> From: "Moritz Fischer" <[email protected]>
> >> Sent Time: Thursday, April 16, 2015
> >> To: "Xinke Zhang" <[email protected]>
> >> Cc: "[email protected]" <[email protected]>
> >> Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
> >>
> >> Hi Xinke,
> >>
> >> When upgrading your device UHD you also need to upgrade your host UHD.
> >> The current dizzy-test images are build from the 3.8.3-RC1 tag. Make
> >> sure you build off of that.
> >> Also note that you'll need to run uhd_images_downloader to get the
> >> correct fpga image in place on the device.
> >>
> >> Cheers,
> >>
> >> Moritz
> >>
> >> On Tue, Apr 14, 2015 at 9:44 PM, Xinke Zhang via USRP-users
> >> <[email protected]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm using the usrp e310, and reburn the sd card with
> >>> http://files.ettus.com/e3xx_images/beta/dizzy-test/sdimage-gnuradio-demo.direct.xz.
> >>> when configuring the usrp e310 as network mode (config the ip addr and
> >>> start
> >>> the usrp_e3x0_network_mode), i use the uhd_find_devices and i can find the
> >>> usrp e310 devices, but when i use the uhd_usrp_probe, it came out the
> >>> error
> >>> message "Error: e300_remote_codec_ctrl_impl trancation failed". Pls help
> >>> check it. Thank you in advance.
> >>>
> >>> the version of uhd installed in the host pc is 3.8.2-151-gbf4f50de.
> >>>
> >>> Best Regards,
> >>>
> >>> Xinke
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> USRP-users mailing list
> >>> [email protected]
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/1517c8ed/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 17 Apr 2015 14:07:28 +0430
From: hossein talaiee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP UHD Library Release suggestion
Message-ID:
<CAAiBEBSsLiQUcSE66AZT7P4+ZpsuSyuX2oDnU_Xhw0yu=Rwe=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I noticed that UHD.dll file linked dynamicly against VS C++ run-time
library that make this dll needy of VS-C-Runtime installation to work, and
I wonder why?
Why when we can do it staticly and have an absolutely portable UHD driver!
As a matter of fact, boost compile must be done with this option too that
can be done with passing "runtime-link=static link=static" to b2 command
line of boost compile.
Also, boost libraries updated now to 1.57 (1.58 also will be out very soon,
they testing 1.58-RC version now), consider upgrading boost libraries in
release version.
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/9814d66e/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 17 Apr 2015 09:47:19 +0000
From: <[email protected]>
To: <[email protected]>, <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Phase offset drift over time for two x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Folks,
Is there any update on this drift issue? I noticed ?X300: Improved phase
alignment across devices?
in the latest 003.008.003 changelog.
Thanks for all the work
Ruben
From: USRP-users [mailto:[email protected]] On Behalf Of
Michael West via USRP-users
Sent: Monday, March 30, 2015 7:55 PM
To: Damiano Scanferla
Cc: usrp-users
Subject: Re: [USRP-users] Phase offset drift over time for two x310
Hi Damiano,
The change Neel sent you was to reduce the oscillations, not the drift. We are
actively looking into the drift and will let you know what we find as soon as
possible.
Regards,
Michael
On Mon, Mar 30, 2015 at 8:18 AM, Damiano Scanferla via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello Neel,
Thanks for your answer. I have tried what you suggested but we did not see any
significant improvements:
- the phase offset at 2.7 GHz drifted by 40 degrees over 3 minutes (same as
before)
- the oscillations of the phase offset over short time were reduced.
Do you have a reason for this phase offset drift over time?
Damiano
On Mon, Mar 30, 2015 at 3:54 PM, Neel Pandeya
<[email protected]<mailto:[email protected]>> wrote:
Hello Damiano Scanferla:
We have seen this issue before, and we believe that we have a solution that
should improve the results that you're seeing. I would like to ask you to make
a one-line change on line 193 of the file
"uhd/host/lib/usrp/x300/x300_clock_ctrl.cpp", and then re-build and re-install
UHD. I've attached a copy of the file with the change in it. It is necessary
that you are running UHD 3.8.2 for this to work. I assume that you're on Linux,
such as Ubuntu 14.04. Please let me know if you see better results with this
change, or if you have any problems making the code change. Thanks.
--Neel
On 27 March 2015 at 05:58, Damiano Scanferla via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I would like to achieve phase alignment at two receivers being 2 SBX-120
daughter-boards of either the same X310 or belonging to 2 different X310s.
I can measure the phase offset between the two receivers and compensate for it.
The problem is that the phase offset is not constant but it is drifting over
time. Of course I can do a periodic calibration of the receivers but I read in
several blogs that the phase offset should be constant so I am wondering what I
am not doing properly in my setup.
SETUP
An RF signal at 800 MHz or 2700 MHz is generated with a signal generator (R&S
SMJ100A) and fed to 2 daughter-boards via splitter and 2 cables of the same
length. At the receiving USRPs, I just measure the phase difference between the
samples received by receiver 1 and receiver 2 (phase offset). The USRPs get the
10 MHz ref and PPS from an OctoClock (both clock_source and time_source set to
"external", and sync set to "unknown PPS").
I have attached the "grc file" and the slope of the phase offset over 3 minutes
for the following configurations:
- 800 MHz, 2 SBX-120 in 1 X310
- 800 MHz, 1 SBX-120 in 2 different X310
- 2700 MHz, 2 SBX-120 in 1 X310
- 2700 MHz, 1 SBX-120 in 2 different X310
2 observations:
- the higher the frequency, the higher the phase drift (almost linear with
frequency). So, could it be due to a phase drift of the 10 MHz reference?
- the phase drift is lower when the 2 daughter-boards belong to the same X310.
Do you know what could be the reason for this? Have you ever seen such
behaviour?
Best regards,
Damiano
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/8d48b8b4/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 17 Apr 2015 12:20:14 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Clock selection between external and GPSDO
clocks
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Hanwen,
have you tried multi_usrp::set_clock_source("gpsdo") and
set_clock_source("external") [1]?
Generally, the N210 should have four possible values:
* internal (on-board oscillator)
* external (SMA connector)
* gpsdo (GPSDO) and
* mimo
You can query these using get_clock_sources[2].
Greetings,
Marcus
[1]
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a73ed40009d0d3787c183d42423d25026
[2]
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a3e1022d151717e49ce69c987bd07b243
On 04/17/2015 07:30 AM, hanwen via USRP-users wrote:
> Hi,
>
> I have some N210 with GPSDO inside. In UHD API, how I can select
> between external 10MH/1PPS from OctoClockG and the internal clock
> signals from GPSDO? I didn?t find any API that I could explicitly
> switch between the external and the GPSDO clocks.
>
>
> Cheers,
> Hanwen
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/bad54a10/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 17 Apr 2015 13:42:27 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Clock selection between external and GPSDO
clocks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi all,
N210 has manually switched clock source between "external" and "gpsdo"
with use of the J510 jumper (see 4th page of schematics
http://files.ettus.com/schematics/n200/n2xx.pdf).
I don't know to the full extent what
multi_usrp::set_clock_source("gpsdo") and set_clock_source("external")
commands do, but on hardware level it seems that they are equivalent.
This is the part usrp2_impl.cpp responsible for setting clock source in
USRP's N210 FPGA register:
case usrp2_iface::USRP_N210_R4:
if (source == "internal")
_mbc[mb].iface->poke32(U2_REG_MISC_CTRL_CLOCK, 0x12);
else if (source == "external")
_mbc[mb].iface->poke32(U2_REG_MISC_CTRL_CLOCK, 0x1C);
else if (source == "gpsdo")
_mbc[mb].iface->poke32(U2_REG_MISC_CTRL_CLOCK, 0x1C);
else if (source == "mimo")
_mbc[mb].iface->poke32(U2_REG_MISC_CTRL_CLOCK, 0x15);
Best Regards,
Piotr Krysik
W dniu 17.04.2015 o 12:20, Marcus M?ller via USRP-users pisze:
> Hi Hanwen,
>
> have you tried multi_usrp::set_clock_source("gpsdo") and
> set_clock_source("external") [1]?
> Generally, the N210 should have four possible values:
> * internal (on-board oscillator)
> * external (SMA connector)
> * gpsdo (GPSDO) and
> * mimo
>
> You can query these using get_clock_sources[2].
>
> Greetings,
> Marcus
> [1]
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a73ed40009d0d3787c183d42423d25026
> [2]
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a3e1022d151717e49ce69c987bd07b243
>
> On 04/17/2015 07:30 AM, hanwen via USRP-users wrote:
>> Hi,
>>
>> I have some N210 with GPSDO inside. In UHD API, how I can select
>> between external 10MH/1PPS from OctoClockG and the internal clock
>> signals from GPSDO? I didn?t find any API that I could explicitly
>> switch between the external and the GPSDO clocks.
>>
>>
>> Cheers,
>> Hanwen
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 16
Date: Fri, 17 Apr 2015 06:08:02 -0700
From: Dan Sego <[email protected]>
To: [email protected]
Subject: [USRP-users] N200 stability
Message-ID:
<CALGEVjs08Q=jacfbgaglq_vtyd3shz2qjcdtpqrtm+vlr+d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Good morning the list.
I have 2 N200s w/ WBX connected via MIMO cable with an internal GPSDO on
the master. I have attached calculated intra-channel and inter-channel
phase stability calculations on from a tone generator. The results over
approximately 100 seconds demonstrate about 0.15 radians of drift with
a fair amount of low frequency noise. The low frequency noise (1 Hz-ish) is
common to both channels.
Are these results consistent with expectations? I have also attached the
two channel code as I'm still not completely sure that I have configured
the clock correctly (and by coincidence just seeing hanwen's posted query,
in particular the option of GPSDO or? MIMO).
Any and all advice is appreciated. Thanks
Dan Sego
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/9f6c7ba4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Stability Measurements.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 107193 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/9f6c7ba4/attachment-0001.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dual_chan_development.cpp
Type: text/x-c++src
Size: 12925 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/9f6c7ba4/attachment-0001.cpp>
------------------------------
Message: 17
Date: Fri, 17 Apr 2015 10:14:24 -0500
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP UHD Library Release suggestion
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Hossein,
the requirement to install VC runtime is actually quite common, and if
we included it in our binaries, they'd become huge. Also, if you're a
developer there's a high chance those runtimes are already installed,
and for a lot of our users, that's true.
As for Boost, there's no reason for us to update that unless we run into
bugs or require more features, so we'll be sticking to our current
version for another while.
Regards,
Martin
On 17.04.2015 04:37, hossein talaiee via USRP-users wrote:
> I noticed that UHD.dll file linked dynamicly against VS C++ run-time
> library that make this dll needy of VS-C-Runtime installation to work,
> and I wonder why?
> Why when we can do it staticly and have an absolutely portable UHD driver!
>
> As a matter of fact, boost compile must be done with this option too
> that can be done with passing "runtime-link=static link=static" to b2
> command line of boost compile.
>
> Also, boost libraries updated now to 1.57 (1.58 also will be out very
> soon, they testing 1.58-RC version now), consider upgrading boost
> libraries in release version.
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 56, Issue 17
******************************************
