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 repor
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:
2015 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.
wrote:
> Hi all,
>
> I'm taking a read through Kristian Maier's
@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 thesi
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
ing does not result in better reception. But you could use
a B210 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
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 generat
requency_c 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,
on within each frame. And their
position in a frame is not right at the beginning 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
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
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 the
s
actually being delayed. 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-gnura
DSP".format(result.rf_freq/1e6, result.dsp_freq))
print("get_center_freq 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, Dougla
(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
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();
>>> print
, the scheduler has no
chance but to find the smallest common multiple of 4096 and your item 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
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
requirement
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 P
id not poll the chip for that info and just threw away a fixed
amount of samples after every 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:
&
14:25, Anderson, 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. Slight
ing temperature,
so it's very 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 DS
ot;
after each tune.
PS2: I don't know whether your overall frequency range 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/
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 c
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 needs
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: discuss-gnuradio-bounces+danders
aram2=val2)", and it works with the current state 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: Tuesd
radio@gnu.org
Subject: Re: [Discuss-gnuradio] passing USRP source block shared pointer
through SWIG
You should easily be able to pass a basic_block sptr and then
dynamic-cast it in your block.
What you're trying to do is not recommended procedure, although I can
see how it's necessary a
Hi all,
I'm looking into the possibility of passing the 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 seems like the object
created i
nly copy at 64bit aligned addresses (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
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 bl
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.
mailto:dander...@its.bldrdoc.gov>>
.bldrdoc@gnu.org
[discuss-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?
Yester
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
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):
de
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 (http://gnuradio.org/doc/doxygen/page_msg_passin
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
325 Broadway St., Boulder, CO 80305 | P: 303 497 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
oug
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: Thursday, January 15, 2015 10:55 AM
To: Nick Foster
Cc: GNURadio Discu
for my question: so 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: [Discus
as far 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 cann
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:
http://stackoverflow.com/questions/27968237/semi-consistent-voltage-pul
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 2
0:59 AM, Martin Braun
mailto: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:
> H
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
Date: Thu Jul 5 22:01:45 2012
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 instantia
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
___
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:
_gr_disabled_components:INTERNA
here was no submodule uhd in gnuradio, I
think you should get a different Error:
from gnuradio import doesntexist
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name doesntexist
Greetings,
Marcus
On 17.07.2014 18:45, Anderson, Douglas J. wrote:
>
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 speci
50 matches
Mail list logo
