-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Iftah,
as for the building part, you seem to be doing fine. I'm a little perplexed, actually. Maybe it's something like http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-September/007415.html where the solution was not to mix debug and release build symbols of UHD. Greetings, Marcus On 17.04.2014 18:17, iftah giladi wrote: > Well, > > The exception happens on this line: > > uhd::device_addrs_t device_addrs = > uhd::device::find(vm["args"].as<std::string>()); > > the exception is: First-chance exception at 0x0f62763b in > uhd_find_devices.exe: 0xC0000005: Access violation reading location > 0x02796000 > > p.s: maybe It will help if you'll write down the basic steps needed > in order to be able to build one of the example code on your on > > Thanks, iftah > > -----Original Message----- From: > discuss-gnuradio-bounces+g_iftah=yahoo....@gnu.org > [mailto:discuss-gnuradio-bounces+g_iftah=yahoo....@gnu.org] On > Behalf Of discuss-gnuradio-requ...@gnu.org Sent: Thursday, April > 17, 2014 7:01 PM To: discuss-gnuradio@gnu.org Subject: > Discuss-gnuradio Digest, Vol 137, Issue 17 > > Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio or, via > email, send a message with subject or body 'help' to > discuss-gnuradio-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@gnu.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > > 1. Re: "Error rate" block with USRP (Azza) 2. Re: "Error rate" > block with USRP (Tom Rondeau) 3. Re: "Error rate" block with USRP > (Azza) 4. Re: "Error rate" block with USRP (Azza) 5. ctest -V > segfault, coredump reveals nothing (kkarranc) 6. Re: ctest -V > segfault, coredump reveals nothing (Martin Braun) 7. Re: ctest -V > segfault, coredump reveals nothing (Kiran Karra) 8. Re: ctest -V > segfault, coredump reveals nothing (West, Nathan) 9. Re: ctest -V > segfault, coredump reveals nothing (Kiran Karra) 10. Digital voice > encryption block (Tigor Christian) 11. How to Access Received Data > for Use In Changing RX Parameters (Jonathan Fox) 12. Digital voice > encryption block (Tigor Christian) 13. Re: dvb-t project with two > USRPN200 devices failure (Nasi) 14. Digital voice encryption block > (Tigor Christian) 15. help on exception on using the uhd.dll i > think... (iftah giladi) 16. Re: help on exception on using the > uhd.dll i think... (Marcus M?ller) 17. Re: Digital voice encryption > block (Ralph A. Schmid, dk5ras) 18. Re: Digital voice encryption > block (Nowlan, Sean) 19. Re: Digital voice encryption block (Marcus > M?ller) 20. Re: "Error rate" block with USRP (Tom Rondeau) 21. > Developer Call today at 1700 UTC (Philip Balister) > > > ---------------------------------------------------------------------- > > Message: 1 Date: Wed, 16 Apr 2014 11:06:48 -0700 (PDT) From: Azza > <azza.ben.mos...@gmail.com> To: Discuss-gnuradio@gnu.org Subject: > Re: [Discuss-gnuradio] "Error rate" block with USRP Message-ID: > <1397671608491-47630.p...@n7.nabble.com> Content-Type: text/plain; > charset=us-ascii > > Tom Rondeau-2 wrote >> On Wed, Apr 16, 2014 at 10:57 AM, Azza < > >> azza.ben.mosbah@ > >> > wrote: >> >>> Thank you. I have taken out the throttle block and add an AGC >>> block at the receiver. To proceed with the synchronization, >>> should I use a Constellation Receiver block or a Polyphase >>> Clock Sync block ? >>> >>> Kind regards, Azza >>> >> >> >> You'll actually need both. AGC -> clock sync -> constellation >> receiver (phase/freq recovery and decoding). >> >> Also, please reply in-line with the rest of the message. By >> cutting off the other part of our conversation makes it difficult >> for others to follow the thread. >> >> Tom >> >> _______________________________________________ Discuss-gnuradio >> mailing list > >> Discuss-gnuradio@ > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > Thank you. I have added modifications to my flowgraph: > <http://gnuradio.4.n7.nabble.com/file/n47630/gnu-ber-modified.png> > But, I am still confused about minimum/maximum frequency deviation > in the Constellation Receiver block. How should it be set? > > Regards, Azza > > > > -- View this message in context: > http://gnuradio.4.n7.nabble.com/Error-rate-block-with-USRP-tp47625p47630.htm > > l > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 2 Date: Wed, 16 Apr 2014 14:54:28 -0400 From: Tom Rondeau > <t...@trondeau.com> To: Azza <azza.ben.mos...@gmail.com> Cc: > GNURadio Discussion List <Discuss-gnuradio@gnu.org> Subject: Re: > [Discuss-gnuradio] "Error rate" block with USRP Message-ID: > <CA+SzT6giaVFmZzfMJt7GCaRrXBYK=ngxose46l-zozvrmti...@mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > On Wed, Apr 16, 2014 at 2:06 PM, Azza <azza.ben.mos...@gmail.com> > wrote: > >> Tom Rondeau-2 wrote >>> On Wed, Apr 16, 2014 at 10:57 AM, Azza < >> >>> azza.ben.mosbah@ >> >>> > wrote: >>> >>>> Thank you. I have taken out the throttle block and add an AGC >>>> block at the >> receiver. >>>> To proceed with the synchronization, should I use a >>>> Constellation Receiver block or a Polyphase Clock Sync block >>>> ? >>>> >>>> Kind regards, Azza >>>> >>> >>> >>> You'll actually need both. AGC -> clock sync -> constellation >>> receiver (phase/freq recovery and decoding). >>> >>> Also, please reply in-line with the rest of the message. By >>> cutting off the other part of our conversation makes it >>> difficult for others to follow >> the >>> thread. >>> >>> Tom >> >> Thank you. I have added modifications to my flowgraph: >> <http://gnuradio.4.n7.nabble.com/file/n47630/gnu-ber-modified.png> >> >> But, I am still confused about minimum/maximum frequency deviation in the >> Constellation Receiver block. How should it be set? >> >> Regards, Azza >> > > Those are settings to keep the frequency sync from walking away, > in normalized frequency. +1 and -1 should work fine. > > Tom -------------- next part -------------- An HTML attachment was > scrubbed... URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140416/29f > > 313a5/attachment.html> > > ------------------------------ > > Message: 3 Date: Wed, 16 Apr 2014 12:37:52 -0700 (PDT) From: Azza > <azza.ben.mos...@gmail.com> To: Discuss-gnuradio@gnu.org Subject: > Re: [Discuss-gnuradio] "Error rate" block with USRP Message-ID: > <1397677072504-47632.p...@n7.nabble.com> Content-Type: text/plain; > charset=us-ascii > > Tom Rondeau-2 wrote >> On Wed, Apr 16, 2014 at 2:06 PM, Azza < > >> azza.ben.mosbah@ > >> > wrote: >> >>> Tom Rondeau-2 wrote >>>> On Wed, Apr 16, 2014 at 10:57 AM, Azza < >>> >>>> azza.ben.mosbah@ >>> >>>> > wrote: >>>> >>>>> Thank you. I have taken out the throttle block and add an >>>>> AGC block at the >>> receiver. >>>>> To proceed with the synchronization, should I use a >>>>> Constellation Receiver block or a Polyphase Clock Sync >>>>> block ? >>>>> >>>>> Kind regards, Azza >>>>> >>>> >>>> >>>> You'll actually need both. AGC -> clock sync -> constellation >>>> receiver (phase/freq recovery and decoding). >>>> >>>> Also, please reply in-line with the rest of the message. By >>>> cutting off the other part of our conversation makes it >>>> difficult for others to follow >>> the >>>> thread. >>>> >>>> Tom >>> >>> Thank you. I have added modifications to my flowgraph: >>> <http://gnuradio.4.n7.nabble.com/file/n47630/gnu-ber-modified.png> >>> >>> But, I am still confused about minimum/maximum frequency deviation in the >>> Constellation Receiver block. How should it be set? >>> >>> Regards, Azza >>> >> >> Those are settings to keep the frequency sync from walking away, >> in normalized frequency. +1 and -1 should work fine. >> >> Tom >> >> >> Tom, >> >> I still found BER=0.5, however the error output of the >> Constellation Receiver block gives 0. >> >> Regards, Azza _______________________________________________ >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@ > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > -- View this message in context: > http://gnuradio.4.n7.nabble.com/Error-rate-block-with-USRP-tp47625p47632.htm > > l > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 4 Date: Wed, 16 Apr 2014 12:38:54 -0700 (PDT) From: Azza > <azza.ben.mos...@gmail.com> To: Discuss-gnuradio@gnu.org Subject: > Re: [Discuss-gnuradio] "Error rate" block with USRP Message-ID: > <1397677134148-47634.p...@n7.nabble.com> Content-Type: text/plain; > charset=us-ascii > > Tom Rondeau-2 wrote >> On Wed, Apr 16, 2014 at 2:06 PM, Azza < > >> azza.ben.mosbah@ > >> > wrote: >> >>> Tom Rondeau-2 wrote >>>> On Wed, Apr 16, 2014 at 10:57 AM, Azza < >>> >>>> azza.ben.mosbah@ >>> >>>> > wrote: >>>> >>>>> Thank you. I have taken out the throttle block and add an >>>>> AGC block at the >>> receiver. >>>>> To proceed with the synchronization, should I use a >>>>> Constellation Receiver block or a Polyphase Clock Sync >>>>> block ? >>>>> >>>>> Kind regards, Azza >>>>> >>>> >>>> >>>> You'll actually need both. AGC -> clock sync -> constellation >>>> receiver (phase/freq recovery and decoding). >>>> >>>> Also, please reply in-line with the rest of the message. By >>>> cutting off the other part of our conversation makes it >>>> difficult for others to follow >>> the >>>> thread. >>>> >>>> Tom >>> >>> Thank you. I have added modifications to my flowgraph: >>> <http://gnuradio.4.n7.nabble.com/file/n47630/gnu-ber-modified.png> >>> >>> But, I am still confused about minimum/maximum frequency deviation in the >>> Constellation Receiver block. How should it be set? >>> >>> Regards, Azza >>> >> >> Those are settings to keep the frequency sync from walking away, >> in normalized frequency. +1 and -1 should work fine. >> >> Tom >> >> _______________________________________________ Discuss-gnuradio >> mailing list > >> Discuss-gnuradio@ > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > Tom, > > I still found BER=0.5, however the error output of the > Constellation Receiver block gives 0. > > Regards, Azza > > > > -- View this message in context: > http://gnuradio.4.n7.nabble.com/Error-rate-block-with-USRP-tp47625p47634.htm > > l > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 5 Date: Wed, 16 Apr 2014 13:27:34 -0700 (PDT) From: > kkarranc <kkarr...@vt.edu> To: Discuss-gnuradio@gnu.org Subject: > [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing > Message-ID: <1397680054634-47635.p...@n7.nabble.com> Content-Type: > text/plain; charset=us-ascii > > Hi All, I have a gnuradio block which I am testing through a C++ QA > function. I call the handler function directly in C++ QA test > function, and everything runs. > > My test function is structured as follows: - I create a pointer to > the object I want to create by using the make function, which > returns a boost::shared_ptr to the object. - I then do > obj-->handler() to run all the tests and they pass fine (The reason > this is a handler and not a standard work() function is because > this block is based on gr-eventstream and it is a subclass of the > es_trigger block). - At the end, I can see that the destructor to > my object is being called and that completes nicely. However, > after desctruction of my object, I get a segfault from ctest (I am > running the test through ctest -V to see what is going on instead > of make test). > > I suspect what is going on is something w/ the boost::shared_ptr > but I don't know what exactly. > > I created a core dump through the usual methods and I can't get it > to output anything useful to help me debug the problem. Here is > the output of "i stack" > > Core was generated by `test-wifi_detector'. Program terminated with > signal 11, Segmentation fault. #0 0x0000000000000031 in ?? () > (gdb) i stack #0 0x0000000000000031 in ?? () #1 > 0x00007f6a7b3ae11e in ?? () #2 0x00007fff8cea6d10 in ?? () #3 > 0x0000000002261ab0 in ?? () #4 0x00007fff8cea6cf0 in ?? () #5 > 0x00007f6a7b3b178e in ?? () #6 0x00007fff8cea7540 in ?? () #7 > 0x00000000022612b0 in ?? () #8 0x00007fff8cea6d10 in ?? () #9 > 0x00007f6a7b3a1072 in ?? () #10 0x0000000100000000 in ?? () #11 > 0x00000000022612b0 in ?? () #12 0x00007fff8cea6d30 in ?? () #13 > 0x00007f6a7b3a1101 in ?? () #14 0x00007fff8cea6d40 in ?? () #15 > 0x000000000226ffa0 in ?? () #16 0x00007fff8cea6d50 in ?? () #17 > 0x00007f6a7b3aa090 in ?? () #18 0x00007fff8cea7120 in ?? () #19 > 0x000000000226ff98 in ?? () #20 0x00007fff8cea6d70 in ?? () #21 > 0x00007f6a7b3ace28 in ?? () #22 0x000000000224ba88 in ?? () #23 > 0x000000000226ff90 in ?? () #24 0x00007fff8cea6d90 in ?? () #25 > 0x00007f6a7b3afc9a in ?? () #26 0x000000000226ff90 in ?? () #27 > 0x00007fff8cea6dbf in ?? () #28 0x00007fff8cea6dd0 in ?? () #29 > 0x00007f6a7b3aea96 in ?? () #30 0x000000000226ff70 in ?? () #31 > 0x000000000224ba88 in ?? () #32 0x0000000000000000 in ?? () > > I tried rebuilding with the debug flags enabled during compile by > doing this: cmake -DCMAKE_BUILD_TYPE=Debug ../ && make clean && > make && make install && ctest -V but I still get question marks. > As for the executable I am passing into gdb, I tried: > "test-wifi_detector /bin/bash and ctest) > > Does anybody have any ideas as to how I can proceed to figure out > what is going on? I am pretty convinced that the block itself is > not segfaulting because the destructor gets called and that gets > cleaned up. Another reason why I think the block is OK is because > when I run it in a grc flowgraph, it works fine ... its just in > test mode that this happens. Another reason why I think this is > something with boost::shared_ptr is, in my unittest function in > C++, if i call sptr.reset(), it segfaults right there (I've > verified the only way I know how, which is with print statements > before and after). > > Thanks, Kiran > > > > -- View this message in context: > http://gnuradio.4.n7.nabble.com/ctest-V-segfault-coredump-reveals-nothing-tp > > 47635.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 6 Date: Wed, 16 Apr 2014 23:59:17 +0200 From: Martin Braun > <martin.br...@ettus.com> To: discuss-gnuradio@gnu.org Subject: Re: > [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing > Message-ID: <534efd35.7060...@ettus.com> Content-Type: text/plain; > charset=ISO-8859-1 > > On 04/16/2014 10:27 PM, kkarranc wrote: >> Hi All, I have a gnuradio block which I am testing through a C++ >> QA function. I call the handler function directly in C++ QA test >> function, and everything runs. > > Any chance you can share the code? > >> Does anybody have any ideas as to how I can proceed to figure out >> what is going on? I am pretty convinced that the block itself is >> not segfaulting because the destructor gets called and that gets >> cleaned up. Another > reason >> why I think the block is OK is because when I run it in a grc >> flowgraph, > it >> works fine ... its just in test mode that this happens. Another >> reason > why >> I think this is something with boost::shared_ptr is, in my >> unittest > function >> in C++, if i call sptr.reset(), it segfaults right there (I've >> verified > the >> only way I know how, which is with print statements before and >> after). > > Try and remove the .xml-file output from the test and run again. > Maybe it's a problem of persistence? > > M > > > > ------------------------------ > > Message: 7 Date: Wed, 16 Apr 2014 19:21:50 -0400 From: Kiran Karra > <kkarr...@vt.edu> To: discuss-gnuradio@gnu.org Subject: Re: > [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing > Message-ID: <534f108e.3050...@vt.edu> Content-Type: text/plain; > charset="iso-8859-1"; Format="flowed" > >>> Any chance you can share the code? > > I will try to get some approval here to release, however it may be > a bit of time before I am allowed to do that unfortunately. > >>> Try and remove the .xml-file output from the test and run >>> again. Maybe > it's a problem of persistence? > > I tried this just now, still seg faulting but thanks for the > suggestion. > > Any ideas as to why I can't see a stacktrace in GDB even though I > rebuilt the code with debug symbols? That seems strange to me. > Tim suggested that perhaps this is due to ctest swallowing the > segfault as a fail in the test ... and I think that is actually > what is happening, because I see ctest move onto the next test. I > looked at ctest help but didn't find a way for it to not swallow > the segfaults... does anybody have any ideas here? > > Thanks again, Kiran > > > -------------- next part -------------- A non-text attachment was > scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: > 2366 bytes Desc: S/MIME Cryptographic Signature URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140416/e37 > > d3ccb/attachment.bin> > > ------------------------------ > > Message: 8 Date: Wed, 16 Apr 2014 20:49:55 -0500 From: "West, > Nathan" <n...@ostatemail.okstate.edu> To: Kiran Karra > <kkarr...@vt.edu> Cc: "discuss-gnuradio@gnu.org" > <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] ctest -V > segfault, coredump reveals nothing Message-ID: > <calkxil+aeacre61ptpeuxrvh31unacg0cyzcr0rw8oagtx_...@mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Apr 16, 2014 at 6:21 PM, Kiran Karra <kkarr...@vt.edu> > wrote: >>>> Any chance you can share the code? >> >> >> I will try to get some approval here to release, however it may >> be a bit > of >> time before I am allowed to do that unfortunately. >> >> >>>> Try and remove the .xml-file output from the test and run >>>> again. Maybe >> >> it's a problem of persistence? >> >> I tried this just now, still seg faulting but thanks for the >> suggestion. >> >> Any ideas as to why I can't see a stacktrace in GDB even though I >> rebuilt the code with debug symbols? That seems strange to me. >> Tim suggested > that >> perhaps this is due to ctest swallowing the segfault as a fail in >> the test ... and I think that is actually what is happening, >> because I see ctest > move >> onto the next test. I looked at ctest help but didn't find a way >> for it > to >> not swallow the segfaults... does anybody have any ideas here? >> >> Thanks again, Kiran > > Sounds plausible. Ctest is actually just running a shell script. > You can try running that script through gdb. The name of the script > will be printed near the top of ctest -V. Alternatively you should > be able to find it in > $build/modname/python/namespace/qa_whatever_your_test_is_called.sh; > > an example for gr-digital: > build/gr-digital/python/digital/qa_mpsk_snr_est_test.sh > > Nathan > > > > ------------------------------ > > Message: 9 Date: Thu, 17 Apr 2014 08:48:50 -0400 From: Kiran Karra > <kkarr...@vt.edu> To: discuss-gnuradio@gnu.org Subject: Re: > [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing > Message-ID: <534fcdb2.9010...@vt.edu> Content-Type: text/plain; > charset="iso-8859-1"; Format="flowed" > >>>> Sounds plausible. Ctest is actually just running a shell >>>> script. > You can try running that script through gdb. The name of the script > will be printed near the top of ctest -V. Alternatively you should > be able to find it in > $build/modname/python/namespace/qa_whatever_your_test_is_called.sh; > an example for gr-digital: > build/gr-digital/python/digital/qa_mpsk_snr_est_test.sh > >>>>> Nathan, great call. Running the script without the ctest > infrastructure yielded a valid stacktrace. I found that it was > related to the way I was creating my fft engines. Instead of > instantiating an FFT directly, I was creating it w/ a > *managed_resource_pool_nofactory*. I haven't investigated fully why > this is causing my program to segfault, but as a quick test I > replaced the way I was creating the fft with just this line: > *fft::fft_complex fft = fft::fft_complex(fftSize);* and am not > getting the segfaults anymore. I'll have to do some debugging to > figure out why this is going on, but atleast I know where to start > now. For those that are curious, the backtrace looks like this: > > Program terminated with signal 11, Segmentation fault. #0 > 0x0000000000000031 in ?? () (gdb) backtrace #0 0x0000000000000031 > in ?? () #1 0x00007f0317592c70 in > boost::checked_delete<gr::fft::fft_complex> (x=0xb07430) at > /usr/include/boost/checked_delete.hpp:34 #2 0x00007f03175974c0 in > boost::detail::sp_counted_impl_p<gr::fft::fft_complex>::dispose > (this=0xb065d0) at > /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #3 > 0x00007f0317585e02 in boost::detail::sp_counted_base::release > (this=0xb065d0) at > /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146 > > #4 0x00007f0317585e91 in boost::detail::shared_count::~shared_count > (this=0xadb240, __in_chrg=<optimized out>) at > /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #5 > 0x00007f031759023c in > boost::shared_ptr<gr::fft::fft_complex>::~shared_ptr > (this=0xadb238, __in_chrg=<optimized out>) at > /usr/include/boost/smart_ptr/shared_ptr.hpp:328 #6 > 0x00007f0317593da8 in std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> >::~pair (this=0xadb230, > __in_chrg=<optimized out>) at > /usr/include/c++/4.8/bits/stl_pair.h:96 #7 0x00007f0317596378 in > __gnu_cxx::new_allocator<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > >::destroy > (this=0x7fff820439ef, __p=0xadb230) at > /usr/include/c++/4.8/ext/new_allocator.h:133 #8 0x00007f0317595742 > in std::_Rb_tree<gr::fft::fft_complex*, > std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> >, > std::_Select1st<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > >, > std::less<gr::fft::fft_complex*>, > std::allocator<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > > >::_M_destroy_node > (this=0xaca178, __p=0xadb210) at > /usr/include/c++/4.8/bits/stl_tree.h:395 #9 0x00007f031759478f in > std::_Rb_tree<gr::fft::fft_complex*, > std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> >, > std::_Select1st<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > >, > std::less<gr::fft::fft_complex*>, > std::allocator<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > > >::_M_erase > (this=0xaca178, __x=0xadb210) at > /usr/include/c++/4.8/bits/stl_tree.h:1127 #10 0x00007f0317593c57 in > std::_Rb_tree<gr::fft::fft_complex*, > std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> >, > std::_Select1st<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > >, > std::less<gr::fft::fft_complex*>, > std::allocator<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > > >::~_Rb_tree > (this=0xaca178, __in_chrg=<optimized out>) at > /usr/include/c++/4.8/bits/stl_tree.h:671 #11 0x00007f0317593176 in > std::map<gr::fft::fft_complex*, > boost::shared_ptr<gr::fft::fft_complex>, > std::less<gr::fft::fft_complex*>, > std::allocator<std::pair<gr::fft::fft_complex* const, > boost::shared_ptr<gr::fft::fft_complex> > > >::~map (this=0xaca178, > __in_chrg=<optimized out>) at > /usr/include/c++/4.8/bits/stl_map.h:96 #12 0x00007f03175957e9 in > pooled_resource<gr::fft::fft_complex>::~pooled_resource > (this=0xaca130, __in_chrg=<optimized out>) at > /home/kiran/awst/gnuradio/include/es/pooled_resource.h:20 #13 > 0x00007f0317595836 in > boost::checked_delete<pooled_resource<gr::fft::fft_complex> > > (x=0xaca130) at /usr/include/boost/checked_delete.hpp:34 #14 > 0x00007f031759747e in > boost::detail::sp_counted_impl_p<pooled_resource<gr::fft::fft_complex> > >> ::dispose (this=0xaca2e0) at > /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #15 > 0x00007f0317585e02 in boost::detail::sp_counted_base::release > (this=0xaca2e0) at > /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146 > > #16 0x00007f0317585e91 in boost::detail::shared_count::~shared_count > (this=0xadb1a0, __in_chrg=<optimized out>) at > /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #17 > 0x00007f0317591d0a in > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >::~shared_ptr (this=0xadb198, __in_chrg=<optimized out>) at > /usr/include/boost/smart_ptr/shared_ptr.hpp:328 #18 > 0x00007f0317591d28 in std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >::~pair > (this=0xadb190, __in_chrg=<optimized out>) at > /usr/include/c++/4.8/bits/stl_pair.h:96 #19 0x00007f0317591d46 in > __gnu_cxx::new_allocator<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >::destroy (this=0x7fff82043bcf, __p=0xadb190) at > /usr/include/c++/4.8/ext/new_allocator.h:133 #20 0x00007f03175912dc > in std::_Rb_tree<int, std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, > std::_Select1st<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, > std::less<int>, std::allocator<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >> ::_M_destroy_node (this=0xac91c8, > __p=0xadb170) at /usr/include/c++/4.8/bits/stl_tree.h:395 #21 > 0x00007f03175905a7 in std::_Rb_tree<int, std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, > std::_Select1st<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, > std::less<int>, std::allocator<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >> ::_M_erase (this=0xac91c8, > __x=0xadb170) at /usr/include/c++/4.8/bits/stl_tree.h:1127 #22 > 0x00007f0317590584 in std::_Rb_tree<int, std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, > std::_Select1st<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, > std::less<int>, std::allocator<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >> ::_M_erase (this=0xac91c8, > __x=0xac9b80) at /usr/include/c++/4.8/bits/stl_tree.h:1125 #23 > 0x00007f031758fa95 in std::_Rb_tree<int, std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > >, > std::_Select1st<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > >, > std::less<int>, std::allocator<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > >> ::~_Rb_tree (this=0xac91c8, > __in_chrg=<optimized out>) at > /usr/include/c++/4.8/bits/stl_tree.h:671 #24 0x00007f031758f248 in > std::map<int, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> >, > std::less<int>, std::allocator<std::pair<int const, > boost::shared_ptr<pooled_resource<gr::fft::fft_complex> > > > > >::~map (this=0xac91c8, __in_chrg=<optimized out>) at > /usr/include/c++/4.8/bits/stl_map.h:96 #25 0x00007f031758f277 in > managed_resource_pool<gr::fft::fft_complex, > int>::~managed_resource_pool (this=0xac91a8, __in_chrg=<optimized > out>) at /home/kiran/awst/gnuradio/include/es/pooled_resource.h:58 > #26 0x00007f031758f2be in > managed_resource_pool_nofactory<gr::fft::fft_complex, > int>::~managed_resource_pool_nofactory (this=0xac91a8, > __in_chrg=<optimized out>) at > /home/kiran/awst/gnuradio/include/es/pooled_resource.h:115 #27 > 0x00007f0317598109 in > gr::wifi_detector::es_80211b_chip_and_freq_sync_c_impl::~es_80211b_chip_and_ > > freq_sync_c_impl > (this=0xac91a0, __in_chrg=<optimized out>, __vtt_parm=<optimized > out>) ---Type <return> to continue, or q <return> to quit--- at > /home/kiran/awst/pybombs/src/gr-ieee-80211b/lib/es_80211b_chip_and_freq_sync > > _c_impl.cc:73 > #28 0x00007f03175981c2 in > gr::wifi_detector::es_80211b_chip_and_freq_sync_c_impl::~es_80211b_chip_and_ > > freq_sync_c_impl > (this=0xac91a0, __in_chrg=<optimized out>, __vtt_parm=<optimized > out>) at > /home/kiran/awst/pybombs/src/gr-ieee-80211b/lib/es_80211b_chip_and_freq_sync > > _c_impl.cc:75 > #29 0x0000000000418a04 in boost::detail::sp_counted_base::release > (this=0xb04e10) at > /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146 > > #30 0x0000000000418a93 in boost::detail::shared_count::~shared_count > (this=0x7fff820441c8, __in_chrg=<optimized out>) at > /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #31 > 0x0000000000426a74 in > boost::shared_ptr<gr::wifi_detector::es_80211b_chip_and_freq_sync_c>::~share > > d_ptr > (this=0x7fff820441c0, __in_chrg=<optimized out>) at > /usr/include/boost/smart_ptr/shared_ptr.hpp:328 #32 > 0x0000000000425b38 in > gr::wifi_detector::qa_es_80211b_chip_and_freq_sync::t1 > (this=0xac8be0) at > /home/kiran/awst/pybombs/src/gr-ieee-80211b/lib/qa_es_80211b_chip_and_freq_s > > ync.cc:57 > #33 0x000000000041681c in > CppUnit::TestCaller<gr::wifi_detector::qa_es_80211b_chip_and_freq_sync>::run > > Test > (this=0xac8e50) at /usr/include/cppunit/TestCaller.h:166 > -------------- next part -------------- An HTML attachment was > scrubbed... URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/989 > > fc505/attachment.html> > -------------- next part -------------- A non-text attachment was > scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: > 2366 bytes Desc: S/MIME Cryptographic Signature URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/989 > > fc505/attachment.bin> > > ------------------------------ > > Message: 10 Date: Thu, 17 Apr 2014 21:50:00 +0800 (SGT) From: Tigor > Christian <christian.ti...@rocketmail.com> To: > "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: > [Discuss-gnuradio] Digital voice encryption block Message-ID: > <1397742600.33022.yahoomail...@web192403.mail.sg3.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > I want to simulate a voice transmission system in GNURadio > Companion (GRC) before I build a real one. My system configuration > is as follows. > > TX: mic --> encoder --> encryption --> modulator --> RF > > Rx: speaker <-- decoder <-- decryption <-- demodulator <-- RF > > I have succeed in simulating the above configuration in Ubuntu > 12.04 LTS machinebut without encryption/decryption blocks. > > I want to encrypt my digital voice using AES (128/192/256, either > one) algorithm, but so far, I couldn't find suitable blocks for my > purpose. > > I know that GNURadio will synthesize a python code when you compile > your blocks configuration in GRC. On the other hand, every python > dev installation in Ubuntu will also install PyCrypto lib in your > machine, this library has a ready-to-use function of AES algorithm. > Furthermore, I also know the concept of Out-of-Tree Module (OoTM) > of GNURadio. > > My questions are: > > 1. My first thought is to get data stream of certain block and do > encryption process with PyCrypto (not in the OoTM, but directly in > synthesized python code) then put them back to the next block. > Would it be possible and how to achieve this? > > 2. Do GNURadio has a ready-to-use GRC blocks or OoTM of digital > encryption algorithm (not scrambler)? and how do I get it (a > tutorial would be fine)? So far, I can not found the block either > in GRC or https://www.cgran.org > > 3. Last question may be off topic a bit. Is it common to use AES > algorithm to encrypt voice data, or is there any common encryption > method (preferably could be implemented in GRC)? > > Thank you for your time and willingness to answer these questions > > Regards tc -------------- next part -------------- An HTML > attachment was scrubbed... URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/91c > > 70bc9/attachment.html> > > ------------------------------ > > Message: 11 Date: Thu, 17 Apr 2014 09:50:21 -0400 From: Jonathan > Fox <31...@cardinalmail.cua.edu> To: GNURadio Discussion List > <discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] How to > Access Received Data for Use In Changing RX Parameters Message-ID: > <capzrquz9qgjs+0-rgk5weojfp+wubozj_yks2sedi6r5ldv...@mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > Hey List, > > I have two scripts I am running, the ofdm_v1_tx_freq_test.py and > the RX version of it (see flow graph images and attached > transmitter Python script). I am transmitting a sinusoid using OFDM > modulation over the USRP, it works perfectly. > > I have made an alteration to the transmitter script by adding a > frequency change function that goes off every 2.5 seconds. The > frequency will inclemently go up 1 MHz 20 times before going back > to the default. That code works; what I want to do now is to cease > the sinusoid broadcast at every 2.5 seconds so I can transmit the > new frequency to the receiver right before I change it. I think I > can figure that part out, I may just use another vector source with > the new frequency and have transmit five times. Probably use > another flow graph to implement it. If there is a better way to do, > I am open for ideas. > > Now for my question: after receiving this new frequency on the RX > side, how do I get my script to read this data and use it to change > frequencies? I have a feeling that this may be simple to do but I > am at a loss in figuring it out. > > Please note, this is more of a proof of concept work, so there is a > reason why I do not have identical frequency change functions in > both TX and RX, the goal down the road is to get some DSA > capabilities. > > Thanks, > > Jon -------------- next part -------------- An HTML attachment was > scrubbed... URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/453 > > 1a532/attachment.html> > -------------- next part -------------- #!/usr/bin/env python > ################################################## # Gnuradio > Python Flow Graph # Title: OFDM Transmitter # Generated: Mon Mar 31 > 09:59:15 2014 ################################################## > > from gnuradio import blocks from gnuradio import digital from > gnuradio import eng_notation from gnuradio import gr from gnuradio > import uhd from gnuradio.digital.utils import tagged_streams from > gnuradio.eng_option import eng_option from gnuradio.gr import > firdes from grc_gnuradio import wxgui as grc_wxgui from optparse > import OptionParser import ConfigParser import numpy import time > import wx > > class ofdm_v1_tx_freq_test(grc_wxgui.top_block_gui): > > def __init__(self): grc_wxgui.top_block_gui.__init__(self, > title="OFDM Transmitter") > > ################################################## # Variables > ################################################## self.tx_signal = > tx_signal = [numpy.sin(2 * numpy.pi * 1.0/8 * x) for x in > range(8*2)] self._tx_ip_config = ConfigParser.ConfigParser() > self._tx_ip_config.read("default") try: tx_ip = > self._tx_ip_config.get("main", "key") except: tx_ip = > "addr=10.2.8.104" self.tx_ip = tx_ip self.samp_rate = samp_rate = > 100e3 self.len_tag_key = len_tag_key = "packet_len" self.freq = > freq = 500e6 self.fft_len = fft_len = 64 > > ################################################## # Blocks > ################################################## > self.uhd_usrp_sink_0 = uhd.usrp_sink( > device_addr="addr=10.2.8.104", stream_args=uhd.stream_args( > cpu_format="fc32", channels=range(1), ), ) > self.uhd_usrp_sink_0.set_samp_rate(samp_rate) > self.uhd_usrp_sink_0.set_center_freq(freq, 0) > self.uhd_usrp_sink_0.set_gain(20, 0) self.digital_ofdm_tx_0 = > digital.ofdm_tx( fft_len=fft_len, cp_len=fft_len/4, > packet_length_tag_key=len_tag_key, bps_header=1, bps_payload=1, > rolloff=0, debug_log=False ) self.blocks_vector_to_stream_0 = > blocks.vector_to_stream(gr.sizeof_char*1, 4) > self.blocks_vector_source_x_0 = blocks.vector_source_f(tx_signal, > True, 1, tagged_streams.make_lengthtags((8*2*gr.sizeof_float,), > (0,), tagname=len_tag_key)) self.blocks_multiply_const_vxx_0 = > blocks.multiply_const_vcc((0.05, )) > > ################################################## # Connections > ################################################## > self.connect((self.blocks_vector_source_x_0, 0), > (self.blocks_vector_to_stream_0, 0)) > self.connect((self.blocks_vector_to_stream_0, 0), > (self.digital_ofdm_tx_0, 0)) self.connect((self.digital_ofdm_tx_0, > 0), (self.blocks_multiply_const_vxx_0, 0)) > self.connect((self.blocks_multiply_const_vxx_0, 0), > (self.uhd_usrp_sink_0, 0)) > > > def get_tx_signal(self): return self.tx_signal > > def set_tx_signal(self, tx_signal): self.tx_signal = tx_signal > > def get_tx_ip(self): return self.tx_ip > > def set_tx_ip(self, tx_ip): self.tx_ip = tx_ip > > def get_samp_rate(self): return self.samp_rate > > def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate > self.uhd_usrp_sink_0.set_samp_rate(self.samp_rate) > > def get_len_tag_key(self): return self.len_tag_key > > def set_len_tag_key(self, len_tag_key): self.len_tag_key = > len_tag_key > > def get_freq(self): return self.freq > > def set_freq(self, freq): self.freq = freq > self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) > > def get_fft_len(self): return self.fft_len > > def set_fft_len(self, fft_len): self.fft_len = fft_len > > def incr_new_freq(self): self.freq = self.freq + 1e6 # return > self.freq self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) > > def decr_new_freq(self): self.freq = 500e6 return self.freq > > def main(tb): i = 0 while 1: print "Current Frequency: %0.1f" % > (tb.freq) time.sleep(2.5) if i == 20: tb.decr_new_freq() i = 0 > else: tb.incr_new_freq() i += 1 > > if __name__ == '__main__': parser = > OptionParser(option_class=eng_option, usage="%prog: [options]") > (options, args) = parser.parse_args() tb = ofdm_v1_tx_freq_test() > tb.Run(True) main(tb) -------------- next part -------------- A > non-text attachment was scrubbed... Name: ofdm_v1_rx.png Type: > image/png Size: 72660 bytes Desc: not available URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/453 > > 1a532/attachment.png> > -------------- next part -------------- A non-text attachment was > scrubbed... Name: ofdm_v1_tx.png Type: image/png Size: 58193 bytes > Desc: not available URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/453 > > 1a532/attachment-0001.png> > > ------------------------------ > > Message: 12 Date: Thu, 17 Apr 2014 22:02:35 +0800 (SGT) From: Tigor > Christian <christian.ti...@rocketmail.com> To: > "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: > [Discuss-gnuradio] Digital voice encryption block Message-ID: > <1397743355.69162.yahoomail...@web192405.mail.sg3.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > I want to simulate a voice transmission system in GNURadio > Companion (GRC) before I build a real one. My system configuration > is as follows. > > TX: mic --> encoder --> encryption --> modulator --> RF > > Rx: speaker <-- decoder <-- decryption <-- demodulator <-- RF > > I have succeed in simulating the above configuration in Ubuntu > 12.04 LTS machine but without encryption/decryption blocks. > > I want to encrypt my digital voice using AES (128/192/256, either > one) algorithm, but so far, I couldn't find suitable blocks for my > purpose. > > I know that GNURadio will synthesize a python code when you compile > your blocks configuration in GRC. On the other hand, every python > dev installation in Ubuntu will also install PyCrypto lib in your > machine, this library has a ready-to-use function of AES algorithm. > Furthermore, I also know the concept of Out-of-Tree Module (OoTM) > of GNURadio. > > My questions are: > > 1. My first thought is to get data stream of certain block and do > encryption process with PyCrypto (not in the OoTM, but directly in > synthesized python code) then put them back to the next block. > Would it be possible and how to achieve this? > > 2. Do GNURadio has a ready-to-use GRC blocks or OoTM of digital > encryption algorithm (not scrambler)? and how do I get it (a > tutorial would be fine)? So far, I can not found the block either > in GRC or https://www.cgran.org > > 3. Last question may be off topic a bit. Is it common to use AES > algorithm to encrypt voice data, or is there any common encryption > method (preferably could be implemented in GRC)? > > Thank you for your time and willingness to answer these questions > > Regards tc -------------- next part -------------- An HTML > attachment was scrubbed... URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/b69 > > 9b13c/attachment.html> > > ------------------------------ > > Message: 13 Date: Thu, 17 Apr 2014 18:07:36 +0400 From: Nasi > <nesaz...@mail.ru> To: Marcus M?ller <mar...@hostalia.de>, Bogdan > Diaconescu <b_diacone...@yahoo.com> Cc: discuss-gnuradio@gnu.org > <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] dvb-t > project with two USRPN200 devices failure Message-ID: > <1397743656.520220...@f304.i.mail.ru> Content-Type: text/plain; > charset="utf-8" > > Can I trans/receive without Rational Resampler? It distorts the > signal too much :( > > > Mon, 31 Mar 2014 20:12:27 +0400 ?? Nasi <nesaz...@mail.ru>: >> Thanks a lot! I will try them too... >> >> >> Mon, 31 Mar 2014 09:08:04 -0700 (PDT) ?? Bogdan Diaconescu > <b_diacone...@yahoo.com>: >>> >>> One thing I did once and worked are: >>> >>> 1. Use a file sink instead of USRP when transmitting. Then, >>> once the file > is generated send the samples from file (opened in a file source) > directly to USRP. That will need a good harddrive with at least > 80MB/s read speed, a SSD will work probably. >>> >>> 2. Do the above but write the file int RAM like dd >>> if=yourfile.bin > of=/dev/ram0 - you may need to give root access. Then open > /dev/ram0 in a file source and send it to USRP. This will consume > you RAM and will potentiall lock your laptop if the .bin file is > bigger than RAM size. >>> >>> But, indeed you probably need a better computer. >>> >>> Bogdan >>> >>> >>> >>> On Monday, March 31, 2014 6:59 PM, Marcus M?ller >>> <mar...@hostalia.de> > wrote: I'm afraid you can't reduce needed sample rate for a fixed > bandwidth. > > You need a stronger laptop. Often, plugging it into mains power > helps. > > Marcus > > On 31.03.2014 17:52, Nasi wrote: >>>>> ohhh, now I understand. It produces UUUU in the transmitter >>>>> side - which probably means underflow with my laptop. Do >>>>> you know how to decrease this power? >>>>> >>>>> >>>>> >>>>> Mon, 31 Mar 2014 08:44:49 -0700 (PDT) ?? Bogdan Diaconescu >>>>> < b_diacone...@yahoo.com >: >>>>>> For dvbt the bandwidth is around 9.14Msps so with the >>>>>> rational resampler you need to set-up the USRP at 10Msps. >>>>>> 1Msps will not work as only a part of the spectrum will >>>>>> be received. >>>>>> >>>>>> Bogdan >>>>>> >>>>>> >>>>>> On Monday, March 31, 2014 6:36 PM, Nasi < >>>>>> nesaz...@mail.ru > wrote: Hi, >>>>>> >>>>>> Thanks! >>>>>> >>>>>> I am using collected data also as >>>>> you say. >>>>>> I am using sampling rate of 1 Mbps instead of 10 Mbps >>>>>> which must be the same for static transmission. Isn't >>>>>> it? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Mon, 31 Mar 2014 08:23:01 -0700 (PDT) ?? Bogdan >>>>>> Diaconescu < b_diacone...@yahoo.com >: Hi, not having >>>>>> access to my setup for now but for the beginning you >>>>>> could try recording the spectrum with your USRP and then >>>>>> use the file source to decode the signal offline. There >>>>>> is a script file apps/capture.sh that I usually use to >>>>>> capture data. You may tweak it for your >> needs (frequency, >>>>>> gain). >>>>>> >>>>>> Sometimes it was reported that on old cpus the processing >>>>>> power is not enough so that the result is an overflow >>>>>> (you directly see a long OOO message in this case). Try >>>>>> to see if this is the case. >>>>>> >>>>>> One way to reduce the overhead is to run the receiving >>>>>> flow directly from command >>>>> line instead of gnuradio-companion (e.g. ./top_block > >>>>> out.txt) after you have generated the flowgraph. The >>>>> gnuradio-companion cannot cope with big amount of data when >>>>> the blocks gets out a lot of text. >>>>>> >>>>>> Bogdan >>>>>> >>>>>> >>>>>> On Monday, >> March 31, 2014 1:22 PM, Nasi < nesaz...@mail.ru > >>>>>> wrote: Hi all, >>>>>> >>>>>> I am using ubuntu 13.04, GNURADIO 3.7. I cannot transmit >>>>>> or receive using two (USRPN200 + XCRV2450 >>>>>> d.board+VERT2450 antennas) devices for DVB-T project. >>>>>> Here is the dvb-t project: >>>>>> https://github.com/BogdanDIA/gr-dvbt >>>>>> >>>>>> It will be very helpful and appreciated if you help me. >>>>>> If someone tested it or can do it, please let me know. As >>>>>> far as I know someone tested it with N210 model. >>>>>> >>>>>> I think this failure is due to high >> noise/interference or smt. >>>>>> else. However I tested it already with all possible >>>>>> configurations. I also attach my .grc files. >>>>>> >>>>>> >>>>>> -- NE _______________________________________________ >>>>>> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- NE >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> _______________________________________________ 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 >>> >> >> >> -- NE > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUAGvAAoJEBQ6EdjyzlHtd8IIAJCFpctTjIeNGIJHSLv2n7LX YHd+iTIFxT6oUV3H4ZxBDmtE5J+dFuQBR3ecEp8NOZH3V1Bihs70c+PIof6l41gk BhOYf8WJ4cD4rNVe/IA3BzBlG9JXhcDTGqGUxw1aSQP9SieshxRI2bgpcVa0xt9M WG+E2zlJb9IPaNRSuDe2e9WldlUMXhDBtyIjauNXiV92321umzsIo+UzvAdLThoI xnI4xjFom3IrNNbZSgzYV6VsfcncAX8fRYJgriOZgRJT8lTujeHoM8q682QHtNC1 jX3FzqoywBWod+6tsXXiB+9ciG2As+n+RRanbQLXgrqp7E4BTYyqHgnzNHr0NOw= =E/5Y -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio