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
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.
FaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=JbLHwD_efOdK-ZuvD-QH2Fw4AAiWtCXu0WvdSfn6_xE=lE6ZF4x-LhtjQkpWmr6HKpawJBtAP1yjwDDIfqzCFhA=>
On Mon, Oct 21, 2019 at 9:37 AM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
I am j
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
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
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:
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 PM, Jason M
, 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 stupid, but I
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
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 are r
] 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-users
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
able 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 Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>
ry 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
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
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 of hardware, but I am
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
ow 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 problem with the E320 (NOTE: we ar
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:
create 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 problem with
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 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
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
being a p
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)
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
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
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
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
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
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
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
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
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
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:
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 reminded me
.
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:usrp
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:
orms 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 addresses (10.95 and 10.45). It is r
rk 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 result from my E310:
eth0
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
?
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
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 Jason
Matusia
. 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 asking
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:
> r
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
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 new/di
ing 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
> and rebooting, I can
/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 checking out sumo alo
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 it as I
to 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 build d
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]
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
as 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>>
_
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 "ImportError: No module named sip" when I try to run:
&
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:
> I also
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 "ImportError: N
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?
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
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
-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 me it has
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
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
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
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
Trying
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
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 started off l
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
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
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:
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
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
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
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
at)
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 try it with my own non-stock multi_
ulti_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 Jason Matusiak v
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
tion 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 Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Is it possible to have a single flowgraph
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 Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
I
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 try it with my own non-stock multi_usrp object, but I
don't - sorry.
Rob
On Fri, Feb 1, 2019 at
uld 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 Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it?
I can't seem to figure
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 try it with my own non-stock multi_usrp object, but I
don't - sorr
andy, 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 Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Is it possible to have a single flowgraph that has 2 X310s running RFNoC in it?
I can't seem to
object, but I
don't - sorry.
Rob
On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
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 t
1 - 100 of 222 matches
Mail list logo
