Re: [Discuss-gnuradio] [User Experience] Hangout Thursday

2013-11-15 Thread Moritz Fischer
Hey guys,

another cool thing I forgot to mention during the call would be to
have something like planet.debian.org (with s/debian/gnuradio/ of
course).

Moritz

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Rational Resampler throws double free or corruption error

2013-11-15 Thread Frederik Wing
Hi everyone,

I am using the latest GNU Radio version compiled and running on a
Raspberry Pi with Raspbian Wheezy.
Most of the blocks seem to work. But the Rational Resampler makes problems.

Here is my sample python script generated by GNU Radio Companion:
http://pastebin.com/R0Z21MfU

Running it throws the error:
*** glibc detected *** /usr/bin/python2: double free or corruption
(!prev): 0x02bee190 ***

Debugging it with gdb gives the output here: http://pastebin.com/rXqtkZVG

Any ideas how to solve this?

Yours,
Frederik

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] [User Experience] Hangout Thursday

2013-11-15 Thread Dan CaJacob
Yes - that would solve the issue of bringing all the third-party blogs
together in one place.

Very Respectfully,

Dan CaJacob


On Fri, Nov 15, 2013 at 4:37 AM, Moritz Fischer wrote:

> Hey guys,
>
> another cool thing I forgot to mention during the call would be to
> have something like planet.debian.org (with s/debian/gnuradio/ of
> course).
>
> Moritz
>
> ___
> 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


Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error

2013-11-15 Thread Marcus Müller

Hi Frederik, hi rest,

this is an interesting error. You might want to report it.
The interesting part of your backtrace is
#8  ~vector (this=0xbee7c59c, __in_chrg=)
at /usr/include/c++/4.6/bits/stl_vector.h:350
#9  gr::filter::firdes::low_pass (gain=,
sampling_freq=, cutoff_freq=0.45001,
transition_width=, window_type=,
beta=) at /home/pi/gnuradio/gr-filter/lib/firdes.cc:136

firdes.cc:136 is the closing bracket of the for loop that iterates over 
both the taps vector and the window vector.
sadly, gdb doesn't tell us whether the w or the taps vector's destructor 
is being called.
As a wild guess, the compiler realised w is not being used after the 
last iteration of the loop in the low_pass function.

Proposal:
do a

gdb --args python top_block.py #or whatever your file is called
gdb>break /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
gdb>run
##at some point, the breakpoint will be reached.

and check if it crashes on the first run, on the last or whenever.

Basically: It's a curious thing that this happens. I do not rule out 
strange and wilde and generally untame things happening in memory here!


Greetings, and look out for memory grues,

Marcus

On 15.11.2013 12:13, Frederik Wing wrote:

Hi everyone,

I am using the latest GNU Radio version compiled and running on a
Raspberry Pi with Raspbian Wheezy.
Most of the blocks seem to work. But the Rational Resampler makes problems.

Here is my sample python script generated by GNU Radio Companion:
http://pastebin.com/R0Z21MfU

Running it throws the error:
*** glibc detected *** /usr/bin/python2: double free or corruption
(!prev): 0x02bee190 ***

Debugging it with gdb gives the output here: http://pastebin.com/rXqtkZVG

Any ideas how to solve this?

Yours,
Frederik

___
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


Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error

2013-11-15 Thread M Dammer
I pulled and compiled the latest gnuradio yesterday on an intel machine.
My project uses the rational resampler as well and I am having no problems.
Mark

On 15/11/13 11:13, Frederik Wing wrote:
> Hi everyone,
>
> I am using the latest GNU Radio version compiled and running on a
> Raspberry Pi with Raspbian Wheezy.
> Most of the blocks seem to work. But the Rational Resampler makes problems.
>
> Here is my sample python script generated by GNU Radio Companion:
> http://pastebin.com/R0Z21MfU
>
> Running it throws the error:
> *** glibc detected *** /usr/bin/python2: double free or corruption
> (!prev): 0x02bee190 ***
>
> Debugging it with gdb gives the output here: http://pastebin.com/rXqtkZVG
>
> Any ideas how to solve this?
>
> Yours,
> Frederik
>
> ___
> 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] I am getting a Segmentation fault (core dumped) error when running companion

