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
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
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
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
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,
[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'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
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 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 num
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 just double-checked and ENABLE_PYTHON is on in my system (which was
apparently the default since I didn't spell it out in my cmake command).
From: Jason Matusiak
Sent: Wednesday, May 1, 2019 10:36 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-
em
gimped or a step down from what was on the E310.
- Original Message -
From:
"Jason Matusiak"
To:
"Philip Balister" , "Ettus Mail List"
Cc:
Sent:
Wed, 1 May 2019 14:40:16 +
Subject:
Re: [USRP-users] E320 numpy missing?
I just double-checked and EN
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
Thanks Neel, I will keep an eye out for updates.
From: Neel Pandeya
Sent: Saturday, May 4, 2019 1:23 AM
To: Jason Matusiak
Cc: Ettus Mail List; Chris Gobbett
Subject: Re: [USRP-users] E320 numpy missing?
Hello Jason and Chris:
I understand your frustration. We
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
already working.
From: Joe Martin
Sent: Wednesday, May 8, 2019 12:56 PM
To: Jason Matusiak
Cc: Joe Martin via USRP-users
Subject: Re: [USRP-users] Bringing an elderly N210 to life by loading current
firmware/fpga images
Wow, okay; that’s disheartening. Thanks much for the info, Jason. Nope
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
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]
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
From: Philip Balister
Sent: Tuesday, May 21, 2019 10:39 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
You need the meta-sdr layer. Choosing a branch may be tricky, only the
older ones have 3.7 support. My recent work in master is all in support
of transitioning t
tbake, or as a
stand-alone build I move over to the device afterwards.
From: Philip Balister
Sent: Tuesday, May 21, 2019 11:05 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
Edit bblayers.conf in your conf directory. There is al
image reverts to the old
one since I didn't commit it. Any steps I am missing?
____
From: Jason Matusiak
Sent: Tuesday, May 21, 2019 11:18 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
OK, that seems to be building (who knows
ettus//conf
$ source ./oe-core/oe-init-build-env ./build ./bitbake
From: Philip Balister
Sent: Thursday, May 23, 2019 11:43 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
Oops, replied to copy in my inbox ...
Adding meta-sdr to pi
nternal # for freeze programs
File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, in
from .numerictypes import object_
File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 87,
in
import numbers
ImportError: No module named
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
I am on sumo. That was the version of everything that Ettus recommended for
their stuff.
From: Philip Balister
Sent: Thursday, May 23, 2019 3:40 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] GR in the E320
Which branch of meta-sdr are you
ver,
this method is incompatible with time alignment across channels, so it
is not an option.
How can I get time-aligned streaming from TwinRX/LFRX working under UHD
v3.14?
Thank you.
Jason
___
USRP-users mailing list
USRP-users@lists.ettu
to see if anything had changed. I didn't get any complaint about
mismatching clock rates, but I did see the same behavior that I complained
about in my earlier message (no data from the LFRX, and a LATE_COMMAND error).
Either way, there seems to be a r
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
On 6/4/19 12:30 PM, Jason Matusiak via USRP-users wrote:
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
OK, thanks everyone. I guess I have some superhet reading up to do 🙂.
From: Robin Coxe
Sent: Tuesday, June 4, 2019 2:41 PM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] offset tuning on the TwinRX
Hi Jason. Yes, it is a super-het receiver
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
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
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
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
: Philip Balister
Sent: Friday, June 7, 2019 11:10 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network
Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname
ld be fine though because I have the same issue when I
am running commands ON my E310. And if it was a routing issue, it would mean
that both my machine and the E310 and the E320 were being screwed up.
From: Marcus D Leech
Sent: Friday, June 7, 2019 12:01 PM
To:
om/manual/page_usrp2.html#usrp2_network_multidev
From: Nate Temple
Sent: Friday, June 7, 2019 12:17 PM
To: Jason Matusiak
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network
Hi Jason,
On the E310, if you pass the device arg
I just realized that using the 127 and 102 addresses don't work with the probe
on the E310. It only works when I don't use the arg flag.
____
From: Jason Matusiak
Sent: Friday, June 7, 2019 12:22 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus
OK, maybe based on my last email (which crossed yours I think). The addr flag
doesn't seem to work at all with the uhd_usrp_probe on the E310 (at least my
version).
From: Nate Temple
Sent: Friday, June 7, 2019 12:37 PM
To: Jason Matusiak
Cc: Marcus D
ubnet.
From: Jason Matusiak
Sent: Friday, June 7, 2019 12:41 PM
To: Nate Temple
Cc: Marcus D Leech; Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network
OK, maybe based on my last email (which crossed yours I think). The addr flag
doesn'
m: Nate Temple
Sent: Friday, June 7, 2019 3:10 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 hogging the network
Hi Jason,
You could try running the new 3.15 MPM based file system for the E310, but it
has some caveats, more details here:
http://lists.ettu
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
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
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
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
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 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
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
ad up on Mender and see if that answers it for me. Thanks again.
On Jun 19, 2019, at 6:56 PM, Chris Gobbett
mailto:go...@tpg.com.au>> wrote:
Hi Jason,
I've had luck with the following:
- backup/clone the original SDCard image to disk and/or larger SDCard (using dd
or otherwise)
- on the
n you do this you may need some extra
linux-fu to shift your new binary/library locations to that partition rather
than the default /usr.
Cheers,
Chris
- Original Message -
From:
"Jason Matusiak"
To:
"Chris Gobbett"
Cc:
"Ettus Mail List"
Sent:
Wed, 19 Jun
s the new size on the
device, that I am overwriting the small partition size and screwing things up...
From: Chris Gobbett
Sent: Wednesday, June 19, 2019 8:21 PM
To: Jason Matusiak; Ettus List
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 with larger SD card
ren't using a pi, but it certainly feels like the same issue.
____
From: Jason Matusiak
Sent: Thursday, June 20, 2019 10:24 AM
To: Chris Gobbett; Ettus List
Subject: Re: [USRP-users] E320 with larger SD card
OK, I thought I had it, but it is still not working. Here
On 5/29/19 10:39 PM, Jason Roehm via USRP-users wrote:
On 5/29/19 3:58 PM, Marcus D. Leech via USRP-users wrote:
I'm a little bit surprised this worked AT ALL--you have 3 independent
multi-usrp objects all pointing at the same hardware.
Time alignment is something that is done WIT
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
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 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
?
From: Sumit Kumar
Sent: Wednesday, July 17, 2019 7:45 AM
To: Jason Matusiak
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Sequence Errors N200
Hi Jason,
Yes they are consistent, I mean the output of uhd_usrp_probe for both N200 is
exactly the same (except the ip
___
From: Sumit Kumar
Sent: Wednesday, July 17, 2019 8:24 AM
To: Jason Matusiak
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Sequence Errors N200
The sticker for sbx shows F33612 and F33814.
How will this help ?
On Wed, Jul 17, 2019 at 1:50 PM Jason
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
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
That would be great, thanks so much
From: Nate Temple
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 unable to lock to external reference
Hi Jason,
This might be a bug with the E320. I will need
Do you need anything from my side of things?
From: Nate Temple
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 unable to lock to external reference
Hi Jason,
This might be a bug with the E320. I will
Thank you Nate. Good to hear that it wasn't a screw up on our part. Do you
have a gut as to whether or not it is a hardware or software issue?
From: Nate Temple
Sent: Tuesday, July 23, 2019 2:01 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re:
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.
again?
From: Erik Heinz
Sent: Monday, July 29, 2019 8:02 AM
To: Jason Matusiak ; usrp-users@lists.ettus.com
Subject: AW: X310 slow with gnuradio
Hi jason,
I had the MTU set to 8028. I increased to 9000, just to make sure -> no change.
As I wrote, the UH
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
Thanks for the update Michael, I'll pass it along. Fingers crossed.
From: Michael West
Sent: Monday, August 5, 2019 4:49 PM
To: Nate Temple
Cc: Jason Matusiak ; Ettus Mail List
Subject: Re: [USRP-users] E320 unable to lock to external reference
We
ers-X300-with-TwinRX-and-LFRX-under-UHD-v3-14-td12749.html)
and never got an answer, but the above commit silently fixed it in
v3.14.1.0.
How can I get correct timekeeping with the X300/TwinRX, while
maintaining my ability to stream from a TwinRX and LFRX sim
On 8/16/19 10:32 PM, Marcus D. Leech via USRP-users wrote:
On 08/16/2019 04:54 PM, Jason Roehm via USRP-users wrote:
I have a software application that interfaces to an X300 with a
TwinRX daughterboard installed. We recently upgraded our UHD version
to v3.14.1.0 in our application. Since
On 8/19/19 12:34 PM, Neel Pandeya wrote:
Hello Jason:
I also would have expected UHD 3.14.1.0 to have resolved this issue.
Would you be able to send me a stand-alone program that I can use to
reproduce this problem?
Also, I'm curious, do you have a GPSDO installed in your X300?
-
On 8/19/19 12:34 PM, Neel Pandeya wrote:
Hello Jason:
I also would have expected UHD 3.14.1.0 to have resolved this issue.
Would you be able to send me a stand-alone program that I can use to
reproduce this problem?
Also, I'm curious, do you have a GPSDO installed in your X300?
-
On 8/19/19 6:52 PM, Neel Pandeya wrote:
Hello Jason:
Thanks for all the detailed feedback! No worries about not having a
stand-alone reproducing program at the moment. Could you please try
using the head of the "UHD-3.14" branch? We just tagged v3.14.1.1-rc1
with some bug fixes
On 8/20/19 7:40 AM, Jason Roehm via USRP-users wrote:
On 8/19/19 6:52 PM, Neel Pandeya wrote:
Hello Jason:
Thanks for all the detailed feedback! No worries about not having a
stand-alone reproducing program at the moment. Could you please try
using the head of the "UHD-3.14" b
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
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 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
king fine on the
E312/E320s. I'll report back if something else turns up.
From: Jonathon Pendlum
Sent: Tuesday, September 10, 2019 11:35 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] No block_id specified for channel 0
Hi Jason,
C
Temple
Sent: Friday, September 20, 2019 11:35 AM
To: Jason Matusiak
Cc: Michael West ; USRP-users@lists.ettus.com
Subject: Re: [USRP-users] E320 unable to lock to external reference
Hi Jason,
Here is the commit that fixes the e320 ext ref issue.
https://github.com/EttusResearch/uhd/commit
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
Howdy Neel,
We are running GR v3.7.13.4.
We will get UHD 3.14.1.1 installed on one of our machines today and give that a
shot.
Thanks.
From: Neel Pandeya
Sent: Monday, September 30, 2019 11:19 AM
To: Jason Matusiak
Cc: usrp-users
Subject: Re: [USRP-users
, 2019 11:19 AM
To: Jason Matusiak
Cc: usrp-users
Subject: Re: [USRP-users] 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?
-
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
t: Tuesday, October 1, 2019 1:52 PM
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
why one flowgraph is doing it as
an int and the other as a float (they are both opened in the same GRC window),
but everything is happy if I just do a save-as on the working one and start
from there.
From: Marcus D Leech
Sent: Tuesday, October 1, 2019 1:52 PM
On 9/26/19 9:26 AM, Neel Pandeya wrote:
Hello Jason:
My apologies for the delay. We were super busy with GNU Radio
Conference. Thanks for providing a stand-alone test program. I'll try
to reproduce this issue later today or tomorrow, and I'll get back to
you with an update.
--Ne
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
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
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
Hey everybody, I'm trying to put together a simple bursting example. In
gnuradio companion I'm generating a PDU, using the framer block, converting to
a tagged stream, and then inserting a tx_time tag in an OOT python block. The
tx_time tag is at the beginning of the streamed frame, just prior t
? Things like
threading.py are missing and only in python3.5 for it.
Thanks.
~Jason
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
t the N310 wouldn't work. I guess we will have to
forgot using it in embedded mode and only use it in network mode. Thanks Robin!
From: Robin Coxe
Sent: Monday, October 21, 2019 12:54 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] pyt
Thanks! I thought that things were sync'd between the USRP and the program,
but I haven't used the *_pps() functions. I'll give them a shot.
On Tuesday, October 22, 2019, 02:35:33 PM PDT, Sam Reiter
wrote:
Hey Jason,
Are you making sure that you're setting your
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.
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
to a
buffer and do nothing with the data; constantly transmit 0's from the transmit
buffer) and the underruns still occur.
I'm running on UHD 3.11.0, and the x310 is is configured with basic TX/RX
daughterboards and flashed with the XG image for use over two 10 gig eth
nd transmit from the same channel
without underflows?
Thanks,
Jason
From: USRP-users on behalf of Jason W
Zheng via USRP-users
Sent: Monday, August 7, 2017 1:05:05 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Buffer underrun issue with simultaneous t
How should I set the tx metadata? My application will essentially stream
continuously.
Thanks,
Jason
From: ROBIN TORTORA
Sent: Monday, August 14, 2017 11:17:07 AM
To: Jason W Zheng via USRP-users; Jason W Zheng
Subject: Re: [USRP-users] Buffer underrun issue
on't think my cpu or network card are the issue as when I change my code to
receive and transmit on separate channels, it works without any underflows.
From: USRP-users on behalf of Jason W
Zheng via USRP-users
Sent: Monday, August 14, 2017 11:27:24 AM
To
sers
Sent: Monday, August 14, 2017 11:32:21 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and
receive on the X310
On 08/14/2017 02:27 PM, Jason W Zheng via USRP-users wrote:
How should I set the tx metadata? My application will essentia
201 - 300 of 304 matches
Mail list logo
