Hello,
this question my arise from my ignorance about C++, but I don't
understand how, if it is possible, to sub-class a GNURadio block that
has moat of his code in an _impl class.
To my understanding I would need to subclass both the class defining the
block and his _impl class. However, it
All,
I'm interested in, and looking into the Pi/4 QPSK modulation technique
(http://en.wikipedia.org/wiki/Phase-shift_keying#.CF.80_.2F4.E2.80.93QPSK).
Has anyone worked on this before and does anyone have any blocks or code that I
could use for reference while making my own? Any help, links,
Hi,
I’m interested in, and looking into the Pi/4 QPSK modulation technique
(http://en.wikipedia.org/wiki/Phase-shift_keying#.CF.80_.2F4.E2.80.93QPSK).
Has anyone worked on this before and does anyone have any blocks or code
that I could use for reference while making my own? Any help,
Osmo-Tetra uses Pi/4-DQPSK:
http://tetra.osmocom.org/trac/wiki/osmo-tetra
Mike
--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com
On Fri, Oct 10, 2014 at 11:05 AM, PEEL Luke luke.p...@uk.thalesgroup.com
wrote:
All,
I’m interested in, and looking into the Pi/4
You're right -- that's one of the reasons why we try and keep the
block's guts (their kernels) elsewhere than the actual block definition.
Not all of our blocks do this, though.
M
On 10/10/2014 12:03 PM, Daniele Nicolodi wrote:
Hello,
this question my arise from my ignorance about C++, but
Hello Martin,
I'm not sure I understand. Are you saying that there is no way of doing
what I want without copying over to my class the implementation of the
block that is in the _impl class?
Why is this a good thing?
Cheers,
Daniele
On 10/10/14 12:16, Martin Braun wrote:
You're right --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniele,
_impl classes are not meant to be subclassed usually.
GR distinguishes between interface or public headers, which are
located in the include directory and private headers which are located
in the lib directory.
You can just add new
Hi,
There
is way to achieve this without copying around significant portions of code?
No, you'll need to copy the _impl
The case at hand is subclassing gr::analog::pll_carriertracking_cc
changing the phase_detector() method to use the regular atan2() instead
of the fast version.
Actually
On 10/10/14 12:25, Johannes Demel wrote:
_impl classes are not meant to be subclassed usually.
GR distinguishes between interface or public headers, which are
located in the include directory and private headers which are located
in the lib directory.
You can just add new classes to your lib
The good part is the separation of the API from the implementation. The
not so good thing is that the implementations themselves often contain
all the logic, usually because they are fairly simple. So, your choices
are to subclass or copy/edit the implementation files. [Just saw
Sylvain's not
yeah, you're right
That's the problem with my location !!
Thank u :)
On Thu, Oct 9, 2014 at 8:06 AM, Marcus Müller marcus.muel...@ettus.com
wrote:
Hi Mostafa,
pybombs tries to install boost from source because 1.49 is known to be
buggy.
It seems like it can't download the file. Since
Ralph/Johannes,
Thanks your reply, I will try use Open lte project to generate data.
在 2014年10月09日 22:40, Ralph A. Schmid, dk5ras 写道:
I could provide storage space for such a file, but only at an upstream of 10
Mbps.
Ralph.
-Original Message-
From:
On 10/10/14 12:30, Sylvain Munaut wrote:
Hi,
There
is way to achieve this without copying around significant portions of code?
No, you'll need to copy the _impl
Ok. Thanks for confirming my understanding.
I copied the _impl definition, however, I would prefer to do not copy
the interface
On 10/10/14 14:29, Daniele Nicolodi wrote:
I copied the _impl definition, however, I would prefer to do not copy
the interface definition, therefore I defined my block as follows:
namespace gr {
namespace baz {
class BAZ_API pll_carriertracking_cc
: public
Hi,
On 10/09/2014 05:43 PM, liisuu wrote:
Hi everyone,
I am a new user of GNU radio. I am trying to communicate between Tmote Sky
sensor node and USRP N210.
I use the Tmote Sky sensor node as transmitter to broadcast messages by
flashing the example code into the node. The messages are
I'm new to gnuradio and sdr. I'm looking to use a x310 usrp in an lte project.
I have read it can support a 184.32MHz clock frequency
which is great for LTE and a sample
rate of 30.72MHz.
I have looked at the uhd source code.
I get the impression that the lte frequencies can only be supported
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think it might be more of a C++-inherent thing:
If you declare a method in a class:
class daniele_s_class {
public:
void my_method(int argument);
};
Then you'll have to either implement that method, or can't instantiate
the class -- which is kind
Hi Paul,
in (maint branch) host/lib/usrp/x300/x300_clock_ctrl.cpp,
set_master_clock_rate(double):
if(doubles_are_equal(_system_ref_rate, 10e6)) {
if(doubles_are_equal(clock_rate, 184.32e6)) {
/* 10MHz reference, 184.32 MHz master clock out, NOT Zero
Delay. */
Dear Marcus and Bloessl,
Thanks for the reply. I also notice the fully functional gr-ieee802-11
package provide by Bloessl. Previously I thought it's only PHY, but as
Marcus mentioned it also include MAC. It seems to me in the
gr-ieee802-11-master package, the MAC does not run csma. I also find
Hi Paul,
On Fri, Oct 10, 2014 at 7:19 AM, Paul Creaser drpaulcrea...@gmail.com wrote:
I'm new to gnuradio and sdr. I'm looking to use a x310 usrp in an lte project.
I have read it can support a 184.32MHz clock frequency
which is great for LTE and a sample
rate of 30.72MHz.
I have looked at
I thought I would join the list of people emailing the list this week about
obscure issues with ancient versions of GNU Radio.
I have a flow graph that needs to operate at a variety of datarates from a
few kbps to about 1 Mbps. Due to the potential for very wide frequency
errors, we still have
On 10/10/2014 06:34 PM, Tom Tsou wrote:
On Fri, Oct 10, 2014 at 7:19 AM, Paul Creaser drpaulcrea...@gmail.com wrote:
I'm new to gnuradio and sdr. I'm looking to use a x310 usrp in an lte
project.
I have read it can support a 184.32MHz clock frequency
which is great for LTE and a sample
Hi John,
On 10.10.2014 19:33, John Malsbury wrote:
Toward the end of the receive chain, there are a multitude of blocks that
are used for Viterbi node synchronization. I've found that the number of
blocks in series (3-5), combined with the low datarates at this point in
the flowgraph, lead to
Default scheduler.
tb.start(1024), with different values, etc, etc.
Most of the downstream blocks are stock GNU Radio blocks - a delay block
(max delay is 1 sample), logical operators, etc. I guess I'll add some
printf debugging?
-John
On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller
Hey John,
I am way out of my depth here, but while working on a custom python block
the other day, I saw some weird behavior in 3.7.5 that was similar.
Setting the global max output had no effect, but setting the just-upstream
block(s) min/max output buffer size(s) low fixed my apparent
On Thu, Oct 9, 2014 at 11:21 AM, John Malsbury jmalsbury.perso...@gmail.com
wrote:
Jeff, Tom,
The packet framer/deframer is mostly identical to the stream-based one in
GNU Radio proper. It's not a bad starting point, but a more general
implementation that could be configured for a variety
On Wed, Oct 8, 2014 at 11:12 PM, Hoang Ngo-Khac
khachoang1...@outlook.com.vn wrote:
Dear all,
I am checking FEC Extended Encoder/Decoder in gnuradio-3.7.6 and would
like to embed it in my OFDM transmission.
First, I run the flowgraph below. It works and I can see how FEC improve
the
I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is regarded as a dodgy hack by all the GR developers here, but it
worked for me (and I read the article on latency). I believe the guy
Yep, that was me. I was getting to pipe-in with the same suggestion.
@(^.^)@ Ed
On 10/10/14 8:20 PM, Vanush Vaswani wrote:
I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is
Sounds dangerous if you also happen to have very high throughput
applications to run? Am I wrong?
On Fri, Oct 10, 2014 at 5:59 PM, Ed Criscuolo edward.l.criscu...@nasa.gov
wrote:
Yep, that was me. I was getting to pipe-in with the same suggestion.
@(^.^)@ Ed
On 10/10/14 8:20 PM, Vanush
On 10/10/14 9:15 PM, John Malsbury wrote:
Sounds dangerous if you also happen to have very high throughput
applications to run? Am I wrong?
Yes, it was a fine line between getting it small enough for acceptable
latency while still maintaining enough throughput to not overrun.
Fortunately for
Is there something i can force on a per block basis in 3.6? Is there some
trickery in the forecast function I might use?
On Oct 10, 2014 6:40 PM, Ed Criscuolo edward.l.criscu...@nasa.gov wrote:
On 10/10/14 9:15 PM, John Malsbury wrote:
Sounds dangerous if you also happen to have very high
32 matches
Mail list logo