2013-11-15 Thread mhorvat
Hello, At one point I had gnuradio companion working just fine. But while trying to get the software to recognize my blade-RF device, I somehow came to a point where I was getting the Segmentation fault error when trying to open companion. I uninstalled and reinstalled gnuradio, but I am still getting the same errors. I stack traced companion and found where the core dump happens. I took the last 15 lines of the trace and pasted them below. mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb0978000read(15, "\3\363\r\n\370O\206Rc\0\0\0\0\0\0\0\0\5\0\0\0@\0\0\0si\7\0\0d\0"..., 4096) = 4096fstat64(15, {st_mode=S_IFREG|0644, st_size=256842, ...}) = 0read(15, "f\1\0d\1\0\206\0\0}\1\0|\1\0S(\2\0\0\0Nc\3\0\0\0\3\0\0\0\5"..., 249856) = 249856read(15, "\0\0/home/nuand/sandbox/gnuradio/b"..., 4096) = 2890read(15, "", 4096)  = 0close(15)   = 0munmap(0xb0978000, 4096)    = 0stat64("/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig", 0xbff55b90) = -1 ENOENT (No such file or directory)open("/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.i386-linux-gnu.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)open("/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.so", O_RDONLY|O_LARGEFILE) = 15fstat64(15, {st_mode=S_IFREG|0644, st_size=1262989, ...}) = 0fstat64(15, {st_mode=S_IFREG|0644, st_size=1262989, ...}) = 0--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe596} ---+++ killed by SIGSEGV (core dumped) +++Segmentation fault (core dumped)Anybody know whats going wrong and how to fix it?Thanks,Michael

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] I am getting a Segmentation fault (core dumped) error when running companion

2013-11-15 Thread Marcus Müller

Hi Michael,

I don't think your trace is very useful; could you try running the 
companion within gdb and offering a backtrace?


gbd --args python $(which gnuradio-companion)
run
#wait for crash
bt

Put the complete backtrace in a pastebin or a github gist, if possible :)

Greetings,
Marcus
On 15.11.2013 18:34, mhor...@cellantenna.com wrote:

Hello,

At one point I had gnuradio companion working just fine. But while 
trying to get the software to recognize my blade-RF device, I somehow 
came to a point where I was getting the Segmentation fault error when 
trying to open companion. I uninstalled and reinstalled gnuradio, but 
I am still getting the same errors. I stack traced companion and found 
where the core dump happens. I took the last 15 lines of the trace and 
pasted them below.


mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb0978000
read(15, 
"\3\363\r\n\370O\206Rc\0\0\0\0\0\0\0\0\5\0\0\0@\0\0\0si\7\0\0d\0"..., 
4096) = 4096

fstat64(15, {st_mode=S_IFREG|0644, st_size=256842, ...}) = 0
read(15, 
"f\1\0d\1\0\206\0\0}\1\0|\1\0S(\2\0\0\0Nc\3\0\0\0\3\0\0\0\5"..., 
249856) = 249856

read(15, "\0\0/home/nuand/sandbox/gnuradio/b"..., 4096) = 2890
read(15, "", 4096)  = 0
close(15)   = 0
munmap(0xb0978000, 4096)= 0
stat64("/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig", 0xbff55b90) 
= -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.i386-linux-gnu.so 
", O_RDONLY|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.so 
", O_RDONLY|O_LARGEFILE) = 15

fstat64(15, {st_mode=S_IFREG|0644, st_size=1262989, ...}) = 0
fstat64(15, {st_mode=S_IFREG|0644, st_size=1262989, ...}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe596} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Anybody know whats going wrong and how to fix it?

Thanks,

Michael


___
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] update_tap method in adaptive filter class

2013-11-15 Thread Philip Balister
I'm looking at Coverity issue 1046173, Self Assignment.

See:

https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/adaptive_fir_ccc_impl.cc#L71

Now, this function obviously doesn't do anything. I am trying to work
out the best way to resolve the issue. Can someone explai what we are
trying to do here? Is there some missing code that needs writing, so I
should replace this line with a comment? Or should we just remove this
function?

Philip

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] update_tap method in adaptive filter class

