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: Fwd: Angle of Arrival Measurements (Michael Duckett)
2. Re: IOE Error Using USB 3.0 to Ethernet Adapter
(Jonathan Hedstrom)
3. Re: IOE Error Using USB 3.0 to Ethernet Adapter (Martin Braun)
4. Re: E312 Multiple Sample Rates in GNU Radio (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Wed, 13 Apr 2016 13:19:34 -0400
From: Michael Duckett <[email protected]>
To: Evan Merewether <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID:
<CAL8gsQS4erpPuY105_o6_4MmtHPB83A69N7qZ4=eeczwnnd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you everybody for the help and suggestions.
Yesterday we ran a few more tests near another radio tower. We were able to
extend the distance between the two antennas to about 90 cm using some SMA
cables that we had (we are getting more to give us the full distance we
want) and the frequency we were measuring was 104.9 MHz (wavelength is
about 285 cm). Unfortunately, we didn't have a rig set up for our B210 and
antennas, so we resorted to holding the B210 and antennas ourselves (will
this affect the signal received?). For the 0 degrees orientation, we were
getting phase offsets which were still out of range of the arcsin domain
even for the larger distance between the antennas. As we changed the
orientation, we noticed very small changes in the phase offset. The
majority of phase offsets were hanging around the pi/-pi boundary.
We then tried a few runs without the wires and instead tilted the antennas
outward so that the tips of the antennas were about 10 in. or 25.4 cm
apart. This seemed to give us mixed results. My partner would hold the
device in one location at the 0 degree orientation and find phase
differences out of range of the arcsin domain and then move to another
location (about a step away) and find measurements which were at least in
the arcsin domain (the calculated angles ranged from 40 to 90 degrees, so
they were way off still). So the results for that experiment were spotty.
what antenna type are you using?
We are using an omni-directional rubber ducky antenna.
Do you do any higher order tracking before or after converting the phase
> offset to an angle?
No, we are not. What do you mean by higher order tracking?
I'd really love to see multiple approaches at AoA being implemented, that
> will definitely be an interesting use case for both SDR in general, the
> USRP B210, and GNU Radio; I don't remember fully, but I think the cel-kit
> account on github has a gr-specest repo, where you can find a few examples
> of parametric spectrum estimators; amongst these MUSIC, an algorithm
> actually originating in the world of direction detection, applied to
> frequency estimation. It should be pretty straightforward to adapt the
> algorithm to spatial problems ? basically, you'd replace the estimated
> signal autocovariance matrix by a antenna cross-correlation matrix.
The MUSIC algorithm seems like something we should definitely try out.
First, height is your friend. Don?t think that getting closer to the
> station tower is better. The Tower probably is an array so you will not be
> in the main beam anyway. Find the tallest building in the area and ask if
> you can do your tests on their roof. A clear and open line of sight to the
> tower is your goal here.
I think we are going to look for a tall place today or tomorrow and try to
get measurements from there.
Third, is the signal really entering the antenna? Or is it coupling to the
> receiver. This can be easily tested by removing the antennas and verifying
> that the signals drop by at least 10 dB. The more it drops, the better
> your measurement. I would try and get at least 20 dB of isolation for a
> good AoA measurement.
When we took the antennas off the SMA cables, there was a significant drop
in dB across the whole bandwidth (at least 20 dB). So it seems like the
signal was entering the antenna.
We are going to try to run more tests soon and hopefully with a structure
which will hold together our B210, cables, and antennas. Thanks again for
the support.
Sincerely,
Michael Duckett
On Tue, Apr 12, 2016 at 9:59 AM, Evan Merewether via USRP-users <
[email protected]> wrote:
> Hi Michael,
>
>
>
> After a quick look, it seems that the methodology is sound, but you may
> have problems with the way you are testing. Here are a few things you can
> do to improve your measurements and test the performance.
>
>
>
> First, height is your friend. Don?t think that getting closer to the
> station tower is better. The Tower probably is an array so you will not be
> in the main beam anyway. Find the tallest building in the area and ask if
> you can do your tests on their roof. A clear and open line of sight to the
> tower is your goal here.
>
>
>
> Second, what else can the signal be bouncing off of? Is there a tall water
> tower nearby? Could you be seeing the effects of reflected signals? For
> this, again, height is your friend. By moving to a tall building, you will
> minimize the number and strength of possible reflective surfaces.
>
>
>
> Third, is the signal really entering the antenna? Or is it coupling to the
> receiver. This can be easily tested by removing the antennas and verifying
> that the signals drop by at least 10 dB. The more it drops, the better
> your measurement. I would try and get at least 20 dB of isolation for a
> good AoA measurement.
>
>
>
> Evan
>
>
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Marcus D. Leech via USRP-users
> *Sent:* Friday, April 08, 2016 3:17 PM
> *To:* [email protected]
> *Subject:* Re: [USRP-users] Fwd: Angle of Arrival Measurements
>
>
>
> On 04/08/2016 04:21 PM, Marcus M?ller via USRP-users wrote:
>
> Hi Michael,
>
>
>
> So, I'm currently having a look at your flow graphs; they look sound to
> me; especially the complex method (Which pretty much is equivalent to
> picking one frequency bin from the FFT, if you add a sharp bandpass filter,
> so that you only see one frequency) looks efficient. In fact, seeing both
> approaches in one place reminded me of OFDM radar, where one actually takes
> advantage of the
>
> I use the complex-conjugate method in astronomical interferometry, which
> is related to AoA, at least in an incidental sense--the emergence
> of fringes is due to change in phase due to change in arrival angle
> relative to the baseline between the antenna.
>
> I also just use it for measuring and/or looking-for phase-drift between
> two sources that should be phase-coherent.
>
>
> time/frequency structure of the signal, and, more elementarily, the fact
> that a shift in time domain is a modulation with an offset frequency in
> frequency domain. Maybe [1] is a bit of a fun read to you; for the angle of
> arrival problem (which for your approaches is really but a time offset
> problem), things boil down to:
> If [image: $x$]and [image: $y$]are the same signal, but [image:
> $y(t)=x(t-\tau)$]is delayed by [image: $\tau$], then their Fourier
> transforms [image: $X$]and [image: $Y$]are also the same but for the
> latter [image: $Y=e^{-j2\pi\tau f} X$]being the first modulated by a
> complex sinusoid. Estimating that sinusoid's frequency gives you the timing
> offset; you can get the "pure" tone by just dividing [image: $\frac YX$].
> Looking at the discrete signal case, note that the frequency resolution you
> can get depends on the DFT you're doing ? i.e. longer observation/larger
> DFT has a very positive effect on accuracy!
>
> I'd really love to see multiple approaches at AoA being implemented, that
> will definitely be an interesting use case for both SDR in general, the
> USRP B210, and GNU Radio; I don't remember fully, but I think the cel-kit
> account on github has a gr-specest repo, where you can find a few examples
> of parametric spectrum estimators; amongst these MUSIC, an algorithm
> actually originating in the world of direction detection, applied to
> frequency estimation. It should be pretty straightforward to adapt the
> algorithm to spatial problems ? basically, you'd replace the estimated
> signal autocovariance matrix by a antenna cross-correlation matrix.
>
> Best regards,
> Marcus
>
> [1] Braun, Martin. *Ofdm radar algorithms in mobile communication
> networks*. Diss. Karlsruhe, Karlsruher Institut f?r Technologie (KIT),
> Diss., 2014, 2014.
> http://d-nb.info/104838490X/34
>
> On 08.04.2016 21:15, Michael Duckett via USRP-users wrote:
>
> We are using two antennas on the same B210 and the distance between them
> is 7cm (the distance between the two "TX/RX" ports). We understand that
> this affects the measured phase difference and the further calculation for
> the AOA. For future tests we may try to widen the distance between the two
> antennas to half the wavelength (I think that would be around 1.3 to 1.7 m
> for FM radio station frequencies).
>
>
>
> This distance between the two antennas brings us to the first question.
> Because the distance between the antennas was small compared to half the
> wavelength of the frequency, the range of valid phase differences was
> shrunk, too. Most of the time when we were measuring we got phase
> differences which were out of range of the valid region. In one spot close
> to the tower, we positioned our antenna array at the 0 degree orientation
> and phase difference values which corresponded to 60-70 degrees. In
> another spot with the same orientation, we got phase difference values
> which were out of range. So when we rotated the antenna array, it was
> difficult to compared the AOA because most of the time that calculation
> wasn't possible. But we can see noticeable changes in the phase difference
> when rotating the array. But there doesn't seem to be an easily
> decipherable pattern to the error.
>
>
>
> We haven't been monitoring the time domain signal levels. We can try that
> next time, as well.
>
>
>
> On Fri, Apr 8, 2016 at 2:19 PM, Derek Kozel <[email protected]> wrote:
>
> Hello Michael,
>
> In addition to Alexander's good thoughts, are you monitoring the time
> domain signal levels to ensure that the receive gain is set appropriately?
> I see a QT GUI Sink (you may consider using the QT Frequency Sink), but it
> would be worth while looking at a QT Time Sink as well to see if you are
> clipping.
>
> Regards,
>
> Derek
>
>
>
>
>
> On Fri, Apr 8, 2016 at 10:28 AM, Alexander Levedahl via USRP-users <
> [email protected]> wrote:
>
> I do not have the ability to look at files right now so sorry if I am
> asking questions that are answered in the files.
>
> If you stand in one spot and rotate, is the error consistent? I.e., if
> you are pointing the array right at it, it shows the AOA as 60-70. If you
> change to pointing 30 degrees, does the AOA change to 90-100?
>
> Are the results consistent across restarting the B210? Depending on the
> answer to these questions, it may simply be a calibration problem. I.e.,
> when you turn it on there needs to be a calibration step.
>
> Finally, how many antennas are you using 2 or are you using multiple
> B210s? Is your antenna spaced appropriately for the operating frequency?
>
>
>
>
>
> On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via USRP-users <
> [email protected]> wrote:
>
> Hello,
>
>
>
> We are trying to measure the angle of arrival of FM using USRP B210. We
> have run into some problems with the measurements and hence we are writing
> this email. It would be nice if we can get some inputs from you on how to
> fix this issue. We have used two methods for computing the phase
> difference. We have used the first one most of the time. However, we are
> posting both the methods here for you to have a look.
>
>
>
> I have attached method 1 (phase_difference_probe.grc for probing and
> phase_difference_view.grc which provides a nice GUI to look at) and method
> 2 (complex_method.grc). Method 1 is based on the following "paper":
>
>
>
>
>
> http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
>
>
>
>
>
> We use these flow graphs and run them in another script which probes the
> "top_block" to get 500 samples which are then averaged to produce one data
> point.
>
>
>
> We also attach a diagram (AoA_Figure.pdf) which shows a basic idea of how
> the antennas and transmitter are setup and what the Angle of Arrival (AoA)
> is, when it comes to our measurements.
>
>
>
> We tried our code in two different situations. In our first test, our
> transmitter was another B210 and we were in an open field. The frequency we
> tried ranged from 200 MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
> difference and consequently our AoA measurement were not too far off, when
> the antenna array was facing the transmitter (i.e. at an expected AoA of 0
> degs). As we moved closer towards an AoA of +- 90 the accuracy of the
> measurement fell off. But the consistency of the 500 samples was still
> pretty good (we were getting a standard deviation under 0.10 radians).
>
>
>
> For our second test, we tried to get the AoA from FM radio towers. We got
> about 800-1000m away from a popular radio station tower and pointed the
> antenna array at the tower (expecting an AoA of around 0 degs). But we got
> measurements which were way off. We did this for a couple of different
> spots but the measurements were all over the place (the standard deviation
> for individual data points were pretty good but the measurement for the 0
> deg position at one spot was different for another spot around the tower).
> We did manege to get angle measurements at one point when we were about 800
> meters from the tower. The expected angle was 0 but we got 60 - 70 degrees
> as the measured angle. We also tried at other places, one was about 800 m
> from the tower and the other about 1200m. But both these places were
> problematic.
>
>
>
> It would be nice to get your inputs on the flow graphs. What are your
> thoughts about the flow graph? Do you see any glaring problems with the
> flow graph or with the set up? If you have any more questions about the
> setup then feel free to ask.
>
>
>
> Most of the information about the setup that we are using are in the
> attached grc files. Thanks a lot for all your time.
>
>
>
> Sincerely,
>
> Michael Duckett
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
>
> _______________________________________________
>
> 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/20160413/6c19bc6c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 583 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 590 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 526 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 657 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1170 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 1158 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 567 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 598 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/6c19bc6c/attachment-0015.png>
------------------------------
Message: 2
Date: Wed, 13 Apr 2016 12:28:14 -0600
From: Jonathan Hedstrom <[email protected]>
To: Alexander Levedahl <[email protected]>
Cc: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] IOE Error Using USB 3.0 to Ethernet Adapter
Message-ID:
<CADbMMAKzuJu_==gqFy-01go-C6rd6nfR0afjmY_G-=hvgys...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Zhihong,
FYI, I'm having very good success with using USB3.0 to gigabit ethernet
dongles. I'm able to run 16 USRP2's off of my laptop through two
USB3.0>gigE adapters + some ethernet switches. I'm on linux and have been
using Ubuntu 15.04/15.10/16.04, all 64 bit.
I've definitely had my share of problems with dongles though because some
of them are junk. The problems I've seen include a lot of errors like what
you've reported which seem to be caused by poor quality drivers hanging
(try unplugging and replugging them in so the driver re-loads). The driver
crashing can also be caused by overheating. I've also seen the cheaper
dongle chipsets create problems because they occasionally hiccup, creating
enough lag to generate underflows. I also agree with Marcus that some
chipsets re-order packets which is a deal breaker.
The best one I've owned so far is this $20 Anker one from amazon with a
Realtek RTL8153 chipset. It has an aluminum body and seems to dissipate
heat well.
http://www.amazon.com/Anker-Unibody-Aluminum-Ethernet-Supporting/dp/B00PC0H9IE?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_search_detailpage
The WEme WM-3464A has a Realtek RTL8153 chipset and worked really well
initially just like the Anker, but it seems to be overheating and hanging
now.
http://www.amazon.com/product-reviews/B00WHL9ENY/ref=cm_cr_dp_srch?filterByKeyword=chipset&search-alias=community-reviews
The "Cable Matters" has an ASIX AX88179 chipset. That one had the
out-of-sequence problems Marcus mentioned, plus it eventually died, most
likely from overheating. It has a plastic case so can't dissipate heat
easily.
http://www.amazon.com/Cable-Matters-SuperSpeed-Gigabit-Ethernet/dp/B00BBD7NFU?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_search_detailpage
So, my assessment is that you can use these USB3.0-to-gigE dongles and get
excellent performance (I've tested them within 98% of maximum ethernet
throughput), but you must choose one with a good chipset and drivers. The
Asix AX88179 should be avoided. The Realtek TRL8153 works well. If you
constantly push the dongle at >50% throughput you may have problems with
overheating, even with an aluminum body. Removing the case may be necessary
to improve cooling.
Good luck!
[ jonathan hedstrom ]
On Wed, Apr 13, 2016 at 6:45 AM, Alexander Levedahl via USRP-users <
[email protected]> wrote:
> Marcus Muller,
>
> You mention that the CPU intervenes when transferring data via USB 3.
> Does this happen to the B2xx USRPS?
>
> Thanks,
> Alex
>
> On Wed, Apr 13, 2016 at 4:30 AM, Marcus M?ller <[email protected]
> > wrote:
>
>> As the other Marcus wrote, there's several customers who've had terrible
>> experiences with USB3-to-gigabit network interfaces. The most important
>> reason is that their firmware or drivers reorder ethernet packets?, which
>> is OK when you're mainly doing TCP transfers over it (e.g. you use the
>> network interface to surf the web or exchange files with your company's
>> storage server), but for real-time protocols, that simply doesn't make any
>> sense. Hence, UHD can't work with that.
>>
>> Moreover, USB is a terrible protocol for encapsulating high-rate Network
>> transfers, because there's no automated DMA that could take the data from
>> the device to a specific position in RAM without the CPU and OS assisting
>> on every packet. The CPU overhead is substantial.
>>
>> I'm afraid the proper choice here is using a laptop with a Gigabit
>> Ethernet interface integrated directly into the mainboard's chipset or
>> attached via PCIexpress (and not attached internally via USB, as some
>> manufacturers have decided to do). Another option would be using an
>> ExpressCard adapter like [1] , but to be honest: I'd expect a notebook with
>> expresscard slot to have native gigabit ethernet, too.
>> Maybe you have a modern Macbook or another high-end laptop with
>> Thunderbolt? The Thunderbolt to Gigabit adapter apple sells should work ?
>> it internally uses a broadcom chipset attached via PCIe; I've never tested
>> that, though.
>> Also, there's external thunderbolt boxes that allow you to use arbitrary
>> PCIe cards, for example 10GE cards. Customers have done this with such a
>> box produced by Sonnet, to attach the X310 to their laptop using 10GE.
>>
>> Best regards,
>> Marcus
>>
>> ? in fact, together with a customer, I dug into the USB-network stack of
>> linux, and I'm pretty sure it's the firmware/USB device itself, not the
>> driver)
>>
>> [1] http://www.delock.de/produkte/G_66216/merkmale.html?setLanguage=en
>>
>>
>> On 13.04.2016 05:17, Zhihong Luo via USRP-users wrote:
>>
>> HI all,
>>
>> I tried to connect to X310 to the laptop using the 1 Gigabit Ethernet
>> port. I used a USB3.0 to Gigabit Ethernet Adapter for this because the
>> laptop has no ethernet ports. I set the ip address to 192.168.10.1 and
>> tried uhd_find_devices and ran into IOE error:
>>
>> linux; GNU C++ version 5.3.1 20160407; Boost_105800;
>> UHD_003.010.rfnoc-316-gb7546712
>>
>>
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>>
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>>
>> UHD Error:
>> x300 fw communication failure #2
>> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>> ^C
>>
>> The MTU is fixed as 1500. I tried to ping 192.168.10.1, there are
>> considerable percentage of packet loss (30%, 40% or more). Is it because I
>> neglected some special settings for laptops, or the speed of the adapter is
>> simply not fast enough (it claims to have Gigabit throughput though...) ?
>> Thanks in advance for any help.
>>
>> Thanks,
>> Zhihong
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> 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/20160413/d3a6e942/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 13 Apr 2016 15:28:28 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] IOE Error Using USB 3.0 to Ethernet Adapter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
To clarify,
the B-series USRPs were defined for USB, so we use USB libraries, and we
know it's USB. For the adapters, we assume a good Ethernet connection,
which the adapters might not provide (e.g., for the reasons Marcus
points out).
M
On 04/13/2016 05:45 AM, Alexander Levedahl via USRP-users wrote:
> Marcus Muller,
>
> You mention that the CPU intervenes when transferring data via USB 3.
> Does this happen to the B2xx USRPS?
>
> Thanks,
> Alex
>
> On Wed, Apr 13, 2016 at 4:30 AM, Marcus M?ller
> <[email protected] <mailto:[email protected]>> wrote:
>
> As the other Marcus wrote, there's several customers who've had
> terrible experiences with USB3-to-gigabit network interfaces. The
> most important reason is that their firmware or drivers reorder
> ethernet packets?, which is OK when you're mainly doing TCP
> transfers over it (e.g. you use the network interface to surf the
> web or exchange files with your company's storage server), but for
> real-time protocols, that simply doesn't make any sense. Hence, UHD
> can't work with that.
>
> Moreover, USB is a terrible protocol for encapsulating high-rate
> Network transfers, because there's no automated DMA that could take
> the data from the device to a specific position in RAM without the
> CPU and OS assisting on every packet. The CPU overhead is substantial.
>
> I'm afraid the proper choice here is using a laptop with a Gigabit
> Ethernet interface integrated directly into the mainboard's chipset
> or attached via PCIexpress (and not attached internally via USB, as
> some manufacturers have decided to do). Another option would be
> using an ExpressCard adapter like [1] , but to be honest: I'd expect
> a notebook with expresscard slot to have native gigabit ethernet, too.
> Maybe you have a modern Macbook or another high-end laptop with
> Thunderbolt? The Thunderbolt to Gigabit adapter apple sells should
> work ? it internally uses a broadcom chipset attached via PCIe; I've
> never tested that, though.
> Also, there's external thunderbolt boxes that allow you to use
> arbitrary PCIe cards, for example 10GE cards. Customers have done
> this with such a box produced by Sonnet, to attach the X310 to their
> laptop using 10GE.
>
> Best regards,
> Marcus
>
> ? in fact, together with a customer, I dug into the USB-network
> stack of linux, and I'm pretty sure it's the firmware/USB device
> itself, not the driver)
>
> [1] http://www.delock.de/produkte/G_66216/merkmale.html?setLanguage=en
>
>
> On 13.04.2016 05:17, Zhihong Luo via USRP-users wrote:
>> HI all,
>>
>> I tried to connect to X310 to the laptop using the 1 Gigabit
>> Ethernet port. I used a USB3.0 to Gigabit Ethernet Adapter for
>> this because the laptop has no ethernet ports. I set the ip
>> address to 192.168.10.1 and tried uhd_find_devices and ran into
>> IOE error:
>>
>> linux; GNU C++ version 5.3.1 20160407; Boost_105800;
>> UHD_003.010.rfnoc-316-gb7546712
>>
>>
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>>
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>>
>> UHD Error:
>> x300 fw communication failure #2
>> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>> ^C
>>
>> The MTU is fixed as 1500. I tried to ping 192.168.10.1, there are
>> considerable percentage of packet loss (30%, 40% or more). Is it
>> because I neglected some special settings for laptops, or the
>> speed of the adapter is simply not fast enough (it claims to have
>> Gigabit throughput though...) ? Thanks in advance for any help.
>>
>> Thanks,
>> Zhihong
>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Wed, 13 Apr 2016 15:36:47 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E312 Multiple Sample Rates in GNU Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
If those rates are multiples of each other, you can do that. E.g. 5 and
10 Msps. You should manually specify a master clock rate.
Cheers,
M
On 04/12/2016 03:40 PM, LB Belella via USRP-users wrote:
> Greetings all. Is it possible to set the sample rate for each RX
> channel of an E312 independently using the usrp_source driver? Looking
> at the uhd driver I can see there is a
> uhd::usrp::multi_usrp::set_rx_rate function that can take a channel
> index but it doesn't look like that translates into the gr-uhd wrapper.
> Is there another way to achieve this? I'm new to the USRP stuff and I
> was hoping someone could provide a little insight.
>
>
>
> Thanks in advance!
>
>
>
> lb
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
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 68, Issue 14
******************************************
