Zhongren,
I am not sure that this will help you, but one of the things that I did when
working with the E31x was to install everything to ~/localhost and leave the
default stuff alone. I then created a setup_env.sh for those new files
(similar to what pybombs does), and run that before I using
Jonathon, If you look at the more recent commits for UHD, they added in a fix
to the split_stream error. Basically you need to change a 1'b1 to a 2'b11 in
the noc_shell section (I think that is the section, I can't recall off the top
of my head). Try that and rebuild.
28&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=JbLHwD_efOdK-ZuvD-QH2Fw4AAiWtCXu0WvdSfn6_xE&s=lE6ZF4x-LhtjQkpWmr6HKpawJBtAP1yjwDDIfqzCFhA&e=>
On Mon, Oct 21, 2019 at 9:37 AM Jason Matusiak via USRP-users
mailto:
I am just starting to play with the N310 and I am having issues with some of
our flowgraphs that work fine with the X310 and the E320. The issue seems to
be that there seems to be minimal support for python 2.7 for the N310. Is
there a toolchain or anything else I can do to get better support?
Jeff,
This is an issue that tripped me up for numerous days in the past until
Jonathon pointed me to the same fix. It appears to be something wrong in
gr-ettus (or a combo of the change and the UHD you and I both used), but they
haven't seemed to have addressed this for some reason. It would
Not sure. I checked my notes and the firewall was the issue I had when I was
forced to use the IP address. All your network configurations look good?
From: Mark Koenig
Sent: Friday, October 4, 2019 1:28 PM
To: Jason Matusiak
Subject: Re: usrp probe and find co
Is your firewall blocking the port that UHD needs? I feel like I had a serial
problem in the past and that was the issue.
From: USRP-users on behalf of Mark Koenig
via USRP-users
Sent: Friday, October 4, 2019 1:17 PM
To: usrp-users@lists.ettus.com
Subject: [U
To: Jason Matusiak
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC not re-tuning consistently
I wonder if this is just because in RFNoC the DDC is explicitly visible, so you
have to program it to account for synthesizer step size?
Sent from my iPhone
On Oct 1, 2019, at 12:52 P
On Oct 1, 2019, at 12:52 PM, Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
I have an issue that is very odd to me. I have tried two different X310s with
different daughter cards and they are all exhibiting this behavior. It feels
like I am doing something stu
I have an issue that is very odd to me. I have tried two different X310s with
different daughter cards and they are all exhibiting this behavior. It feels
like I am doing something stupid, but I can't quite figure out what. (a picture
is attached)
If I have a usrp source connected to a freq s
-Neel Pandeya
On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
We are having another issues with our TwinRXs. A co-worker has been trying to
get this to work for a while, but has had no luck with the PPS timing. Here is
the notes:
We
] next pps issues with TwinRX
Hello Jason:
We'll look into this and get back to you shortly.
If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ?
Which version of GNU Radio are you using?
--Neel Pandeya
On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-
We are having another issues with our TwinRXs. A co-worker has been trying to
get this to work for a while, but has had no luck with the PPS timing. Here is
the notes:
We are running UHD_3.14.1.HEAD-12-g5f75f73f.
The setup is a single X310 (revision: 11, revision_compat: 7) with two TwinRX
ers@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference
Hi Jason,
This might be a bug with the E320. I will need to try to recreate this issue.
I'll follow up as soon as I have more info.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 12:32 PM Jason
ould you try reverting gr-ettus back one commit to 4980cbef and let me know if
that works?
Jonathon
On Tue, Sep 10, 2019 at 5:23 AM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
I have an RFNoC flowgraph and bitfile combo that used to work but is erroring
out now
I have an RFNoC flowgraph and bitfile combo that used to work but is erroring
out now. I've been using the code successfully on the E320 and E310 and decided
to re-build for the X310 (and XG flowgraph). When I run my flowgraph, I am see
a lot of addition debug that I am not used to seeing (whi
users on behalf of Jason
Matusiak via USRP-users
Sent: Wednesday, September 4, 2019 9:51 AM
To: Ettus Mail List
Subject: [USRP-users] flowgraphs not stopping
I have a weird problem that I've seen for a while and I've just ignored until
now. I've seen this with numerous pieces o
I have a weird problem that I've seen for a while and I've just ignored until
now. I've seen this with numerous pieces of hardware, but I am currently using
an E320 in network mode. This seems to only happen when I am using RFNoC, so I
assumed it was me, but today I was testing with only stock
te this issue.
I'll follow up as soon as I have more info.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to
being a
Also, there is a timeout clock running somewhere (can't recall off the top of
my head) that will throw that message when it gets tripped. That is fine
though if you are INTENDING to do something that might cause there to be a gap
in samples and trigger a timeout. I had an RFNoC block that was
Erik,
Whoops, I glazed over that point, sorry. I am not really sure what else to
try. That is a pretty old version of GR, could you maybe try a newer version
in a different directory/prefix (so it doesn't mess up your current build)? At
what sample rate do things seem to work right again?
_
Shot in the dark Erik:
What is your MTU set at for the ethernet port? Try setting it to 9000 if
it isn't and see if that does anything for you.
From: USRP-users on behalf of Erik Heinz
via USRP-users
Sent: Monday, July 29, 2019 7:30 AM
To: usrp-users@lists.
ed to try to recreate this issue.
I'll follow up as soon as I have more info.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to
need to try to recreate this issue.
I'll follow up as soon as I have more info.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it
to try to recreate this issue.
I'll follow up as soon as I have more info.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to
OK, we've been fighting this for a while and we think we narrowed it down to
being a problem with the E320 (NOTE: we are running the E320 in network mode,
not embedded)
Some background:
1) external reference input is from an octo clock (so it the 1pps input) on
many different ports
a) a
I never got a response on this, but in case others have the same problems, I
use this command instead of the shutdown -h command: systemctl poweroff
It is a small sample size, but it seems to work every time.
From: Jason Matusiak
Sent: Monday, July 1, 2019 12:03
You are right, the table of revisions was for the X-series
try running the command from your prefix:
src/uhd/host/build/utils/usrp_burn_mb_eeprom --args="type=n200" --read-all
don't quote me on the type portion, I don't have a board in front of me to see
if it is n200 or something else. I //th
Sumit,
OK, the last idea I have:
There is a sticker on the back of the N-series devices it usually says the
version there, but not always. This has a little info:
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#N200.2F210_EEPROM
Do they match?
_
I am not really an N-series guy, so this probably won't be helpful. Have you
tried doing a uhd_usrp_probe on both devices and seen that the responses are
consistent?
From: USRP-users on behalf of Sumit Kumar
via USRP-users
Sent: Wednesday, July 17, 2019 7:15
Koyel,
It "supports" it, but that is a bit of a misnomer. Unless you are using the
aforementioned network mode (which has its own speed limitations due to it not
being designed for anything more than testing), the Ethernet goes through the
ARM first, so the speeds are no where near the possibi
I've noticed issues getting my E320 to shutdown sometimes. It is almost like
it is halting, but not going down far enough to turn off the unit (the LED
doesn't turn off).
I'll issue the "shutdown -h now" command and it will kick me out of my ssh
session (which is fine). I cannot ping it anym
Alright, I am going to say that this is a non-starter for the time being.
Digging around I found this "Known Issues" comment on the mender-convert page
(https://github.com/mendersoftware/mender-convert):
* An issue for Raspberry Pi Zero W has been spotted with the mender-convert
tool vers
OK, I thought I had it, but it is still not working. Here are some new details
though.
I load up a fresh SD card (I've tried both bmaptools as well as dd). I toss it
into my E320 and it boots up happy as pie. I do a proper shutdown and put it
back into my host PC. I unmount and then using
OK, I see now what you were doing different. I think I could deal with leaving
the /data partition the same size and increasing the two filesystems. I was
just trying to save myself the hassle of performing a mender update down the
road and forgetting that the data in ~/ wasn't persistent.
I gu
Chris, thanks for the tips.
So I put a fresh load on a card, then used gparted to extend the data partition
to fill things out. That isn't enough, and your instructions certainly show
more steps. But I don't understand what you mean with the partitions in the
middle.
I'll read up on Mender and
19, 2019 12:33 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E320 with larger SD card
On 06/19/2019 12:29 PM, Jason Matusiak via USRP-users wrote:
I wanted to use a larger SD card than the one that as supplied, but I am having
issues. I loaded up the card, and then extended the data
I wanted to use a larger SD card than the one that as supplied, but I am having
issues. I loaded up the card, and then extended the data partition to use up
the rest of the free space (about 100GB). But then it doesn't boot.
I am wondering if the change to a partition size screwed up somethin
Problem solved. It was a firewall issue. Is there a list of what ports I
should make sure are opened to UDP? The ones I caught were 49152 and 49154.
Are there any others I need to know?
From: Jason Matusiak
Sent: Wednesday, June 12, 2019 10:32 AM
To: Ettus Ma
I have a new issue with my E320. I loaded up an E320 with an SD card image
that I have used on a different working E320.
On my personal machine, I am using a 1G image that seems to work fine and
uhd_find_device (and probe) seems to be working fine. I change the IP and load
up an XG image ont
I had similar issues (that I never overcame). Here was some tips I received
back in FEB when I tried:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-February/059114.html
From: USRP-users on behalf of kailash
kumar via USRP-users
Sent: Tuesd
Leech via USRP-users
Sent: Friday, June 7, 2019 5:34 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E320 hogging the network
On 06/07/2019 03:05 PM, Jason Matusiak via USRP-users wrote:
OK, this is actually an E310 problem. The E310 always looks off device first.
A coworker remind
hanks.
From: Sylvain Munaut <246...@gmail.com>
Sent: Wednesday, June 5, 2019 11:31 AM
To: Jason Matusiak
Cc: Robin Coxe; Ettus Mail List
Subject: Re: [USRP-users] offset tuning on the TwinRX
On Wed, Jun 5, 2019 at 4:41 PM Jason Matusiak via USRP-users
mailto
st
Subject: Re: [USRP-users] E320 hogging the network
Hi Jason,
On the E310, if you pass the device arg addr with 127.0.0.1 does it work as
expected?
uhd_usrp_probe --args "addr=127.0.0.1"
Regards,
Nate Temple
On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users
mailto:
I know that on some ARM platforms that has to be programmed in at boot and
perhaps these system images have it set to the same value.
Sent from my iPhone
On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Philip,
They have unique addre
with 127.0.0.1 does it work as
expected?
uhd_usrp_probe --args "addr=127.0.0.1"
Regards,
Nate Temple
On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Darn, I was hoping that was it, but I don't think so.
Here is the
the network
Hi Jason,
On the E310, if you pass the device arg addr with 127.0.0.1 does it work as
expected?
uhd_usrp_probe --args "addr=127.0.0.1"
Regards,
Nate Temple
On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
D
addr with 127.0.0.1 does it work as
expected?
uhd_usrp_probe --args "addr=127.0.0.1"
Regards,
Nate Temple
On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Darn, I was hoping that was it, but I don't think so.
He
9, at 11:52 AM, Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Philip,
They have unique addresses (10.95 and 10.45). It is really weird that when I
am on the E310, and set the ip-addr to himself, that he would even look off the
device
They both have ho
?
Philip
On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the
> network.
>
>
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the
> default 10.2). I can ssh into it and
OK, another E320 question. With my custom RFNoC image, only a Radio_0 shows
up. Shouldn't there be a Radio_1 as well?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
It looks like I am misunderstanding something with how the E320 handles the
network.
I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the
default 10.2). I can ssh into it and things seem to run fine in embedded mode.
Now, if I ssh onto an E312 that is on the same netwo
I figured it out. The problem was that in noc_block_split_stream.v, rb_stb was
set to 1'b1 in the noc_shell instantiation.
I changed it to ".rb_stb({NUM_OUTPUTS{1'b1}})" and it seems to have build OK.
From: USRP-users on behalf of Jaso
I've seen chatter on this around here before (an I think I might have been
involved with it during my failed N310 project a while back), but I haven't
come up with a solution yet.
I have a custom RFNoC bitfile I want to use on the E320. I set things up and
built it with the mods in rfnoc_ce_a
. All other Ettus radios employ
direct conversion transceivers.
-Robin
From: USRP-users on behalf of Jason
Matusiak via USRP-users
Sent: Wednesday, June 5, 2019 2:31 AM
To: Ettus Mail List
Subject: [USRP-users] offset tuning on the TwinRX
An associate was
An associate was asking me about the TwinRX (which I haven't really used). He
apparently uses offset tuning on the B series often for his gnuradio
flowgraphs. He was trying to do it with the TwinRX and can't find the hooks
for it. I looked around briefly and came up empty as well. I assume t
using? GNURadio 3.7 is python2 only.
The master branch works with python3.
It looks like you have numpy for both verions, but the config is
different or something, I've never run into this problem.
Philip
On 05/23/2019 03:16 PM, Jason Matusiak via USRP-users wrote:
> Here is what I get:
&
t;license" for more information.
>>> import numbers
>>>
From: Philip Balister
Sent: Thursday, May 23, 2019 1:45 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
On 05/23/2019 12:25 PM, Jason Matusiak via USRP-user
numbers
From: Philip Balister
Sent: Thursday, May 23, 2019 12:04 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
> OK, thanks Philip,
>
> This is all a little
E320, so pretty much flying blind regarding hardware issues.
Philip
On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
> Philip, before building one of your images, does anything need to be done to
> get ethernet to work? It seems like after using mender to setup a new image
ed :)
Philip
On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
> Interesting, thanks. They are using sumo, so I will try to check that branch
> out and see how it works.
>
> I will need to research how to add it in and build it as I see pulling it
> down and c
so an add layer
command, but I'm old fashioned :)
Philip
On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
> Interesting, thanks. They are using sumo, so I will try to check that branch
> out and see how it works.
>
> I will need to research how to add it in and build
o the unreleased 3.8 gnuradio, which is much better
for embedded builds.
Might also be some pain due to Ettus forking the uhd recipe.
Philip
On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
> OK, so I am a total newbie when it comes to open-embedded. I know that the
> docker to bu
OK, so I am a total newbie when it comes to open-embedded. I know that the
docker to build doesn't include a gnuradio-image bitbake option (only
developer-image), so I tried to make one. I created a new gnuradio-image.bb
file and added gnuradio to the list of things to build. Sadly, I appear
According to this, it is a dipole:
https://kb.ettus.com/images/9/9e/ettus_research_vert2450_datasheet.pdf
From: USRP-users on behalf of Koyel Das
(Vehere) via USRP-users
Sent: Tuesday, May 14, 2019 5:45 AM
To: 'USRP-users@lists.ettus.com'
Subject: [USRP-users]
Maybe try running a VM of a version of Ubuntu that is roughly the vintage of
that version of UHD?
From: USRP-users on behalf of Joe Martin
via USRP-users
Sent: Thursday, May 9, 2019 9:53 AM
To: Joe Martin
Cc: usrp-users@lists.ettus.com
Subject: [USRP-users] Nee
R3 didn't work for me either. I am not sure I would even bother with the
support email, I think they tried hard for me last year and they couldn't
revive that rev's source code at all. We abandoned our r2 Ns and just worked
on the ones that were already working.
__
See here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
From: USRP-users on behalf of Ramazan
Çetin via USRP-users
Sent: Wednesday, May 8, 2019 8:02 AM
To: Ettus Research Support; usrp-users@lists.ettus.com
Subject: [USRP-users] Running E
well to update the mailing list.
--Neel Pandeya
On Thu, 2 May 2019 at 08:07, Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Chris,
It is a shame that the E320 doesn't seem to have complete support, but maybe
someone from Ettus will chime in at some point
CaJacob
mailto:dan.caja...@gmail.com>> wrote:
GPS doesn't like to go back in time. You probably need to reset the almanac and
a reboot is doing that.
On Tue, Apr 30, 2019, 9:53 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com&g
or the exact issues
at the time.
From: Philip Balister
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?
On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportErro
ook back at the emails for the exact issues
at the time.
From: Philip Balister
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?
On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
the exact issues
at the time.
From: Philip Balister
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?
On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "Impo
I also get a "ImportError: No module named sip" when I try to run:
uhd_siggen_gui
So I think a few things might be missing from the cross-compile setup.
From: Jason Matusiak
Sent: Wednesday, May 1, 2019 8:46 AM
To: Ettus Mail List
Subject: E320 numpy missing?
Fi
Finally got my E320 in and I cross-compiled a new setup. I tried to fire up my
flowgraph (which works fine on an E310) and it is complaining about numpy
missing.
If I do a search from / on the E320, the only numpy that is showing up is:
/usr/include/boost/python/numpy
If I do a search from a g
I've seen this a few times, but I cannot seem to lock it down to any particular
reason. While sitting at my desk with a GPS simulator (so I have a known good
signal), I will be doing testing and everything is fine (it seems to be walking
around the place where the unit was built). I will turn
[USRP-users] E312 wrong sample rate
On 04/29/2019 03:28 PM, Jason Matusiak via USRP-users wrote:
I was debugging a problem with a flowgraph when I realized that I wasn't
getting the amount of samples I expected passing out of the USRP source block.
If I set a sample rate too low, it tells
I was debugging a problem with a flowgraph when I realized that I wasn't
getting the amount of samples I expected passing out of the USRP source block.
If I set a sample rate too low, it tells me it has to set the sample rate to
0.125MSps. Currently I have a single stream from my source block,
I know this is an older thread, but I am running up against the same issue. Do
you know if you were able to get past it?
Thanks
On Wed, Aug 22, 2018 at 11:12 AM, Andrew Danowitz <
and...@whitefoxdefense.com> wrote:
> Hi,
>
> I rebuilt everything using the latest recipes for rfnoc and e3xx-r
Whoops. Realized it was a swig issue. Once I fixed the problem it was fine
again. Hopefully this helps someone else in the future.
From: Jason Matusiak
Sent: Tuesday, April 23, 2019 10:29 AM
To: Ettus Mail List
Subject: RFNoC has no attribute E312
OK, I am mis
OK, I am missing something simple here that I am just overlooking. I have a
particular bitfile that when I do a probe on my E312 using it and its
associated UHD/GR/etc, it runs OK and shows me my RFNoC blocks (it actuall
shows an EnvironmentError: IOError on the radio, but usually those things
I haven't tried it yet, but have you looked at this blog post (I //think// it
is still relevant today)?
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
From: USRP-users on behalf of Ryan Marlow
via USRP-users
Sent: Thursday, April 11, 2019 10:51 AM
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
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
you can enable RFNoC by adding the cmake flag
-DENABLE_RFNOC=ON
Regards,
Nate Temple
On Mon, Apr 8, 2019 at 12:34 PM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
I should be getting an e320 in this week, so I started to get my environment
setup. I st
So I think I goofed. Not sure why I was pointing it to the mpm directory for
the CMakeLists. When I do the normal ../ it builds fine.
Now I end up with the issue I used to have with the e310 many moons ago. The
sysroots doesn't have qt in it. So when I run a cmake of gr-ettus, I get this
er
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
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 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
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
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
Se
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
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
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
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
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
USRP-users] two X310s in one RFNoC flowgraph
Hi Jason,
Given that under the hood, the stock multi_usrp (along with legacy_compat)
implements an RFNoC graph, it must be possible. I have run multiple X310s with
the stock multi_usrp. I have looked at legacy_compat pretty thoroughly and it
keeps trac
usrp (along with legacy_compat)
implements an RFNoC graph, it must be possible. I have run multiple X310s with
the stock multi_usrp. I have looked at legacy_compat pretty thoroughly and it
keeps track of blocks as a function of device number (motherboard). If I had a
2nd X310 handy, I would
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
th
the stock multi_usrp. I have looked at legacy_compat pretty thoroughly and it
keeps track of blocks as a function of device number (motherboard). If I had a
2nd X310 handy, I would try it with my own non-stock multi_usrp object, but I
don't - sorry.
Rob
On Fri, Feb 1, 2019 at 8:30 AM Ja
1 - 100 of 235 matches
Mail list logo
