[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] help on exception on using the uhd.dll i think...
|
From: |
Marcus Müller |
|
Subject: |
Re: [Discuss-gnuradio] help on exception on using the uhd.dll i think... |
|
Date: |
Thu, 17 Apr 2014 18:30:40 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
-----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:
> address@hidden
> [mailto:address@hidden On
> Behalf Of address@hidden Sent: Thursday, April
> 17, 2014 7:01 PM To: address@hidden Subject:
> Discuss-gnuradio Digest, Vol 137, Issue 17
>
> Send Discuss-gnuradio mailing list submissions to
> address@hidden
>
> 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
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> 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
> <address@hidden> To: address@hidden Subject:
> Re: [Discuss-gnuradio] "Error rate" block with USRP Message-ID:
> <address@hidden> 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
> <address@hidden> To: Azza <address@hidden> Cc:
> GNURadio Discussion List <address@hidden> Subject: Re:
> [Discuss-gnuradio] "Error rate" block with USRP Message-ID:
> <address@hidden>
>
>
Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, Apr 16, 2014 at 2:06 PM, Azza <address@hidden>
> 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
> <address@hidden> To: address@hidden Subject:
> Re: [Discuss-gnuradio] "Error rate" block with USRP Message-ID:
> <address@hidden> 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
> <address@hidden> To: address@hidden Subject:
> Re: [Discuss-gnuradio] "Error rate" block with USRP Message-ID:
> <address@hidden> 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 <address@hidden> To: address@hidden Subject:
> [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing
> Message-ID: <address@hidden> 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
> <address@hidden> To: address@hidden Subject: Re:
> [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing
> Message-ID: <address@hidden> 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
> <address@hidden> To: address@hidden Subject: Re:
> [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing
> Message-ID: <address@hidden> 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" <address@hidden> To: Kiran Karra
> <address@hidden> Cc: "address@hidden"
> <address@hidden> Subject: Re: [Discuss-gnuradio] ctest -V
> segfault, coredump reveals nothing Message-ID:
> <address@hidden>
>
>
Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Apr 16, 2014 at 6:21 PM, Kiran Karra <address@hidden>
> 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
> <address@hidden> To: address@hidden Subject: Re:
> [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing
> Message-ID: <address@hidden> 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 <address@hidden> To:
> "address@hidden" <address@hidden> Subject:
> [Discuss-gnuradio] Digital voice encryption block Message-ID:
> <address@hidden>
> 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 <address@hidden> To: GNURadio Discussion List
> <address@hidden> Subject: [Discuss-gnuradio] How to
> Access Received Data for Use In Changing RX Parameters Message-ID:
> <address@hidden>
>
>
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 <address@hidden> To:
> "address@hidden" <address@hidden> Subject:
> [Discuss-gnuradio] Digital voice encryption block Message-ID:
> <address@hidden>
> 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
> <address@hidden> To: Marcus M?ller <address@hidden>, Bogdan
> Diaconescu <address@hidden> Cc: address@hidden
> <address@hidden> Subject: Re: [Discuss-gnuradio] dvb-t
> project with two USRPN200 devices failure Message-ID:
> <address@hidden> 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 <address@hidden>:
>> Thanks a lot! I will try them too...
>>
>>
>> Mon, 31 Mar 2014 09:08:04 -0700 (PDT) ?? Bogdan Diaconescu
> <address@hidden>:
>>>
>>> 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
>>> <address@hidden>
> 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
>>>>> < address@hidden >:
>>>>>> 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 <
>>>>>> address@hidden > 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 < address@hidden >: 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 < address@hidden >
>>>>>> 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 address@hidden
>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- NE
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> _______________________________________________ Discuss-gnuradio
>>>>> mailing list address@hidden
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list address@hidden
>>> 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-----