"Jon Pendlum"
Date: 8/20/18 10:58 am
To: "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
Hey Jason,
You could try testing with noc_block_skeleton. It only does a loopback and has
a self checking testbench.
Jonathon
On Mon, Aug 20, 2018, 11:48 PM Jason M
This is a long shot, but I have been fighting with my rfnoc block the last few
days trying to figure out why it won't work. I am basically combining the
threshold block and the siggen block (so it takes in values, and spits out data
based on the siggen parameters).
My block has been spitting
nt the last two days trying to debuf this before I found out it was
the axi fifo filling up. It is weird to me that it is slowly falling behind. It
makes me feel like tlast maybe has something to do with it.
Original message From: Brian Padalino
Date: 8/22/18 4:04 PM (GMT-0
OK, let me elaborate since my first email was not very well written (I was
throwing it out there on the way out the door). I spent all day yesterday
thinking that I was making progress, the last simulation was copacetic, so I
did a build over night, and yet again, no love.
I started on this b
Whoops, I misspoke on the SPP size. At some point I must have changed the SPP
to 1024. So with a file size of 57344 bytes, it was 57344/8/1024 = 7 full
packets that made it though.
When I tried it at SPP=16, 3840 bytes were in the file sink. So 3840/8/16 = 30
packets made it through.
This
I may be wrong, but I am pretty sure that RFNoC has issues with more inputs
than outputs on a block. I believe the workout is to put a dummy output on the
other side and hide it in GRC. Hopefully someone will speak up if I am wrong.
- Original Message - Subject: [USRP-users]
Andrew,
I have this issue all the time. To get around it, I go into properties of the
block (double click on it in the GRC), go to the the RFNoC Config tab, and
change the Device Select to 0 for one of them, and 1 for the other. There is
some sort of issue (I don't recall why, but it was exp
fifos are filling up without reading
(axi_fifo_short).
I am going to try to find another machine to see if I threshold works there,
but I am thinking that something else is going on somewhere
- Original Message - Subject: RE: Re: [USRP-users] RFNoC fifo
filling up
F
I know that this is an old thread from Dec 2017, but I see the same issues. I
am running Centos now, and I am thinking that this is related to that (old
kernels, etc.).
The error I see when I do the make is:
[ 39%] Building CXX object
lib/CMakeFiles/uhd.dir/usrp/e300/e300_sysfs_hooks.cpp.o
[
Philip, I know I am digging this up from early in the year, but I didn't see an
answer. I am having the exact same issue with the six package. Were you ever
able to fix this?
- Original Message -On 04/02/2018 06:58 PM, Marcus D. Leech
wrote:
> On 04/02/2018 06:09 PM, P
- Subject: Re: [USRP-users] Issues
installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
From: "Philip Balister"
Date: 9/5/18 3:35 pm
To: "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
> Ph
Just finished running the second command just mentioned below, still died with
the package "six" error.
- Original Message - Subject: RE: Re: [USRP-users] Issues
installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
From: "Jason Matusiak"
Dat
he directory with the uncompressed six and run "python setup.py
install"
5) Open a new terminal
6) Go back to your prefix directory and source setup_env.sh
7) Run pybombs rebuild gnuradio
8) Run pybombs install gr-ettus
On Wed, Sep 5, 2018 at 12:35 PM, Philip Balister via USRP-users
The issue is on your output side. It has been explained to me (I think it is
somewhere on this mailing list due to an issue I and other have had), that you
can't mix ports to be both host and rfnoc streams on the same side of the RFNoC
block. So it sounds like the input side has both inputs co
OK, I am having a weird cross-compile issue still. I am using the latest
cross-compile files from Philip, but I am getting a weird error that has me
stumped.
Here are the steps I took, maybe I hosed something up along the way. I am
worried about:
1 - How I setup the cmakes
2 - enabling RFNOC
:get_system_time();
It feels like I need to use the head of GR, but that something in the
cross-compile isn't playing nice with the single_threaded_scheduler.cc operator
overload. It's never easy...
- Original Message - Subject: Re: [USRP-users] E310
cross-compile
Rob,
Honestly, it seems like stuff has gotten sideways all over the place. Things I
used to be able to do are no longer working (granted, I am working on an E310,
so that increases the complexities).
Try this instruction though:
https://github.com/gnuradio/gnuradio/issues/1706#issuecomment-
It has been a while since I've built a bitfile for the E310, but I used a setup
that works fine for my X310.
I source: /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd-fpga/usrp3/top/e300/setupenv.sh
it finds vivado 2017.4 fine and it said it was successful.
then I run: /uhd_image_builder.py keep_1_in_
There was a thread back in 2017 (and revisited at least once) on the mailing
list that is biting me and stopping me from running an RFNoC cross-compiled UHD
on an E312.
Here is Jonathon's answer on the original thread:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/02395
ant TX/RX --rate 1e6 --null
it actually runs fine. So it feels like UHD is working pretty well, but
something about the UHD/GR link is fubared...
- Original Message - Subject: Error in uhd_usrp_probe revisit
From: "Jason Matusiak"
Date: 9/13/18 9:41 am
To: "Ettu
rd fpga timing issue?).
Extra info:
1 - The uhd hash is: eec24d7
2 - The fpga-src hash within uhd is: 9c8c2ba
3 - gnuradio's hash is (this shouldn't matter since I am not even running GR
yet): e4acf4f
4 - gr-ettus' hash is: 51e8828
~Jason
I have a cross-compile setup for my E312 that is working fine. If I run a
benchmark_rate using my compiled UHD and bitfile, it works as intended. I see
about 10MHz throughput from the FPGA to the ARM before I start dropping
samples, that is about right based on my readings.
Now, if I use all
are running stock. I am hoping maybe these comments will strike a
chord in someone's mind and there might be something easy to look into that
might be causing the issue!
TIA
- Original Message - Subject: UHD not getting full bandwidth on
E310
From: "Jason Matusiak
I have a flowgraph I am running on an E310 using all stock RFNoC blocks. It
looks a lot like this:
RFNoC:Radio ---> RFNoC: Split Stream ---> RFNoC: FFT ---> RFNoC: Keep 1 in N
---> RFNoC: Log Power > GR: complex to float ---> GR:Raster Sink
Is the max usable SPP size on the E310 capped at 512? In my flowgraph, I have
an RFNoC FFT block. I know that the SPP needs to be set to the size of the FFT
to make things happy and using 512 seems to work fine. As soon as I step up to
1024 I see a lot of errors:
RFNoC Streamer block receiv
I wouldn't mind seeing your solution to #2 as well. The messages certainly
make things look more ominous than they actually are.
- Original Message - Subject: Re: [USRP-users] Can't find a
block controller for key FFT, using default block controller!
From: "EJ Kreinar via USR
odd with the sample rate? This doesn't add up to me.
- Original Message - Subject: general RFNoC timing question
From: "Jason Matusiak"
Date: 9/24/18 2:48 pm
To: "Ettus Mail List"
I have a flowgraph I am running on an E310 using all stock RFNoC b
PP
on the E310
From: "Jon Pendlum"
Date: 9/25/18 10:57 am
To: "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
Hey Jason,
Yes 512 is the max SPP, due to the 4k max DMA transfer size. To support larger
FFTs, you could modify the FFT noc block to split up the frame
I have a block that outputs a message with a frequency. I would love to be
able to set the frequency adjustment in the RFNoC DDC, but I don't see a way to
do it it automagically.
I am guessing that there is no way to do it even though it can be set from a
variable slider easily. Is there an opt
.
What options do I have for debugging the EEPROM?
Thank you,
Jason Meyer
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hi Marcus,
I am using UHD v3.11.1.0. The command format I've used is:
uhd_image_loader --args="type=x300,addr=192.168.10.2"
--fpga-path="/usr/local/share/uhd/images/.bit"
Jason
On Thu, Sep 27, 2018 at 5:28 PM Marcus D. Leech via USRP-users <
usrp-users@lists.e
via JTAG. This has happened with 3 different USRPs.
Jason
On Thu, Sep 27, 2018 at 6:40 PM Marcus D. Leech wrote:
> On 09/27/2018 06:34 PM, Jason Meyer wrote:
>
> Hi Marcus,
>
> I am using UHD v3.11.1.0. The command format I've used is:
>
> uhd_image_loader --args=&q
I don't believe so, as I copy/pasted the bit file path from Vivado to the
terminal. So I know I am using the same bit file for uhd_image_loader as I
am for the JTAG programming, which is working fine.
Thanks,
Jason
On Thu, Sep 27, 2018 at 7:17 PM Wade Fife wrote:
> Is it possible tha
Yes, I’m seeing the same behavior with a standard image as with my custom image.
Jason
> On Sep 27, 2018, at 8:31 PM, Marcus D. Leech wrote:
>
>> On 09/27/2018 07:09 PM, Jason Meyer wrote:
>> The command produces output as if there is no issue. It shows the progress
>
To: usrp-users@lists.ettus.com
Hi Jason,
I was about to write code, but then realized: gr-ettus' Block impl
already has what you need, the message port "rfnoc", which'll accept
messages in the PMT dict format. You can extract the shape of
information you need to send in from the
poked
in via a variable, so I am not sure why that would work).
- Original Message - Subject: RE: Re: [USRP-users] Messaging
the DDC
From: "Jason Matusiak"
Date: 10/3/18 9:27 am
To: "Marcus Müller" , usrp-users@lists.ettus.com
Sorry, Marcus, I was out
tuples, but no luck.
Any guesses?
- Original Message - Subject: RE: Re: [USRP-users] Messaging
the DDC
From: "Jason Matusiak"
Date: 10/3/18 2:58 pm
To: "Marcus Müller" , usrp-users@lists.ettus.com
Marcus, Looking a little closer, I am a little confused
I have a problem that I thought I solved a year or two back, but I can't seem
to find it in my notes anywhere.
I have a GR app that I want to run on boot on an E310, I know how to do that
for straight GR. The problem is that it is an RFNoC GR app, so I need to
source the cross-compiled tools
x27;feval_ll.eval'
Any idea how to do this? I tried poking through the mailing list as well as
the USRP manual, but I don't see any way to do it when you are an RFNoC radio.
~Jason
___
USRP-users mailing list
USRP-users@
into that for the future.
~Jason
- Original Message - Subject: Re: [USRP-users] getting GPS time
from RFNoC bitfile on E310
From: "Marcus Müller"
Date: 10/23/18 3:44 am
To: "EJ Kreinar" , "Jason Matusiak"
Cc: "USRP-users@lists.ettus.
USRP-users] Messaging
the DDC
From: "Jason Matusiak"
Date: 10/3/18 2:58 pm
To: "Marcus Müller" , usrp-users@lists.ettus.com
Marcus, Looking a little closer, I am a little confused.
I can make the change, and that allows the message block to appear in GRC, but
I am thinkin
I might be speaking out of turn here since I don't really know what the replay
block does. But in the past, I successfully created a block that used a .coe
file as a generated signal I transmitted over and over again. It was a pretty
easy OOT module that just used a Xilinx core if I remember r
(sorry for the hijack, but I felt it was somewhat on topic)
Just curious, I am sure there is a good reason, but why can't we build in our
own custom drivers (I am not a low-level linux guy, so I am sure it is probably
obvious)? So far we have been OK, but we have been a little nervous with som
Stupid question. I do a lot of work on both the E310 and X310. Currently I
setup my X310 via pybombs and then my E310 by hand (pybombs install doesn't
seem to work for us). The problem is that I am now maintaining two different
trees if I want to have the same OOT module in both. Is there ar
OK, this has befuddled me for 3 days and I can't seem to get past it. I have a
prefix that seems to work fine.
Here are my working steps for building a bitfile on an E310:
cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
source ../../top/e300/setupenv.sh
./uhd_image_builder.py kee
ples. Then wash, rinse,
repeat. The verilog is attached since I was having trouble keeping formatting
when I pasted it here.
- Original Message - Subject: Re: [USRP-users] rfnoc build
works for E310, doesn't meet timing with X310
From: "EJ Kreinar"
Dat
n't meet timing with X310
From: "EJ Kreinar"
Date: 11/8/18 10:02 am
To: "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
First, it's really not failing by much -- you got under 7 ns, so it's
*almost* there.
Two suggestions:
1. If the input/ou
Peter, I know that this is an old thread, but I was wondering if you remember
if you've ever solved this? I think that I am running into the same issue with
my RFNOC OOT block.
Thanks.
Hi All,
Tutorial aside, I was running the rfnoc_fir example from GNU Radio
Companion. At 10M sample rat
I have a problem that I think I have a workaround for, but I would like to
understand what is going on if I could. I am guessing that it is a DSPish
issue with the way that the DDC is implemented, but I can't quite figure it out.
My design had been working on an E310 and I was trying to move i
I am seeing something weird that I am sure is a simple mistake on my side, but
I can't quite see what I am doing wrong.
I have a test transmitter outputting a signal at 391.5MHz. It is on 10s, and
then off 10s. This works fine and runs independently.
My flowgraph of interest on the receive
t the first time and then can bounce around a little on subsequent
re-runs. So if I power cycle between runs it is fine. Not sure what is going
on there, but I'll come back to that issue later.
- Original Message - Subject: weirdness with RFNoC RX "walking"
From: &q
t.
After making the mod, I am working pretty well (small sample size though).
- Original Message - Subject: RE: Re: Re: [USRP-users] RFNoC
FPGA clear_tx_seqnum behavior
From: "Jason Matusiak"
Date: 7/2/18 12:03 pm
To: "Brian Padalino"
Cc: "USRP-us
I have a flowgraph where I use 3 different DDCs on an X310. There is a dual
DDC that is connected to the two radios on the X310. Then I have 2 single DDCs
chained off of that first one. I built these DDCs to only have a single
input/output on them.
The flowgraph will work, but sometimes won
24d7b
- Original Message - Subject: Can I use chained DDCs?
From: "Jason Matusiak"
Date: 12/3/18 7:23 am
To: "Ettus Mail List"
I have a flowgraph where I use 3 different DDCs on an X310. There is a dual
DDC that is connected to the two radios on the X310. Then I ha
uld handle. Right now I am not touching the
CORDIC modifications at all.
What version of UHD are you running for your applications?
- Original Message - Subject: Re: [USRP-users] Can I use
chained DDCs?
From: "Brian Padalino"
Date: 12/3/18 11:44 am
To: "Jason M
as well. Thanks!
- Original Message - Subject: Re: Re: [USRP-users] Can I use
chained DDCs?
From: "Brian Padalino"
Date: 12/3/18 12:03 pm
To: "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
Hey Jason,
On Mon, Dec 3, 2018 at 11:50 AM Jason Ma
into that more next.
- Original Message - Subject: RE: Re: Re: [USRP-users] Can I
use chained DDCs?
From: "Jason Matusiak"
Date: 12/3/18 12:08 pm
To: "Brian Padalino"
Cc: "USRP-users@lists.ettus.com"
Brian,
No. I am leaving it alone on
I have a X310 with a pair of CBX-130s installed and am running RFNoC. The
flowraph looks like this:
Radio (running at 200MHz) -> DDC (200MHz down to 50MHz) -> splitter -> off to
some other blocks.
What is weird to me is that I wasn't thinking and I set the sample_rate to to
be the master
- Subject: Re: [USRP-users] X310's sample
rate
From: "Brian Padalino"
Date: 12/4/18 10:40 am
To: "Jason Matusiak"
Cc: "USRP-users@lists.ettus.com"
On Tue, Dec 4, 2018 at 10:35 AM Jason Matusiak via USRP-users
wrote:
I have a X310 with a pair of CBX-
users"
Date: 12/9/18 5:27 am
To: usrp-users@lists.ettus.com
Hi Jason,
I'm currently on the rfnoc-devel branch of uhd/host as well. And having
the same problem: Changing frequency on the DDC or radio causes hangs.
However, on 'master', the data format out of the rfnoc blocks d
I finally got an N310 to play with. I was trying to build a custom RFNoC FPGA
image, but it keeps erroring out.
The command I am running is:
./uhd_image_builder.py -d N310 -t N310_RFNOC_XG -I
/opt/gnuradio/N310/src/rfnoc-nocblocks -y
/opt/gnuradio/N310/src/rfnoc-nocblocks/fpga_build/n310_4ddc
does
uhd_image_builder work with N310
From: "EJ Kreinar"
Date: 12/14/18 12:27 pm
To: rkoss...@nd.edu
Cc: "Jason Matusiak" ,
"USRP-users@lists.ettus.com"
Hi Jason and Rob,
I'm using OOT RFNoC builds for N300 and N310 successfully. What version are you
on?
Al
Has anyone successfully created a new build for an N310 (RFNoC version in
particular)? I was going to bring it up to date, but seem to be having issues.
I ran: uhd_images_downloader -t sdimg -v
To get the *.sh image for cross-compiling:
oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
I
Original Message - Subject: cross-compiling for N310
From: "Jason Matusiak"
Date: 12/17/18 1:35 pm
To: "Ettus Mail List"
Has anyone successfully created a new build for an N310 (RFNoC version in
particular)? I was going to bring it up to date, but seem to b
ginal Message - Subject: RE: cross-compiling for N310
From: "Jason Matusiak"
Date: 12/17/18 3:15 pm
To: "Ettus Mail List"
OK, I see the first mistake. I was copying-and-pasting my notes for the E310
which had a different sysroot. Once I made the change to the proper o
step which is next (needed for RFNoC). I haven't tried running
gnuradio, but it builds.
- Original Message - Subject: Re: [USRP-users] cross-compiling
for N310
From: "Philip Balister"
Date: 12/18/18 10:25 am
To: "Jason Matusiak" , "Ettus Mai
I think I need to rebuild mpm since I rebuilt UHD for the embedded N310.
I tried to rebuild it on the host with cross-compile sourced, but I get this
error that keeps make from working:
CMake Warning at
/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindBoost.cmak
I was struggling with this problem a while back and had to drop it, but am back
to dealing with it now.
I have an RFNoC block that is basically crossing in/out streams. It has 2
inputs and 2 outputs. Input 0 goes to output 1, and input 1 goes to output 0.
Eventually it will be more complica
I'm a bit confused about the rfnoc siggen packet size option is doing. I am
trying to incorporate the siggen block into one of my designs, but it doesn't
work right. If I set packet size to 1, things aren't working right.
So I change my packet size to something like 256, setting my other bloc
riginal Message - Subject: Re: [USRP-users] How does RFNoC
siggen packet size work
From: "Rob Kossler"
Date: 1/15/19 9:58 am
To: "Jason Matusiak"
Cc: "Ettus Mail List"
Have you looked at the GRC siggen examples in gr-ettus? I just took a quick
look and perhaps they are n
Nick, I was wondering if you ever posted anything about your workaround to the
limitation you talked about below from back in June?
In my flowgraph, I have both RFNoC radio's receiving and each stream has a
split_stream in it. I am concerned that the split stream might be causing some
of my i
Is it possible to have two different DMAFifo RFNoC blocks on an X310? I am not
worried about the resources so much as how to implement it (I know that I
cannot add it to the uhd_image_builder as it is a special case).
Thanks.
___
USRP-users mailing l
Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it?
I can't seem to figure out a way to make it work, though I think there must be
a way. Both streams would be streaming to the same host machine for processing.
Thanks.
__
w, Device 0 will get associated with addr0, and device 1 will get associates
with addr1.
I hope that makes sense and helps someone.
From: Rob Kossler
Sent: Friday, February 1, 2019 9:23 AM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] tw
hings.
From: Jason Matusiak
Sent: Friday, February 1, 2019 9:43 AM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph
Rob,
I just figured it out (I found lots of people asking the question, but no
answers, so hopefully thi
Yep, works fine. When I am doing it in companion, it also reports info on both
boxes while setting it up, but it feels like it only tries to talk to the first
one it sees.
From: Rob Kossler
Sent: Friday, February 1, 2019 1:08 PM
To: Jason Matusiak
Cc: Ettus
ep
getting that error.
If feels like there is a UHD issue that when it is trying to setup which block
goes with which device, it thinks that there is only one device
From: Rob Kossler
Sent: Friday, February 1, 2019 1:14 PM
To: Jason Matusiak
Cc: Ettus Mai
of issue where it assigns IP addresses to the two devices, and then there is a
race condition with which one responds first
From: Rob Kossler
Sent: Friday, February 1, 2019 1:28 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one
ed:0
Num transmitted samples: 0
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 0
Num late commands:0
Num timeouts (Tx):0
Num timeouts (Rx):0
Done!
____
From: Rob Kossler
Sent: Friday, Feb
it is a crap-shoot.
From: Jason Matusiak
Sent: Friday, February 1, 2019 1:53 PM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph
I needed to make some mods to your command, but it seems to have worked. Not
sure why it
Kossler
Sent: Friday, February 1, 2019 2:19 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph
Not sure..
This may be irrelevant, but I noticed that you only have 2 FFT and 2 fosphor
blocks per device, whereas the TwinRx has 4 channels since the
I am attempting to use PCIe on an X310 for the first time. I poked around and
it looked like I needed to download and install
niusrprio-installer-18.0.0.tar.gz. It seems to install correctly. I started
up the service and then the X310, but I cannot seem to uhd_find_device.
I am running Cento
I just realized that the order of IP addresses in Device3 matters for boxes
that aren't TwinRX as well. So this isn't a multi_usrp twinrx problem, but a
more generic one.
____
From: Jason Matusiak
Sent: Friday, February 1, 2019 2:02 PM
To: Rob Kossler
Cc:
mment).
I assume that if it was easy to make it thread safe it would have been done
already, but I think it is biting me now and my quick attempt at working around
it hasn't gone so well as of yet.
____
From: Jason Matusiak
Sent: Monday, February 4, 2019 1:40 PM
A while back, I had asked about the lack of get_mboard_sensor when using an
RFNoC source block:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-October/058279.html
I just revisted that this week and seem to have the hooks working as I would
hope. I then went to move onto some
Ron,
Can you elaborate on what the changes you referenced are and their
consequences? In my past experience, increasing the frame size has been
critical to achieving full-rate throughput on the B200 series.
Jason
> On Feb 8, 2019, at 3:45 PM, Ron Economos via USRP-users
> wrote:
&g
How much current can the X300 REF OUT port drive? I have another device that
has a reference input with a relatively low input impedance, and I want to
ensure that it can source enough current to properly drive it.
Thanks.
Jason
___
USRP-users
Ramazan,
The timeout channel 0 error is using a timeout that RFNoC is throwing. There
is a timeout built in that can be ignored if you are purposely dropping a bunch
of samples in the RFNoC domain (which I do in a few flowgraphs). If you dig
through the mailing list, someone pointed to where
Cherif. I will attempt to take a stab at a few of your questions. Don't take
my answers as 100% right
1 - All the blocks run at the same rate, but I am pretty sure you can implement
an MMCM within your block to lower the rate for your needs and then back up to
the crossbar rate. Don't qu
Probably not the approved way, but I made an FFT 2048 block a while back. I
didn't much with packet sizes or anything, I just sucked in two 1024 packets,
did the FFT, and then sent two 1024 packets back out. It seemed to work fine.
The only issue is that you have to remember downstream that y
I've started playing with the E310's IMU and I keep seeming to go around in
circles. All I really want is a heading. I have my own app that is heavily
borrowed from the RTIMULibDemo included on the device (and from github), but I
can't seem to get the heading still right when dealing with the
As usual, I should have emailed days ago since I found the answer just
afterwards.
Using the code from here:
https://github.com/kriswiner/MPU9150/blob/master/MPU9150BasicAHRS.ino
I was able to get good values. q[0] is w in his equation.
From: Jason Matusiak
And you have a 1Gb SFP plugged into the first port in the X310 going to a 1GB
connection on the other end?
From: USRP-users on behalf of Nicolas
GALLAND via USRP-users
Sent: Thursday, March 28, 2019 7:26 AM
To: Marcus D. Leech; Joe Martin
Cc: usrp-users@lists.e
I don't know why this would be, but it almost feels like a hex issue somewhere.
Where are you setting the block size to 10? It feels like something is
interpreting that as 0x10, and I think 16 is a magic number that is too large.
From: USRP-users on behalf of
FWIW, these are the steps I use (some of them aren't really needed, but it
works, so I do it every time):
mkdir ~/E310 ###This is the directory that will be a mount point for your
remote E310
sshfs -o allow_root root@192.168.1.10:/ ~/E310 ###Your E310's / directory now
starts at ~/E310 on y
I should be getting an e320 in this week, so I started to get my environment
setup. I started off like I do for the e310 and ran the cross-compile shell
script. I then sourced the environment. I cloned uhd and checked out
rfnoc-devel like I usually do. Within uhd, I created a folder called
ed on the Ettus site. Does something like that exist for this?
____
From: Jason Matusiak
Sent: Monday, April 8, 2019 3:33 PM
To: usrp-users@lists.ettus.com
Subject: rfnoc build for an e320
I should be getting an e320 in this week, so I started to get my environment
s
t).
____
From: Nate Temple
Sent: Monday, April 8, 2019 4:03 PM
To: Jason Matusiak
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc build for an e320
Hi Jason,
You can disable the QT widgets (not needed on the E320 itself) by adding the
cmake flag -DE
Trying to build a FPGA image with an OOT module is not going well. I first
built with standard blocks and that worked, so I know my setup is OK.
I then tried to build with my OOT module (and this used to work on an old
prefix), but now is erroring out because it can't find my OOT block. The
c
it is in the this case), it doesn't try to
include it anymore?
From: USRP-users on behalf of Jason
Matusiak via USRP-users
Sent: Wednesday, April 10, 2019 1:23 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] OOT RFNoC not building on latest
Tryi
101 - 200 of 304 matches
Mail list logo
