Re: [Discuss-gnuradio] [User Experience] Hangout Thursday
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
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
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 moritz.fisc...@ettus.comwrote: 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
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=optimized out) at /usr/include/c++/4.6/bits/stl_vector.h:350 #9 gr::filter::firdes::low_pass (gain=optimized out, sampling_freq=optimized out, cutoff_freq=0.45001, transition_width=optimized out, window_type=optimized out, beta=optimized out) 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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
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
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
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
http://_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
http://_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
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
On Fri, Nov 15, 2013 at 2:03 PM, Philip Balister phi...@balister.org 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
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=optimized out) at /usr/include/c++/4.6/bits/stl_vector.h:350 #9 gr::filter::firdes::low_pass (gain=optimized out, sampling_freq=optimized out, cutoff_freq=0.45001, transition_width=optimized out, window_type=optimized out, beta=optimized out) 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 gdbbreak /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 gdbrun ##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
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
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
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 ? http://gnuradio.4.n7.nabble.com/file/n44750/25.png 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
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
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 http://gnuradio.4.n7.nabble.com/file/n44752/flowgraph_to_read_RSSI.png 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#%YZTPM8FL*=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
