Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
On Sat, Apr 14, 2012 at 22:13, Ben Reynwar wrote: > I've > attached a patch that make each test use it's own random number > generating object which seems a tidier way to do this, and makes the > tests repeatable. This will have to wait until morning, but I'll get this on maint and master. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
It appears that each test case is being run twice. I think once to generate the xml output, and once to generate output for stdout and tell you whether it failed. The random number generator isn't being reseeded at the start of each test so they can produce different results, so you can sometimes see debug statements that indicate it should fail, but the output to stdout claims that is passes. I've attached a patch that make each test use it's own random number generating object which seems a tidier way to do this, and makes the tests repeatable. Since there seem to be a fair number of choices of seed that produce an error fraction of over 0.2, I've also increased the acceptable error rate in the test to 0.3, as Alick initially suggested. On Sat, Apr 14, 2012 at 9:39 AM, Alick Zhao wrote: > On Sat, 14 Apr 2012 13:40:35 +0200, Martin Braun wrote: >> On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote: >>> Yes the bug still occurs. >>> >>> I just wrote a simple script to ran the test for 50 times on T60 with >>> Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set >>> to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's >>> output is almost identical in each set except particular test time >>> length. The ones before FREQUENCY_OFFSET change is basically the same as >>> test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set >>> to 0 is attached below. I guess the almost same contents of output is >>> due to fixed random seed. >>> >>> I also ran the script on a Dell desktop with Fedora, and the result is >>> 50/50 pass the test. Then I notice one line in the qa python file says >>> that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell >>> desktop. >> >> So, >> >> I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me >> it's using "Volk machine: sse3_32". >> >> I also noticed the line that says seed=1234 fails. Also, the seed is set >> multiple times in the script. If this is the source of the bug or not, >> it should be fixed, because the seed is reset somewhere in the guts of >> the test. I'll post a patch on patch-gnuradio--this eliminates the >> problem on my machine, for some reason. If it does the same for you, >> this might actually be the solution. >> >> MB >> >> > > I applied the patch and tested it. No failure, yeah! > > However, with my debugging line, I can see this: > > [...] > constellation: differential: True correct: > 0.942307692308 > constellation: differential: True correct: > 0.772435897436 > constellation: differential: True correct: 1.0 > [...] > > So why 0.77XXX on the second line does not cause the assert to fail? > > alick > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 0001-Improving-qa_constellation_receiver.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] strange problem with packet sink
Hey all, The benchmark_rx.py file uses the generic_mod_demod.py and on the receiver side to be specific generic_demod whose input is gr.io_signature(1, 1, gr.sizeof_gr_complex), # Input signatureand the output signature is gr.io_signature(1, 1, gr.sizeof_char)) # Output signature . It also uses gr_framer_sink_1.cc which is for the basic benchmark purposes. What i am currently working with is a modified packet structure at the transmitter side keeping the modulation- demodulation of the system intact but a slight modification in the way it is received. I placed a packet sink giving it the default_access_code , the msg_queue and the required threshold , but the problem comes in when the demodulation with a "CHAR" outpout signature is connected to a packet_sink whose signtaures are : gr_make_io_signature (1, 1, sizeof(float)), #input signature gr_make_io_signature (0, 0, 0)), #output signature I didnt realise it at first when i did the usual self.connect(self ,self._demodulator , self._packet_sink) at the receiver side , and i get a TypeError : Itemsize mismatch error . Is there another alternative to this or would i have to create another packet_sink according to my requirements ? Thanks, Joshua. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Muted parts in the transmitted signal
Hi, I am using a flowgraph to make a SNR estimation of a transmitted OFDM signal. The method I am using to estimate SNR calculates the difference between the power of the received signal and the noise floor. In the low SNR case(-20 dB for example) I was getting, for a transmitter with constant gain, a SNR that varies a lot over time. Sometimes, I could get oscillations of 5 dB or maybe more for more than 20 samples. I took some samples of the OFDM signal and store them in a file. What I noticed is that there are some "mute" parts in the received signal that appear from time to time as you can see in the picture http://old.nabble.com/file/p33688580/oscillation.jpg I wonder what is the explanation for this phenomenon -- View this message in context: http://old.nabble.com/Muted-parts-in-the-transmitted-signal-tp33688580p33688580.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] Where's next?
On Sat, Apr 14, 2012 at 13:58, Martin Braun wrote: > it seems 'next' is gone? Tried to build 'next' using build-gnuradio, and > was just about to blame the script--when I figured out that the next > branch does not seem to exist on the remote repository. > (Sorry Marcus for doubting you :) The 'next' branch was merged back into 'master' a few days ago (this was announced in advance on the list) in order to switch over to the 3.6 API. Once we work out any remaining issues with 3.6.0git, we'll release 3.6.0, and start a new 'next' branch for work toward the 3.7 API. The 'master' branch will be used for new features conforming to the 3.6 API, to be releases as 3.6.1, 3.6.2, 3.6.3, etc. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Where's next?
Hi guys, it seems 'next' is gone? Tried to build 'next' using build-gnuradio, and was just about to blame the script--when I figured out that the next branch does not seem to exist on the remote repository. (Sorry Marcus for doubting you :) MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpOYxqvqKhLb.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More dumpeths
On Sat, Apr 14, 2012 at 13:30, Marcus D. Leech wrote: >> Please try commit c787fb66, which is the merge on the former 'next' >> branch of a PMT library modification (this is one of the ones that >> failed in trellis for you, hopefully you can make it work.) >> > This commit fails. But I had to roll-back to an older version of UHD to get > it to build. Still failed though. > > >> If this last fails, please try branch 'test/undo-pmt-deleter', which >> I've pushed to the main gnuradio repository. >> > That works. No segfaults on exit. Excellent, thanks. As this is in the 3.5.3 release, I'm going to rebase this 'fix' off the last 3.5.3 maint, but hold off merging it. I'm hoping Josh can supply an actual fix soon so we don't have to take that functionality out altogether. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More dumpeths
On 04/14/2012 04:03 PM, Johnathan Corgan wrote: On Sat, Apr 14, 2012 at 12:25, Marcus D. Leech wrote: Both of those commits fail to build for me in gr-trellis Not sure why that is, might be a result of repeated git checkouts on different tags, etc., without cleaning up in between. It compiles ok here. Two more tests will help me narrow this down: Please try commit 29c887da, which is the merge on former 'next' branch of the working commit 27dd737a. This commit fails. Please try commit c787fb66, which is the merge on the former 'next' branch of a PMT library modification (this is one of the ones that failed in trellis for you, hopefully you can make it work.) This commit fails. But I had to roll-back to an older version of UHD to get it to build. Still failed though. If this last fails, please try branch 'test/undo-pmt-deleter', which I've pushed to the main gnuradio repository. That works. No segfaults on exit. I appreciate all the testing, since I can't duplicate the problem, and obviously this is important to fix as soon as possible. Johnathan -- 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] More dumpeths
On Sat, Apr 14, 2012 at 12:25, Marcus D. Leech wrote: > Both of those commits fail to build for me in gr-trellis Not sure why that is, might be a result of repeated git checkouts on different tags, etc., without cleaning up in between. It compiles ok here. Two more tests will help me narrow this down: Please try commit 29c887da, which is the merge on former 'next' branch of the working commit 27dd737a. Please try commit c787fb66, which is the merge on the former 'next' branch of a PMT library modification (this is one of the ones that failed in trellis for you, hopefully you can make it work.) If this last fails, please try branch 'test/undo-pmt-deleter', which I've pushed to the main gnuradio repository. I appreciate all the testing, since I can't duplicate the problem, and obviously this is important to fix as soon as possible. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More dumpeths
On 04/14/2012 03:18 PM, Johnathan Corgan wrote: On Sat, Apr 14, 2012 at 12:11, Johnathan Corgan wrote: On Sat, Apr 14, 2012 at 11:57, Marcus D. Leech wrote: Somewhere between commit 2f73fe22c5e1591242a9556221ec8487170a7b00 and 27dd737afdab4123e40a1b886635b387b3c063c6 Both of these commits fail, correct? What was the last good one you tried? In particular, I'd like to confirm that f88b8cf5 (3.5 API) or c787fb66 (3.6 API) are working correctly. It's that last time we changed the PMT library. Johnathan Both of those commits fail to build for me in gr-trellis -- 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] More dumpeths
On Sat, Apr 14, 2012 at 12:11, Johnathan Corgan wrote: > On Sat, Apr 14, 2012 at 11:57, Marcus D. Leech wrote: > >> Somewhere between commit 2f73fe22c5e1591242a9556221ec8487170a7b00 and >> 27dd737afdab4123e40a1b886635b387b3c063c6 > > Both of these commits fail, correct? What was the last good one you tried? In particular, I'd like to confirm that f88b8cf5 (3.5 API) or c787fb66 (3.6 API) are working correctly. It's that last time we changed the PMT library. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More dumpeths
On Sat, Apr 14, 2012 at 11:57, Marcus D. Leech wrote: > Somewhere between commit 2f73fe22c5e1591242a9556221ec8487170a7b00 and > 27dd737afdab4123e40a1b886635b387b3c063c6 Both of these commits fail, correct? What was the last good one you tried? Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More dumpeths
On 04/14/2012 01:41 PM, Johnathan Corgan wrote: On Sat, Apr 14, 2012 at 10:40, Johnathan Corgan wrote: Also, can you document gcc version, boost version, OS, etc.? I see this from your other email, thanks. Johnathan Somewhere between commit 2f73fe22c5e1591242a9556221ec8487170a7b00 and 27dd737afdab4123e40a1b886635b387b3c063c6 Those commits were only a couple of commits apart, but I didn't bisect it further. -- 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] More dumpeths
On Sat, Apr 14, 2012 at 10:40, Johnathan Corgan wrote: > Also, can you document gcc version, boost version, OS, etc.? I see this from your other email, thanks. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More dumpeths
On Sat, Apr 14, 2012 at 10:17, Marcus D. Leech wrote: > I've attached a core-dump "bt" trace that was produced exiting GRC--I wasn't > even actively running a flow-graph. Interestingly enough, PMT > seems to have been involved at the very top of the stack--just like the > dumps I've been getting exiting from running flow-graphs. Since you can reliably generate these failures, could you use git bisect to narrow it down? Also, can you document gcc version, boost version, OS, etc.? Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] More dumpeths
I've attached a core-dump "bt" trace that was produced exiting GRC--I wasn't even actively running a flow-graph. Interestingly enough, PMT seems to have been involved at the very top of the stack--just like the dumps I've been getting exiting from running flow-graphs. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org #0 0x7ff8ddad06d7 in pmt::intrusive_ptr_release(pmt::pmt_base*) () from /usr/local/lib64/libgruel-3.6.0git.so.0.0.0 #1 0x0034b5e369f1 in exit () from /lib64/libc.so.6 #2 0x0034c3b0752f in Py_Exit () from /usr/lib64/libpython2.7.so.1.0 #3 0x0034c3b07672 in ?? () from /usr/lib64/libpython2.7.so.1.0 #4 0x0034c3b078dd in PyErr_PrintEx () from /usr/lib64/libpython2.7.so.1.0 #5 0x7ff8e0d3b70a in ?? () from /usr/lib64/python2.7/site-packages/gtk-2.0/gobject/_gobject.so #6 0x0034b8a0e03e in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #7 0x0034b8a1ee87 in ?? () from /lib64/libgobject-2.0.so.0 #8 0x0034b8a27d77 in g_signal_emitv () from /lib64/libgobject-2.0.so.0 #9 0x7ff8e0d3314e in ?? () from /usr/lib64/python2.7/site-packages/gtk-2.0/gobject/_gobject.so #10 0x0034c3ae965b in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #11 0x0034c3aeb04d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #12 0x0034c3a71c62 in ?? () from /usr/lib64/libpython2.7.so.1.0 #13 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #14 0x0034c3a5a65f in ?? () from /usr/lib64/libpython2.7.so.1.0 #15 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #16 0x0034c3aa4ea4 in ?? () from /usr/lib64/libpython2.7.so.1.0 #17 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 ---Type to continue, or q to quit--- #18 0x0034c3ae8783 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #19 0x0034c3aeb04d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #20 0x0034c3a71c62 in ?? () from /usr/lib64/libpython2.7.so.1.0 #21 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #22 0x0034c3a5a65f in ?? () from /usr/lib64/libpython2.7.so.1.0 #23 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #24 0x0034c3ae3a87 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0 #25 0x7ff8e0d3b5ed in ?? () from /usr/lib64/python2.7/site-packages/gtk-2.0/gobject/_gobject.so #26 0x0034b8a0e03e in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #27 0x0034b8a1ee87 in ?? () from /lib64/libgobject-2.0.so.0 #28 0x0034b8a28555 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #29 0x0034b8a28983 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #30 0x0036e1885aef in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #31 0x0036e174c34d in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #32 0x0036e1261a8c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #33 0x0034b7a41e33 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 ---Type to continue, or q to quit--- #34 0x0034b7a42610 in ?? () from /lib64/libglib-2.0.so.0 #35 0x0034b7a42c82 in g_main_loop_run () from /lib64/libglib-2.0.so.0 #36 0x0036e174b0b7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #37 0x7ff8e0a23914 in ?? () from /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/_gtk.so #38 0x0034c3ae912b in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #39 0x0034c3aeb04d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #40 0x0034c3a71c62 in ?? () from /usr/lib64/libpython2.7.so.1.0 #41 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #42 0x0034c3a5a65f in ?? () from /usr/lib64/libpython2.7.so.1.0 #43 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #44 0x0034c3ae3a87 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0 #45 0x0034c3a5b31e in PyInstance_New () from /usr/lib64/libpython2.7.so.1.0 #46 0x0034c3a48fc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #47 0x0034c3ae8783 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #48 0x0034c3aeb04d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #49 0x0034c3aeb162 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0 ---Type to continue, or q to quit--- #50 0x0034c3b0639c in ?? () from /usr/lib64/libpython2.7.so.1.0 #51 0x0034c3b071d0 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0 #52 0x0034c3b07daf in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0 #53 0x0034c3b198ce in Py_Main () from /usr/lib64/libpython2.7.so.1.0 #54 0x0034b5e1ee5d in __libc_start_main () from /lib64/libc.so.6 #55 0x00400649 in _start () ___ Discuss-gnuradio mailing list
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
On Sat, 14 Apr 2012 13:40:35 +0200, Martin Braun wrote: > On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote: >> Yes the bug still occurs. >> >> I just wrote a simple script to ran the test for 50 times on T60 with >> Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set >> to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's >> output is almost identical in each set except particular test time >> length. The ones before FREQUENCY_OFFSET change is basically the same as >> test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set >> to 0 is attached below. I guess the almost same contents of output is >> due to fixed random seed. >> >> I also ran the script on a Dell desktop with Fedora, and the result is >> 50/50 pass the test. Then I notice one line in the qa python file says >> that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell >> desktop. > > So, > > I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me > it's using "Volk machine: sse3_32". > > I also noticed the line that says seed=1234 fails. Also, the seed is set > multiple times in the script. If this is the source of the bug or not, > it should be fixed, because the seed is reset somewhere in the guts of > the test. I'll post a patch on patch-gnuradio--this eliminates the > problem on my machine, for some reason. If it does the same for you, > this might actually be the solution. > > MB > > I applied the patch and tested it. No failure, yeah! However, with my debugging line, I can see this: [...] constellation: differential: True correct: 0.942307692308 constellation: differential: True correct: 0.772435897436 constellation: differential: True correct: 1.0 [...] So why 0.77XXX on the second line does not cause the assert to fail? alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
On Sat, Apr 14, 2012 at 04:40, Martin Braun wrote: > I'll post a patch on patch-gnuradio--this eliminates the > problem on my machine, for some reason. If it does the same for you, > this might actually be the solution. This was applied on 3.5.3 maint and 3.6.0git master. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Experimental version of build-gnradio up
http://www.sbrac.org/files/build-gnuradio-test Is a version of build-gnuradio that includes experimental support for RedHat RHEL 6 and Debian 6.* series. If someone wants to test this on Debian 6, I'd love to get feedback. I don't have a Debian image here to test on, neither do I have a RHEL 6. So I'm rather "brailing it". This experimental version also includes the "-e" option that is used to add "extras" to the build, the syntax is: -e URL-to-repo So it takes a URL of the form: git://host/blah/blah/blah http://host/blah/blah/blah.git or: http://host/blah/blah/svn/blah The important thing to notice is that the existence of git: or blah.git triggers a GIT fetch, and the presence of the name component "svn" triggers an SVN fetch. This is patterned after the way CGRAN serves up packages. And will fetch the resulting codebase via GIT or SVN and attempt to build it. It only supports GNu Radio "add-ons" that adhere to the CMake build environment--there are only a small number of these at the moment, but perhaps this will encourage conversion to CMake among the "add-ons". -- 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
[Discuss-gnuradio] video streaming on ofdm
hye... i'm using grc for video streaming of ofdm system... i manage to transmit the video but the quality is so bad and sometime the video can play,but sometime it doesn't play at all... how to improve the video quality?is it approriate to add buffer on it? and i got this message...what does it meant?? gst-launch -v playbin uri=file:///root/rx Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Stream contains no data. Additional debug info: gsttypefindelement.c(570): gst_type_find_element_handle_event (): /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Can't typefind empty stream ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... tq -- View this message in context: http://old.nabble.com/video-streaming-on-ofdm-tp33672798p33672798.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] Question about USRP2 Tx procedure
original mail-- Message: 11 Date: Fri, 13 Apr 2012 08:25:36 -0700 From: Josh Blum To:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure Message-ID:<4f884570.5010...@ettus.com> Content-Type: text/plain; charset=ISO-8859-1 On 04/13/2012 06:54 AM, Pan, Luyuan wrote: Hi everyone, I now have some trouble in understanding how the usrp2 sent out the data. My scenario of the test is: We tried to control the usrp2 to transmit in a fixed time slot, such as 5 seconds. The code is: tb = usrp.transmit_path() # Create the path t1 = time.time() tb.start() while (time.time() - t1< 5): .. # The code to send out the data continue; time.sleep(0.65)# to ensure all the data are sent truly out. Question?? WHY tb.stop() tb.wait() My question lies in line time.sleep(0.65). if we don't use time.sleep(), we can not receive all the packets, every time the receive side will lose about 50 packets(each one is 1500 bytes), and if time.sleep()<0.65s, it will still lose but less than 50. So, I want to know why it need such a time(about 650ms)? And we have some hypotheses: 1. The usrp did not send out data instantly at tb.start(), it need time to build the flow graph. But we do an experiment to get the time we received the first packet, and found the truth is not that. The time tb.start and (in the recv side)the time we received the packet is almost the same. So, It send out immediately. 2. But we encountered another dilemma, if we let it send an extremely short time, like while (time.time() - t1< 0.02) (generally less than 50 packets), and do not use time.sleep(), it will never send out the data. Only add time.sleep(), it will success. Why? I really confused!~ 3. Considering that we only need 650ms, no matter how long we send(like 10s or more). We guess there is a fixed size cache in the usrp and it send the cached data at a precise-controlled time, but I can not persuade myself. Can anyone interpret the strange phenomenon? Any suggestion is appreciated, thank you!! The is buffering in the USRP2, about 1 MB. Give your sample rate and 4 bytes per sample you can approximate the sleep time. The more proper way to do this is to send an end-of-burst tag with the last sample and to wait on the async message queue for a burst ACK packet. About the TX tags for the sink block: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n52 Also see the async message source: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_amsg_source.h -josh -- Hello, In order to find out the reasons, today we did another test, we used wireshark to capture the data through the wEthernet card. But, we guess the problem may lies in the FIFO in the software side, the scenarios are: 1. we use while (time.time() - t1< 0.05) and no time.sleep(), then the receive side can get only one packet. the useful data through the Ethernet is about 55 packets(not take into account the packet less than 1498 bytes, we consider them as the control info). 2. we use while (time.time() - t1< 0.05) and time.sleep(0.65), so we can receive all the data(10 packets). And the data through the Ethernet is nearly 600 packets. For the fact 1/10 almost equals 55/600, we think USRP2 send the data out immediately after he get it from the host PC. The main problem now is for some unknown reason the PC did not pass the data to USRP2, so he has nothing to send. Did I misunderstand something or some other reasons? Thank you for your help! -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote: > Yes the bug still occurs. > > I just wrote a simple script to ran the test for 50 times on T60 with > Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set > to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's > output is almost identical in each set except particular test time > length. The ones before FREQUENCY_OFFSET change is basically the same as > test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set > to 0 is attached below. I guess the almost same contents of output is > due to fixed random seed. > > I also ran the script on a Dell desktop with Fedora, and the result is > 50/50 pass the test. Then I notice one line in the qa python file says > that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell > desktop. So, I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me it's using "Volk machine: sse3_32". I also noticed the line that says seed=1234 fails. Also, the seed is set multiple times in the script. If this is the source of the bug or not, it should be fixed, because the seed is reset somewhere in the guts of the test. I'll post a patch on patch-gnuradio--this eliminates the problem on my machine, for some reason. If it does the same for you, this might actually be the solution. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpRFF4P4WQ4H.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
On Fri, 13 Apr 2012 13:20:01 -0700, Ben Reynwar wrote:
> 2012/4/12 Alick Zhao :
>> Hi all,
>>
>> Recently I have upgraded my gnuradio build to v3.5.3 on several
>> computers, and I find that on two machines with Ubuntu 11.10, make test
>> will fail the test qa_constellation_receiver while on the other two with
>> Fedora 16 all tests are passed.
>>
>> To investigate the problem, I add one line in the file
>> `gr-digital/python/qa_constellation_receiver.py` which just print the
>> value of constellation, differential, and correct before the assert.
>> Then I run the script
>> `build/gr-digital/python/qa_constellation_receiver_test.sh`. The output
>> is recorded and attached below. Among them:
>>
>> * test.t41.log is from a Thinkpad T41 with Ubuntu 11.10 32bit installed,
>> * test.t60.log is from a Thinkpad T60 with Ubuntu 11.10 32bit installed,
>> * test.f16.log is from a HP 6531s with Fedora 16 x86_64 installed.
>>
>> Hope these logs are helpful to diagnose the problem.
>>
>> PS: As a side note, my debugging line's output appears later than the
>> result, which is not the case for screen output. I think this is
>> probably related to stdout buffering.
>>
>> PS2: I once changed the REQ_CORRECT to 0.7 on one Ubuntu machine,
>> and then made the test passed. I wonder if it is a valid fix.
>>
>
> It sounds like this is definitely a bug, but it's hard for me to track
> it down because I can't replicate it. Does the bug still occur if you
> set FREQUENCY_OFFSET = 0 in the test case?
Yes the bug still occurs.
I just wrote a simple script to ran the test for 50 times on T60 with
Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set
to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's
output is almost identical in each set except particular test time
length. The ones before FREQUENCY_OFFSET change is basically the same as
test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set
to 0 is attached below. I guess the almost same contents of output is
due to fixed random seed.
I also ran the script on a Dell desktop with Fedora, and the result is
50/50 pass the test. Then I notice one line in the qa python file says
that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell
desktop.
alick
[HANDLER_OUTPUT]
Test project /home/niulab/gnuradio/build3.5.3
Start 82: qa_constellation_receiver
1/1 Test #82: qa_constellation_receiver ***Failed3.41 sec
>>> gr_fir_ccf: using SSE
>>> gr_fir_ccc: using SSE
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct:
0.982300884956
constellation: differential: True correct: 1.0
constellation: differential: True correct:
0.96837944664
constellation: differential: True correct:
0.990118577075
constellation: differential: True correct:
0.957746478873
constellation: differential: True correct:
0.93896713615
constellation: differential: True correct:
0.821596244131
constellation: differential: True correct:
0.863849765258
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct: 1.0
constellation: differential: True correct:
0.977876106195
constellation: differential: True correct:
0.893805309735
constellation: differential: True correct:
0.990118577075
constellation: differential: True correct:
0.990118577075
constellation: differential: True correct:
0.951486697966
constellation: differential: True correct:
0.981220657277
constellation: differential: True correct:
0.801251956182
constellation: differential: True correct:
0.735524256651
F
==
FAIL: test_basic (__main__.test_constellation_receiver)
--
Traceback (most recent call last):
File "/home/niulab/gnuradio/gr-digital/python/qa_constellation_receiver.py",
line 101, in test_basic
self.assertTrue(correct > REQ_CORRECT)
AssertionError: False is not true
--
Ran 1 test in 1.438s
FAILED (failures=1)
Using Volk machine: ssse3_32
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 3.43 sec
The following tests FAILED:
82 - qa_constellation_receiver (Failed)
[ERROR_MESSAGE]
Errors while running CTest
#!/bin/bash
prefix=${1:-log}
n_ok=0
for cnt in $(seq 50); do
if ctest -Q --output-on-failure -R qa_constellation_receiver \
-O ${prefix}/ctest.log.$cnt; then
let ++n_ok
fi
done
echo "right/total: $n_ok