2013-11-15 Thread Tom Rondeau
On Fri, Nov 15, 2013 at 2:03 PM, Philip Balister  wrote:
> I'm looking at Coverity issue 1046173, Self Assignment.
>
> See:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/adaptive_fir_ccc_impl.cc#L71
>
> Now, this function obviously doesn't do anything. I am trying to work
> out the best way to resolve the issue. Can someone explai what we are
> trying to do here? Is there some missing code that needs writing, so I
> should replace this line with a comment? Or should we just remove this
> function?
>
> Philip

Basically, and adaptive_filter like this is never meant to be run by
itself. It should always be subclassed and the "error" and
"update_tap" functions overloaded.

I think this issue represents a issue we had early on when converting
over the 3.7 where we couldn't declare this as a virtual class and use
it properly outside of gr-filter. We've since figured that out (IIRC),
but this was left as is since it wasn't, technically, bothering
anyone.

The real way this should work is to turn this into a virtual class
that things like the cma and lms_dd equalizers inherit from and
overload those two functions.

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error

2013-11-15 Thread Frederik Wing
Good evening Marcus,

thanks for your fast response.

In my sources firdes.cc:136 is
> return taps;
I cloned them from the git repository. Here is the source of the
trouble-making file:
http://gnuradio.org/redmine/projects/gnuradio/repository/entry/gr-filter/lib/firdes.cc?rev=master

Maybe you have an other idea?

Yours
Frederik

Am 15.11.2013 12:53, schrieb Marcus Müller:
> Hi Frederik, hi rest,
>
> this is an interesting error. You might want to report it.
> The interesting part of your backtrace is
> #8  ~vector (this=0xbee7c59c, __in_chrg=)
> at /usr/include/c++/4.6/bits/stl_vector.h:350
> #9  gr::filter::firdes::low_pass (gain=,
> sampling_freq=, cutoff_freq=0.45001,
> transition_width=, window_type=,
> beta=) at
> /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
>
> firdes.cc:136 is the closing bracket of the for loop that iterates
> over both the taps vector and the window vector.
> sadly, gdb doesn't tell us whether the w or the taps vector's
> destructor is being called.
> As a wild guess, the compiler realised w is not being used after the
> last iteration of the loop in the low_pass function.
> Proposal:
> do a
>
> gdb --args python top_block.py #or whatever your file is called
> gdb>break /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
> gdb>run
> ##at some point, the breakpoint will be reached.
>
> and check if it crashes on the first run, on the last or whenever.
>
> Basically: It's a curious thing that this happens. I do not rule out
> strange and wilde and generally untame things happening in memory here!
>
> Greetings, and look out for memory grues,
>
> Marcus
>
> On 15.11.2013 12:13, Frederik Wing wrote:
>> Hi everyone,
>>
>> I am using the latest GNU Radio version compiled and running on a
>> Raspberry Pi with Raspbian Wheezy.
>> Most of the blocks seem to work. But the Rational Resampler makes
>> problems.
>>
>> Here is my sample python script generated by GNU Radio Companion:
>> http://pastebin.com/R0Z21MfU
>>
>> Running it throws the error:
>> *** glibc detected *** /usr/bin/python2: double free or corruption
>> (!prev): 0x02bee190 ***
>>
>> Debugging it with gdb gives the output here:
>> http://pastebin.com/rXqtkZVG
>>
>> Any ideas how to solve this?
>>
>> Yours,
>> Frederik
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] More Coverity fixes

2013-11-15 Thread Philip Balister
Here are some simple coverity fixes:

https://github.com/balister/GNU-Radio/commits/cov-fixes

Note one of them messes with the QA code, I see random failures on the
on the tests now. However the original code was clearly bad :)

https://github.com/balister/GNU-Radio/commit/dcdc4655ce08de17ab0f1ffb33f369924f78a20e

I'll look at the adaptive filter stuff some more. Hopefully, itis a
matter of removing un-needed files from the build.

Philip

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Measuring RSSI values using GRC

2013-11-15 Thread Naceur
Hello GR list,

I am intending to read RSSI values on a RX (USRP N210),
I have found in the post of Marcus D. Leech in
https://www.ruby-forum.com/topic/1857766


