On 09/11/13 20:14, Marcus D. Leech wrote:
You can pull the .grc into gnuradio-companion, although that might not
work out that well, since the block-names changed across 3.7.
When I do this a large percentage of blocks/connectors do mot render.
In a separate thread I can present what I have s
On 09/11/2013 09:12 PM, John wrote:
On 09/11/13 20:02, Marcus D. Leech wrote:
Multimode hasn't been converted to 3.7 yet.
Thanks!
I have heard good things about how it handles nbfm and wanted to
compare it to what I have hacked together. I have been reviewing
examples of nbfm demodulation
On 09/11/13 20:02, Marcus D. Leech wrote:
Multimode hasn't been converted to 3.7 yet.
Thanks!
I have heard good things about how it handles nbfm and wanted to compare
it to what I have hacked together. I have been reviewing examples of
nbfm demodulation and would appreciate any pointers to
On 09/11/2013 08:51 PM, John wrote:
I am running gnuradio 3.7.0 and been using grc with good results. When
I try to make Multimon (recent trunk) I get the following errors:
trunk # make
/usr/local/bin/grcc -d . multimode.grc
>>> Error: Block key "gr_complex_to_real" not found in Platform -
grc
I am running gnuradio 3.7.0 and been using grc with good results. When I
try to make Multimon (recent trunk) I get the following errors:
trunk # make
/usr/local/bin/grcc -d . multimode.grc
>>> Error: Block key "gr_complex_to_real" not found in Platform -
grc(GNU Radio Companion)
Traceback (mos
Hi Tom,
I spent a while playing around with this, including adding a bunch of debug
output to tpb_thread_body::tpb_thread_body, and found that when a block is
done, the DONE state should propagate through the flow graph as
tpb_detail::notify_neighbours is called (as I'm sure you're aware). The
pr
Hi all,
Just to update you all, I've updated gr-ais to the GR 3.7 API this morning.
I still have a mile's worth of updates to take care of, but it compiles and
runs OK. Be sure to use a 162MHz bandpass filter as in many places nearby
FM and broadcast TV RFI will saturate even the most linear front
On Tue, Sep 10, 2013 at 7:44 PM, Rick Spanbauer wrote:
> I'm converting some old blocks I wrote for ~3.5 gnuradio APIs to 3.7. I
> have a block that
> calculates the MER of an incoming signal - this block is a synchronous
> decimator, and
> the make function takes a constellation_sptr and decimat
On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell
wrote:
> Hello all,
>
> I have written a sync block that takes in samples and outputs messages
> (similar to tagged_stream_to_pdu), but when writing a test for the block I
> found that when I called top_block.run(), the test never finished, as it
> a
On Wed, Sep 11, 2013 at 6:44 AM, Marcus Müller wrote:
> Hi Nemanja,
>
> I don't think deriving from two blocks will work; C++ allows you two have
> multiple superclasses, sure enough, but what deriving from two subclasses of
> the same base class (at least gr::block in this case) will give you is
Hi Nemanja,
I don't think deriving from two blocks will work; C++ allows you two
have multiple superclasses, sure enough, but what deriving from two
subclasses of the same base class (at least gr::block in this case) will
give you is the so-called diamond problem. As an example let's say
you'
On Tue, Sep 10, 2013 at 09:58:16PM +, Monahan-Mitchell, Tim wrote:
> GR 3.7.1
> gr-digital/examples/ofdm/rx_ofdm.grc
>
> 1. The OFDM Frame Equalizer block that is downstream from the Header Stream
> Virtual Source block has the Length Tag Key field set to length_tag_name, yet
> all other blo
Actually my question is: is there any example where some block is derived
from two other blocks (for example from two sync blocks)?
On Tue, Sep 10, 2013 at 12:45 PM, Nemanja Savic wrote:
> Thank you Josh. At the moment I wanted to make this as simple as possible.
> My idea was to make a new cla
13 matches
Mail list logo
