Hi Mike - Thanks for the pointer. Just to be clear, are you talking
about Boost 1.66.0 beta 1? That seems to be the latest version available
from boost.org. Boost often goes through a few betas before a release,
so it's possible that the API will be restored or further altered; I
haven't looked int
... and ... looks like boost 1.66.0 was released today (2017-12-18).
Since there was just 1 beta TTBOMK, this Boost version probably still
has the reported issue. Let the testing begin! - MLD
On Sun, Dec 17, 2017, at 04:05 PM, Michael Dickens wrote:
> Hi Mike - Thanks for the pointer. Just to be c
Thanks for the diffs, Mike. I'll get them a try shortly when I have
Boost 1.66.0 release installed. Cheers! - MLD
On Mon, Dec 18, 2017, at 10:05 AM, Mike wrote:
>
> Zitat von Michael Dickens :
>
> > Hi Mike - Thanks for the pointer. Just to be clear, are you talking
> > about Boost 1.66.0 beta 1
Hi Weihan - When you simulate "over the air" inside GNU Radio, there are fewer
wireless issues encountered & the data is much more likely to be received.
Actual OTA is somewhat more challenging, especially if you're sending just 1
frame.
Some suggestions, based on personal experience:
* try se
In initial testing, Boost 1.66.0 is fully compatible with the current GNU Radio
and Volk GIT master & current releases. There's an issue with UHD that has
already been fixed in the GIT master, but the new boost otherwise seems to work
with UHD & the backport to the latest release is very straigh
Hi David - It looks like you have 2 versions of UHD around, both of
which are in standard install locations (/usr and /usr/local). This can
cause confusion / issues when running executables for either install.
I'd advise you to pick one UHD install and remove the other; you might
have to even remov
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 mid-Jan
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 instruct
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 n
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
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 - You're welcome & the PER block sounds cool ... do you have a
public repo where we can view the source? Well done!
As for your other question: Have you tried updating to the latest UHD
release (3.11)? That might fix the issue "out of the box" ... and if
not, try building from source via t
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 port
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 OS-inde
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 t
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 part
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 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 <
usrp-users@lists.ettus.com>
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 out?
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 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 message
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 us
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 s
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
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, Ap
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
> tryin
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
probab
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 <
usrp-users@lists.ettus.
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 sh
+ via the UHD C++ 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 1
via the UHD C++ 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
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: https://ettus.
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 “stati
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 t
... 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
r
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, Je
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 canno
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, of
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), su
Thanks for the UHD 4.0rc1 update, Michael. This UHD version will be the
most robust and compatible version yet!
For macOS users of UHD and GNU Radio, a brief update:
UHD 3.15 and UHD 4.0rc1 build and run on many macOS versions -- at
least 10.11 " El Capitan" through 10.15 "Catalina", and probably
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) 4.8
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;
* USR
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
10.16-be
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
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 o
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 E
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 using
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 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 i
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 b
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 <
ra.a...@globale
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
>
<
https://files.ettus.com/binaries/cache/e3xx/met
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. Us
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
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
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 --args="type=n200
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; UHD_3.15.0.HEAD
Hi Ben - This issue has been reported to R&D 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 <
usrp-users@lists.
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 specif
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
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? The
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 meani
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
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
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 nicely
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 poi
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
ha
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 pro
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, includ
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 linkin
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 compi
Hi Mitch - Can you provide your code for us to review, to get an idea of
what you're doing that's causing this issue for you? Without specific
code, debugging is a little difficult ... And, no, I haven't seen this
issue to the best of my knowledge / understanding of what it might be.
Cheers! - ML
Hi Ale - Reducing this query to just the USRP list since I'm guessing if
there is any issue its with that side of things. I'll reiterate Marcus'
query, and augment it. The performance depends on which USRP and which
version of UHD you're using. You didn't mention those. Scripts are
important (thank
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, Merc
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&C 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 g
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 ha
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:> Hello
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 uhd"
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" you'll
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 a
Hi Dylan - From what you've posted, it sounds like you have an issue with the
HackRF One, not the NI USRP; could be configuring it, or some runtime issue;
really not clear. Given that this is the -USRP- users list, I'd advise you to
look to GSG about what's going on; this website provides some g
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 be
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 tr
Could you also provide the files that do these Python commands?
{{{
from receive_path import receive_path
from transmit_path import transmit_path
from uhd_interface import uhd_receiver
}}}
Those really are the heart of your Tx and Rx ! - MLD
- Original message -
> From: "Jiang, Fengyang"
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 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 Sneha - This is really a GR issue, not a USRP one. Thus, I'm replying for
completion here & will reply to just the GR list after this. - MLD
On Wed, Jun 5, 2019, at 10:25 AM, Sneha vasan via USRP-users wrote:
> Hi everyone,
>
> Can anybody guide me on this???.. I am using x310 with sampling r
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 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
"tx_
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 offs
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
"M
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 sa
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 Git
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 time
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 eve
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 developm
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/*.
>
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 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 you're
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.
1 - 100 of 113 matches
Mail list logo
