On Mon, Dec 19, 2011 at 10:54:02AM -0800, Josh Blum wrote:
> Are you positive that its not a problem with the gui sink itself. See
> this bug: http://gnuradio.org/redmine/issues/464
> One way around it would be to feed both float signals into a float to
Yeah, that's the problem, thanks. The work
And of course, you can always put a GRC wrapper around your custom block...
Indeed, and donate it back to the community...
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio m
And of course, you can always put a GRC wrapper around your custom block...
-Original Message-
From: discuss-gnuradio-bounces+callen=mitre@gnu.org
[mailto:discuss-gnuradio-bounces+callen=mitre@gnu.org] On Behalf Of Ed
Criscuolo
Sent: Monday, December 19, 2011 5:18 PM
To: discuss
If you're somewhat familiar with how to write/modify blocks, it probably
wouldn't be difficult to implement that functionality by making a new block
that is a copy of gr_multiply_const_vcc.cc (for instance) and changing the work
function to do what you want.
Sean
Here's a vector-subtract grap
Yes, I can do my own blocks. It would be pretty trivial to do it
there. I just wanted to know if there was an easy way to do it
solely using GRC.
@(^.^)@ Ed
On 12/19/11 5:05 PM, Nowlan, Sean wrote:
If you're somewhat familiar with how to write/modify blocks, it probably
wouldn't be diffi
I did a hand-contrived case with a simple 16-element vector, and it
seems to work.
@(^.^)@ Ed
On 12/19/11 4:58 PM, Allen, Cam wrote:
Hmm... I'm not sure about that. Seems reasonable to assume that the
stream-to-vector and vector-to-stream blocks would be inverses of each other.
Mostly I'd
If you're somewhat familiar with how to write/modify blocks, it probably
wouldn't be difficult to implement that functionality by making a new block
that is a copy of gr_multiply_const_vcc.cc (for instance) and changing the work
function to do what you want.
Sean
-Original Message-
Fro
Hmm... I'm not sure about that. Seems reasonable to assume that the
stream-to-vector and vector-to-stream blocks would be inverses of each other.
Mostly I'd just be worried about the first or last subtraction - you might only
get a length 1023 vector out at the end.
When you link it up, can y
Will that preserve the absolute positions of the original vector
elements? The initial vector represents an FFT, so it's
important to me that I keep the same positions.
@(^.^)@ Ed
On 12/19/11 4:33 PM, Allen, Cam wrote:
I would probably try converting the vector to a stream, delay the stream b
I would probably try converting the vector to a stream, delay the stream by 1
sample, subtract one stream from the other, and then convert the resulting
(difference) stream back to a vector.
-Cam
-Original Message-
From: discuss-gnuradio-bounces+callen=mitre@gnu.org
[mailto:discuss
I have a vector quantity (size 1024), and I want to do a calculation
on it such that v_out[i] = v_in[i] - v_in[i-1]
Is such a calculation possible in GRC? I haven't found any way to
get a hold of the individual elements of a vector.
@(^.^)@ Ed
___
D
Ok, I glanced at your code quickly, here are my thoughts (some of which you may
already do in files I haven't seen):
1) You are using tx_io[15] as a potentially highspeed I/O. This signal travels
via the radio daughter cards and could easily lead to EMI noise issues. You
could consider multiple
On Mon, Dec 19, 2011 at 2:33 PM, Matt Mills wrote:
> Any chance it could be recorded or webcast for those of us a tad further
> away?
>
I'm not sure. That's a question for the organizers. If there is a recording
of it, I'll be sure to let everyone know.
Tom
> On Mon, Dec 19, 2011 at 12:20 P
On Dec 19, 2011, at 10:40 AM, Philip Balister wrote:
At the same time, can we clean up the various combination of
-I/usr/inclide/gnuradio etc
with
#include "gr-header.h"
#include "gnuradio/gr-header.h"
?
I'd like to see the use of -I dropped where possible and all
hea
Any chance it could be recorded or webcast for those of us a tad further
away?
On Mon, Dec 19, 2011 at 12:20 PM, Tom Rondeau wrote:
> Hey everyone,
> I just wanted to let everyone know that I will be speaking at the new
> Software Radio Implementation Forum's (SRIF) first workshop this January.
>
Hey everyone,
I just wanted to let everyone know that I will be speaking at the new
Software Radio Implementation Forum's (SRIF) first workshop this January.
It's in Hong Kong, but registration is free for people in that part of the
world. You can find more details about it here:
http://srif2012.i
Andrew -
It would probably be helpful if we could confirm that someone else
with the same setup sees the same issue.
What versions of of the WX libraries and development packages do you
have installed? What checkout of GNU Radio do you have? What about
the relevant Python packages?
Cheer
On Sun, Dec 18, 2011 at 8:30 PM, Michael Dickens wrote:
> On Dec 18, 2011, at 3:41 PM, Tom Rondeau wrote:
> > The differences, though, coming in the naming scheme and installation
> > method. Instead of having a gr_.h file installed into
> > $prefix/include/gnuradio, it's just .h that is installe
On Mon, Dec 19, 2011 at 10:40 AM, Philip Balister wrote:
> On 12/18/2011 08:30 PM, Michael Dickens wrote:
> > On Dec 18, 2011, at 3:41 PM, Tom Rondeau wrote:
> >> The differences, though, coming in the naming scheme and installation
> >> method. Instead of having a gr_.h file installed into
> >> $
On Mon, Dec 19, 2011 at 4:21 AM, Martin Braun wrote:
> On Sun, Dec 18, 2011 at 03:41:13PM -0500, Tom Rondeau wrote:
> > Hey list,
> >
> > I'm working on merging Josh's gr_blocks branch into GNU Radio, and he's
> made a
> > few structural changes to how things will be installed. I wanted to have
>
> could you please give us a link to the relevant branch? Josh sends so
> many git-URLs around, it's a bit hard to keep track :)
>
Browse here:
http://gnuradio.org/cgit/jblum.git/tree/gr-blocks?h=gr_blocks
http://gnuradio.org/cgit/jblum.git/tree/gr-filter?h=gr_blocks
-Josh
__
On 12/19/2011 07:58 AM, Paul Miller wrote:
> If I'm doing something dumb, I can't find it. Happens all the
> time though. I'm using the python_blocks branch
> 5cd66eef8ab8a81589dc08a134457d15b431434e .
>
> I made a really simple sync_block that square-waves an input
> signal. I have a fancy b
I also like the structure change, and I think Michael's suggestion for
handling the migration is perfect.
Cheers,
Ben
On Sun, Dec 18, 2011 at 5:30 PM, Michael Dickens wrote:
> On Dec 18, 2011, at 3:41 PM, Tom Rondeau wrote:
> > The differences, though, coming in the naming scheme and installat
Andrew -
It would probably be helpful if we could confirm that someone else with the
same setup sees the same issue.
What versions of of the WX libraries and development packages do you have
installed? What checkout of GNU Radio do you have? What about the
relevant Python packages?
Cheers,
Ben
On 12/18/2011 08:30 PM, Michael Dickens wrote:
> On Dec 18, 2011, at 3:41 PM, Tom Rondeau wrote:
>> The differences, though, coming in the naming scheme and installation
>> method. Instead of having a gr_.h file installed into
>> $prefix/include/gnuradio, it's just .h that is installed into
>> $pre
Hi,
I have made some modifications to the existing burst tagger in the GNU Radio
source code.
It is now able to specify an amount of pre and post samples, which are
additionally tagged before and after the tag signal.
I have put my changes on my GitHub account, which is:
https://bar...@github
On Sun, Dec 18, 2011 at 03:41:13PM -0500, Tom Rondeau wrote:
> Hey list,
>
> I'm working on merging Josh's gr_blocks branch into GNU Radio, and he's made a
> few structural changes to how things will be installed. I wanted to have a
> discussion to see what people felt about the changes. Note that
27 matches
Mail list logo