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. Switching daughterboards (Eric C.)
2. Re: Switching daughterboards ([email protected])
3. Re: Power management E310 (Philip Balister)
4. Re: Switching daughterboards (Eric C.)
5. Re: X310 RFNOC getting UHD to recognize new RFNOC block
(James Wagner)
6. Re: Switching daughterboards (Marcus D. Leech)
7. Disabling GPS-DO (Eric C.)
8. Re: Disabling GPS-DO (Marcus D. Leech)
9. Questions Regarding Ubuntu 16.04 and B200mini
([email protected])
10. Re: Questions Regarding Ubuntu 16.04 and B200mini (Derek Kozel)
11. Re: Effective a length of VERT2450 antenna and its impact on
receiving signal. (Jeon)
12. Tooling for connector on B200mini (Mark Napier)
13. Re: Unable to load rfnoc-radio-redo bit file into E310
(Joshua Monson)
14. USRP B210 Overflow (=?ISO-8859-1?B?aWxsdWFudGlzaW9u?=)
15. Re: USRP B210 Overflow (Anon Lister)
16. Re: Tooling for connector on B200mini (Dan CaJacob)
17. Re: Tooling for connector on B200mini (Mark Napier)
18. Re: Tooling for connector on B200mini (Dan CaJacob)
19. Re N210 interfacing issue (avinash kalyanaraman)
20. Re: Re N210 interfacing issue (Marcus M?ller)
21. Re: Unable to load rfnoc-radio-redo bit file into E310
(Jonathon Pendlum)
22. Re: USRP B210 Overflow (Marcus M?ller)
23. Re: Unable to load rfnoc-radio-redo bit file into E310
(Joshua Monson)
24. Re: Unable to load rfnoc-radio-redo bit file into E310
(Joshua Monson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Jun 2016 13:49:40 -0600
From: "Eric C." <[email protected]>
To: [email protected]
Subject: [USRP-users] Switching daughterboards
Message-ID:
<cabf-ja5nggzkcegbfkqagvohcvz5t6dpsaghmjdl1qw4cwj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have two USRPs with two different daughterboards. Unfortunately I damaged
one USRP, so I have to swap the daughtercards to continue using the other
one. I don't see any instructions online, is there anything that's not
straightforward that I should be aware of?
-- Eric C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/a1741276/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 16 Jun 2016 15:57:56 -0400
From: [email protected]
To: "Eric C." <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Switching daughterboards
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
What type of USRP do you have, and what kind of daughtercards? Should
be straightforward swap.
On 2016-06-16 15:49, Eric C. via USRP-users wrote:
> I have two USRPs with two different daughterboards. Unfortunately I damaged
> one USRP, so I have to swap the daughtercards to continue using the other
> one. I don't see any instructions online, is there anything that's not
> straightforward that I should be aware of?
>
> -- Eric C.
> _______________________________________________
> 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/20160616/8baa9ea0/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 16 Jun 2016 16:06:41 -0400
From: Philip Balister <[email protected]>
To: Claudio Cicconetti <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Power management E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/16/2016 05:25 AM, Claudio Cicconetti via USRP-users wrote:
> Dear all,
> Has anybody tried to user power management on an E310?
>
> I would like to suspend Linux, then resume based on certain trigger.
>
> Timed sleep would be ideal, but I understand this might be difficult to
> achieve.
>
> A suitable alternative could be waking up on LAN or GPIO stimulus.
I've heard of this possibly working on the E310, but do not know the
details.
Philip
>
> Best regards,
> Claudio
>
------------------------------
Message: 4
Date: Thu, 16 Jun 2016 14:14:21 -0600
From: "Eric C." <[email protected]>
To: [email protected]
Cc: "Eric C." <[email protected]>, [email protected]
Subject: Re: [USRP-users] Switching daughterboards
Message-ID:
<CABf-Ja78UTqS=qt_eUhNVVA=sykmprwcoagze0+tywzmiwo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks, I should have mentioned that.
1. USRP N200 with SBX
2. USRP N210 with WBX
I want the WBX to go with the N200.
-- Eric C.
On Thu, Jun 16, 2016 at 1:57 PM, <[email protected]> wrote:
> What type of USRP do you have, and what kind of daughtercards? Should be
> straightforward swap.
>
>
>
>
>
>
> On 2016-06-16 15:49, Eric C. via USRP-users wrote:
>
> I have two USRPs with two different daughterboards. Unfortunately I
> damaged one USRP, so I have to swap the daughtercards to continue using the
> other one. I don't see any instructions online, is there anything that's
> not straightforward that I should be aware of?
>
> -- Eric C.
>
> _______________________________________________
> 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/20160616/e25c615c/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 16 Jun 2016 13:23:48 -0700
From: James Wagner <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 RFNOC getting UHD to recognize new
RFNOC block
Message-ID:
<ca+usoojursxyqxng1y2fjwpd5hbx3mweuuu6vdk9mmf8fnb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
OK, so I figured out what the problem was. the framework checks to see if
the blockname specified in the XML has a valid format if not it returns an
empty string. apparently underscore is not a valid character. so i had the
by changing the blockname from pack_samp_decim to packsampdecim and it now
appears to work.
incidentally it appears that the getting started instructions are out of
date since most blocks don't actually require their own block controller.
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
On Tue, Jun 14, 2016 at 1:37 PM, James Wagner <[email protected]> wrote:
> we have created a RFNOC block and then successfully loaded it into the
> x310's FPGA but now we are not sure exactly what has to be done in order to
> get the UHD to recognize and communicate with it. looking at the getting
> started page we were able to create an XML which seems to enable the
> uhd_usrp_probe to run without seg faulting but the outputted list of blocks
> shows a blank name for our block. the getting started page also suggested
> that a header and implementation for a block controller would need to
> created but seeing how only the fir has it's own block controller(and that
> seems to be for a special method to load the taps) I am not sure that
> requirement is still current.
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/b2522b6f/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 16 Jun 2016 17:38:29 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Eric C." <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Switching daughterboards
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/16/2016 04:14 PM, Eric C. wrote:
> Thanks, I should have mentioned that.
>
> 1. USRP N200 with SBX
> 2. USRP N210 with WBX
>
> I want the WBX to go with the N200.
>
>
> -- Eric C.
That's a straight swap, easy-peasy:
https://kb.ettus.com/USRP_N_Series_Quick_Start_%28Daughterboard_Installation%29
>
> On Thu, Jun 16, 2016 at 1:57 PM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> What type of USRP do you have, and what kind of daughtercards?
> Should be straightforward swap.
>
> On 2016-06-16 15:49, Eric C. via USRP-users wrote:
>
>> I have two USRPs with two different daughterboards. Unfortunately
>> I damaged one USRP, so I have to swap the daughtercards to
>> continue using the other one. I don't see any instructions
>> online, is there anything that's not straightforward that I
>> should be aware of?
>>
>> -- Eric C.
>>
>> _______________________________________________
>> 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/20160616/72bf620a/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 16 Jun 2016 15:51:58 -0600
From: "Eric C." <[email protected]>
To: [email protected]
Subject: [USRP-users] Disabling GPS-DO
Message-ID:
<CABf-Ja44wrYR_+KVLOP_bkfmJ1JrQfMx8YPGwMQcdqN=rt1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I was wondering how far I have to go to disable the GPS-DO? In looking at
the schematics it would seem that switching the J510 jumper should be
enough, then I can use an external 10 MHz reference and 1 PPS. But I think
I still get a message when I start up the device about detecting and using
the GPS-DO. Should I unplug the power? The 10 MHz and 1 PPS internal rf
cables? The serial cable? Thanks.
-- Eric C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/9d18ea60/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 16 Jun 2016 17:59:13 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Disabling GPS-DO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/16/2016 05:51 PM, Eric C. via USRP-users wrote:
> I was wondering how far I have to go to disable the GPS-DO? In looking
> at the schematics it would seem that switching the J510 jumper should
> be enough, then I can use an external 10 MHz reference and 1 PPS. But
> I think I still get a message when I start up the device about
> detecting and using the GPS-DO. Should I unplug the power? The 10 MHz
> and 1 PPS internal rf cables? The serial cable? Thanks.
>
> -- Eric C.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
When you create your USRP object, just configure it for external 10Mhz
and 1PPS reference. It'll still go through the motions on start-up
to confirm the GPSDO presence, but the actual "session" will use
external.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/c8df0014/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 17 Jun 2016 01:04:53 +0000 (UTC)
From: <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Questions Regarding Ubuntu 16.04 and B200mini
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
I have a few questions regarding UHD on Ubuntu 16.04USRP: B200mini(USB 3.0)
Within the "rx_samples_to_file" program I specify thewirefmt to be 8bits (I
would like to sample at a higher rate), but Iend up with a 32 MB binary file
that is full of zeros. It looks likenothing is being written to the file.
Q1: Why doesn't anything get written to the file when I have thewirefmt set to
8bits?*Write medium is USB 2.0 and --wirefmt sc16 works fine.
Q2: Is it possible to receive samples from two antennas(configuring TRX and RX2
to both receive) on the B200mini? If so, howshould I go about doing this?
When I use the command: dpkg -s uhd or dpkg -s uhd-host, sudo apt-get updateto
get more information about the uhd package I get the followingmessage:
package 'uhd' is not installed and no information is available
Q3:What is the difference between uhd and uhd-host, and why can't dpkgfind
either of them??*Usingapt-cache search uhd I can see uhd-host as one of
theoptions.* Using sudo apt-get install uhd-host updates package.
Glad to be a part of the USRP community,Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/5250900f/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 17 Jun 2016 00:01:09 -0700
From: Derek Kozel <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Questions Regarding Ubuntu 16.04 and
B200mini
Message-ID:
<CAA+K=tuundnjpstpk_81gh7qo039hfuw7rhewbx-prf4qk4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Wilson,
The B200mini has only one receive chain with the ability to switch which
antenna port it is using. This is for convenience when the application
doesn't require full duplex, simultaneous transmission and reception. By
default it will use the RX2 connector for reception, but you can set the it
to use TX/RX using the set_rx_antenna function. The B210 has two separate
receivers and so is able to simultaneously receive from two antennas.
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a72b7947cb0c434b98e9915f91b8f8fe0
I like using apt search combined with apt show for finding out more about
packages.
`apt search uhd` returns a short list of packages including the three
relevant ones.
libuhd-dev/xenial 3.9.2-1 amd64
universal hardware driver for Ettus Research products - headers
libuhd003/xenial 3.9.2-1 amd64
universal hardware driver for Ettus Research products - library
uhd-host/xenial 3.9.2-1 amd64
universal hardware driver for Ettus Research products - host apps
`apt show <package name>` prints the full description, but the short
description pretty much covers it. You can install apt-file and use
`apt-file list <package name>` to see what files are installed by the
package.
libuhd003 is all that is needed when using a program compiled with UHD
support. However it is rare that anyone installs only the library as the
utilities and manual included in uhd-host are very useful. The libuhd-dev
package is only needed if you (or another program) will be compiling code
using UHD. This too is common so most people install all three.
Can you let us know the full commandline call you are using with
rx_samples_to_file?
Thanks,
Derek
On Thu, Jun 16, 2016 at 6:04 PM, Wilson Besner via USRP-users <
[email protected]> wrote:
> Hello,
>
> I have a few questions regarding UHD on Ubuntu 16.04
> USRP: B200mini (USB 3.0)
>
> Within the "rx_samples_to_file" program I specify the wirefmt to be 8bits
> (I would like to sample at a higher rate), but I end up with a 32 MB binary
> file that is full of zeros. It looks like nothing is being written to the
> file.
>
> Q1: Why doesn't anything get written to the file when I have the wirefmt
> set to 8bits?
> *Write medium is USB 2.0 and *--wirefmt sc16* works fine.
>
>
> Q2: Is it possible to receive samples from two antennas (configuring TRX
> and RX2 to both receive) on the B200mini? If so, how should I go about
> doing this?
>
> When I use the command: *dpkg -s uhd* or *dpkg -s uhd-host*, sudo apt-get
> update to get more information about the uhd package I get the following
> message:
>
> *package 'uhd' is not installed and no information is available*
>
> Q3: What is the difference between uhd and uhd-host, and why can't dpkg
> find either of them?
> *Using *apt-cache search uh**d I can see *uhd-host as one of the options.
> * Using *sudo apt-get install uhd-host* updates package.
>
> Glad to be a part of the USRP community,
> Wilson
>
>
>
>
>
> _______________________________________________
> 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/20160617/603858c0/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 17 Jun 2016 17:25:30 +0900
From: Jeon <[email protected]>
To: USRP users mailing list <[email protected]>
Subject: Re: [USRP-users] Effective a length of VERT2450 antenna and
its impact on receiving signal.
Message-ID:
<CACfn7v7K_ZN96JK_x9D8ULfttrszib_=brdeqq7jea-zrfh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks to both of you for responses.
I'll study and investigate on antenna theories.
Regards,
Jeon.
2016-06-16 3:05 GMT+09:00 Marcus M?ller <[email protected]>:
> In addition to Steven's references, I'd like to add that yes, VERT2450 is
> really just a monopole. It *is* a good 2.4GHz WiFi antenna, but if you're
> looking for measurement antennas, it's definitely not the product of choice.
>
> Other than that: WiFi cards equalize heavily. I don't believe that even a
> very narrowband antenna would pose a significant problem for that.
> But yes, *everything*, including temperature, air moisture and connector
> pressure influence the channel matrix. The question is how you would
> measure that with something like a WiFi card, which is by no means a device
> meant for measurements, or with something as varying, fading, selective as
> the typical WiFi channel, short of using an anechoic chamber.
>
> Best regards,
> Marcus
>
>
> On 06/14/2016 03:14 PM, Steven Knudsen via USRP-users wrote:
>
> Good places to start reading and learning would be
>
> http://www.arrl.org/antennas
>
> http://www.arrl.org/arrl-antenna-book
>
> and there may be some good starting points here
>
> http://www.antenna-theory.com/
>
> For your particular topic, I?d start by reading IEEE journals as much work
> has been published on channel characterization. There you will find the
> answer to your last question is ?yes?.
>
> Finally, it?s likely worth searching for theses and dissertations on the
> topic. I remember a few published back in the late 90s early 2000s by
> students at my university.
>
>
> Good luck.
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> *Der entscheidende Augenblick der menschlichen Entwicklung
> ist immerw?hrend. Darum sind die revolution?ren geistigen Bewegungen,
> welche alles Fr?here f?r nichtig erkl?ren, im Recht, denn es ist
> noch nichts geschehen. - Franz Kafka*
>
> On Jun 14, 2016, at 06:43, Jeon via USRP-users <[email protected]>
> wrote:
>
> Dear USRP users,
>
> I wonder that how long a length of VERT2450 antenna inside plastic cover
> is.
>
> Currently, I am trying to measure channel matrix, channel state
> information (magnitude and phase of each OFDM subcarrier) of Wi-Fi.
>
> And also I am curious whether a length of VERT2450 antenna has an impact
> of measuring magnitude and phase of each OFDM subcarrier. (e.g., incorrect
> antenna length results in incorrect channel state information.)
>
> Frankly speaking, I am using not USRP, but only VERT2450 antenna. I am
> using it with connected to Atheros 802.11n Wi-Fi card. (ath9k series;
> AR9580, etc.)
>
> The last small question is,does a length of a cable, and shielding
> connecting VERT2450 and Wi-Fi card (or duaghterboard) have an impact on
> channel matrix?
>
> Regards,
> Jeon.
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/92be5536/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 17 Jun 2016 08:02:21 -0400
From: Mark Napier <[email protected]>
To: [email protected]
Subject: [USRP-users] Tooling for connector on B200mini
Message-ID:
<CAFS2mBf2tkbv8p2JRABj5boDDeQ9UW=t3ixxmugvsc3k9ex...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
We're trying to make a couple of cables to mate up with J5 and J6 on the
B205mini. Have the mating connector and contacts. However, the contacts
are *very* tiny with open barrel construction. The recommended tooling for
them is for mass production and is wildly expensive. Our technician is
trying with a couple different hand crimpers (very high quality) but right
now is very frustrated.
What do you use in house? Is there a hand-held crimper that will do an
acceptable job? Failing that, is there someone you use to make cables for
you?
Thank you much,
Mark Napier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/7b866e26/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 17 Jun 2016 12:22:34 +0000 (UTC)
From: Joshua Monson <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file
into E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Swanson, Craig via USRP-users <usrp-users@...> writes:
> -- ? Updating muxes?
> -- [0/Radio_1] radio_ctrl::update_muxes()?
> -- [0/Radio_1] radio_ctrl::update_muxes()?
> -- ? dboards/A/tx_frontends/B/connection == IQ
> -- [0/Radio_1] radio_ctrl::update_muxes()?
> -- ? dboards/A/rx_frontends/B/connection == IQ
>
> -- Performing CODEC loopback test... fail
> Error: RuntimeError: CODEC loopback test failed.
Hi Craig,
I'm having the exact same problem with the CODEC loopback in the E310 on
the radio-redo branch. Were you ever able to resolve this problem?
Thanks,
Josh
------------------------------
Message: 14
Date: Fri, 17 Jun 2016 21:20:08 +0800
From: "=?ISO-8859-1?B?aWxsdWFudGlzaW9u?=" <[email protected]>
To: "=?ISO-8859-1?B?dXNycC11c2Vycw==?=" <[email protected]>
Subject: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
If anyone of you encountered the overflow problem when streaming data into a
file using USRP B210 through USB 3.0?
The situation is that:
1) Everything works fine without overruns in benchmark rate test:
./benchmark_rate --rx_rate=50e6 --otw=sc16
2) Everything works fine without overruns in rx_samples_to_file test:
./rx_samples_to_file --file=/dev/null --rate=50e6 --wirefmt=sc16
--duration=600
3) There will DEFINITELY be overruns (in less than 2 minutes) when streaming
data to a file even with sampling rate of 5 MHz: ./rx_samples_to_file
--file=~/Desktop/test.bin --rate=5e6 --wirefmt=sc16 --duration=600
The throughput of the Samsung mSATA SSD disk we are using is more than 500
MBps, and it works fine with N210. I am quite sure this problem is not the
fault of CPU, memory, SSD disk or USB 3.0. It seems that something happens when
they work together with B210.
I also found previous reports about the same problem in the 2014 March usurp
mail list here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-March/008894.html;
and in the Github issues here: https://github.com/EttusResearch/uhd/issues/58.
Streaming data into files is a basic application of USRP. Hope some of you
could provide with solutions for this problem.
Best regards,
Xuesong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/3cf10f40/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 17 Jun 2016 09:40:24 -0400
From: Anon Lister <[email protected]>
To: illuantision <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID:
<camp204t0tpbz9eos-h5+cgunjeahs12yw3c0hcauznagjwj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
https://github.com/garverp/gr-analysis/
Try the specrec tool from here. They gave a presentation on this a year or
two ago. If that works it is probably that you are dropping when buffers
are flushed to disk. For me it seemed to improve things alot. I was
dropping after a bit and have a 950 (~2G/Sec). Which seemed odd. Using this
I can save fine up to 51 meg bw, which appears to be where my (probably USB
chipset-based) limit is.
I don't know if there's a way to do this with rx_samples but basically it
does synchronous writes to disk, instead of caching in ram and doing 1 big
write. The downside is for small recordings and slow hard drives, it will
fare worse, however for longer ones where your HDD is fast enough, you
should see an improvement. Would love to hear some ettus folks feedback on
this as I was not at the original talk.
-Anon
On Jun 17, 2016 9:21 AM, "illuantision via USRP-users" <
[email protected]> wrote:
> Hi all,
>
> If anyone of you encountered the overflow problem when streaming data into
> a file using USRP B210 through USB 3.0?
>
> The situation is that:
>
> 1) Everything works fine without overruns in benchmark rate test:
> ./benchmark_rate --rx_rate=50e6 --otw=sc16
>
> 2) Everything works fine without overruns in rx_samples_to_file test:
> ./rx_samples_to_file --file=/dev/null --rate=50e6 --wirefmt=sc16
> --duration=600
>
> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
> streaming data to a file even with sampling rate of 5 MHz:
> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6 --wirefmt=sc16
> --duration=600
>
> The throughput of the Samsung mSATA SSD disk we are using is more than 500
> MBps, and it works fine with N210. I am quite sure this problem is not the
> fault of CPU, memory, SSD disk or USB 3.0. It seems that something happens
> when they work together with B210.
>
> I also found previous reports about the same problem in the 2014 March
> usurp mail list here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-March/008894.html;
> and in the Github issues here:
> https://github.com/EttusResearch/uhd/issues/58.
>
> Streaming data into files is a basic application of USRP. Hope some of you
> could provide with solutions for this problem.
>
>
> Best regards,
> Xuesong
>
> _______________________________________________
> 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/20160617/7d4b0ad0/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 17 Jun 2016 14:34:00 +0000
From: Dan CaJacob <[email protected]>
To: Mark Napier <[email protected]>, [email protected]
Subject: Re: [USRP-users] Tooling for connector on B200mini
Message-ID:
<camomjocvwrwf8kksrezfd3eroswaas+3g7egrjep_wfsh__...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What type of cables/connectors are these? You can usually buy pre-made
cables from places like DigiKey and Mouser as well as other smaller, more
specific RF houses. They're not the best cables in the world, but they're
inexpensive.
On Fri, Jun 17, 2016 at 8:04 AM Mark Napier via USRP-users <
[email protected]> wrote:
> Hello,
>
> We're trying to make a couple of cables to mate up with J5 and J6 on the
> B205mini. Have the mating connector and contacts. However, the contacts
> are *very* tiny with open barrel construction. The recommended tooling for
> them is for mass production and is wildly expensive. Our technician is
> trying with a couple different hand crimpers (very high quality) but right
> now is very frustrated.
>
> What do you use in house? Is there a hand-held crimper that will do an
> acceptable job? Failing that, is there someone you use to make cables for
> you?
>
> Thank you much,
>
> Mark Napier
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/d682ce9f/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 17 Jun 2016 10:47:39 -0400
From: Mark Napier <[email protected]>
To: Dan CaJacob <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Tooling for connector on B200mini
Message-ID:
<cafs2mbeuu3hnpynhfeiv540sjkmroa3+v1gemb5v2odk7fx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The contact is 440147-2 from Tyco Electronics. Wire is 28 AWG. Digikey
has already said they don't do them. Think crazy small.
On Fri, Jun 17, 2016 at 10:34 AM, Dan CaJacob <[email protected]> wrote:
> What type of cables/connectors are these? You can usually buy pre-made
> cables from places like DigiKey and Mouser as well as other smaller, more
> specific RF houses. They're not the best cables in the world, but they're
> inexpensive.
>
> On Fri, Jun 17, 2016 at 8:04 AM Mark Napier via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> We're trying to make a couple of cables to mate up with J5 and J6 on the
>> B205mini. Have the mating connector and contacts. However, the contacts
>> are *very* tiny with open barrel construction. The recommended tooling for
>> them is for mass production and is wildly expensive. Our technician is
>> trying with a couple different hand crimpers (very high quality) but right
>> now is very frustrated.
>>
>> What do you use in house? Is there a hand-held crimper that will do an
>> acceptable job? Failing that, is there someone you use to make cables for
>> you?
>>
>> Thank you much,
>>
>> Mark Napier
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/24d76f83/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 17 Jun 2016 15:12:35 +0000
From: Dan CaJacob <[email protected]>
To: Mark Napier <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Tooling for connector on B200mini
Message-ID:
<camomjoag1px6zjlaxswcytpr67p1bbhnvzxz3ozcsnb+ntn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Oh, I thought you were talking about an RF cable.
On Fri, Jun 17, 2016 at 10:47 AM Mark Napier <[email protected]> wrote:
> The contact is 440147-2 from Tyco Electronics. Wire is 28 AWG. Digikey
> has already said they don't do them. Think crazy small.
>
>
> On Fri, Jun 17, 2016 at 10:34 AM, Dan CaJacob <[email protected]>
> wrote:
>
>> What type of cables/connectors are these? You can usually buy pre-made
>> cables from places like DigiKey and Mouser as well as other smaller, more
>> specific RF houses. They're not the best cables in the world, but they're
>> inexpensive.
>>
>> On Fri, Jun 17, 2016 at 8:04 AM Mark Napier via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello,
>>>
>>> We're trying to make a couple of cables to mate up with J5 and J6 on the
>>> B205mini. Have the mating connector and contacts. However, the contacts
>>> are *very* tiny with open barrel construction. The recommended tooling for
>>> them is for mass production and is wildly expensive. Our technician is
>>> trying with a couple different hand crimpers (very high quality) but right
>>> now is very frustrated.
>>>
>>> What do you use in house? Is there a hand-held crimper that will do an
>>> acceptable job? Failing that, is there someone you use to make cables for
>>> you?
>>>
>>> Thank you much,
>>>
>>> Mark Napier
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>
> --
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/bf313497/attachment-0001.html>
------------------------------
Message: 19
Date: Sat, 18 Jun 2016 03:12:42 +1200
From: avinash kalyanaraman <[email protected]>
To: [email protected]
Subject: [USRP-users] Re N210 interfacing issue
Message-ID:
<CAJpBU_GK7gooDZkKbBuV4YaR_gAQ=0e-tzwnt6i2ej8tp8v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I have an USRP N210 and a host running Ubuntu 15.04 with a 100MB/s ethernet
connection. I read that a Gigabit connection is needed to connect to the
USRP.
So I interfaced it with a Gigabit Ethernet switch. I initially see the
device with uhd_find_devices. Later when I run uhd_fft, I see the following:
WARN gr uhd usrp source0 Sensor 'lo_locked' failed to lock within timeout
on channel 0
And then my laptop freezes.
Could you please let me know how I might be able to fix it ? The issue
doesn't happen when I connect it to a Mac which has gigabit support.
Thanks!
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160618/4c2f3994/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 17 Jun 2016 17:26:30 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Re N210 interfacing issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Avinash,
On 06/17/2016 05:12 PM, avinash kalyanaraman via USRP-users wrote:
> Hello all,
>
> I have an USRP N210 and a host running Ubuntu 15.04 with a 100MB/s
> ethernet connection. I read that a Gigabit connection is needed to
> connect to the USRP.
100% true. The N210 needs the Gigabit Ethernet Frames, can't work over
100Mb/s.
>
> So I interfaced it with a Gigabit Ethernet switch. I initially see the
> device with uhd_find_devices.
...which might work, but you won't get more than 3MS/s over that ? if,
and only if, your 100Mb/s adapter and your switch work perfectly fast in
100Mb/s mode (which is not always the case). This is a very very
suboptimal solution.
> Later when I run uhd_fft, I see the following:
>
> WARN gr uhd usrp source0 Sensor 'lo_locked' failed to lock within
> timeout on channel 0
That is unrelated to the network issue ? it's a problem with the
daughterboard you're using, or your reference oscillator.
Which daughterboard are you using, and which revision of UHD?
>
> And then my laptop freezes.
That is even more unrelated.
>
> Could you please let me know how I might be able to fix it ? The issue
> doesn't happen when I connect it to a Mac which has gigabit support.
Well, the freezing is an issue with your laptop, somehow something goes
wrong there, or maybe it's just overwhelmed by doing so much work ? I
haven't used a laptop that did not have Gigabit Ethernet in the last
decade, so it's possible your laptop is simply too slow.
Maybe, however, something else crashes.
I really don't know whether we should pursue this path any further ?
really, using a laptop without Gigabit Ethernet with an N210 is... an
imbalanced choice of equipment.
Best regards,
Marcus
------------------------------
Message: 21
Date: Fri, 17 Jun 2016 10:33:48 -0500
From: Jonathon Pendlum <[email protected]>
To: Joshua Monson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file
into E310
Message-ID:
<CAGdo0uT+f_xpZOeAQvxywEy6XJXDFwLVc2w3X0=qj9fw3on...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Josh,
Does it fail CODEC loopback test every time you run or intermittently?
Jonathon
On Fri, Jun 17, 2016 at 7:22 AM, Joshua Monson via USRP-users <
[email protected]> wrote:
> Swanson, Craig via USRP-users <usrp-users@...> writes:
>
> > -- Updating muxes
> > -- [0/Radio_1] radio_ctrl::update_muxes()
> > -- [0/Radio_1] radio_ctrl::update_muxes()
> > -- dboards/A/tx_frontends/B/connection == IQ
> > -- [0/Radio_1] radio_ctrl::update_muxes()
> > -- dboards/A/rx_frontends/B/connection == IQ
> >
> > -- Performing CODEC loopback test... fail
> > Error: RuntimeError: CODEC loopback test failed.
>
> Hi Craig,
>
> I'm having the exact same problem with the CODEC loopback in the E310 on
> the radio-redo branch. Were you ever able to resolve this problem?
>
> Thanks,
>
> Josh
> _______________________________________________
> 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/20160617/7087aea0/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 17 Jun 2016 17:34:48 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Xuesong,
On 06/17/2016 03:20 PM, illuantision via USRP-users wrote:
> Hi all,
>
> If anyone of you encountered the overflow problem when streaming data
> into a file using USRP B210 through USB 3.0?
Yes. Storage devices are usually slower at consuming data than the B210
is at producing them.
Furthermore, not all USB3 host controller chipsets can deal with the
full rate coming from a USRP. They simply throttle, drop packets or crash.
>
> The situation is that:
>
> 1) Everything works fine without overruns in benchmark rate test:
> ./benchmark_rate --rx_rate=50e6 --otw=sc16
Excellent! Your USB3 works fine at these rates.
>
> 2) Everything works fine without overruns in rx_samples_to_file test:
> ./rx_samples_to_file --file=/dev/null --rate=50e6 --wirefmt=sc16
> --duration=600
The same as above.
>
> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
> streaming data to a file even with sampling rate of 5 MHz:
> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
> --wirefmt=sc16 --duration=600
This is 50MS/s * 4B/S = 200MB/s = 1600Mb/s of data, to a total of 120GB.
Not even most SSDs are up to that write speed over that much data, which
definitely exceeds typical file system RAM buffers.
If you really need to store 120GB of recorded spectrum at once, you'll
either need a lot of RAM to first write this into a RAMdisk, or you'll
need a really really capable storage subsystem ? PCIe SSDs, or
impressive RAIDs of cheaper SSDs might work. Also, you'll want to
optimize your filesystem for continued streaming (journalling file
systems make no sense here, huge buffers do), and you'll probably want
something else than our rx_samples_to_file example: it's not really
multithreaded, and does no internal write buffering.
>
> The throughput of the Samsung mSATA SSD disk we are using is more than
> 500 MBps,
Which is too little by more than a factor of 3
> and it works fine with N210.
Which can't do more than 25MS/s @SC16
> I am quite sure this problem is not the fault of CPU, memory, SSD disk
> or USB 3.0. It seems that something happens when they work together
> with B210.
Pretty sure this is your SSD.
>
> I also found previous reports about the same problem in the 2014 March
> usurp mail list here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-March/008894.html;
> and in the Github issues here:
> https://github.com/EttusResearch/uhd/issues/58.
>
> Streaming data into files is a basic application of USRP. Hope some of
> you could provide with solutions for this problem.
I'm afraid all I can tell you is:
* faster storage
* using a multi-threaded, buffering program instead of the
rx_samples_to_file example (it's /really/ just an example of how to use
UHD to receive files, not a throughput-optimized application)
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/40e74fa4/attachment-0001.html>
------------------------------
Message: 23
Date: Fri, 17 Jun 2016 11:47:43 -0400
From: "Joshua Monson" <[email protected]>
To: "'Jonathon Pendlum'" <[email protected]>
Cc: <[email protected]>
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file
into E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
It fails everytime. I?m including all of the output just in case its helpful.
root@ettus-e3xx-sg1:~# uhd_usrp_probe --init-only
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Initializing core control...
-- Performing register loopback test... pass
-- [E300] Setting up dest map for host ep 0 to be stream 0
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_0/ports/out/0
-- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/A/connection == IQ
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/A/connection == IQ
-- [E300] Setting up dest map for host ep 1 to be stream 1
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_1/ports/out/0
-- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_1] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/B/connection == IQ
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/B/connection == IQ
-- Performing CODEC loopback test... fail
Error: RuntimeError: CODEC loopback test failed.
root@ettus-e3xx-sg1:~#
Josh
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Friday, June 17, 2016 11:34 AM
To: Joshua Monson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file into E310
Josh,
Does it fail CODEC loopback test every time you run or intermittently?
Jonathon
On Fri, Jun 17, 2016 at 7:22 AM, Joshua Monson via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Swanson, Craig via USRP-users <usrp-users@... <mailto:usrp-users@...> > writes:
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/B/connection == IQ
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/B/connection == IQ
>
> -- Performing CODEC loopback test... fail
> Error: RuntimeError: CODEC loopback test failed.
Hi Craig,
I'm having the exact same problem with the CODEC loopback in the E310 on
the radio-redo branch. Were you ever able to resolve this problem?
Thanks,
Josh
_______________________________________________
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/20160617/04c43014/attachment-0001.html>
------------------------------
Message: 24
Date: Fri, 17 Jun 2016 11:58:08 -0400
From: "Joshua Monson" <[email protected]>
To: "'Jonathon Pendlum'" <[email protected]>
Cc: <[email protected]>
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file
into E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Yes, I switched to the rfnoc-radio-redo branch in the FPGA source and rebuilt
the image. I?ve also switched from to the rfnoc-radio-redo branch of uhd. I
rebuilt them both and installed uhd over sshfs using ?make install? and copied
the new bitstream with this command ?cp usrp_e310_fpga_RFNOC.bit
~/E310/usr/share/uhd/images/usrp_e310_fpga.bit? (the E310 directory maps to my
E310 root using sshfs).
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Friday, June 17, 2016 11:49 AM
To: Joshua Monson <[email protected]>
Subject: RE: [USRP-users] Unable to load rfnoc-radio-redo bit file into E310
Josh,
Did you build a new FPGA image? The radio redo branch is experimental, so we
haven't made an image package for it. That means the image you get from the
images downloader is not compatible.
On Jun 17, 2016 10:43 AM, "Joshua Monson" <[email protected]
<mailto:[email protected]> > wrote:
Jonathon,
It fails everytime. I?m including all of the output just in case its helpful.
root@ettus-e3xx-sg1:~# uhd_usrp_probe --init-only
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Initializing core control...
-- Performing register loopback test... pass
-- [E300] Setting up dest map for host ep 0 to be stream 0
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_0/ports/out/0
-- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/A/connection == IQ
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/A/connection == IQ
-- [E300] Setting up dest map for host ep 1 to be stream 1
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_1/ports/out/0
-- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_1] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/B/connection == IQ
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/B/connection == IQ
-- Performing CODEC loopback test... fail
Error: RuntimeError: CODEC loopback test failed.
root@ettus-e3xx-sg1:~#
Josh
From: Jonathon Pendlum [mailto:[email protected]
<mailto:[email protected]> ]
Sent: Friday, June 17, 2016 11:34 AM
To: Joshua Monson <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file into E310
Josh,
Does it fail CODEC loopback test every time you run or intermittently?
Jonathon
On Fri, Jun 17, 2016 at 7:22 AM, Joshua Monson via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Swanson, Craig via USRP-users <usrp-users@... <mailto:usrp-users@...> > writes:
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/B/connection == IQ
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/B/connection == IQ
>
> -- Performing CODEC loopback test... fail
> Error: RuntimeError: CODEC loopback test failed.
Hi Craig,
I'm having the exact same problem with the CODEC loopback in the E310 on
the radio-redo branch. Were you ever able to resolve this problem?
Thanks,
Josh
_______________________________________________
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/20160617/48133482/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 70, Issue 17
******************************************