10*LOG10(DECIMATE(SINGLE_POLE_IIR_FILTER(COMPLEX_TO_MAG**2(SIGNAL

Using GRC, I tried to implement that method of calculation as shown in the
attached figure,

1/ Is the flowgraph correct, or is there any missing block (decimation) ? 
2/ Then how can I read in human readable format (ASCII) the RSSI values from
the test_RSSI.txt file sink ?
3/ Is there a way to command the duration of execution of the flowgraph
within GRC () ?
4/ How can I format the test_RSSI.txt file sink to obtain single RSSI values
per line ?

Any explanations are welcome,  
Regards,
Naceur



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Measuring-RSSI-values-using-GRC-tp44749.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Reading RSSI Values with GRC

2013-11-15 Thread Naceur
Hello GR list, 

I am intending to read RSSI values on a RX (USRP N210), 
I have found in the post of Marcus D. Leech in
https://www.ruby-forum.com/topic/1857766


10*LOG10(DECIMATE(SINGLE_POLE_IIR_FILTER(COMPLEX_TO_MAG**2(SIGNAL 

Using GRC, I tried to implement that method of calculation as shown in the
attached figure, 

1/ Is the flowgraph correct, or is there any missing block (decimation ?) ? 
2/ Then, how can I read in human readable format (ASCII) the RSSI values
(expected to be in dBm) from the test_RSSI.txt file sink ? 
3/ Is there a way to command the duration of execution of a flowgraph within
GRC () ? 
4/ How can I format the test_RSSI.txt file sink to obtain single RSSI values
per line ?

 

Any explanations are welcome,   
Regards, 
Naceur



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Reading-RSSI-Values-with-GRC-tp44750.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Measuring RSSI values using GRC

2013-11-15 Thread Marcus D. Leech

Hello GR list,

I am intending to read RSSI values on a RX (USRP N210),
I have found in the post of Marcus D. Leech in
https://www.ruby-forum.com/topic/1857766


10*LOG10(DECIMATE(SINGLE_POLE_IIR_FILTER(COMPLEX_TO_MAG**2(SIGNAL

Using GRC, I tried to implement that method of calculation as shown in the
attached figure,

1/ Is the flowgraph correct, or is there any missing block (decimation) ?

There are blocks in GRC to do all of that.


2/ Then how can I read in human readable format (ASCII) the RSSI values from
the test_RSSI.txt file sink ?
3/ Is there a way to co

Use a "head" block -- you can tell it how many samples to process


mmand the duration of execution of the flowgraph
within GRC () ?
4/ How can I format the test_RSSI.txt file sink to obtain single RSSI values
per line ?
The file-sink blocks write out data values in raw-binary format, not 
ASCII text.


You could use a "probe" and poll the probe at 1Hz and have it call a 
Python function of your own to to the ASCII conversions.






Any explanations are welcome,
Regards,
Naceur



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Measuring-RSSI-values-using-GRC-tp44749.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Measuring RSSI values using GRC

2013-11-15 Thread Naceur
Thank you Marcus for the reply, 


Marcus Leech-2 wrote
> There are blocks in GRC to do all of that.

Sorry I forget to attach the GRC flowgraph

  
 am I missing any block ?

Actually I tried using the binascii python module, but what I got is as
follows:

with the binascii.b2a_qp(data) function:
...
=AD=BC=C1L=8B=BC=C1w=94=BC=C1=DFP=BC=C1*;=BC=C1,=1A=BC=C1.x=BC=C1=1Ae=BC=C1=
=16`=BC=C1r=81=BC=C1=E6=9D=BC=C1)=9C=BC=C1=B8k=BC=C1@U=BC=C1=AEa=BC=C1=BCj=
=BC=C1=00}=BC=C1=86=15=BD=C1=C6=EC=BC=C1=CA=D1=BC=C1nM=BC=C1=AF=D5=BB=C1nB
... 

and with the binascii.b2a_uu(data) function:

L   TPP  -,,  #3#   TPP  -,,  #3#%YZTPM&8FL*=7H/"K;)ZP@0^3<( 


Am I misusing functions, how can I get number values as output 


Marcus Leech-2 wrote
> The file-sink blocks write out data values in raw-binary format, not 
> ASCII text.
> 
> You could use a "probe" and poll the probe at 1Hz and have it call a 
> Python function of your own to to the ASCII conversions.

How can I configure the frequency of polling to 1Hz (Is "probe" here refer
to "Prob Signal" block in GRC ?)

Regards



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Re-Measuring-RSSI-values-using-GRC-tp44751p44752.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio