[Discuss-gnuradio] 3.7.7 and ControlPort
Hi, Anyone knows if we´ll get controlport back in 3.7.7? Thanks, Murray ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] "make" error while making detector (howto_detect_ff) block.
hey,
I am working to make a detector block in gnuradio 3.7.1 using gr-how
"out-of-tree module". I am stuck with an error during make command
abhishek@abhishek-Inspiron-N5110:~/gr-howto/build$ make
Scanning dependencies of target gnuradio-howto
[ 5%] Building CXX object
lib/CMakeFiles/gnuradio-howto.dir/howto_detect_ff_impl.cc.o
/home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:37:5: error:
‘howto_detect_ff_sptr’ does not name a type
howto_detect_ff_sptr
^
/home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc: In constructor
‘gr::howto::howto_detect_ff_impl::howto_detect_ff_impl(float, int, int)’:
/home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:59:17: error:
expression cannot be used as a function
d_pfa(pfa), d_L(L), d_samples(samples)
^
/home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:59:25: error:
expression cannot be used as a function
d_pfa(pfa), d_L(L), d_samples(samples)
^
/home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:59:45: error:
expression cannot be used as a function
d_pfa(pfa), d_L(L), d_samples(samples)
^
/home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:185:1: error: expected
‘{’ before ‘}’ token
} /* namespace howto */
^
make[2]: *** [lib/CMakeFiles/gnuradio-howto.dir/howto_detect_ff_impl.cc.o]
Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-howto.dir/all] Error 2
make: *** [all] Error 2
Os is ubuntu 14.04. Even i have attached howto_detect_ff_impl.h,
howto_detect_ff_impl.cc and howto_swig.i file.
It seems that some mistake is there in howto_detect_ff.h file whose path is
gr-howto/include/howto. But i am not getting what exactly it is
Any solution to sort an error will be appreciated.
Thanks in advance,
Abhishek.
/* -*- c++ -*- */
/*
* Copyright 2015 <+YOU OR YOUR COMPANY+>.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3, or (at your option)
* any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street,
* Boston, MA 02110-1301, USA.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include "howto_detect_ff_impl.h"
#include
#include
#include
#include
#include
namespace gr {
namespace howto {
howto_detect_ff_sptr
howto_make_detect_ff(float pfa, int L, int samples)
{
return gnuradio::get_initial_sptr
(new howto_detect_ff_impl(pfa, L, samples));
}
static const int MIN_IN = 1; // mininum number of input streams
static const int MAX_IN = 1; // maximum number of input streams
static const int MIN_OUT = 1; // minimum number of output streams
static const int MAX_OUT = 1; // maximum number of output streams
float mem = 0; //Global Variable
/*
* The private constructor
*/
howto_detect_ff_impl::howto_detect_ff_impl (float pfa, int L, int samples)
: gr::block("howto_detect_ff",
gr::io_signature::make (MIN_IN, MAX_IN, sizeof (float)),
gr::io_signature::make (MIN_OUT, MAX_OUT, sizeof(float)),
d_pfa(pfa), d_L(L), d_samples(samples)
{
}
/*
* Our virtual destructor.
*/
howto_detect_ff_impl::~howto_detect_ff_impl()
{
}
//functions---
/*This function gives the CDF value for the pfa in input*/
float TracyWidom (float p){
float pd, tw;
tw = 0.45;
pd = 1 - p;
if (pd >= 0.01 && pd <= 0.05){
tw = 18*(pd - (17/75)); printf("a - %f\n", tw);
}else if (pd >= 0.05 && pd <= 0.1){
tw = 8*(pd - (179/400)); printf("b - %f\n", tw);
}else if (pd >= 0.1 && pd <= 0.3){
tw = (87/20)*(pd - (643/870)); printf("c - %f\n", tw);
}else if (pd >= 0.3 && pd <= 0.5){
tw = (16/5)*(pd - (287/320)); printf("d - %f\n", tw);
}else if (pd >= 0.5 && pd <= 0.7){
tw = (17/5)*(pd - (297/340)); printf("e - %f\n", tw);
}else if (pd >= 0.7 && pd <= 0.9){
tw = (5.2)*(pd - (0.813)); printf("f - %f\n", tw);
}else if (pd >= 0.9 && pd <= 0.95){
tw = (53/5)*(pd - (909/1060)); printf("g - %f\n", tw);
}else if (pd >= 0.95 && pd <= 1){
tw = 26*(pd - (593/650)); printf("h - %f\n", tw);
}else{
printf ("wrong pfa value: it must be between 0 and 1\n");
printf ("the pfa value standard is 0.1\n");
tw = (53/5)*(0.9 - (909/1060));
}
return tw;
}
/*this function calculates the threshold for the test
the inputs are: ns = numbers of samples;
L = length of the correlation function;
pfa = probability of false alarm*/
float gamma (int ns, int L, float pfa){
float A, B, C, ra
Re: [Discuss-gnuradio] "make" error while making detector (howto_detect_ff) block.
Hi Abhishek,
your _impl.cc is using old-style naming in out-of-tree-modules and their
components, whilst your detect_ff.h uses the consistent new way.
I think this could be the result of using gr_modtool to generate the
module skeleton, and then copy/pasting over lines from a pre-3.7 code
example. Is that possible?
Also, I already pointed you to the newer guided tutorials[1], which
don't build on the unmaintained gr-howto example. Please use these to
get used to GNU Radio.
Greetings,
Marcus
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
On 03/29/2015 03:16 PM, Abhishek Shukla wrote:
> hey,
> I am working to make a detector block in gnuradio 3.7.1 using gr-how
> "out-of-tree module". I am stuck with an error during make command
>
> abhishek@abhishek-Inspiron-N5110:~/gr-howto/build$ make
> Scanning dependencies of target gnuradio-howto
> [ 5%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/howto_detect_ff_impl.cc.o
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:37:5: error:
> ‘howto_detect_ff_sptr’ does not name a type
> howto_detect_ff_sptr
> ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc: In constructor
> ‘gr::howto::howto_detect_ff_impl::howto_detect_ff_impl(float, int, int)’:
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:59:17: error:
> expression cannot be used as a function
> d_pfa(pfa), d_L(L), d_samples(samples)
> ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:59:25: error:
> expression cannot be used as a function
> d_pfa(pfa), d_L(L), d_samples(samples)
> ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:59:45: error:
> expression cannot be used as a function
> d_pfa(pfa), d_L(L), d_samples(samples)
> ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:185:1: error:
> expected ‘{’ before ‘}’ token
> } /* namespace howto */
> ^
> make[2]: ***
> [lib/CMakeFiles/gnuradio-howto.dir/howto_detect_ff_impl.cc.o] Error 1
> make[1]: *** [lib/CMakeFiles/gnuradio-howto.dir/all] Error 2
> make: *** [all] Error 2
>
>
>
> Os is ubuntu 14.04. Even i have attached howto_detect_ff_impl.h,
> howto_detect_ff_impl.cc and howto_swig.i file.
> It seems that some mistake is there in howto_detect_ff.h file whose
> path is gr-howto/include/howto. But i am not getting what exactly it is
> Any solution to sort an error will be appreciated.
> Thanks in advance,
> Abhishek.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-ais fails?
Hi, with latest UHD and Gnuradio built from sources, gr-ais throws this error when callin ais_rx: ras@ubuntu:~$ ais_rx linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-143-g8c20712d -- Operating over USB 3. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.00 MHz... -- Actually got clock rate 32.00 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Tune Request: 162.00 MHz -- The RF LO does not support the requested frequency: -- Requested LO Frequency: 162.00 MHz -- RF LO Result: 162.00 MHz -- Attempted to use the DSP to reach the requested frequency: -- Desired DSP Frequency: -0.00 MHz -- DSP Result: -0.00 MHz -- Successfully tuned to 162.00 MHz -- Tuned to 162.000MHz Setting gain to 38 Gain is 38 Rate is 25 Using Volk machine: avx_64_mmx_orc Traceback (most recent call last): File "/usr/local/bin/ais_rx", line 23, in main() File "/usr/local/bin/ais_rx", line 18, in main tb = ais.radio.ais_radio(options) File "/usr/local/lib/python2.7/dist-packages/ais/radio.py", line 88, in __init__ self._rx_paths = (ais_rx(161.975e6 - 162.0e6, options.rate, "A"), File "/usr/local/lib/python2.7/dist-packages/ais/radio.py", line 63, in __init__ self.demod = ais.ais_demod(options) #ais_demod takes in complex baseband and spits out 1-bit unpacked bitstream File "/usr/local/lib/python2.7/dist-packages/ais/ais_demod.py", line 37, in __init__ self.preamble_detect = digital.msk_correlate_cc(self.preamble, 0.4, self._samples_per_symbol) AttributeError: 'module' object has no attribute 'msk_correlate_cc' ras@ubuntu:~$ Any ideas what is wrong? Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.7 and ControlPort
It's unlikely to happen for 3.7.7, though it may show up on the master branch of the source repository soon after, for an eventual 3.7.8 release. On Sun, Mar 29, 2015 at 3:36 AM, Murray Thomson wrote: > Hi, > > Anyone knows if we´ll get controlport back in 3.7.7? > > Thanks, > Murray > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.7 and ControlPort
On Sun, Mar 29, 2015 at 10:58 AM, Johnathan Corgan wrote: > It's unlikely to happen for 3.7.7, though it may show up on the master > branch of the source repository soon after, for an eventual 3.7.8 release. > > On Sun, Mar 29, 2015 at 3:36 AM, Murray Thomson < > murraythomson...@gmail.com> wrote: > >> Hi, >> >> Anyone knows if we´ll get controlport back in 3.7.7? >> >> Thanks, >> Murray >> > You can find the current work here: https://github.com/trondeau/gnuradio/tree/ctrlport_thrift There have only been two of us working on this, and I might need to pull in a few more updates from him. There are a couple of minor issues we're still working with. I was hoping we'd be ready by 3.7.7, but I don't feel confident enough in it to put it in the next release. When it gets into the master branch, we'll start getting more people hammering on it. Right now, I feel pretty good about things, but that just means that I'm not testing enough. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.7 and ControlPort
Thanks for the update, it's much appreciated. Murray On 29 March 2015 at 19:28, Tom Rondeau wrote: > On Sun, Mar 29, 2015 at 10:58 AM, Johnathan Corgan < > johnat...@corganlabs.com> wrote: > >> It's unlikely to happen for 3.7.7, though it may show up on the master >> branch of the source repository soon after, for an eventual 3.7.8 release. >> >> On Sun, Mar 29, 2015 at 3:36 AM, Murray Thomson < >> murraythomson...@gmail.com> wrote: >> >>> Hi, >>> >>> Anyone knows if we´ll get controlport back in 3.7.7? >>> >>> Thanks, >>> Murray >>> >> > You can find the current work here: > > https://github.com/trondeau/gnuradio/tree/ctrlport_thrift > > There have only been two of us working on this, and I might need to pull > in a few more updates from him. There are a couple of minor issues we're > still working with. I was hoping we'd be ready by 3.7.7, but I don't feel > confident enough in it to put it in the next release. When it gets into the > master branch, we'll start getting more people hammering on it. Right now, > I feel pretty good about things, but that just means that I'm not testing > enough. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird behavior of the correlate_and_sync block
On Sun, 2015-03-29 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org wrote: > From: Richard Bell > To: Karl Koscher > Cc: "discuss-gnuradio@gnu.org" > Subject: Re: [Discuss-gnuradio] Weird behavior of the > correlate_and_sync block > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I was seeing results with amplitudes like that as well, but I didn't trust > myself. I didn't push hard enough to get it working. I let it go. I'm still > need to get it working, for the same reason as you, but I can't say when I > will be able to put the time in. I'll let you know what happens when I do, > if no one else comments on this. > > Rich > > On Sat, Mar 28, 2015 at 6:19 PM, Karl Koscher > wrote: > > > I'm trying to use the correlate_and_sync block to get an initial timing > > estimate from a packet radio, but it doesn't seem to work at all. I decided > > to dig a bit deeper and try to figure out what it was doing. As it turns > > out, the sequence it correlates against seems to be completely wrong. > > Here's a simple test script to demonstrate the problem: > > > > #!/usr/bin/python > > > > from gnuradio import digital > > from gnuradio.filter import firdes > > from pylab import * > > > > preamble = [1,1,-1,-1] * 10 > > taps = firdes.root_raised_cosine(32, 32, 1, 0.35, 11*4*32) > > corr_and_sync = digital.correlate_and_sync_cc(preamble, taps, 8, 32) > > plot(corr_and_sync.symbols()) > > show() > > > > > > This produces a non-deterministic graph, but will often show wildly > > oscillating samples, with an amplitude as high as 1e31. Clearly something > > is amiss. > > > > When I extend the preamble to be 64 symbols long, everything seems to > > work. However, when I change the filter it uses, it breaks again. > > > > Any ideas what's going on? > > > > - Karl Karl and Rich, The short story is I know why these things happen; check the list archives if you care to learn the whys. You really want the correlate and sync block changes waiting in this pull request: https://github.com/gnuradio/gnuradio/pull/376 You will be much happier with its performance, as I tried to address everything I found amiss with the block. The patches are based on top of Nick Foster's work of specifying the correlation pattern input by using the GNURadio modulators to build the target correlation waveform. If you rebuild GNURadio with these patches, you can look at the example test_corr_and_sync.grc file, that is in that pull request, for guidance. Hopefully, Tom will merge this in some form in the next release or two. It is an ABI change, so it just can't be winged in as a fix. HTH, Andy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 148, Issue 32
On Sun, 2015-03-29 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org wrote: > From: "Ralph A. Schmid, dk5ras" > To: > Subject: [Discuss-gnuradio] gr-ais fails? > Message-ID: <007801d06a38$76635ac0$632a1040$@schmid.xxx> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > > > with latest UHD and Gnuradio built from sources, gr-ais throws this > error > when callin ais_rx: > > > > ras@ubuntu:~$ ais_rx > [snip] > > self.preamble_detect = digital.msk_correlate_cc(self.preamble, > 0.4, > self._samples_per_symbol) > > AttributeError: 'module' object has no attribute 'msk_correlate_cc' > > ras@ubuntu:~$ > > > > > > Any ideas what is wrong? You need a version of GNURadio (that Nick Foster has out on some development branches) that has the block. This branch is really out of date but still has the block in question: https://github.com/bistromath/gnuradio/tree/msk_blocks/gr-digital/lib This branch is more recent, but the block has been removed from that branch in favor of using an improved, more general correlate and sync block (see my list from earlier today): https://github.com/bistromath/gnuradio/tree/msk_from_master/gr-digital/lib Nick probably has better advice for you. Regards, Andy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird behavior of the correlate_and_sync block
On Sun, Mar 29, 2015 at 3:47 PM, Andy Walls wrote: > On Sun, 2015-03-29 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org > wrote: > > > > From: Richard Bell > > To: Karl Koscher > > Cc: "discuss-gnuradio@gnu.org" > > Subject: Re: [Discuss-gnuradio] Weird behavior of the > > correlate_and_sync block > > Message-ID: > >s...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > I was seeing results with amplitudes like that as well, but I didn't > trust > > myself. I didn't push hard enough to get it working. I let it go. I'm > still > > need to get it working, for the same reason as you, but I can't say when > I > > will be able to put the time in. I'll let you know what happens when I > do, > > if no one else comments on this. > > > > Rich > > > > On Sat, Mar 28, 2015 at 6:19 PM, Karl Koscher < > super...@cs.washington.edu> > > wrote: > > > > > I'm trying to use the correlate_and_sync block to get an initial timing > > > estimate from a packet radio, but it doesn't seem to work at all. I > decided > > > to dig a bit deeper and try to figure out what it was doing. As it > turns > > > out, the sequence it correlates against seems to be completely wrong. > > > Here's a simple test script to demonstrate the problem: > > > > > > #!/usr/bin/python > > > > > > from gnuradio import digital > > > from gnuradio.filter import firdes > > > from pylab import * > > > > > > preamble = [1,1,-1,-1] * 10 > > > taps = firdes.root_raised_cosine(32, 32, 1, 0.35, 11*4*32) > > > corr_and_sync = digital.correlate_and_sync_cc(preamble, taps, 8, 32) > > > plot(corr_and_sync.symbols()) > > > show() > > > > > > > > > This produces a non-deterministic graph, but will often show wildly > > > oscillating samples, with an amplitude as high as 1e31. Clearly > something > > > is amiss. > > > > > > When I extend the preamble to be 64 symbols long, everything seems to > > > work. However, when I change the filter it uses, it breaks again. > > > > > > Any ideas what's going on? > > > > > > - Karl > > Karl and Rich, > > The short story is I know why these things happen; check the list > archives if you care to learn the whys. > > You really want the correlate and sync block changes waiting in this > pull request: > > https://github.com/gnuradio/gnuradio/pull/376 > > You will be much happier with its performance, as I tried to address > everything I found amiss with the block. > > The patches are based on top of Nick Foster's work of specifying the > correlation pattern input by using the GNURadio modulators to build the > target correlation waveform. If you rebuild GNURadio with these > patches, you can look at the example test_corr_and_sync.grc file, that > is in that pull request, for guidance. > > Hopefully, Tom will merge this in some form in the next release or two. > It is an ABI change, so it just can't be winged in as a fix. > > HTH, > Andy Yeah, I've looked into this and am trying to pull in as much of this work into the 3.7 API so we can get it out there and help people with these issues. It's just one of those things that I need more time to focus just on that problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI time sink (float) unnecessary memmove()?
On Sat, Mar 28, 2015 at 5:32 PM, Andy Walls wrote: > When testing, I used 5 float streams rumning at over 150 Msps each, with > 15 microsecomd bursts of 50 MHz at about 10 microseconds apart. I used > enough x points to see two bursts on the gui. Normal trigger. (Free or auto > trigger moght be too taxing.) > > -Regards > Andy > Andy, if you have a chance, can you check out this new branch: https://github.com/trondeau/gnuradio/tree/qtgui/controlpanel It adds the fixes that we talked about. I just want to verify that things are still looking and behaving well for you. The other trick of this branch is if you go into the QT GUI Time Sink properties and turn "Control Panel" to Yes. I wouldn't mind a quick bit of feedback there, either. Tom > On March 28, 2015 8:06:08 PM EDT, Tom Rondeau wrote: >> >> On Sat, Mar 28, 2015 at 12:50 PM, Andy Walls > > wrote: >> >>> On Sat, 2015-03-28 at 14:45 -0400, Andy Walls wrote: >>> > Hi Tom: >>> > >>> > >>> > On Sat, 2015-03-28 at 11:12 -0700, Tom Rondeau wrote: >>> > > On Sat, Mar 28, 2015 at 11:00 AM, Andy Walls >>> > > wrote: >>> > >>> > > Can this memmove() be safely skipped >>> > > >>> > > >>> https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/lib/time_sink_f_impl.cc#L627 >>> > [snip] >>> > > The volk_32f_convert_64f_u_avx() call is unavoidable as Qwt >>> > > wants >>> > > doubles for plotting and not floats. But it might also be >>> able >>> > > to be >>> > > deferred to the very end when the decision to plot is known >>> > > for sure. >>> > > (But that's more surgery than I care to take on at the >>> > > moment.) >>> > >>> >>> > >>> > > But thinking about the volk convert function, that's both copying >>> the >>> > > data from the input buffer into the internal buffer as well as >>> > > performing the conversion. We can't just hold data in the input since >>> > > we don't want to back up the data until we're ready to plot both with >>> > > timing and with a full enough buffer -- it's just sampling a section >>> > > at a time and drops everything in between. >>> > >>> > Right. >>> > >>> > > That part could be converted into a memcpy instead of the volk >>> > > convert. Then, when we're ready to plot, we call the volk convert >>> that >>> > > also does the move from d_start to 0, so it combines those two >>> > > elements. >>> > >>> > Yeah, that's the surgery part. :) It would require adding a new set of >>> > buffers to hold floats objects, and then convert them when a >>> > determination to plot was made. >>> > >>> > This also affects the memmove() of the tail for the trigger delay. It >>> > would operate on the new set of float buffers (vs the buffers holding >>> > doubles). >>> > >>> > > Thoughts on those proposals? >>> >>> Your proposal for implementing memcpy() and deferring volk_*() to do the >>> conversion and "memmove" in one step is great! :) >>> >>> I just implemented it, and the time_sink_f thread has gone from 41.5% >>> CPU down to 29.1% CPU in my tests. :) memcpy() now dominates the >>> thread, but that's to be expected. >>> >>> >>> >>> With my initial hack: >>> >>> > CPU: Intel Sandy Bridge microarchitecture, speed 3.5e+06 MHz >>> (estimated) >>> > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a >>> unit mask of 0x00 (No unit mask) count 10 >>> > samples %image name symbol name >>> > 7815839.0737 libvolk.so.0.0.0 volk_32f_convert_64f_u_avx >>> > 2277711.3870 no-vmlinux /no-vmlinux >>> > 13972 6.9851 libgnuradio-qtgui-3.7.7git.so.0.0.0 >>> gr::qtgui::time_sink_f_impl::_test_trigger_slope(float const*) const >>> > 7781 3.8900 libgnuradio-qtgui-3.7.7git.so.0.0.0 >>> gr::qtgui::time_sink_f_impl::_test_trigger_norm(int, std::vector>> const*, std::allocator >) >>> > 7236 3.6175 libpthread-2.18.so pthread_mutex_lock >>> > 6163 3.0811 libgnuradio-runtime-3.7.7git.so.0.0.0 >>> boost::detail::sp_counted_base::release() >>> > 5942 2.9706 libpthread-2.18.so pthread_mutex_unlock >>> > 4947 2.4732 libgnuradio-runtime-3.7.7git.so.0.0.0 >>> gr::block_executor::run_one_iteration() >>> > 3826 1.9127 libgnuradio-runtime-3.7.7git.so.0.0.0 >>> gr::block_detail::input(unsigned int) >>> > 3555 1.7773 libstdc++.so.6.0.19 >>> /usr/lib64/libstdc++.so.6.0.19 >>> > 3206 1.6028 libc-2.18.so __memmove_ssse3_back >>> > [...] >>> >>> With my implementation of your suggestion: >>> >>> CPU: Intel Sandy Bridge microarchitecture, speed 3.5e+06 MHz (estimated) >>> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a >>> unit mask of 0x00 (No unit mask) count 9 >>> samples %image name symbol name >>> 2759535.6051 libc-2.18.so __memcpy_sse2_unaligned >>> 1222515.7736 no-vmlinux /no-vmlinux >>> 4051 5.2269 libpthread-2.18.so pthread_mutex_lock >>> 3739
Re: [Discuss-gnuradio] Achievable Sampling Rate without Under/Overflows
On Sat, Mar 28, 2015 at 9:35 AM, Marcus Müller wrote: > Hi Richard, > > there's definitely people doing working real-time IEEE 802.11a/b/g > decoding/encoding [1] at 10MHz and 20MHz bandwidths (==sampling rates). > > Greetings, > Marcus > > [1] http://dl.acm.org/citation.cfm?doid=2643230.2643240 > [2] http://dl.acm.org/citation.cfm?doid=2491246.2491248 Table 1 > Just an FYI...reference [1] is not available to ACM non-members without purchase. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Swig and python import problem due to other out-of-tree modules used in my out-of-tree module
I've asked this question before. But there are lots of ambiguity and
uncertainty. Thus, this is the clarification.
I am using Reed-Solomon En/decoder in my own OOT module sources. The
Reed-Solomon en/decoder are implemented in [gr-dvbt](
https://github.com/BogdanDIA/gr-dvbt).
Important codes are:
[include/reed_solomon.h](
https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon.h
)
[include/reed_solomon_enc.h](
https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon_enc.h
)
[lib/reed_solomon.cc](
https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon.cc)
[lib/reed_solomon_end_impl.h](
https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.h
)
[lib/reed_solomon_end_impl.cc](
https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.cc
)
I've built and installed my module. But when I import my module in Python
for tests, error occurs:
>>> import myOOTmodule
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py", line 51,
in
from myOOTmodule_swig import *
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 28, in
_myOOTmodule_swig = swig_import_helper()
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_myOOTmodule_swig', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined
symbol: _ZN2gr4dvbt12reed_solomonC1E
You can also see the error above in [gist](
https://gist.github.com/gsongsong/e07883959f6a339b5d78)
The problem is that the above error occurs since I am using
gr:dvbt::reed_solomon, which is neither in GNU Radio source tree nor in my
module.
I don't know the exact reason for this. But in my guess...
It seems that myOOTmodule thinks gr::dvbt::reed_solomon is a part of
myOOTmodule itself. But there is no declaration and implementation and it
causes the error.
Or myOOTmodule has no idea where to import gr:dvbt:reed_solomon.
Another hypothesis is that, an OOT module cannot use other OOT modules (in
swig-python?). I'm not sure about it. Or, there is a way to do this, but I
just don't know about it.
Regards,
Jeon.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
