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 seem
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, b
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, l
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
wrote:
> All,
>
>
>
> I’m interested in, and looking into the Pi/4 QPSK modulation technique
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++, bu
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 -- tha
-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 classes
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.
Actu
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
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 a
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
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 this works here, that
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: discuss-gnuradio-bounces+ralph=sch
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 in
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 gr::analog::
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 broadca
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. */
cl
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 th
Hi Paul,
On Fri, Oct 10, 2014 at 7:19 AM, Paul Creaser 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 the uhd source cod
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 to
On 10/10/2014 06:34 PM, Tom Tsou wrote:
> On Fri, Oct 10, 2014 at 7:19 AM, Paul Creaser 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
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
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
wrote:
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 slowliness
On Thu, Oct 9, 2014 at 11:21 AM, John Malsbury 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 of applications,
> codes,
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
> t
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
wh
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 rega
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
wrote:
> 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:
>
>>
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" wrote:
> On 10/10/14 9:15 PM, John Malsbury wrote:
>
>> Sounds dangerous if you also happen to have very high throughput
>> application
32 matches
Mail list logo
