Re: [Discuss-gnuradio] gr-rds
On Wed, Jan 15, 2014 at 06:44:51AM +0100, Bastian Bloessl wrote:
> On 2014-01-14 14:21, Michael Dickens wrote:
> >Not RPATH; that's messed up and I don't recommend using it any more than
> >necessary. I'm taking about the absolute path. See my prior email on this
> >subject. Here's what you do in CMake to fix this:
> >{{{
> > IF(APPLE)
> > SET_TARGET_PROPERTIES([LIBRARY] PROPERTIES
> > INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/${LIBRARY_DIR}"
> > )
> > ENDIF(APPLE)
> >}}}
> >where [LIBRARY] is the CMake name for the library as defined by the first
> >argument to ADD_LIBRARY, and LIBRARY_DIR is traditionally used to define
> >where libraries are installed. You might use different names than this, but
> >I think you can figure this out. If you add this to both the .so and .dylib
> >CMakeLists.txt files, it should fix this issue since CMake will then handle
> >setting both the self-id and then any linkage correctly both for "make test"
> >as well as after "install".
> >
> >Let me know if you want more direct help. - MLD
>
> I never heard about install_name_dir, but I just pushed a fix and
> hopefully I got it right now :-)
> Thanks for your help!
>
> Btw if this is the way to link under OSX it might be a good idea to
> add this to the template of gr_modtool.
Good point, it seems like a harmless patch. Michael, what do you think?
MB
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how this error can be solve
On Tue, Jan 14, 2014 at 11:24:07PM -0800, Johannes Demel wrote: > Hi Maheshkumar, > > the output of 'Complex to Mag^2' is a vector of length '2'. That > doesn't fit to the input signature of the following block 'Threshold'. GRC actually highlights these problems for you. In your screenshot, there's a red arrow at the offending port. Check for these things marked in red to give you a clue where the problem might be. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Sure; if it's not in there already, it should be. I much prefer -all- binaries (executables, libraries, shared objects, etc) to have correct linkage include self-id -- because it's good coding practice as much as anything else. I say go for it. One of these days I'll get around to trying out modtool on OSX to see if/how it works :) - MLD On Jan 15, 2014, at 5:06 AM, Martin Braun wrote: > Good point, it seems like a harmless patch. Michael, what do you think? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
On Jan 15, 2014, at 12:46 PM, Martin Braun wrote:
> OK, can you please make sure I didn't mess anything up here. It's a
> pretty simple patch, but I know bugger-all about OSX :)
>
> https://github.com/mbr0wn/gnuradio/commit/5743258c3329824761de2823a8b59fd91a992965
>
> Just give me a quick thumbs-up (or -down) and I'll make sure it gets
> merged (or fixed).
Yes, that's fine. Why not use ${GR_LIBRARY_DIR} instead of "lib"? It'll be
correct, but globally settable from the top-level CMakeLists.txt file.
Another change (not related to the OSX-specific one above): In the
"install(TARGETS", why not do:
lib${LIB_SUFFIX} -> ${GR_LIBRARY_DIR}
bin -> ${GR_RUNTIME_DIR}
? - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Bastian - Your change (commit 340cda20) looks like it should do the trick for the primary library. Thanks for getting that added, and so promptly! - MLD On Jan 15, 2014, at 12:44 AM, Bastian Bloessl wrote: > I never heard about install_name_dir, but I just pushed a fix and hopefully I > got it right now :-) > Thanks for your help! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
> > >> >> I've opened http://gnuradio.org/redmine/issues/611 and will try and >> figure this out. > > Hello Martin, I am still facing a problem here. (I have pulled the newest sources from GIT). First, let me describe the environment. I have connected the transmitter side to a channel model that introduces frequency and timing offsets (so that I have control over how dirty the channel is). From this channel model block, I feed it into the receiver blocks. I am not using any USRP or real hardware as of now. Issue A: I notice that when the header CRC check fails, the entire receive path soon freezes up. Issue B: Additionally, I notice that sometimes the header gets so corrupted that the CRC check passes (I suppose these false positives cannot be helped, unless we have a longer CRC for the header, but that's probably a waste). Issue A is the main problem for me. :) Thank you! Best regards, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
> > Hello Martin, > > I am still facing a problem here. (I have pulled the newest sources from > GIT). First, let me describe the environment. I have connected the > transmitter side to a channel model that introduces frequency and timing > offsets (so that I have control over how dirty the channel is). From this > channel model block, I feed it into the receiver blocks. I am not using any > USRP or real hardware as of now. > > Issue A: I notice that when the header CRC check fails, the entire receive > path soon freezes up. > > Issue B: Additionally, I notice that sometimes the header gets so > corrupted that the CRC check passes (I suppose these false positives cannot > be helped, unless we have a longer CRC for the header, but that's probably > a waste). > > Issue A is the main problem for me. :) > > > Dear All, Please accept my sincere apologies. Regarding issue A: The *payload* path freezes up, and this is the expected behavior since there are no valid headers that can be decoded. I had erroneously stated that the *entire* receive path freezes up, which I just realized, is not the case. Apologetically, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Dear All, There is a variant of this issue that I discovered and would like to point it out to the community. Synopsis: After the first time the header CRC fails, *all* subsequent packets fail. Setup: - GRC examples of Tx/Rx OFDM - Noise source with a variable slider to control the amount of noise. The output of the Tx block is added with the output of the noise source. - The output of this adder is connected to the Rx block. Procedure: - Start the experiment with 0 noise. We see that the packets are successfully decoded. - Increase the noise, and we observe that the packet success rate begins to drop (payload CRC failures) - Further increase the noise to force a header CRC failure. - Decrease the noise back to 0. Notice that the packet success rate remains 0, even though the noise is 0. This is highly repeatable. Any help would be greatly appreciated. Best, Aditya On Wed, Jan 15, 2014 at 4:34 PM, Aditya Dhananjay wrote: > > >> Hello Martin, >> >> I am still facing a problem here. (I have pulled the newest sources from >> GIT). First, let me describe the environment. I have connected the >> transmitter side to a channel model that introduces frequency and timing >> offsets (so that I have control over how dirty the channel is). From this >> channel model block, I feed it into the receiver blocks. I am not using any >> USRP or real hardware as of now. >> >> Issue A: I notice that when the header CRC check fails, the entire >> receive path soon freezes up. >> >> Issue B: Additionally, I notice that sometimes the header gets so >> corrupted that the CRC check passes (I suppose these false positives cannot >> be helped, unless we have a longer CRC for the header, but that's probably >> a waste). >> >> Issue A is the main problem for me. :) >> >> >> > Dear All, > > Please accept my sincere apologies. > > Regarding issue A: The *payload* path freezes up, and this is the expected > behavior since there are no valid headers that can be decoded. I had > erroneously stated that the *entire* receive path freezes up, which I just > realized, is not the case. > > Apologetically, > Aditya > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] It must be defined inside the context of a function !
Dear Sir,
Below code will produce compilation error: 'input_sizes' does not name a
type.
This is because input_sizes must be assigned inside a context of a function
in c++, right ?
std::vector input_sizes;
input_sizes.push_back(sizeof(float));
input_sizes.push_back(sizeof(double));
gr_sync_block("my block", gr_make_io_signaturev(2, 2, input_sizes),
gr_make_io_signature(1, 1, sizeof(float)))
Source:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#IO-signatures
My code (which produce error) is below.
[code]
/* -*- c++ -*- */
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
#include
#include "sample_and_hold_cc_impl.h"
namespace gr {
namespace howto {
sample_and_hold_cc::sptr
sample_and_hold_cc::make()
{
return gnuradio::get_initial_sptr
(new sample_and_hold_cc_impl());
}
/*
* The private constructor
*/
std::vector xx;
xx.push_back(25);
xx.push_back( sizeof( float ) );
xx.push_back( sizeof( std::complex ) );
sample_and_hold_cc_impl::sample_and_hold_cc_impl()
: gr_sync_block("sample_and_hold_cc",
gr_make_io_signature(<+MIN_IN+>, <+MAX_IN+>,
sizeof(<+ITYPE+>)),
gr_make_io_signature(<+MIN_OUT+>, <+MAX_OUT+>,
sizeof(<+OTYPE+>)))
{}
/*
* Our virtual destructor.
*/
sample_and_hold_cc_impl::~sample_and_hold_cc_impl()
{
}
int
sample_and_hold_cc_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const <+ITYPE+> *in = (const <+ITYPE+> *) input_items[0];
<+OTYPE+> *out = (<+OTYPE+> *) output_items[0];
// Do <+signal processing+>
// Tell runtime system how many output items we produced.
return noutput_items;
}
} /* namespace howto */
} /* namespace gr */
[/code]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
