Hi Radio User aka "radiogeek381" - USRPs work for me on Big Sur using UHD
from MacPorts; I've tested a B200mini, B210, E310, and X310. I'm mostly
testing UHD 4.0 (port "uhd-devel") rather than 3.15 (port "uhd"), but
either should work. I have a bunch of builtbots for testing MacPorts
builds,
Hi Pat - Thanks for your sleuthing and info from Intel on how the XL710
Intel NIC allocates lanes when in 2x2x10 mode. This is certainly an issue
with what the N321 expects. It would be desirable if the Intel NIC
configuration utility allowed one to select which lanes to use, and/or if
we could
Hi Gokul - Did you update UHD to the same version on both the host computer
running OAI as well as the USRP (via the filesystem on the SDcard)? It
looks from the GIT commands like you're trying to use UHD 4.0-beta on this
new host & you note UHD 3.15 on the USRP ... which won't work. You have to
What version of UHD are you using? Different UHD versions provide different
filesystems, which configure networking differently. - MLD
On Fri, Jan 15, 2021 at 9:01 AM Mark D via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Thanks Cédric,
>
> I used the networkctl status eth0 command that
Thanks for reporting back, Jim! I'm glad redoing the 1G networking resolved
the issue & got you to the expected max sample rate for the E320 in network
mode. Since I almost never use the 1G SFP+ mode, I'm not worried about my
1G networking & will just stick with the 10G SFP+ mode which works
Hi Jim - Yes you are correct in the E320 FPGA image options: 1G, XG, and
AA. I booted up my E320 to verify; forgot that there is just a single SFP+
port on the E320 ... I've been working with X310's and N310's for a while
now, both of which have 2 SFP+ ports!
Since I'm on my E320, I tried out the
Hi Jim - Just for completion: Try loading the "HG" image -- again if
necessary: 1 Gb on SFP+ port 0 and 10 Gb on SFP+ port 1. Regardless of
whatever Linux / ifconfig / ethtool shows, the SFP+-based networking will
not work if the link speeds are not met on both ends. All USRPs will set
the correct
Try this UHD-provided utility:
https://github.com/EttusResearch/uhd/blob/master/host/utils/x300_reset.py
Guessing it ends up doing similarly to what Nate mentioned. Worth a try! - MLD
> On Dec 4, 2020, at 5:42 PM, Dustin Widmann via USRP-users
> wrote:
>
>
> Hi Jeff,
>
> I have been
Hi Pat - I'm glad that info helped!
Yes, I plan on adding this information into the N32x Getting Started Guide,
once I have a better handle on it. Right now I have just a few data points
& those are not consistent! and I don't know why! Thus ...
Which Intel QSFP+ utility did you end up using?
Hi Pat - I recently verified that the N321 QAFP+ interface works with UHD 4.0
release. I am also using an Intel XL710 (QDA2, but that probably doesn’t matter
too much). The trick for me was using the Intel QSFP+ NIC configuration tool to
set the NIC to 2x(2x10 Gb) mode. This is the setting that
Check the PYTHONPATH to make sure it holds the correct install directory
for UHD Python. I'm guessing it does not. I'm pretty sure UHD by default
installs its Python library and files into
"/usr/local/lib/python3/site-packages" ... or "dist-packages" ... note the
"/python3/" rather than some
Hi Ben - This issue has been reported to R internally. If you wish to
create a public-facing UHD issue on our Github tracker please go ahead & do
so, and tag me on it so that we can keep track of it internally. - MLD
On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users <
Let's take this off-USRP list for the moment. We can always reply to the
list if appropriate once this issue is resolved. - MLD
On Wed, Oct 28, 2020 at 12:15 PM Dev Joshi wrote:
>
>
> *uhd_find_devices --args="type=usrp2"[INFO] [UHD] linux; GNU C++ version
> 7.5.0; Boost_106501;
Try "type=usrp2" ...
On Wed, Oct 28, 2020 at 12:09 PM Dev Joshi via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Neel,
>
> Thanks for the reply, I tried the suggestion:
>
> * augment your device string with type=n2xx*
>
> And this is what I get:
>
>
> *uhd_find_devices
Hi Jim - I replied to your query to "supp...@ettus.com" about 3 hours after
you sent it. Maybe that message didn't get through? I received nothing back
from the emails servers noting any issues. Please reply to your original
request & we'll try this again. - MLD
---
Dr Michael L Dickens
Principal
Pretty much any SFP+ to RJ-45 adapter should work. I have had very good
success with some generics from Amazon as well as some from fs.com . Note
that if your 10 GbE adapter provides SFP+ (not RJ-45), then using a DAC
cable ("direct attach copper": SFP+ <-> SFP+, without the RJ-45 conversion)
is a
You're welcome, Mark! I'm glad that moving to a newer SDK worked; good luck
with your USRP work! - MLD
On Mon, Oct 12, 2020 at 4:59 PM Andrews, Mark J.
wrote:
> THANK YOU! I thought that it seemed like the SDK had to be wrong, but
> never saw links to the newer versions in all my searching.
Hi Mark - You need to use a more recent SDK for the cross-build. Here are
the SDKs for the 2 most recent UHD releases. I hope this helps! - MLD
<
https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/e3xx_e320_sdk_default-v3.15.0.0.zip
>
<
Hi Rigiel - You've reached the limits of my knowledge in this regard.
Hopefully others can chime in to augment what I've written. For all I know,
you're in uncharted territory! Sorry I can't be of more help & good luck! -
MLD
On Tue, Oct 6, 2020 at 1:27 AM Anes Rose Rigiel Anony <
Hi Mark - Yeah you can't compile your UHD application for your host
computer (not cross-compiled using the USRP's SDK) and expect it to run on
the USRP. The USRP comes with a full UHD and development install, so you
should be able to compile your UHD application directly on the USRP. It
might not
Hi Rigiel - At least in theory both the Bladerf XA4 and USRP B210 provide
external input for a 10 MHz REF, which -might- allow for some sense of
synchronization between them. It's really not clear to me whether that will
be enough, and whether the software controlling these devices can be
coerced
Hi Emil - Your comment (3) is interesting ... it very well might be that
CTRLPORT / Thrift no longer works reliably; as I noted: both interfaces
have not been actively maintained for years. I don't see this changing any
time soon either. Anyway: Disabling them as you note is the way to go & I
hope
Hi Emil - A few thoughts:
1) This is a GNU Radio question; not a USRP one. You'd be better served by
querying the GR discussion list <
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >.
2) Those failing tests are related to CTRLPORT and it's use of Thrift.
Unless you are going to be
UHD 3.15: just on the E310. No network mode.
UHD 4.0: either.
On Fri, Oct 2, 2020 at 1:57 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> Is it possible to run an Ettus example app & UHD on the host PC with an
> E310 (rather than running the app/UHD directly on the
For Ubuntu, you can generally do PPA installs:
UHD 4.0.0.0
https://files.ettus.com/binaries/uhd_stable/uhd_004.000.000.000-release/Ubuntu-installers_README.txt
GR 3.8.2.0
https://wiki.gnuradio.org/index.php/InstallingGR#Ubuntu_PPA_Installation
I don't think we have a PPA for gr-ettus ... but
Hi Emil - What branch of UHD and GR are you trying to build? That AppNote
is a bit dated, and needs a serious update! If what you want is the latest
releases of UHD and GR, for many OSs those are available for download and
install as precompiled binaries. - MLD
On Fri, Oct 2, 2020 at 8:59 AM Emil
FYI for macOS users using MacPorts: I updated the "uhd-devel" port to the
current 4.0.0.0 release commit (20200913-90ce6062); the "uhd" port is still
at 3.15.0.0. Both ports should work with the "gnuradio" port for GNU Radio
3.8.2.0, and should install and execute under macOS 10.11 through
In my experience, this happens when the networking isn't stable, which can
be for all sorts of reasons:
* connectors / cables are flaky;
* host SW configuration isn't quite correct;
* actual NIC has issues, HW or FW / configuration;
* USRP NIC has issues ... very rare, but it can happen;
*
Minimum GCC is 5.4.0 ; requires C++14 . - MLD
On Fri, Aug 28, 2020 at 12:22 PM Carmichael, Ryan via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Michael,
>
>
>
> I’m getting this error during compilation. Is there a minimum gcc version
> needed for 4.0.0.0-rc1? My RHEL7 has g++ (GCC)
FYI there's a new PCIe driver out that supports kernel version 5; you can
find the info here < https://files.ettus.com/manual/page_ni_rio_kernel.html >.
- MLD
On Wed, Aug 5, 2020 at 9:15 AM Michael Dickens
wrote:
> The default FPGA image for the X310 (which is the Ettus USRP of your
> 2955),
The default FPGA image for the X310 (which is the Ettus USRP of your 2955),
supports 10 GbE on the SFP+ port 1 <
https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface > ... so, you
could use just that link if your application's aggregate sample rate can
fit within the link capacity.
You can,
Nope. gr-ettus is, plus or minus, integrated into gr-uhd on GR master. - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
On Fri, May 29, 2020 at 5:40 PM Hodges, Jeff
wrote:
> Is gr-ettus still required for rfnoc on master branch? I
Hi Jeff - The new tool is called "rfnoc_create_verilog" ... it's located in
the UHD repo as "host/utils/rfnoc_blocktool/rfnoc_create_verilog.py". - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
On Thu, May 28, 2020 at 11:54 PM Hodges,
... the "UHD.3.15.LTS" branch, not tag:
{{{
% git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/UHD-3.10
remotes/origin/UHD-3.11
remotes/origin/UHD-3.12
remotes/origin/UHD-3.13
remotes/origin/UHD-3.14
remotes/origin/UHD-3.14.L
remotes/origin/UHD-3.15.LTS
Hi Max (& Rob) - I'm working my way up to 2xX310. The following applies to
1x X310 + 2x SFP+ links; it -might- be applicable toward your 2x (1x X310 +
1x SFP+ link) situation; worth a try! - MLD
By default, UHD + X310 will use just a single SFP+ link for data transport,
which (obviously) limits
HI Clark - I'll try to work with you off-list. - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
On Mon, Apr 27, 2020 at 1:41 PM Clark (US), Kenneth C <
kenneth.c.cla...@boeing.com> wrote:
> If I remove “constexpr” completely, thus
Hi Ken - Try removing the "constexpr" entirely. We love "const" and
"constexpr", but some compilers don't love them in various forms /
combinations :) Hopefully that will get you past that issue. - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web:
for GPIO.
>>
>> Fun fun fun! - MLD
>>
>>
>> On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler wrote:
>>
>>> The following link (GR documentation) shows some UHD GPIO functionality.
>>> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block
++ API for GPIO.
Fun fun fun! - MLD
On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler wrote:
> The following link (GR documentation) shows some UHD GPIO functionality.
> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html
>
> On Fri, Apr 17, 2020 at 10:27 AM Michael
Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via UHD
in GNU Radio?
In theory this should be possible, at least in C++ and of course it
requires that the specific USRP have GPIO ...
I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there is
then that method
Maybe this KB info is what you're looking for?
<
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
>
Maybe not, too. Worth a look IMHO. - MLD
On Fri, Apr 10, 2020 at 4:23 PM Devin Kelly via USRP-users <
Hi fe8769 - Although you're clearly trying to use an Ettus B210 USRP, your
query is really about the API used by SoapySDRUtil and osmocom_fft to
access the SDR hardware. I'd guess that most folks here use UHD -- and do
not use SoapySDR or gr-osmosdr -- for their USRP work -- though there are
Excellent! Thanks for reporting back your success! - MLD
--
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
On Wed, Apr 1, 2020 at 1:51 PM Jeff S wrote:
> Michael,
>
> You hit a bullseye! It took a bit to finally find the culprits while
>
Hi Jeff - I'm pretty sure the error means you have a prior version of GNU
Radio installed into a standard system search prefix (e.g., /usr/local ).
If you disable / remove / deactivate that install, then redo-the whole GR
build from the start, the error should be fixed. Hopefully! - MLD
On Wed,
Bonjour Louis-Adrien - Cool experiment! Since we don't have access to your
flowgraph, the following are just guesses. I believe that getting the
signal gains "correct enough" is the key to what you're doing. 60 dB of
attenuation is quite a bit! it's wise to protect the USRP Rx from signal
overload
That's great to hear, Simon! Cheers! - MLD
On Sun, Feb 23, 2020 at 2:23 AM wrote:
> Hi,
>
>
>
> Some feedback: I’ve been reading the UHD code and now have the X310
> running well albeit at 20Msps as the user has only GigE, but he’s buying a
> 10 GigE card and does have a ‘stonking’ Windows PC
Hi Simon - When you say "but performance is not great" ... beyond CPU load:
do you get good Tx and Rx rates (e.g., if you run "benchmark_rate") without
underruns / overflows / late packets (etc)? What is the MTU set to for this
ENET link? 1 GbE or 10 GbE? Can you provide a little more detail for
HI Santosh - Please see this reply to your original post. Marcus didn't
reply to you directly, just the USRP list. If you're not receiving emails
from the list, then you should note so in your query so that we know how
to respond to you. Hope his reply is useful! - MLD
-- Forwarded
Hi Kyle - Pretty much any PoE+ splitter should do the trick so long as it
can match the E320's input voltage & power plug size. Some of the Ettus
developers have tested a few stock splitters with good success. We don't
have a specific recommended device. Cheers! - MLD
On Tue, Jan 28, 2020 at 7:13
Hi Sebastian - The power draw of the E313 in 2x2 MIMO is peak of about 9 W
and more typically averaging around 6 W. An injector meeting the original
PoE 802.3af standard at 12.95 W at the device should be plenty sufficient.
What PoE injector are you trying to use? Do you have any others to try
Hi Jean Marie - Have you tried the instructions here <
https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card
>? Guessing those will do the trick for you. Hope this is useful! - MLD
On Mon, Jan 27, 2020 at 9:13 AM Jean Marie Brieussel via USRP-users <
Hi Massoud - The 'O' and 'U' mean overflow and underrun, respectively; see
also:< https://files.ettus.com/manual/page_general.html#general_ounotes >.
Note that if the O/U occur regularly during runtime they -will- impact data
flow; these are best avoided! Any that occur during flowgraph startup or
Hi Paweł - I'd recommend using these install instructions <
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>.
Please note specifically the section for "Configuring USB". It sounds like
you've done most of the work already; just a couple
Excellent & Happy New Year to the UHD / Volk / GNU Radio community!
For OSX (Mac OS X / macOS) users, I updated the 'uhd' port in MacPorts to
this release last night; it is available right now!
We (MacPorts developers) recommend doing the following semi-regularly to
keep your 'ports' install up
Hi Jit - This is the USRP users list. Generating GPS signals is outside the
scope of this list's general topic domain. There are plenty of DSP and GSP
related Q groups and websites on the internet would be appropriate for
your query. Good luck! - MLD
On Thu, Nov 7, 2019 at 12:55 PM Joshi J (Engg)
Hi Isaac - UHD itself provides no API to the IMU; never has. The RTIMULib,
possibly an older version than current and assuming it can be built and
installed on the E310, should be able to access the IMU to provide
information from it. Note "possibly", "assuming", "should" ... clearly this
isn't a
Hi Andrew - That's certainly interesting! Have you tried a more recent
version of UHD? 3.14.1.1 is the latest release, and it might contain fixes
for the issue you're having. Worth a try IMHO. - MLD
On Mon, Oct 28, 2019 at 2:41 PM Boggio-Dandry, Andrew via USRP-users <
usrp-users@lists.ettus.com>
Hi JJ - The UHD MATLAB interface is provided and supported by The
MathWorks. Please contact them with any queries / issues. - MLD
On Mon, Oct 21, 2019 at 10:21 AM F1EHN via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear users,
>
>
>
> The running of my host computer with my X310 platform
Hi Arun - Short answer: No, the X310 doesn't support "sc8" OTW yet; we're
still working on the RFNoC converter from "sc16" to "sc8". As noted, the
X310 provides dual SPF+ 1GbENET and 10GbENET, and obtaining the ENET
hardware interface to a host computer is very doable, providing a lot of
possible
Yes sorry about the GR37 release version: 3.7.13.5 is the correct on.
Installing Py27-six should be pretty straight forward & should allow you to
proceed with that install. GR38 has it's own set of dependencies, some of
which overlap with GR37 and some of which don't. You'll want to follow the
OK. Thanks for the info Saeid. I'll look into creating a VM using Ubuntu
16.04.1 to see what happens. - MLD
On Fri, Oct 11, 2019 at 4:47 PM Saeid Hashemi wrote:
> It's Ubuntu 16.04.1, but yes, I will follow the source build instructions.
>
> On Fri, Oct 11, 2019 at 3:11 PM Michael Dickens
>
Hi Saeid - Thanks for the followup. I totally agree that if you just "sudo
apt install gnuradio", compatible versions should be installed. Are you
using Ubuntu 16.04.6 LTS (Xenial Xerus)? If you choose to install from
source, you can follow instructions such as the GR recommended way here <
Hi Saeid - The error shows that the version of UHD as installed isn't fully
compatible with the version of GR. GR 3.7.9.1 is quite old ... unless you
need that specific version of GR, I'd recommend uninstalling that GR and
installing 3.7.14.5 from source. There are install guides around for doing
Hi Jason - I've been working with Neel on this topic. I'll email you
off-list to discuss more. If we come up with anything useful we can always
reply to the overall list. - MLD
On Thu, Oct 3, 2019 at 8:48 AM Jason Roehm via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
> On 9/26/19 9:26 AM,
Hi Khizar - Have you tried doing what the error recommends ... executing
"/usr/local/lib/uhd/utils/uhd_images_downloader.py"? It could be that you
just need to download the images for your specific UHD install. Hope this
helps! - MLD
On Thu, Sep 19, 2019 at 4:03 AM Khizar Abbas via USRP-users <
Hi Rajesh - Sorry for the delay. Which branch / commit of gr-ieee802-11 are
you using? The version of GR is pretty old (3.7.6), and there's a
reasonable chance it's not compatible with the version of gr-ieee802-11 ...
but it could be something else too. Otherwise, yes, the settings you list
look
Hi Rajesh - CMake found your GR38 install, not your GR37 install. You
should pick GR37 or GR38 and go with just it, and remove the one you're not
going with. Then, pick the same branch of gr-ieee802-11. Hope this is
useful! - MLD
On Sat, Sep 7, 2019 at 9:47 AM Dr. Rajesh Tiwari via USRP-users <
Hi Rajesh - The block "OFDM Sync Short" is part of the GR out-of-tree (OOT)
module "gr-ieee802-11" ... as are many of the other blocks in the image you
provided. If that OOT is not installed already, it shouldn't be difficult
to do so. Hope this is useful! - MLD
On Fri, Sep 6, 2019 at 5:10 AM Dr.
Hi Joel - IIRC UHD takes and provides std::complex values that are
in (-1.0,+1.0), meaning that the minimum (most negative) value is
-1.0+epsilon and the maximum (most positive) value is 1.0-epsilon, where
"epsilon" is the smallest positive 32-bit float value (approximately
1.17549e-38).
If
Hi JS - Maybe check out this Python example from UHD <
https://github.com/EttusResearch/uhd/blob/master/host/examples/python/rx_to_file.py
>
... it does Rx to file, and can save as NumPy format ... which could then
presumably be easily read back into NumPy. - MLD
On Thu, Sep 5, 2019 at 11:08 AM J
HI Emil - Thanks for that info. I'll work with you off-list & we can report
back on-list if appropriate. - MLD
On Wed, Aug 14, 2019, at 5:08 AM, Emil Bjelski wrote:
> Hi,
> I want to compile and install one of the existing example scripts that are
> located in */rfnoc/src/uhd/host/examples/*.
>
OK; that OS is great for GR / UHD / RFNoC work. What step are you on in the
guide?
On Tue, Aug 13, 2019, at 12:51 PM, Emil Bjelski wrote:
> Hello Michael,
>
> I am using Ubuntu 18.04.2 LTS.
>
> I installed UHD, GnuRadio and RFNoC using pybombs by following "Getting
> stared with RFNoC
Hi Emil - Can you tell us what OS you're using for the UHD host computer? If
you're trying to compile UHD from source, which version of UHD (release / GIT /
version). Those are useful starting points. Cheers! - MLD
On Tue, Aug 13, 2019, at 10:47 AM, Emil Bjelski via USRP-users wrote:
> Hello
Let's take this discussion off list. If there's something useful to report back
to the list we will. - MLD
On Fri, Aug 9, 2019, at 3:41 AM, Sneha vasan wrote:
> I want to know the time it takes to transmit and receive the signal,(which is
> in the sense delay). I calculate this based on the
Hi Zhao Xu - Your query is really about GNSS-SDR, not about USRP (or GNU
Radio). Hence it is better suited for their email list <
https://sourceforge.net/p/gnss-sdr/mailman/gnss-sdr-developers/ >, or directly
to one of their development team < https://gnss-sdr.org/team/ >, or maybe on
their
Hi Sneha - Please "reply all" to keep the discussion on the USRP users email
list. More eyes reading these means a greater chance that folks will jump in to
help!
The startup time for UHD / USRP / GR will be very similar between different
runs of the exact same flowgraph, but not exactly the
Hi Sneha - I take it by you forwarding your query without further comment that
you didn't receive an answer to it? FYI It would be useful in the future to add
such a comment, enquiring politely, before the forwarded part.
So the big question here is how you are generating the signal. You say
Hi Simona - Please see my reply just now to the GR discussion list, following
up from the other emails on the topic earlier today. - MLD
On Tue, Jul 30, 2019, at 12:42 PM, Simona Sibio via USRP-users wrote:
> Hi everyone,
>
> I am using N200 with GNU radio and I would like to measure the DC
Hi Zhenghao - To the best of my knowledge and memory, all of the examples
provided by UHD and GR are just single-channel. My guess is you'll need to
create your own custom flowgraph to handle 2 output channels from a single
input file. That said, if what you hope to do is the equivalent of
Hi Simona - Can you please educate us as to a few items?
* your setup: you have an N200 + some daughterboard (which one) + some spectrum
analyzer (which one), connected ?somehow? -> are you doing actual wireless Tx
-> Rx, or do you have a cable hooked up between the N200 & spectrum analyzer?
*
Hi Sneha - This is a GR issue, not a USRP issue, so you'd be better off
querying that email list (possibly along with this list, as you note a X310
that you're using). I'm following up here for completion. I'll reply to you &
the GR list after this email. - MLD
On Tue, Jun 4, 2019, at 9:50 AM,
Hi Fengyang - I'm glad to hear that things got working for your SDRs,
regardless of how. Sometimes "cruft happens" and things just need to be reset.
Good luck with your research! - MLD
On Thu, May 30, 2019, at 8:46 PM, Jiang, Fengyang wrote:
> Hi Michael,
>
> I've been trying different ways on
Hi Fengyang - Please "reply all" to stay on the list: more eyes reading
increases the chances of someone helping! I'm forwarding your email along with
its attachments just for this reason. Thanks for providing those scripts & your
commandlines: those will really help us in knowing what you're
Hi Fengyang - Since we don't know what exactly you're transmitting (meaning:
the Tx flowgraph or code), there could be all sorts of issues or settings
affecting the system to make it work at some frequencies and not at others. If
you could share the actual Tx & Rx flowgraph or code that would
Excellent news, Joe! You're welcome for the assistance; any time! Congrats on
persisting & now: have fun! - MLD
On Fri, May 10, 2019, at 7:55 PM, Joe Martin via USRP-users wrote:
> Holy smoke! SUCCESS!! Nick pointed out that there are two switches on the
> N210; S1 and S2 and S1 is a reset, so
The version of Volk currently installed is too new for the version of GNU Radio
you're trying to build. I'm not 100% clear on how to install different recipes
in PyBOMBS, but if you can do so try a newer version of GNU Radio (if you
search the GIT logs for "volk_32f_8u_polarbutterfly_32f"
Hi Rob - MacPorts sets a bunch of CMake arguments to force the build to
use headers and libraries provided by MacPorts as much as possible,
which you're probably not setting in your build-from-source UHD. If you
do "sudo port build uhd" then you can view the build log which is at
"port logfile
Hi dapodun nudopad - Check out < https://github.com/anastas/gr-cdma >
... the "pac_err_cal" block might do what you want. If not, it's
probably a good template for doing what you actually want. Hope this is
useful! - MLD
On Mon, Oct 29, 2018, at 8:26 AM, dapodun nudopad via USRP-users wrote:>
Apple's latest OSX, macOS Mojave 10.14, was officially released on September
24, 2018 -- just under a month ago. I've been running the public beta for a few
months on a separate partition to make sure GR / UHD / Volk work on this new
release ... and, the good news is that that they do!
There
Hi dapodun nudopad - Yes there are a variety of possible ways the Tx/Rx
can result in the "Parser returned #f" issue. What it means is that the
S detected a header, but the header CRCs (computed versus embedded)
didn't match up. Since we can't see your whole flowgraph, its a little
difficult to
OK thanks, Ale; maybe you did say; now we really do know ;)
Related: What version of UHD are you using?
The UHD version does make a difference, as some issues with the B2XY
series have been fixed recently that were introduced after the 3.9 LTS
release. - MLD
On Mon, Oct 15, 2018, at 8:43 AM,
Hi Sneha - If you're looking for the installed "tx_bursts" example, the
default location should be in the directory
"/usr/local/share/uhd/examples/". Cheers! - MLD
On Tue, Oct 9, 2018, at 5:25 AM, Sneha vasan via USRP-users wrote:
> Hi Sumit,
>
> I am trying to send samples in bursts. How to
Hi Sneha - Would you mind elaborating on your query? It's a little
uncertain what you're asking for here. ".cpp" files contain code written
in c++, and must be compiled using some c++ compiler. They can be
grouped together into a library or an executable. Sometimes executables
are created by
Boost 1.67.0 was released over the weekend, and there are incompatibilities
introduced by it for both GNU Radio and UHD -- both release and current GIT
master of each. Volk latest release as well as current GIT master both seem to
build and test cleanly using this new Boost version.
The
UHD 3.11.0.1 Release Candidate 1 is now in MacPorts as the port "uhd-
devel", for folks who want to try it. If you're currently using the
"uhd" port, then moving to "uhd-devel" might require rebuilding GNU
Radio; "port" should properly detect this situation and ask to rebuild
GR (and any other
Hi Sarah - Glad you're heading down a positive path.
The header data is removed from the raw data being decoded, but added as
meta-data on the stream. This meta-data is optionally printed out by GR
OFDM and/or various Qt displays. Once the header has been verified (via
CRC8), it is no longer part
Hi Sarah - A few things to note on using the default GR OFDM using real
SDR devices that could be relevant here:
* tx data amplification: This needs to be such that the data heading to
UHD doesn't saturate on conversion. You can visually see this if you
look at the raw Rx signal ... it will
For folks using Mac OS X / macOS and MacPorts, I have updated the "uhd-devel"
port to 3.11.0.0rc1 (git hash 9f67f624). These changes will be live by around
11 AM / US / Eastern.
If you use MacPorts and the current "uhd-devel" port, and you wish to test out
this release candidate, then all you
UHD 3.10.3.0 is also available for Mac OS X / macOS users via MacPorts,
through a 2 step process that most MacPorts users know very well already
but I'll repeat below for newer users wondering what to do.
If you don't have MacPorts installed yet and wish to do so, there are
comprehensive
I and other MacPorts developers have been testing out boost 1.66.0 for a
while now & it seems very stable. There are a ton of ports that rely on
Boost, and it takes time to go through them to verify that they at least
build & hopefully function too. I expect we'll be updating from 1.65.1
by
1 - 100 of 103 matches
Mail list logo
