If I build an FPGA image that includes a radio and a DDC and use the
Gnuradio USRP block to record 2-channel data on pulsed signals at a 1
MHz sample rate it runs fine and the streams are time aligned.
If I build a simple flowgraph with the RFNoC radio+DDC it also runs
fine but the samples are mis
Nothing beats the doctor's office effect. In case anyone else has been
looking for this I just got it:
in c++:
:
stream_cmd.stream_now = false; //true; //change this line
stream_cmd.time_spec = radio_ctrl->get_time_now()+1.5; //or prob. less
rx_stream->issue_stream_cmd(stream_cmd); //existing li
I'm trying to process multi-channel RFNoC streams in Gnuradio but would
settle for using the c++ API if necessary. I'm using just one of the
two TwinRX card in an X310. The simplest example of the alignment issue
is seem by comparing 2-channel recordings made at a 1 MHz sample rate
on an aperiodic
I've been a little embarassed at still not getting this so spent quite
a bit of time trying to figure it out before replying -- with no luck.
At this point you've provided everying except the gnuradio script so
maybe that last piece will fix it. Here is my script and my output. I'm
putting the add
ick Foster wrote:
> Here's a modified add-only block. You'll have to make a matching .xml
> descriptor and GRC block (if you're using gr-ettus).
>
> Probably it would be a super useful thing to have an add/sub block,
> instead of an addsub block. A register-controlled mux to
Theseus Cores
> project.
>
> Nick
>
> On Fri, Sep 6, 2019 at 3:18 PM d.des via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Nick-
> > Could you share the tricks to remove one of the output ports? I
> > don't
> > I'm having simil
Nick-
Could you share the tricks to remove one of the output ports? I don't
I'm having similar issues with my modified addsub block and don't have
enough room on the e310 fpga for extra fifos. It's not obvious from the
noc_block_addsub code, the use of splitstream and dummy variables is
very confus
I have a two-channel signal conditioning block based on
noc_block_addsub between the radio and a DDC. The entire flowgraph is
radio(2 channels out)->addsub(2 channels in and out)-> two separate ZMQ
Push Sinks. I'm using the DDC as an integrator/decimator because a pair
of FIRs or moving average blo
I'm trying to get 10 pounds of processing in a 5-pound radio. I have a
homemade signal conditioning block that (should) allow for integration
and decimation suitable for low-rate reporting. I've been placing my
block between the radio and the stock DDC but the DDC does more than I
need and takes a
and QT display issues. There
> is a few more minor things fixed in them but can you please give them
> and try on your system? I will try to replicate the siggen issue you
> ran into.
>
>
> Regards,
> Nate Temple
>
> On Sun, Aug 11, 2019 at 1:38 PM d.des via USRP-users
Thanks, Royce, that fixed the usrp side of both fosphor and my block!
I also made two minor tweaks to the host side to get fosphor working on
my PC. These are probably things that a Gnuradio expert would see right
away but in case there's anyone else out there who primarily uses the
c++ uhd interf
The latest version of AN-315
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
is a very nice update. It was great to be able to build a more-up-to-
date version of UHD error-free. There still seem to be issues getting
the example o
The trick to making rfnocnodtool work with Vivado Webpack is to edit
uhd/fpga-src/usrp3/tools/make/viv_sim_preamble.mak
#change the following line
#PART_ID = xc7k410t/ffg900/-2
PART_ID = xc7z020/clg484/-1
Don't ask how long it took me to figure this out.
I haven't had any luck building any E31
I'm still trying to revive Channel 0 on the E310 in UHD 3.15. I've
swapped SD cards with 3.15 from
http://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0-e310_prerelease/
and several older UHD versions such as
http://files.ettus.com/e3xx_images/e3xx-release-4/ in several E310
radios and
The good news is that my RFNoC module does what I want it to do. The
bad news is that every version of UHD I've tried it on has serious RF
quality issues on one or both channels. I don't remember this from the
last time I use E310s about 5 years ago so my next step is to find step
back SD images lo
At the risk of being repetitive, has anyone reading this checked to see
if anything but receiver noise is coming out of Radio Port 0? As of a
git pull of 3.15 last night Channel 1 looks great but Channel 0 is
still useless for me. It's as if neither antenna switch is connected
even though the LED
I've been testing RFNoC Blocks on the E310 using the SD image from
http://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0-e310_prerelease/
and a recent pull from git: commit
6563c53743617215a18542db7d7050a04a0d409d (HEAD, tag: v3.15.0.0-
e310_prerelease).
I got my RFNoC images doing what
I've wasted a lot of time on this over the past month with the same
goal and am just now getting up and running using the sd card image at
http://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0-e310_prerelease/
and a recent pull from git: commit
6563c53743617215a18542db7d7050a04a0d409d (H
It turns out that I was building the same image over and over again.
uhd_image_builder.py doesn't work out of the box for the e310 because
of the directory name change at top from e300 to e31x. I'd modified a
line:
build_dir = {
:
#'e310':'e300',
'e310':'e31x',
:
This caused
I'm using the new sdk and sd image from
http://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0-e310_prerelease/
and have build and run the base and rfnoc images from .../src/uhd/fpga-
src/usrp3/top/e31x by following the old tutorial on kb.ettus with just
a little updating.
it mostly see
Marcus Leach wrote:
>What happens if you specify an fpga image that doesn't actually
>exist?
>Does it error out?
It ignores the bad file, even though the args seem to be making it
pretty far into the process. I still can't find where uhd loads the
.bit file.
I'm using the version on the refere
Marcus Leach wrote:
>What happens if you specify an fpga image that doesn't actually
>exist?
>Does it error out?
It ignores the bad file, even though the args seem to be making it
pretty far into the process. I still can't find where uhd loads the
.bit file.
I'm using the version on the refere
Marcus Leach wrote:
> See this thread here:
>
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/046784.html
I understand how it's supposed to work, and it's always worked that way
before including in the outdated
http://files.ettus.com/e3xx_images/e3xx-release-4/ setup. Wi
I found the new SD image and cross-compiler described in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html
and it seems to work well for the UHD that's pre-installed. I was also
able to build the v3.15.0.0 pre-release host code from git and run it
from a sshfs "newin
can anyone provide guidance on finding or creating an updated cross-
compile toolchain for the E310? The newest one at
http://files.ettus.com/e3xx_images/ won't build recent uhd because of
an old cmake and probably more.
___
USRP-users mailing list
USR
update: as far as I can tell uhd_images_downloader no longer tells the
user where on Ettus's server it looks for the files and even with an
internet connection it doesn't grab the RFNoC images. However, I was
able to look inside the uhd_images_downloader.py file itself and piece
together the new im
I'm still trying to re-create the situation which existed back when
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
was written but am not having any luck. Following those insructions I
can't get access to any pre-build modules ot
The instructions at
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
are pretty good and with a little tweaking to account for changes in
image file naming and storage location conventions. The process
produces a partially-useful
armonics of
> > clocks
> > involved in your cabling setup, and determine how to might enter
> > one of
> > the GNSS bands and how you are going to attenuate them.
> >
> > Mark-Jan
> >
> > On Sat, Jan 19, 2019 at 06:36:03PM +, d.des via
We've experienced some GPS degradation with the B210 running USB3 that
was bad enough to kick us off a small test platform. The only way we've
found to reduce the EMI to acceptable levels was to use a USB2 cable to
force the controller down to the slower speed, and the bandwidth
reduction makes for
I know that this isn't a Redhawk forum but maybe someone here has a quick
pointer. Is there a step-by-step guide to making a simple recording using a
B210 and Redhawk 2.1.0? I'm running on a fresh Centos 7.2 installation, which
is one of their tested OS recomendations. None of the waveform exam
31 matches
Mail list logo
