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. USRP2 and UHD 3.8.3 (Martin Braun)
2. Re: USRP2 and UHD 3.8.3 (Jonathan Hedstrom)
3. Re: USRP2 and UHD 3.8.3 (Ian Buckley)
4. Re: B200 Broadcast FM and other signals on airband (Marcus M?ller)
5. Re: B200 Broadcast FM and other signals on airband (Paul B)
6. X310 w/ UBX-160 failure (Nowlan, Sean)
7. Re: B200 Broadcast FM and other signals on airband
(Marcus D. Leech)
8. Re: X310 w/ UBX-160 failure (Michael West)
9. Re: X310 over PCIe Instability (The Tilla)
10. Re: Time of arrival of first sample in a 2 Rx setup (siva sankar)
11. Re: Time of arrival of first sample in a 2 Rx setup (siva sankar)
12. Re: Time of arrival of first sample in a 2 Rx setup
(Marcus M?ller)
13. Re: Sync issue between the two TX channels of X310
(Carel Combrink)
14. Re: Cannot find usrp e310 with uhd_find_devices (Ivan)
15. Re: time sync 2 ettus x310 (Sanjoy Basak)
16. Re: time sync 2 ettus x310 (Michael West)
17. Re: Sync issue between the two TX channels of X310 (Michael West)
18. Re: Cannot find usrp e310 with uhd_find_devices (Philip Balister)
19. Re: X310 w/ UBX-160 failure (Nowlan, Sean)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Apr 2015 10:12:07 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] USRP2 and UHD 3.8.3
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear USRP2 users,
(*Note:* this does not affect N2x0, or any other device! Only USRP2,
with the SD-Card).
The latest release (3.8.3) has an issue where UHD won't let you use
USRP2s. Apologies for missing that during testing and RC phases. Latest
maint (and master) contain a fix for this, and future releases will also
work.
If you need to run USRP 2 with a stable release, we recommend 3.8.2,
although the USRP2 code (both host- and FPGA-side) has not changed in a
long time, so older versions will also work.
So, what happened? Our latest release actually had some changes for
N2x0, mostly related to UBX fixes. As a consequence, we updated the N2x0
FPGA images, and increased the compat number. On USRP2, nothing was
changed at all, but due to shared host driver code, UHD is looking for
the same compat number on both devices. Since we didn't touch USRP2
specifically, it fell through in our testing.
This fix simply provides separate compat numbers for USRP2 and N2x0. The
actual FPGA image for USRP2 never changed, so you don't need to burn the
SD card for this. If you already did, that's also fine -- the current
FPGA images for USRP2 are legit.
Cheers,
Martin
------------------------------
Message: 2
Date: Thu, 23 Apr 2015 11:47:32 -0600
From: Jonathan Hedstrom <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 and UHD 3.8.3
Message-ID:
<CADbMMALktKO-tP6Gv=hvQmc=-dmfzlug52jfzfeey2j4egb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
Working on a MIMO project with eight USRP2's. I updated everything last
night to uhd.git/release_003_008_003-1 ('uhd_usrp_probe' reports
UHD_003.008.003-0-g87dfdc3c) and a custom FPGA image based on
fpga.git/UHD-3.8.3. Everything seems to be working correctly. Looking at
u2_core.v it seems that the compatibility version is correctly changed to
v11.1 (from 10.1 previously). What am I missing?
Is this only a problem if you're using the usrp2_fpga.bin image downloaded
with the uhd_images_downloader app? I didn't test this.
[ jonathan hedstrom ]
On Thu, Apr 23, 2015 at 11:12 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> Dear USRP2 users,
>
> (*Note:* this does not affect N2x0, or any other device! Only USRP2,
> with the SD-Card).
>
> The latest release (3.8.3) has an issue where UHD won't let you use
> USRP2s. Apologies for missing that during testing and RC phases. Latest
> maint (and master) contain a fix for this, and future releases will also
> work.
>
> If you need to run USRP 2 with a stable release, we recommend 3.8.2,
> although the USRP2 code (both host- and FPGA-side) has not changed in a
> long time, so older versions will also work.
>
> So, what happened? Our latest release actually had some changes for
> N2x0, mostly related to UBX fixes. As a consequence, we updated the N2x0
> FPGA images, and increased the compat number. On USRP2, nothing was
> changed at all, but due to shared host driver code, UHD is looking for
> the same compat number on both devices. Since we didn't touch USRP2
> specifically, it fell through in our testing.
>
> This fix simply provides separate compat numbers for USRP2 and N2x0. The
> actual FPGA image for USRP2 never changed, so you don't need to burn the
> SD card for this. If you already did, that's also fine -- the current
> FPGA images for USRP2 are legit.
>
> Cheers,
>
> Martin
>
> _______________________________________________
> 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/20150423/ec34f22e/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 23 Apr 2015 11:06:19 -0700
From: Ian Buckley <[email protected]>
To: Jonathan Hedstrom <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 and UHD 3.8.3
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Jonathon,
The source code for both USRP2 and N210 was updated at the same commit with the
new FPGA compat number (78eab419fdcdc18f4da8fd33f267af6c4d0494f6).
Hoever because nothing changed *functionally* on USRP2 someone forgot to
re-build USRP2 images for inclusion in the updated binary image package.
You are not affected because you build your FPGA from source?it only affects
(typical) users who get pre-built FPGA's from Ettus.
-Ian
On Apr 23, 2015, at 10:47 AM, Jonathan Hedstrom via USRP-users
<[email protected]> wrote:
> Hi Martin,
>
> Working on a MIMO project with eight USRP2's. I updated everything last night
> to uhd.git/release_003_008_003-1 ('uhd_usrp_probe' reports
> UHD_003.008.003-0-g87dfdc3c) and a custom FPGA image based on
> fpga.git/UHD-3.8.3. Everything seems to be working correctly. Looking at
> u2_core.v it seems that the compatibility version is correctly changed to
> v11.1 (from 10.1 previously). What am I missing?
>
> Is this only a problem if you're using the usrp2_fpga.bin image downloaded
> with the uhd_images_downloader app? I didn't test this.
>
> [ jonathan hedstrom ]
>
> On Thu, Apr 23, 2015 at 11:12 AM, Martin Braun via USRP-users
> <[email protected]> wrote:
> Dear USRP2 users,
>
> (*Note:* this does not affect N2x0, or any other device! Only USRP2,
> with the SD-Card).
>
> The latest release (3.8.3) has an issue where UHD won't let you use
> USRP2s. Apologies for missing that during testing and RC phases. Latest
> maint (and master) contain a fix for this, and future releases will also
> work.
>
> If you need to run USRP 2 with a stable release, we recommend 3.8.2,
> although the USRP2 code (both host- and FPGA-side) has not changed in a
> long time, so older versions will also work.
>
> So, what happened? Our latest release actually had some changes for
> N2x0, mostly related to UBX fixes. As a consequence, we updated the N2x0
> FPGA images, and increased the compat number. On USRP2, nothing was
> changed at all, but due to shared host driver code, UHD is looking for
> the same compat number on both devices. Since we didn't touch USRP2
> specifically, it fell through in our testing.
>
> This fix simply provides separate compat numbers for USRP2 and N2x0. The
> actual FPGA image for USRP2 never changed, so you don't need to burn the
> SD card for this. If you already did, that's also fine -- the current
> FPGA images for USRP2 are legit.
>
> Cheers,
>
> Martin
>
> _______________________________________________
> 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/20150423/6e819576/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 23 Apr 2015 20:27:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200 Broadcast FM and other signals on
airband
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Paul,
sorry to hear you're still in trouble; I'll try my best to help you,
though HDSDR and Windows are really not my forte.
Balint is currently not in office, so I can only give you my piece of
insight:
first of all, I'm a bit confused; your settings say you've got a
sampling rate of 16MS/s, and your center frequency is 120.8MHz, so your
observable spectrum should be 112.8MHz - 128.8MHz. However, HDSDR's
waterfall shows different frequency limits -- maybe there's some
sweeping or caching, or is maybe my definition of tuning and LO
frequency different from that of HDSDR?
I can, however, explain the incompatibility warning: HDSDR is linked
against a specific version of UHD, and can only work with exactly that
version of the UHD.dll, which is why Balint packages it with the whole
Extio framework. Installing a more modern version of UHD system-wide
doesn't help you, here, since HDSDR continues to use the packaged
UHD.dll. Thus, after installation of UHD and flashing of the images,
you've got "modern" FPGA and firmware on your B200, and "old" UHD
talking to the device -- which is what the error complains about.
Regarding your ghost signals: Those are interesting, though, if I read
that correctly, they are at -82dB, which is relatively little,
considering your 27dB gain. Can you try to disable AGC? If that's not
enough, my first guess would be to play around with gain: Too much gain
leads to spectral images[1], too little gain together with AGC might
over-emphasize spurs.
Greetings,
Marcus
[1] If you have a strong signal, and high gain, your amplifier, being
composed of nothing more than transistors, goes into saturation; the
transmission function then is no longer practically output = input *
gain ($y(t) = a x(t)$), but gets a quadratic term ($y(t) = ax(t) -
bx^2(t)$); now using the some properties of the trigonometric functions,
in this case $\sin \alpha \; \sin \beta = \frac{1}{2}\left(\cos
(\alpha-\beta) - \cos (\alpha+\beta)\right)$ applied to an input signal
$x(t) = \sin(f t)$, you'll notice that for $x^2 = \sin^2(ft)=
\sin(ft)\sin(ft) = \frac12 \left(\cos(ft-ft)-\cos(ft+ft)\right)$ you see
a signal with twice the input frequency. In fact, semiconductor mixers
are usually based on that principle, and thus are basically amplifiers
driven out of spec :)
On 04/23/2015 01:07 AM, Paul B via USRP-users wrote:
> Hi guys,
>
> My troubles seem to be at no end at the moment!
>
> After reinstalling my Windows 8.1 due to a hard drive change, i've
> been having trouble with my B200 on HDSDR using
> Balints ExtIO_USRP+FCD+RTL2832U + BorIP-1.6 BETA 3.
>
> Before re-installing Windows 8.1, i had no issues at all, but since
> re-installing, i've been getting what seem like ghost signals on
> airband. They appear from about 114MHz through to 128MHz. They appear
> to be broadcast FM, Trunking and MotoTRBO signals, though when i move
> the frequency slider, they vanish, only to reappear when i move
> further along the band.
>
> I've included a picture of the problem, and my settings in ExtIO:
>
> https://www.dropbox.com/s/o6u3oe83ch4gm9o/Signals.jpg?dl=0
>
> and my settings:
>
> https://www.dropbox.com/s/082d17pi0osnw36/Settings.jpg?dl=0
>
> I'm running the B200 over USB 3, and it's using 003.007.001, which
> unfortunately, i can't seem to upgrade due to getting an
> incompatability warning when trying to use HDSDR after upgrading.
> I've installed the B200 USB Driver, and in Device Manager, my device
> shows up as USRP B200.
>
> Does anyone have any idea what could be causing this problem, and any
> possible solution?
>
> Thanks for any help,
>
> Paul
>
>
>
> _______________________________________________
> 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/20150423/599d10f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-4.png
Type: image/png
Size: 1117 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/599d10f1/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-3.png
Type: image/png
Size: 1367 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/599d10f1/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-2.png
Type: image/png
Size: 1828 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/599d10f1/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-1.png
Type: image/png
Size: 1262 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/599d10f1/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-5.png
Type: image/png
Size: 2400 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/599d10f1/attachment-0009.png>
------------------------------
Message: 5
Date: Thu, 23 Apr 2015 21:43:48 +0100
From: Paul B <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B200 Broadcast FM and other signals on
airband
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Marcus,
Thank you for your advice and the explanation of the HDSDR/UHD incompatability.
Regarding the tuning, i believe that my centre frequency is 122.590MHz, and i
can tune to +/- 8MHz either side of that. I?m not completely sure though, as
i?m still rather new to the whole SDR scene, and the B200 is my first major SDR
since using the RTL Dongles.
I?ve managed to, i think, narrow down the problem to the computer i?m using. I
tried the B200 on my partners laptop, plugging it in, installing Balints ExtIO
package, zadig driver and libusb0 and it seemed to work fine. No ghost signals
at all. Admittedly it was using USB 2, but even when using USB 2 on my main
computer, i was still getting ghost signals.
The computer i use the B200 with is running the USB 3.0 Intel eXtensible host
controller, which i believe is compatible with the B200 series, and i?ve done a
complete fresh install of Windows 8.1, installing Balints package, and using
the zadig driver only, so i can?t see the error being within Windows.
I?ve also noticed they appear even with rather low gain, but only within 110MHz
? 135MHz region. I?ve not seen any signals above that, that shouldn?t be there.
Paul
From: Marcus M?llervia USRP-users
Sent: Thursday, April 23, 2015 7:27 PM
To: [email protected]
Subject: Re: [USRP-users] B200 Broadcast FM and other signals on airband
Hi Paul,
sorry to hear you're still in trouble; I'll try my best to help you, though
HDSDR and Windows are really not my forte.
Balint is currently not in office, so I can only give you my piece of insight:
first of all, I'm a bit confused; your settings say you've got a sampling rate
of 16MS/s, and your center frequency is 120.8MHz, so your observable spectrum
should be 112.8MHz - 128.8MHz. However, HDSDR's waterfall shows different
frequency limits -- maybe there's some sweeping or caching, or is maybe my
definition of tuning and LO frequency different from that of HDSDR?
I can, however, explain the incompatibility warning: HDSDR is linked against a
specific version of UHD, and can only work with exactly that version of the
UHD.dll, which is why Balint packages it with the whole Extio framework.
Installing a more modern version of UHD system-wide doesn't help you, here,
since HDSDR continues to use the packaged UHD.dll. Thus, after installation of
UHD and flashing of the images, you've got "modern" FPGA and firmware on your
B200, and "old" UHD talking to the device -- which is what the error complains
about.
Regarding your ghost signals: Those are interesting, though, if I read that
correctly, they are at -82dB, which is relatively little, considering your 27dB
gain. Can you try to disable AGC? If that's not enough, my first guess would be
to play around with gain: Too much gain leads to spectral images[1], too little
gain together with AGC might over-emphasize spurs.
Greetings,
Marcus
[1] If you have a strong signal, and high gain, your amplifier, being composed
of nothing more than transistors, goes into saturation; the transmission
function then is no longer practically output = input * gain (), but gets a
quadratic term (); now using the some properties of the trigonometric
functions, in this case applied to an input signal , you'll notice that for
you see a signal with twice the input frequency. In fact, semiconductor mixers
are usually based on that principle, and thus are basically amplifiers driven
out of spec :)
On 04/23/2015 01:07 AM, Paul B via USRP-users wrote:
Hi guys,
My troubles seem to be at no end at the moment!
After reinstalling my Windows 8.1 due to a hard drive change, i've been
having trouble with my B200 on HDSDR using Balints ExtIO_USRP+FCD+RTL2832U +
BorIP-1.6 BETA 3.
Before re-installing Windows 8.1, i had no issues at all, but since
re-installing, i've been getting what seem like ghost signals on airband. They
appear from about 114MHz through to 128MHz. They appear to be broadcast FM,
Trunking and MotoTRBO signals, though when i move the frequency slider, they
vanish, only to reappear when i move further along the band.
I've included a picture of the problem, and my settings in ExtIO:
https://www.dropbox.com/s/o6u3oe83ch4gm9o/Signals.jpg?dl=0
and my settings:
https://www.dropbox.com/s/082d17pi0osnw36/Settings.jpg?dl=0
I'm running the B200 over USB 3, and it's using 003.007.001, which
unfortunately, i can't seem to upgrade due to getting an incompatability
warning when trying to use HDSDR after upgrading.
I've installed the B200 USB Driver, and in Device Manager, my device shows up
as USRP B200.
Does anyone have any idea what could be causing this problem, and any
possible solution?
Thanks for any help,
Paul
_______________________________________________
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/20150423/0660a5f0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-4.png
Type: image/png
Size: 1117 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/0660a5f0/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-3.png
Type: image/png
Size: 1367 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/0660a5f0/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-2.png
Type: image/png
Size: 1828 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/0660a5f0/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-1.png
Type: image/png
Size: 1262 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/0660a5f0/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-5.png
Type: image/png
Size: 2400 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/0660a5f0/attachment-0009.png>
------------------------------
Message: 6
Date: Thu, 23 Apr 2015 21:33:52 +0000
From: "Nowlan, Sean" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] X310 w/ UBX-160 failure
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm having trouble getting an X310 to fully recognize an installed UBX-160
daughterboard. It looks like the board is recognized, but TX and RX frontends
are listed as "unknown". I am using the new 3.8.3 release and I flashed the
FPGA image that was fetched using uhd_images_downloader.
The output of uhd_usrp_probe can be found here: http://pastebin.com/ter7jGVs
Thanks,
Sean Nowlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/8b694529/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 23 Apr 2015 18:14:29 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200 Broadcast FM and other signals on
airband
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/23/2015 04:43 PM, Paul B via USRP-users wrote:
> Hi Marcus,
> Thank you for your advice and the explanation of the HDSDR/UHD
> incompatability.
> Regarding the tuning, i believe that my centre frequency is
> 122.590MHz, and i can tune to +/- 8MHz either side of that. I'm not
> completely sure though, as i'm still rather new to the whole SDR
> scene, and the B200 is my first major SDR since using the RTL Dongles.
> I've managed to, i think, narrow down the problem to the computer i'm
> using. I tried the B200 on my partners laptop, plugging it in,
> installing Balints ExtIO package, zadig driver and libusb0 and it
> seemed to work fine. No ghost signals at all. Admittedly it was using
> USB 2, but even when using USB 2 on my main computer, i was still
> getting ghost signals.
> The computer i use the B200 with is running the USB 3.0 Intel
> eXtensible host controller, which i believe is compatible with the
> B200 series, and i've done a complete fresh install of Windows 8.1,
> installing Balints package, and using the zadig driver only, so i
> can't see the error being within Windows.
> I've also noticed they appear even with rather low gain, but only
> within 110MHz -- 135MHz region. I've not seen any signals above that,
> that shouldn't be there.
> Paul
You may, then, not be dealing with intermodulation or other
non-linearity products at all then, but rather, spurs produced by your
computer,
and carried along the USB cable, or just plain radiated by your computer.
> *From:* Marcus M?llervia USRP-users <mailto:[email protected]>
> *Sent:* Thursday, April 23, 2015 7:27 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] B200 Broadcast FM and other signals on airband
> Hi Paul,
>
> sorry to hear you're still in trouble; I'll try my best to help you,
> though HDSDR and Windows are really not my forte.
> Balint is currently not in office, so I can only give you my piece of
> insight:
>
> first of all, I'm a bit confused; your settings say you've got a
> sampling rate of 16MS/s, and your center frequency is 120.8MHz, so
> your observable spectrum should be 112.8MHz - 128.8MHz. However,
> HDSDR's waterfall shows different frequency limits -- maybe there's
> some sweeping or caching, or is maybe my definition of tuning and LO
> frequency different from that of HDSDR?
>
> I can, however, explain the incompatibility warning: HDSDR is linked
> against a specific version of UHD, and can only work with exactly that
> version of the UHD.dll, which is why Balint packages it with the whole
> Extio framework. Installing a more modern version of UHD system-wide
> doesn't help you, here, since HDSDR continues to use the packaged
> UHD.dll. Thus, after installation of UHD and flashing of the images,
> you've got "modern" FPGA and firmware on your B200, and "old" UHD
> talking to the device -- which is what the error complains about.
>
> Regarding your ghost signals: Those are interesting, though, if I read
> that correctly, they are at -82dB, which is relatively little,
> considering your 27dB gain. Can you try to disable AGC? If that's not
> enough, my first guess would be to play around with gain: Too much
> gain leads to spectral images[1], too little gain together with AGC
> might over-emphasize spurs.
>
> Greetings,
> Marcus
>
> [1] If you have a strong signal, and high gain, your amplifier, being
> composed of nothing more than transistors, goes into saturation; the
> transmission function then is no longer practically output = input *
> gain ($y(t) = a x(t)$), but gets a quadratic term ($y(t) = ax(t) -
> bx^2(t)$); now using the some properties of the trigonometric
> functions, in this case $\sin \alpha \; \sin \beta =
> \frac{1}{2}\left(\cos (\alpha-\beta) - \cos (\alpha+\beta)\right)$
> applied to an input signal $x(t) = \sin(f t)$, you'll notice that for
> $x^2 = \sin^2(ft)= \sin(ft)\sin(ft) = \frac12
> \left(\cos(ft-ft)-\cos(ft+ft)\right)$ you see a signal with twice the
> input frequency. In fact, semiconductor mixers are usually based on
> that principle, and thus are basically amplifiers driven out of spec :)
>
>
> On 04/23/2015 01:07 AM, Paul B via USRP-users wrote:
>> Hi guys,
>> My troubles seem to be at no end at the moment!
>> After reinstalling my Windows 8.1 due to a hard drive change, i've
>> been having trouble with my B200 on HDSDR using Balints
>> ExtIO_USRP+FCD+RTL2832U + BorIP-1.6 BETA 3.
>> Before re-installing Windows 8.1, i had no issues at all, but since
>> re-installing, i've been getting what seem like ghost signals on
>> airband. They appear from about 114MHz through to 128MHz. They appear
>> to be broadcast FM, Trunking and MotoTRBO signals, though when i move
>> the frequency slider, they vanish, only to reappear when i move
>> further along the band.
>> I've included a picture of the problem, and my settings in ExtIO:
>> https://www.dropbox.com/s/o6u3oe83ch4gm9o/Signals.jpg?dl=0
>> and my settings:
>> https://www.dropbox.com/s/082d17pi0osnw36/Settings.jpg?dl=0
>> I'm running the B200 over USB 3, and it's using 003.007.001, which
>> unfortunately, i can't seem to upgrade due to getting an
>> incompatability warning when trying to use HDSDR after upgrading.
>> I've installed the B200 USB Driver, and in Device Manager, my device
>> shows up as USRP B200.
>> Does anyone have any idea what could be causing this problem, and any
>> possible solution?
>> Thanks for any help,
>> Paul
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ------------------------------------------------------------------------
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/58290368/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1117 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/58290368/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1367 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/58290368/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1828 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/58290368/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1262 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/58290368/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2400 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/58290368/attachment-0009.png>
------------------------------
Message: 8
Date: Thu, 23 Apr 2015 15:19:55 -0700
From: Michael West <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 w/ UBX-160 failure
Message-ID:
<CAM4xKrrSA=pDq9m3i2JMVr55_9d8cVoeGqn=0hz5d09zxte...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sean,
Yes, there is a known issue and we are scrambling to get the fix out. The
attached patch should fix the issue.
Regards,
Michael
On Thu, Apr 23, 2015 at 2:33 PM, Nowlan, Sean via USRP-users <
[email protected]> wrote:
> I?m having trouble getting an X310 to fully recognize an installed
> UBX-160 daughterboard. It looks like the board is recognized, but TX and RX
> frontends are listed as ?unknown?. I am using the new 3.8.3 release and I
> flashed the FPGA image that was fetched using uhd_images_downloader.
>
>
>
> The output of uhd_usrp_probe can be found here:
> http://pastebin.com/ter7jGVs
>
>
>
> Thanks,
>
> Sean Nowlan
>
> _______________________________________________
> 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/20150423/84b5c999/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_3_8_3_ubx.patch
Type: text/x-patch
Size: 486 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/84b5c999/attachment-0001.patch>
------------------------------
Message: 9
Date: Thu, 23 Apr 2015 18:59:29 -0400
From: "The Tilla" <[email protected]>
To: "'usrp-users'" <[email protected]>
Subject: Re: [USRP-users] X310 over PCIe Instability
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Latest update:
We went through all kinds of updates: system bios, NRIO, chipset driver, UHD,
etc.
Nothing helped.
THEN, started over again at the beginning with no updates and one of the guys
opened NIMax application (comes with NI-RIO package), then ran looping
initialization test. NEVER FAILED J
Also device initialization was almost twice as fast?
When NIMax is not running, device initialization is slowed quite a bit and
initialization failures were again apparent?
Thoughts?
From: [email protected] [mailto:[email protected]]
Sent: Friday, March 27, 2015 11:20 AM
To: [email protected]
Cc: usrp-users
Subject: Re: [USRP-users] X310 over PCIe Instability
Hi Neel,
I can not change this system to Ubuntu or do any of the things you outline.
My simple test program pseudocode that illustrates the problem is something
like this:
for( int I=0 ; I < 100 ; I++ )
{
usrp = uhd::multi_usrp::make( "resource=RIO0" );
Sleep( 5000 );
usrp->reset();
Sleep (5000);
}
On 3.8.1, the loop above would never get past 10 before failing. On 3.8.2, it
was better, but still encountered errors consistently.
I am trying to get a system setup on a more available platform to help
facilitate easier debugging, but that has been quite challenging.
Also, removing one of the WBX cards (so there is now only a single card) did
not fix the issue (something I figured I would try to see if there was some
sort of race condition initializing both boards)...
Any other suggestions to help debug this would be much appreciated.
I have purchased 10 devices at 8K per device makes 80K of hardware that I
cannot make use of... :(
Thanks.
_____
From: "tilla--- via USRP-users" <[email protected]>
To: "usrp-users" <[email protected]>
Sent: Monday, March 16, 2015 7:12:19 PM
Subject: Re: [USRP-users] X310 over PCIe Instability
I have verified our chipset is C600/X79...
Some more info:
I upgraded to 3.8.2 and it did offer some improvements.
Instead of getting 1 out of 3 failures for the 4 reasons listed previously, I
got about 2 out of 10 failures with the radio cntrl message timeout failure.
So there is some improvement, but still some gremlins in the mix.
My X310 has 2 WBX-120 daughter cards within.
Is there something else that I can do help trace this down? Only speculation
that comes to mind is some sort of race condition initializing the multiple
cards.
My system is win7, so no chance for an lshw results...
Let me know if you have any further thoughts...
_____
From: USRP-users [mailto:[email protected]] On Behalf Of Neel
Pandeya via USRP-users
Sent: Friday, February 27, 2015 3:55 PM
To: tilla
Cc: usrp-users
Subject: Re: [USRP-users] X310 over PCIe Instability
I looked at the specs for the HP Z820 at [1], and it looks like the Intel C602
system chipset is being used. I'd like to confirm the PCIe chipset. When you
get back in the office, please run "sudo lshw -html > system_config.html", and
post the HTML file to the mailing list.
[1] http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c04111177
On 27 February 2015 at 12:41, tilla <[email protected]> wrote:
I am out of the office for the next week, not sure of the chipset but these are
brand new high end HP Z820 machines.
I will check as soon as I get back.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Neel Pandeya
Date:02/27/2015 14:15 (GMT-05:00)
To: [email protected]
Cc: usrp-users ,Ashish Chaudhari
Subject: Re: [USRP-users] X310 over PCIe Instability
Some PCI-Express chipsets do not work as well as others. Results can vary
between chipsets. What motherboard and PCIe chipset are you using?? Could you
run "sudo lshw -html > system_config.html", and send the HTML file as an
attachment to the mailing list?
Here in the office, we have a system that works well with X310 over PCIe, with
the specifications below.
Dell Precision T3600
Intel Xeon CPU E5-1650 0 @ 3.20GHz
C600/X79 series chipset PCI Express Virtual Root Port
--Neel
On 25 February 2015 at 11:08, tilla--- via USRP-users
<[email protected]> wrote:
Peeps,
SW Platform:
UHD 3.8.1 64 bit
Windows 7 64 bit
VS 2013
Have a gaggle of N210s and X310s. All work flawlessly over Ethernet.
I have assessed going to PCIe on the X310s to lower latency of sample rx/tx.
We never have any problems over Ethernet initializing the devices.
Over PCI, the devices fail about 2 times out of 10 purely in the initialization
phase.
The equivalent code is something so simple like:
uhd::usrp::multi_usrp::make( "resource=RIO0" );
This fails for the following list of reasons:
_______________________________________________
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/20150423/573302e1/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 24 Apr 2015 11:15:55 +0530
From: siva sankar <[email protected]>
To: LOUF Laurent <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID:
<CAAubjiVDnpu2zb_DwOK=qod89fodjetkew-hk5pno_jxa0w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Marcus,
I am attaching the picture of the set up. The two receivers(Receiver 1 and
Receiver 2) shown in the picture are on one USRP B210. We are trying to
calculate the angle of arrival using the TDOA.
These are the equations being used:
Sin ?= S/L;
S = (TDOA)*Speed of light(C);
?=arcsin(((TDOA)*C)/L);
On Thu, Apr 23, 2015 at 7:38 PM, LOUF Laurent <[email protected]>
wrote:
> Hi,
>
>
>
> If you just want the time difference, you may want to compute the
> correlation between the two signals for different offsets (unit : samples)
> and find the offset that gives you the maximum of correlation (and then
> translate the number of samples into a time difference with the sampling
> frequency). If receivers are not too far away one from the other, I guess
> that could be a solution (to be investigated).
>
>
>
> Regards,
>
> Laurent.
>
>
>
>
>
> *De :* USRP-users [mailto:[email protected]] *De la part
> de* siva sankar via USRP-users
> *Envoy? :* jeudi 23 avril 2015 14:54
> *? :* Marcus M?ller
> *Cc :* [email protected]
> *Objet :* Re: [USRP-users] Time of arrival of first sample in a 2 Rx setup
>
>
>
> Hey Marcus,
>
> Thanks for the reply.
> The receivers here are at different distances from the transmitter and we
> are looking for the time difference of arrival of the samples at the
> receive buffers.
>
> How do we proceed with this ?
>
> Regards
> Siva
>
> Hello Siva,
> recv() will do an aligned reception, i.e. the first samples of both
> streams were received at the same time.
>
> Often, you don't want to *know* *afterwards* the time of reception, you
> want to *define* it beforehand. You can do that by using a stream_cmd
> with a stream_now = false and a timespec to allow you to define when the
> reception is going to take place.
>
> Greetings,
> Marcus
>
> On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
>
> Hello List,
>
>
>
> I am using USRP B210 and the UHD version is 003.008.000. We are
> transmitting on one channel and receiving simultaneously on both the
> channels and what we want is the time of arrival of the first sample in
> both the receive buffers.
>
>
>
> We have used the "time_spec_t" to get the time of the first sample but we
> don't know if the time that we are getting is for both the channels or for
> one of the receiver buffers.
>
>
>
> We have tried using two "recv" commands one for each buffer hoping we
> could calculate the time from each metadata parameter passed to the "recv"
> command in one thread but it throws "multi channel alignment" error and
> stops running.
>
>
>
> We also tried to create individual threads for both the rx channels and
> pass different metadata parameters and hence know the time of first sample
> for each buffer. However, this throws segmentation fault.
>
>
>
> Any help on how to calculate the time of first sample for each receive
> buffer will be appreciated.
>
>
>
> Thanks
>
> Siva.
>
>
>
> _______________________________________________
>
> 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
>
--
Thanks and regards
Siva Sankar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/3ce5f4b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1Tx2Rx.PNG
Type: image/png
Size: 38297 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/3ce5f4b1/attachment-0001.PNG>
------------------------------
Message: 11
Date: Fri, 24 Apr 2015 11:30:55 +0530
From: siva sankar <[email protected]>
To: LOUF Laurent <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID:
<caaubjivx6ber1jjdi6tf6bpd5xe4ecgcorihuisayug_pid...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Laurent,
Thanks for the suggestion infact this is what we initially tried to do but
we are not able to give the offset as we require high sampling rate which
on giving is throwing a sequence of L's(LLLLLLL...) .
Regards
Siva.
On Thu, Apr 23, 2015 at 7:38 PM, LOUF Laurent <[email protected]>
wrote:
> Hi,
>
>
>
> If you just want the time difference, you may want to compute the
> correlation between the two signals for different offsets (unit : samples)
> and find the offset that gives you the maximum of correlation (and then
> translate the number of samples into a time difference with the sampling
> frequency). If receivers are not too far away one from the other, I guess
> that could be a solution (to be investigated).
>
>
>
> Regards,
>
> Laurent.
>
>
>
>
>
> *De :* USRP-users [mailto:[email protected]] *De la part
> de* siva sankar via USRP-users
> *Envoy? :* jeudi 23 avril 2015 14:54
> *? :* Marcus M?ller
> *Cc :* [email protected]
> *Objet :* Re: [USRP-users] Time of arrival of first sample in a 2 Rx setup
>
>
>
> Hey Marcus,
>
> Thanks for the reply.
> The receivers here are at different distances from the transmitter and we
> are looking for the time difference of arrival of the samples at the
> receive buffers.
>
> How do we proceed with this ?
>
> Regards
> Siva
>
> Hello Siva,
> recv() will do an aligned reception, i.e. the first samples of both
> streams were received at the same time.
>
> Often, you don't want to *know* *afterwards* the time of reception, you
> want to *define* it beforehand. You can do that by using a stream_cmd
> with a stream_now = false and a timespec to allow you to define when the
> reception is going to take place.
>
> Greetings,
> Marcus
>
> On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
>
> Hello List,
>
>
>
> I am using USRP B210 and the UHD version is 003.008.000. We are
> transmitting on one channel and receiving simultaneously on both the
> channels and what we want is the time of arrival of the first sample in
> both the receive buffers.
>
>
>
> We have used the "time_spec_t" to get the time of the first sample but we
> don't know if the time that we are getting is for both the channels or for
> one of the receiver buffers.
>
>
>
> We have tried using two "recv" commands one for each buffer hoping we
> could calculate the time from each metadata parameter passed to the "recv"
> command in one thread but it throws "multi channel alignment" error and
> stops running.
>
>
>
> We also tried to create individual threads for both the rx channels and
> pass different metadata parameters and hence know the time of first sample
> for each buffer. However, this throws segmentation fault.
>
>
>
> Any help on how to calculate the time of first sample for each receive
> buffer will be appreciated.
>
>
>
> Thanks
>
> Siva.
>
>
>
> _______________________________________________
>
> 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
>
--
Thanks and regards
Siva Sankar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/9294d617/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 24 Apr 2015 08:58:55 +0200
From: Marcus M?ller <[email protected]>
To: siva sankar <[email protected]>, LOUF Laurent
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Siva,
ok, so you actually have one B210; that makes things easier, because
that is inherently in sync with itself :)
So what you'd have to do is (not tested, not complete):
stream_cmd_t start_cmd(STREAM_MODE_START_CONTINUOUS);
start_cmd.stream_now = false;
start_cmd.timespec = my_usrp->get_time_now() + time_spec_t(0.5); //start
in 0.5 seconds
stream_args_t str_args;
str_args.channels = boost::assign::list_of(0)(1);
rx_streamer::sptr rx = my_usrp->get_rx_streamer(str_args);
tx_streamer::sptr rx = my_usrp->get_tx_streamer(str_args);
rx->issue_stream_cmd(start_cmd);
tx->issue_stream_cmd(start_cmd);
//spawn two threads, or intermittently rx->recv() and tx->send()
//the first call to recv() and/or send() will possibly block until their
time has come.
Now you'll /know a priori/ that the timestamp of the first received
samples is what is in start_cmd.timespec. Since there is analog and DSP
delay in the B210, you will have to calibrate once for each sampling
rate / analog bandwidth / frequency combination you want to use.
Two things to notice:
1. you need a two-channel TX, because the AD9361 wants it that way; you
can't have 2xRX 1xTX, it needs to be 2xRX 2xTX or 1xRX 1xTX. Just set
zero gain for the channel you're not using, and send 0s.
2. both RX are running of the same LO, but a different oscillator than
TX; so you'll have to calibrate phase after every tune, because you
can't know which phase the TX LO has relative to the RX LO after a tune.
A clever way of doing this might be connecting an antenna at the
"unused" port, placing it in the middle between your two RX antennas,
and transmitting a short known sequence on it, detecting it with your RX
and estimating the phase offset between RX and TX with that -- you'd
also have a way of knowing the pure loopback delay in your current
configuration like this.
Best regards,
Marcus
On 04/24/2015 07:45 AM, siva sankar wrote:
> Hey Marcus,
>
> I am attaching the picture of the set up. The two receivers(Receiver 1
> and Receiver 2) shown in the picture are on one USRP B210. We are
> trying to calculate the angle of arrival using the TDOA.
> These are the equations being used:
> Sin ?= S/L;
> S = (TDOA)*Speed of light(C);
> ?=arcsin(((TDOA)*C)/L);
>
>
> On Thu, Apr 23, 2015 at 7:38 PM, LOUF Laurent
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hi,
>
>
>
> If you just want the time difference, you may want to compute the
> correlation between the two signals for different offsets (unit :
> samples) and find the offset that gives you the maximum of
> correlation (and then translate the number of samples into a time
> difference with the sampling frequency). If receivers are not too
> far away one from the other, I guess that could be a solution (to
> be investigated).
>
>
>
> Regards,
>
> Laurent.
>
>
>
>
>
> *De :*USRP-users [mailto:[email protected]
> <mailto:[email protected]>] *De la part de* siva
> sankar via USRP-users
> *Envoy? :* jeudi 23 avril 2015 14:54
> *? :* Marcus M?ller
> *Cc :* [email protected] <mailto:[email protected]>
> *Objet :* Re: [USRP-users] Time of arrival of first sample in a 2
> Rx setup
>
>
>
> Hey Marcus,
>
> Thanks for the reply.
> The receivers here are at different distances from the transmitter
> and we are looking for the time difference of arrival of the
> samples at the receive buffers.
>
> How do we proceed with this ?
>
> Regards
> Siva
>
> Hello Siva,
> recv() will do an aligned reception, i.e. the first samples of
> both streams were received at the same time.
>
> Often, you don't want to /know/ /afterwards/ the time of
> reception, you want to /define/ it beforehand. You can do that by
> using a stream_cmd with a stream_now = false and a timespec to
> allow you to define when the reception is going to take place.
>
> Greetings,
> Marcus
>
> On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
>
> Hello List,
>
>
>
> I am using USRP B210 and the UHD version is 003.008.000. We
> are transmitting on one channel and receiving simultaneously
> on both the channels and what we want is the time of arrival
> of the first sample in both the receive buffers.
>
>
>
> We have used the "time_spec_t" to get the time of the first
> sample but we don't know if the time that we are getting is
> for both the channels or for one of the receiver buffers.
>
>
>
> We have tried using two "recv" commands one for each buffer
> hoping we could calculate the time from each metadata
> parameter passed to the "recv" command in one thread but it
> throws "multi channel alignment" error and stops running.
>
>
>
> We also tried to create individual threads for both the rx
> channels and pass different metadata parameters and hence know
> the time of first sample for each buffer. However, this throws
> segmentation fault.
>
>
>
> Any help on how to calculate the time of first sample for each
> receive buffer will be appreciated.
>
>
>
> Thanks
>
> Siva.
>
>
>
> _______________________________________________
>
> 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
>
>
>
>
> --
> Thanks and regards
> Siva Sankar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/7be4e2a7/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 24 Apr 2015 11:48:15 +0200
From: Carel Combrink <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sync issue between the two TX channels of
X310
Message-ID:
<caaxnqaro2wgqxii6yhjj0j9xspf9ex-kgyyq2nmx-jittyj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
> To be clear, set_time_now() will cause the VITA times on the 2 radios of
>> the X310 to be different and is most likely the cause of the
>> synchronization issue. You must use set_time_next_pps() or
>> set_time_unknown_pps() to ensure the times are the same. It is highly
>> recommend to use set_time_unknown_pps() as it takes additional steps to
>> make sure the times are synchronized.
>>
>
>
Is there a way to synchronise the 2 radios without an external PPS? Is
there an internal PPS available to the daughter-boards when the clock is
set to "internal" on the mother-board? Or can we simulate something like
this?
We do have the Board Mounted GPSDO installed if that might help at all.
We have solved the problem before as mentioned with the OctoClock, but the
OctoClock is not available any more, and using the OctoClock to sync 2
radios on the same device is overkill.
Regards,
Carel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/563a5f26/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 24 Apr 2015 10:32:09 +0000 (UTC)
From: Ivan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot find usrp e310 with uhd_find_devices
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
I managed to make some progress thanks to the tips from Marcus and Neel.?I
modified slightly the build-gnuradio script to take -DENABLE_E300=ON option in
the uhd build function and then?I built everything again on the host PC.?
The E310 USRP is connected directly to the PC with a cross-over ethernet cable
and has a static IP address.I can now detect the E310 from the PC using
uhd_find_devices after I turn on the network mode on the E310.?However, I still
cannot run uhd_fft. When I ran it for the first time I got the error message:
"Runtime error: Expected?FPGA compatibility number 6.x but got 4.0. The FPGA
build is not compatible with the host code build"?
I copied the usrp_e310_fpga.bit file from /usr/local/share/uhd/images on the PC
to /usr/share/uhd/images on the E310 using scp. The old bit file was replaced
but I still kept a copy of it in a separate directory. I ran uhd_fft again and
this time I got a different error message: "e300_remote_codec_ctrl_impl
transaction failed".
Do I still have the compatibility problem or is it something else?
Ivan?
From: Neel Pandeya <[email protected]>
To: Ivan <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Wednesday, 22 April 2015 4:58 AM
Subject: Re: [USRP-users] Cannot find usrp e310 with uhd_find_devices
Hello Ivan:
I assume you're trying to run "uhd_find_devices" on the external host, running
Ubuntu 14.04. You need to have Network Mode enabled on your E310, and you also
need to build UHD on the external host with E310 support. By default, E310 is
not enabled when you build UHD. To enable E310 support, add "-DENABLE_E300=ON"
as an option when you invoke cmake. Please see the links below.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk_usage_uhd
--Neel
On 20 April 2015 at 22:44, Ivan via USRP-users <[email protected]>
wrote:
Hi,
I've recently started using an E310 USRP. I want to use some GNU radio examples
to generate and receive waveforms but the device is not being detected. I can
log on using both the console and ethernet port. I've configured the usrp to
use a static IP address and set it to 192.168.10.3. I can access this address
through ssh and pinging it also sends replies back. However, running
uhd_find_devices does not work. I get "no uhd devices found". Even when I
specify the address with uhd_find_devices --args="addr=192.168.10.3", I still
don't get anything.?
I use Ubuntu 14.04. I've installed gnuradio and uhd using the gnuradio build
script. When I run uhd_find_devices or uhd_fft, the uhd version that comes out
is UHD_003.008.003-137-g2f760ac0. I've also tried disabling the firewall with
sudo ufw disable, but that makes no difference. What else should I do?
Regards,Ivan
?
_______________________________________________
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/20150424/b3b13712/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 24 Apr 2015 14:10:01 +0200
From: Sanjoy Basak <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID:
<CAJPQ1a1jZT=nAg469=9ggunykoy5g1ep2rc-ab2xxbopwed...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Mr. Michael,
I have a stupid question. I don't really know how to apply the patch files.
I tried different ways to apply, but none of those worked well. I tried
with 'apply patch 'filename'' or git patch 'filename' on terminal; but
could not make it work.
I am actually using python file to operate usrp or simply with grc.
Could you please tell me how to apply the patch file now or what exactly I
need to modify with python? or what exactly I need to do.
Please let me know.
best regards
Sanjoy
On Wed, Apr 22, 2015 at 5:48 PM, Michael West <[email protected]>
wrote:
> Hi Sanjoy,
>
> I have attached the UHD patch that changes the ATR settings at the idle
> state to always enable frontend components for SBX and CBX daughter
> boards. Give it a try and let us know if it works for you.
>
> Regards,
> Michael
>
> On Wed, Apr 22, 2015 at 2:36 AM, Sanjoy Basak <[email protected]>
> wrote:
>
>> Dear Mr. Michael,
>> Thank you very much for the reply. I am putting all the information here
>> regarding usrp.
>>
>> daughter board: SBX-120
>> UHD version: UHD_003.008.002-80-ge28d7844
>>
>> I am attaching here a pdf which includes all other information of the
>> usrp. Please send me the patch and other instruction and suggestion.
>> Have a nice day.
>>
>> best regards
>> Sanjoy
>>
>>
>> On Wed, Apr 22, 2015 at 2:29 AM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Sanjoy,
>>>
>>> The distortion may be due to the fact that some frontend components are
>>> disabled or powered down while not transmitting or receiving and take a
>>> little time to settle when enabled or powered up. For the X310, there are
>>> 3 ways around this:
>>>
>>> 1) Start TX and RX earlier and throw away RX data (as you have done)
>>> 2) Modify ATR settings dynamically so the frontend components stay
>>> powered on and enabled. This can be done by using the
>>> multi_usrp::set_gpio_attr() method. The banks are RX0, RX1, TX0, and TX1.
>>> You can accomplish this by adding the following lines to your code:
>>> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>>> "ATR_XX", 0), ~0, 0);
>>> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>>> "ATR_XX", 0), ~0, 0);
>>> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>>> "ATR_XX", 0), ~0, 0);
>>> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>>> "ATR_XX", 0), ~0, 0);
>>> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>>> "ATR_XX", 1), ~0, 1);
>>> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>>> "ATR_XX", 1), ~0, 1);
>>> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>>> "ATR_XX", 1), ~0, 1);
>>> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>>> "ATR_XX", 1), ~0, 1);
>>> *Note that changing the antenna or gain settings may overwrite these
>>> values.
>>> 3) Modify ATR settings in UHD code. This is done by editing the UHD
>>> code for the specific daughter board to change the ATR settings.
>>>
>>> Option #3 is the one that has worked the best for most users. If you
>>> let me know what daughter card and UHD version you are using, I may be able
>>> to provide you with a UHD patch.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 1:34 AM, Sanjoy Basak via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Dear Mr. Martin,
>>>> Thanks for the reply. Yes, right now I am not using octoclock, so the
>>>> problem while using 2 USRPsis understandable.
>>>>
>>>> However, regarding distortion, yes I am having distortion at the
>>>> beginning when I am using one usrp for SISO case for x310. I found this
>>>> problem even in b210 as well. I wonder why no one discussed or how did they
>>>> actually solved for radar uses. But I hope I would get my solution here.
>>>>
>>>>
>>>> [image: Inline image 1]
>>>> This is a figure of xcorr of rx and tx signal. The red marked
>>>> distortion I am having almost always. I don't know the reason. If I drop
>>>> few bins in my binary file and then start receiving my signal then I am
>>>> getting an undistorted signal looks like the following.( I am transmitting
>>>> and receiving using binary file).
>>>> However, dropping bins is undesirable for radar application.
>>>> [image: Inline image 3]
>>>> If I use the distorted frame, as obvious I get distorted result.
>>>> However, after dropping bins the fresh frame gives me the exact result
>>>> after signal processing in matlab.
>>>> Can you please tell me how to avoid this distortion at the beginning?
>>>>
>>>> best regards
>>>> Sanjoy
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Sanjoy,
>>>>>
>>>>> if you want to do radar, you need to make sure both devices are
>>>>> connected to the same external reference. For radar, you can't run off
>>>>> of separate clocks.
>>>>>
>>>>> We've confirmed timing accuracy across devices on the nanosecond scale
>>>>> in the past (using OctoClocks for clock distribution).
>>>>>
>>>>> Cheers,
>>>>> M
>>>>>
>>>>> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
>>>>> > Hi all,
>>>>> > I am trying to sync 2 ettus x310 in time. However, I am always
>>>>> having a
>>>>> > distortion at the beginning after receiving, and there is always a
>>>>> > delay of few microseconds between the tx and rx. I put tx in one x310
>>>>> > and rx in another x310 and its in a wired connection. GPS antenna is
>>>>> > connected to one usrp(with Tx) and another one is on external
>>>>> ref(Rx).
>>>>> >
>>>>> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
>>>>> > then I am compensating it making it set_start_time both at for 4s. So
>>>>> > ideally I should get time synced tx and rx signal.
>>>>> >
>>>>> > But I am getting distortion in Rx signal for 2seconds at the
>>>>> beginning;
>>>>> > this is constant for every sampling freq; so if in that region I
>>>>> have my
>>>>> > rx signal I can't retrieve that as the distortion is already
>>>>> introduced
>>>>> > there.
>>>>> > As I am trying to implement radar with x310, this is a serious
>>>>> problem
>>>>> > for me. As within first 2 seconds and few microseconds I can't
>>>>> receive
>>>>> > anything.
>>>>> >
>>>>> > I would really appreciate any kind of suggestion that come through.
>>>>> If
>>>>> > anyone have question regarding setup or python code please ask.
>>>>> > Thanks for reading.
>>>>> >
>>>>> > Best regards
>>>>> > Sanjoy
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > USRP-users mailing list
>>>>> > [email protected]
>>>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> >
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/f90fcbf3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/f90fcbf3/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/f90fcbf3/attachment-0003.jpg>
------------------------------
Message: 16
Date: Fri, 24 Apr 2015 05:56:34 -0700
From: Michael West <[email protected]>
To: Sanjoy Basak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID:
<CAM4xKrpGAavLwKYBiO+oaAskNr3Ggcat29XGe+ExqZjU=kk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sanjoy,
Go to the top of the UHD source directory and type "git apply <patch>".
Then follow the instructions to build and install from the source:
http://files.ettus.com/manual/page_build_guide.html
(In Linux, it should be as simple as navigating to the UHD build directory
and typing "sudo make install".)
Regards,
Michael
On Fri, Apr 24, 2015 at 5:10 AM, Sanjoy Basak <[email protected]>
wrote:
> Dear Mr. Michael,
> I have a stupid question. I don't really know how to apply the patch
> files. I tried different ways to apply, but none of those worked well. I
> tried with 'apply patch 'filename'' or git patch 'filename' on terminal;
> but could not make it work.
> I am actually using python file to operate usrp or simply with grc.
> Could you please tell me how to apply the patch file now or what exactly I
> need to modify with python? or what exactly I need to do.
> Please let me know.
>
> best regards
> Sanjoy
>
> On Wed, Apr 22, 2015 at 5:48 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Sanjoy,
>>
>> I have attached the UHD patch that changes the ATR settings at the idle
>> state to always enable frontend components for SBX and CBX daughter
>> boards. Give it a try and let us know if it works for you.
>>
>> Regards,
>> Michael
>>
>> On Wed, Apr 22, 2015 at 2:36 AM, Sanjoy Basak <[email protected]>
>> wrote:
>>
>>> Dear Mr. Michael,
>>> Thank you very much for the reply. I am putting all the information here
>>> regarding usrp.
>>>
>>> daughter board: SBX-120
>>> UHD version: UHD_003.008.002-80-ge28d7844
>>>
>>> I am attaching here a pdf which includes all other information of the
>>> usrp. Please send me the patch and other instruction and suggestion.
>>> Have a nice day.
>>>
>>> best regards
>>> Sanjoy
>>>
>>>
>>> On Wed, Apr 22, 2015 at 2:29 AM, Michael West <[email protected]>
>>> wrote:
>>>
>>>> Hi Sanjoy,
>>>>
>>>> The distortion may be due to the fact that some frontend components are
>>>> disabled or powered down while not transmitting or receiving and take a
>>>> little time to settle when enabled or powered up. For the X310, there are
>>>> 3 ways around this:
>>>>
>>>> 1) Start TX and RX earlier and throw away RX data (as you have done)
>>>> 2) Modify ATR settings dynamically so the frontend components stay
>>>> powered on and enabled. This can be done by using the
>>>> multi_usrp::set_gpio_attr() method. The banks are RX0, RX1, TX0, and TX1.
>>>> You can accomplish this by adding the following lines to your code:
>>>> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>>>> "ATR_XX", 0), ~0, 0);
>>>> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>>>> "ATR_XX", 0), ~0, 0);
>>>> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>>>> "ATR_XX", 0), ~0, 0);
>>>> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>>>> "ATR_XX", 0), ~0, 0);
>>>> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>>>> "ATR_XX", 1), ~0, 1);
>>>> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>>>> "ATR_XX", 1), ~0, 1);
>>>> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>>>> "ATR_XX", 1), ~0, 1);
>>>> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>>>> "ATR_XX", 1), ~0, 1);
>>>> *Note that changing the antenna or gain settings may overwrite these
>>>> values.
>>>> 3) Modify ATR settings in UHD code. This is done by editing the UHD
>>>> code for the specific daughter board to change the ATR settings.
>>>>
>>>> Option #3 is the one that has worked the best for most users. If you
>>>> let me know what daughter card and UHD version you are using, I may be able
>>>> to provide you with a UHD patch.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>>
>>>> On Tue, Apr 21, 2015 at 1:34 AM, Sanjoy Basak via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Dear Mr. Martin,
>>>>> Thanks for the reply. Yes, right now I am not using octoclock, so the
>>>>> problem while using 2 USRPsis understandable.
>>>>>
>>>>> However, regarding distortion, yes I am having distortion at the
>>>>> beginning when I am using one usrp for SISO case for x310. I found this
>>>>> problem even in b210 as well. I wonder why no one discussed or how did
>>>>> they
>>>>> actually solved for radar uses. But I hope I would get my solution here.
>>>>>
>>>>>
>>>>> [image: Inline image 1]
>>>>> This is a figure of xcorr of rx and tx signal. The red marked
>>>>> distortion I am having almost always. I don't know the reason. If I drop
>>>>> few bins in my binary file and then start receiving my signal then I am
>>>>> getting an undistorted signal looks like the following.( I am transmitting
>>>>> and receiving using binary file).
>>>>> However, dropping bins is undesirable for radar application.
>>>>> [image: Inline image 3]
>>>>> If I use the distorted frame, as obvious I get distorted result.
>>>>> However, after dropping bins the fresh frame gives me the exact result
>>>>> after signal processing in matlab.
>>>>> Can you please tell me how to avoid this distortion at the beginning?
>>>>>
>>>>> best regards
>>>>> Sanjoy
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Sanjoy,
>>>>>>
>>>>>> if you want to do radar, you need to make sure both devices are
>>>>>> connected to the same external reference. For radar, you can't run off
>>>>>> of separate clocks.
>>>>>>
>>>>>> We've confirmed timing accuracy across devices on the nanosecond scale
>>>>>> in the past (using OctoClocks for clock distribution).
>>>>>>
>>>>>> Cheers,
>>>>>> M
>>>>>>
>>>>>> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
>>>>>> > Hi all,
>>>>>> > I am trying to sync 2 ettus x310 in time. However, I am always
>>>>>> having a
>>>>>> > distortion at the beginning after receiving, and there is always a
>>>>>> > delay of few microseconds between the tx and rx. I put tx in one
>>>>>> x310
>>>>>> > and rx in another x310 and its in a wired connection. GPS antenna is
>>>>>> > connected to one usrp(with Tx) and another one is on external
>>>>>> ref(Rx).
>>>>>> >
>>>>>> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
>>>>>> > then I am compensating it making it set_start_time both at for 4s.
>>>>>> So
>>>>>> > ideally I should get time synced tx and rx signal.
>>>>>> >
>>>>>> > But I am getting distortion in Rx signal for 2seconds at the
>>>>>> beginning;
>>>>>> > this is constant for every sampling freq; so if in that region I
>>>>>> have my
>>>>>> > rx signal I can't retrieve that as the distortion is already
>>>>>> introduced
>>>>>> > there.
>>>>>> > As I am trying to implement radar with x310, this is a serious
>>>>>> problem
>>>>>> > for me. As within first 2 seconds and few microseconds I can't
>>>>>> receive
>>>>>> > anything.
>>>>>> >
>>>>>> > I would really appreciate any kind of suggestion that come through.
>>>>>> If
>>>>>> > anyone have question regarding setup or python code please ask.
>>>>>> > Thanks for reading.
>>>>>> >
>>>>>> > Best regards
>>>>>> > Sanjoy
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > USRP-users mailing list
>>>>>> > [email protected]
>>>>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>> >
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/975ca84b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/975ca84b/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/975ca84b/attachment-0003.jpg>
------------------------------
Message: 17
Date: Fri, 24 Apr 2015 05:58:40 -0700
From: Michael West <[email protected]>
To: Carel Combrink <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sync issue between the two TX channels of
X310
Message-ID:
<cam4xkrqqck5ah+h9coqoppaavcuhtqpt0cbbrcci6shw7ga...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Carel,
Yes, the X310 has an internal PPS. So, just set the time source to
"internal" and call set_time_unknown_pps() and you should be fine.
Regards,
Michael
On Fri, Apr 24, 2015 at 2:48 AM, Carel Combrink <[email protected]>
wrote:
> Hi Michael,
>
>
>> To be clear, set_time_now() will cause the VITA times on the 2 radios of
>>> the X310 to be different and is most likely the cause of the
>>> synchronization issue. You must use set_time_next_pps() or
>>> set_time_unknown_pps() to ensure the times are the same. It is highly
>>> recommend to use set_time_unknown_pps() as it takes additional steps to
>>> make sure the times are synchronized.
>>>
>>
>>
>
> Is there a way to synchronise the 2 radios without an external PPS? Is
> there an internal PPS available to the daughter-boards when the clock is
> set to "internal" on the mother-board? Or can we simulate something like
> this?
>
> We do have the Board Mounted GPSDO installed if that might help at all.
>
> We have solved the problem before as mentioned with the OctoClock, but the
> OctoClock is not available any more, and using the OctoClock to sync 2
> radios on the same device is overkill.
>
> Regards,
> Carel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150424/0a7b37f5/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 24 Apr 2015 10:19:10 -0400
From: Philip Balister <[email protected]>
To: Ivan <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Cannot find usrp e310 with uhd_find_devices
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/24/2015 06:32 AM, Ivan via USRP-users wrote:
> I managed to make some progress thanks to the tips from Marcus and Neel. I
> modified slightly the build-gnuradio script to take -DENABLE_E300=ON option
> in the uhd build function and then I built everything again on the host PC.
> The E310 USRP is connected directly to the PC with a cross-over ethernet
> cable and has a static IP address.I can now detect the E310 from the PC using
> uhd_find_devices after I turn on the network mode on the E310. However, I
> still cannot run uhd_fft. When I ran it for the first time I got the error
> message: "Runtime error: Expected FPGA compatibility number 6.x but got 4.0.
> The FPGA build is not compatible with the host code build"
> I copied the usrp_e310_fpga.bit file from /usr/local/share/uhd/images on the
> PC to /usr/share/uhd/images on the E310 using scp. The old bit file was
> replaced but I still kept a copy of it in a separate directory. I ran uhd_fft
> again and this time I got a different error message:
> "e300_remote_codec_ctrl_impl transaction failed".
> Do I still have the compatibility problem or is it something else?
The key thing is the version of uhd on the e310 must match the version
on the PC. Otherwise you see this sort of trouble.
I realize we haven't done a great job (to date) with the version on
images being easy to match with a uhd release. That said, the last set
of test images I posted have uhd-3.8.3 (with no funny stuff).
If I was trying to get network mode running, I'd write
sdimage-gnuradio-dev.direct.xz to an 8G usd card with bmaptool[1], then
install uhd-3.8.3 on my host computer. This should work.
Philip
[1]
http://gnuradio.org/redmine/projects/gnuradio/wiki/Copy_an_image_file_to_the_SD_card
> Ivan
> From: Neel Pandeya <[email protected]>
> To: Ivan <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Sent: Wednesday, 22 April 2015 4:58 AM
> Subject: Re: [USRP-users] Cannot find usrp e310 with uhd_find_devices
>
> Hello Ivan:
>
> I assume you're trying to run "uhd_find_devices" on the external host,
> running Ubuntu 14.04. You need to have Network Mode enabled on your E310, and
> you also need to build UHD on the external host with E310 support. By
> default, E310 is not enabled when you build UHD. To enable E310 support, add
> "-DENABLE_E300=ON" as an option when you invoke cmake. Please see the links
> below.
>
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
>
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk_usage_uhd
>
> --Neel
>
>
>
> On 20 April 2015 at 22:44, Ivan via USRP-users <[email protected]>
> wrote:
>
>
>
> Hi,
>
> I've recently started using an E310 USRP. I want to use some GNU radio
> examples to generate and receive waveforms but the device is not being
> detected. I can log on using both the console and ethernet port. I've
> configured the usrp to use a static IP address and set it to 192.168.10.3. I
> can access this address through ssh and pinging it also sends replies back.
> However, running uhd_find_devices does not work. I get "no uhd devices
> found". Even when I specify the address with uhd_find_devices
> --args="addr=192.168.10.3", I still don't get anything.
> I use Ubuntu 14.04. I've installed gnuradio and uhd using the gnuradio build
> script. When I run uhd_find_devices or uhd_fft, the uhd version that comes
> out is UHD_003.008.003-137-g2f760ac0. I've also tried disabling the firewall
> with sudo ufw disable, but that makes no difference. What else should I do?
> Regards,Ivan
>
> _______________________________________________
> 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: 19
Date: Fri, 24 Apr 2015 14:43:44 +0000
From: "Nowlan, Sean" <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 w/ UBX-160 failure
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Thanks! I?ll just wait for it to find its way onto git master.
Sean
From: Michael West [mailto:[email protected]]
Sent: Thursday, April 23, 2015 6:20 PM
To: Nowlan, Sean
Cc: [email protected]
Subject: Re: [USRP-users] X310 w/ UBX-160 failure
Hi Sean,
Yes, there is a known issue and we are scrambling to get the fix out. The
attached patch should fix the issue.
Regards,
Michael
On Thu, Apr 23, 2015 at 2:33 PM, Nowlan, Sean via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
I?m having trouble getting an X310 to fully recognize an installed UBX-160
daughterboard. It looks like the board is recognized, but TX and RX frontends
are listed as ?unknown?. I am using the new 3.8.3 release and I flashed the
FPGA image that was fetched using uhd_images_downloader.
The output of uhd_usrp_probe can be found here: http://pastebin.com/ter7jGVs
Thanks,
Sean Nowlan
_______________________________________________
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/20150424/8597fa7c/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 56, Issue 24
******************************************
