Hi all,
I've been getting an intermittent core dump when my gnuradio script closes. It
doesn't seem to be a very critical error, but I ran across this:
https://lists.gnu.org/archive/html/commit-gnuradio/2015-04/msg00327.html
Which shows a bt different from the one I'm getting, and says to
Hi, I've been trying for the last week or so to get VOLK to build on the E310
or on another ARMv7 mini computer (Odroid XU4) that I have access to. I've
tried git HEAD on down the the oldest release available on libvolk.org and
depending on the version, they fail 2 out of the following 3 tests:
Hi all,
I'm taking a read through Kristian Maier's thesis document on the gr-lte repo
(and by read I mean looking at the pictures because I don't know German).
Looks like he was piping his Coarse PSS Sync block into a Decimating FIR
Filter block, but I can't seem to find that (I don't use GRC
5:42 PM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Where to find the Decimating FIR Filter for
gr-lte
On Jul 24, 2015, at 14:47, Anderson, Douglas J. dander...@its.bldrdoc.gov
wrote:
Hi all,
I'm taking a read through Kristian Maier's thesis document
@gnu.org] on behalf of
Anderson, Douglas J. [dander...@its.bldrdoc.gov]
Sent: Friday, July 24, 2015 3:47 PM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] Where to find the Decimating FIR Filter for gr-lte
Hi all,
I'm taking a read through Kristian Maier's thesis document on the gr
or a similar device which offers to RX channels in order to
exploit this extra diversity.
Hope that sheds some light on why and how things are done. Also let me
know about specifics which are unclear in those blocks. So I'll add
some doc.
Cheers
Johannes
On 01.07.2015 23:16, Anderson, Douglas J. wrote:
Hi
Hi all,
I'm working at putting together a flowgraph based on gr-lte.
For the channel estimator hier block [1], it looks like there are two RS map
generators, one for each of 2 antenna ports.
I only have one antenna connected to my USRP N210. Is this a problem? Do I
still use 2 RS map
of a frame.
If you have specific questions about parts of the flowgraph, just ask.
Cheers
Johannes
On 24.06.2015 18:07, Martin Braun wrote:
On 24.06.2015 08:48, Anderson, Douglas J. wrote:
Lately I've been working with gr-lte and trying to use some of
those blocks in my own application (not grc
blocks mixes in a CW signal at the correct frequency to
adjust the samples from the USRP. Yes?
-Doug
From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
Anderson, Douglas J
I recently faced a similar problem with my USRP N210 with a resampler chewing
up my CPU. These steps helped a lot:
1) Design a filter with less taps (as Marcus recommended)
2) Build the latest GNURadio and UHD from git, and flash the N210 with the
recently released FPGA update.
Not sure if
Hi all,
Lately I've been working with gr-lte and trying to use some of those blocks in
my own application (not grc).
I'm still in the learning phase about ofdm/lte, and I'm struggling with the
lack of documentation or comments in gr-lte.
I think I would prefer to use GNU Radio's built-in OFDM
. Right now I feel like I just have to take in on faith
that timed commands are working, know what I mean?
-Doug
From: Marcus Müller [marcus.muel...@ettus.com]
Sent: Wednesday, April 29, 2015 10:07 AM
To: Anderson, Douglas J.; discuss-gnuradio@gnu.org; Martin Braun
(and the center freq was 700e6 before running the command)
From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
Anderson, Douglas J. [dander...@its.bldrdoc.gov]
Sent: Wednesday
before sleep: {:f} MHz.format(u.get_center_freq()/1e6))
time.sleep(2)
print(get_center_freq after sleep: {:f} MHz.format(u.get_center_freq()/1e6))
Greetings,
Marcus
On 04/28/2015 12:03 AM, Anderson, Douglas J. wrote:
Hi all,
I'm playing around with timed commands on the USRP, but I'm not sure I
Hi all,
I'm playing around with timed commands on the USRP, but I'm not sure I
understand them correctly.
I've got a usrp connected as u and set to center freq 700e6.
u.set_command_time(u.get_time_now() + uhd.time_spec(2));
u.set_center_freq(800e6); u.clear_command_time();
size.
Greetings,
Marcus
On 04/21/2015 08:04 PM, Anderson, Douglas J. wrote:
Would it be possible to dive into this a bit deeper? I'm trying to get more
familiar with the the scheduler and how the buffer is laid out.
So using tried to allocate 41 items of size 1592. Due to alignment
requirements
Would it be possible to dive into this a bit deeper? I'm trying to get more
familiar with the the scheduler and how the buffer is laid out.
So using tried to allocate 41 items of size 1592. Due to alignment
requirements 512 were allocated as an example, the scheduler looked at the
requirements
, Douglas J. wrote:
Marcus,
That makes sense, I hadn't thought of the DSP tuning issue, though I
think it would be infinitely more useful to make the stream tagging
logic aware of LO/DSP tuning and tag the first usable block in either
case. Slightly more involved than I assumed though
rx_freq tag. Also, polling the sensor
might get in the way of normal operation, because it'd occupy the
serial line.
Greetings,
Marcus
On 04/01/2015 07:49 PM, Anderson, Douglas J. wrote:
Martin,
I think we could have the same effect with a much simpler solution:
What about adding an lo_locked
I just threw up in my mouth a little...
From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
Martin Braun [martin.br...@ettus.com]
Sent: Wednesday, April 01, 2015 1:30
Hi all,
I've been working on a flowgraph that controls sweeping a USRP by retuning and
then dumping samples until catching the sample tagged with rx_freq of the
correct value.
I was confused as to why I was still getting mountains of garbage samples
(several hundred thousand at 10MS/s) after
allows this, but as long
as you tune within your USRP/daughterboards physical bandwidth, you might just
tune digitally and avoid LO retuning:
http://files.ettus.com/manual/page_general.html#general_tuning_process
On 03/31/2015 09:54 PM, Anderson, Douglas J. wrote:
Hi all,
I've been working
hard to calibrate once forever, whereas things like IQ imbalance
tend to behave alike on both I and Q, so that temperature dependency is not as
bad.
On 03/31/2015 11:25 PM, Anderson, Douglas J. wrote:
Marcus,
That makes sense, I hadn't thought of the DSP tuning issue, though I think it
would
Hi Vishwanatha,
Looks like you have a function called set_loop_bandwidth that hasn't been
declared in your header files.
-Doug
Douglas Anderson | Intern
DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
From:
Jeon,
I've recently dealt with a similar problem. Chances are that if things are
building and installing correctly but the error is in the SWIG import, the
actual problem lies in your CMakeLists.txt... seems like the C++ linker is
being smart enough to get things linked correctly but SWIG
of most issues.
M
On 23.03.2015 10:13, Anderson, Douglas J. wrote:
Hi all,
I'm looking into the possibility of passing the gr_block gr uhd usrp
source (0) object from Python into a C++ out of tree module. In my
module, I have:
controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source
of PMT.
The only downside is it's kind of icky to parse, but I'm not sure if having a
dedicated dict type would ease that any.
-Doug
From: Martin Braun [martin.br...@ettus.com]
Sent: Tuesday, March 24, 2015 1:50 PM
To: Anderson, Douglas J.; discuss
Hi all,
I'm looking into the possibility of passing the gr_block gr uhd usrp source
(0) object from Python into a C++ out of tree module. In my module, I have:
controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr usrp,
[...])
I get a TypeError when I instantiate the block. It
(complex float
items, and the buffer should be page aligned). hm...
Greetings,
Marcus
[1] disclaimer: I don't consider any distro to be *sane*, and few to be
*reasonable*
On 03/18/2015 12:06 AM, Anderson, Douglas J. wrote:
Hi all,
I just finished writing a flowgraph with a few custom C++ blocks
Hi all,
I just finished writing a flowgraph with a few custom C++ blocks, but when I
connect it to a USRP N210 at about 25MS/s it's not too hard to find a combo of
parameters that will cause a sea of DDs to come flooding into the term.
I think there are some areas I can improve in my
Rondeau
[t...@trondeau.com]
Sent: Sunday, March 15, 2015 2:09 PM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Python message passing block hangs (test file
included)
On Thu, Mar 12, 2015 at 5:00 PM, Anderson, Douglas J.
dander...@its.bldrdoc.govmailto:dander
Yesterday I asked a question about a failing flowgraph when connecting the copy
block to a message source and running the flowgraph multiple times.
I'm still trying to understand what's going on, so I decided to write a version
of copy in python to try and better understand things. Even though
-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
Anderson, Douglas J. [dander...@its.bldrdoc.gov]
Sent: Friday, March 13, 2015 12:26 PM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] Can you spot the error in the python basic block?
Yesterday I asked a question about a failing
Hi all,
I'm struggling to understand an issue I'm having with a simple python block
with a registered message port connected to the copy block.
The python block looks like this: it literally does nothing, it just happens to
have a message port registered:
class signal_sink(gr.sync_block):
Thanks Tom, that gives me a good starting point.
-Doug
From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau
[t...@trondeau.com]
Sent: Tuesday, February 17, 2015 1:47 PM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re
Hi all,
I'm looking for the best way to retune the USRP from another block in a running
flowgraph. I've seen the tune callback method used by bin_statistics_f, but I
was wondering if there are other ways to do it. I took a look at message
passing
I think having the work fn return -1 will cause the flowgraph to exit, so you
could potentially have a self.count = 1 in __init__ and then when you've
output = self.count, have work return -1
-Doug
Douglas Anderson | Intern
DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
as
discarding samples off the front?
-Doug
From: Nick Foster [bistrom...@gmail.com]
Sent: Thursday, January 15, 2015 10:40 AM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] voltage pulse from UHD driver
In general you cannot use
that I can better understand the
underlying process. Thank you for the details!
-Doug
From: Nick Foster [bistrom...@gmail.com]
Sent: Thursday, January 15, 2015 10:49 AM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] voltage pulse
-bounces+danderson=its.bldrdoc@gnu.org
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
Anderson, Douglas J. [dander...@its.bldrdoc.gov]
Sent: Thursday, January 15, 2015 10:55 AM
To: Nick Foster
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] voltage pulse
Hi all,
I've been slowly working to understand/isolate an issue with a strange voltage
pulse at all freqs and on USRP N210 with 50 Ohm load.
I posted about it on StackExchange here, and there are more details at this
link:
3582
From: Marcus D. Leech [mle...@ripnet.com]
Sent: Thursday, January 15, 2015 11:40 AM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] voltage pulse from UHD driver
On 01/15/2015 01:11 PM, Anderson, Douglas J. wrote:
Marcus
Hi all,
I'm trying to understand the impact that changing the wire-format of a USRP has
on the uhd_fft script provided by GNURadio.
Using UHD_003.008.001-42-g8c87a524 and GNURadio built by pybomb a few weeks ago
(3427a667c).
On a USRP N210 with 50 Ohm load, I ran
uhd_fft --wire-format=sc8 -s
Hi all,
I was looking into the possibility of adding a reset ability (ala the head
block) to skiphead.
In my search to find out if it had already been done, I came up with this
commit message:
commit 9aabbe0601919c9fecd46e4e418e5c94183fca45
Author: Tom Rondeau trond...@vt.edu
Date: Thu Jul
Braun
martin.br...@ettus.commailto:martin.br...@ettus.com wrote:
Doug,
that commit is in master. Note that it's old, and committed *before* the
3.7 API change, so the changes are moved to the corresponding new block
in gr-blocks.
M
On 10/28/2014 06:54 PM, Anderson, Douglas J. wrote:
Hi all,
I
Hi all,
A little while back I submitted an issue
(http://gnuradio.org/redmine/issues/693) regarding the inability to instantiate
the delay block with a negative int (to consume samples) despite the code
comments and documentation.
Tom submitted a commit and clarified that you have to
I just installed gnuradio and uhd via pybomb, sourced the env file in the
prefix dir, and attempted to do from gnuradio import uhd. gnuradio imports
and inspection shows it's the prefixed version, but uhd fails with ImportError:
No module named uhd.
Do I need to pass pybomb some kind of
, I
think you should get a different Error:
from gnuradio import doesntexist
Traceback (most recent call last):
File input, line 1, in module
ImportError: cannot import name doesntexist
Greetings,
Marcus
On 17.07.2014 18:45, Anderson, Douglas J. wrote:
I just installed gnuradio and uhd via
Thanks Tom and Marcus,
Yeah not sure about the error discrepancy, must have been paraphrasing :)
UHD is where it should be and was detected successfully by cmake, but these
couple lines from CMakeCache.txt make me realize I have bigger problems than
just gr-uhd:
Wish I had a clever solution to all this, but I ended up just nuking my prefix
and pybombs dirs and starting over with pybombs - uhd - gnuradio. All is good
now. I think it was in fact a failed build early on that wasn't cleaning up
quite right.
Thanks!
-Doug
50 matches
Mail list logo
