[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: |
iftah giladi |
|
Subject: |
Re: [Discuss-gnuradio] help on exception on using the uhd.dll i think... |
|
Date: |
Thu, 17 Apr 2014 19:17:07 +0300 |
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:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>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
>>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1
>>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>>iQEcBAEBAgAGBQJTOZDPAAoJEBQ6EdjyzlHtDWwIALcmUMVs7Rrx/WdFtqJ//Fxn
>>tzMvsVrDOKBu+5AnmmbVZ20dVulN2lcZ25vZScpFYKOAbe5TwRy2XTsFODHItGNF
>>dhmyOQNLVArDSSQuWTLSnMODKEUMCgU/sxyDtal0SVz6KuCSjjwP/exgaKHtNweU
>>tQid+PdH0JTZ/5iqvtQyHJhwy0rcl0RIK8ig0MXhoQG8IQVl2lKZXUtlOle1wMsC
>>w5oed0uop0d1J4bWDxC3oBRd6DfSCLx9avXtCHEFdgiAZSkFPva0XhJbimm3K8GP
>>V6qzH2S29eojRZYQHqlWxy8ISMG8SCr0Ii2joHv6iESCB9cgK1KkWrECMc0Ltvk=
>>=HjFO
>>-----END PGP SIGNATURE-----
>>
>>
>>_______________________________________________
>>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
--
NE
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/05f
5ae0b/attachment.html>
------------------------------
Message: 14
Date: Thu, 17 Apr 2014 22:10:55 +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/9c8
db3c9/attachment.html>
------------------------------
Message: 15
Date: Thu, 17 Apr 2014 17:12:49 +0300
From: "iftah giladi" <address@hidden>
To: <address@hidden>
Subject: [Discuss-gnuradio] help on exception on using the uhd.dll i
think...
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hey,
In order to start my on application code using the uhd code, I tried
creating a new blank project ,and did all
The necessary includes, and library include in the linker an compiler and so
on..
As a starter I copied the uhd_find_devices.cpp to my project lib and build
it.
It's run o.k , and then I tried to use the exe and it has this exception:
First-chance exception at 0x0f62763b in uhd_find_devices.exe: 0xC0000005:
Access violation reading location 0x02796000
What can I do next??
Thanks,
iftah
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/6b7
faec7/attachment.html>
------------------------------
Message: 16
Date: Thu, 17 Apr 2014 16:21:02 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] help on exception on using the uhd.dll
i think...
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Iftah,
usually you'd run it with a debugger, and try to find out where
exactly the access violation happens.
Greetings,
Marcus
On 17.04.2014 16:12, iftah giladi wrote:
> Hey,
>
>
>
> In order to start my on application code using the uhd code, I
> tried creating a new blank project ,and did all
>
> The necessary includes, and library include in the linker an
> compiler and so on..
>
> As a starter I copied the uhd_find_devices.cpp to my project lib
> and build it.
>
>
>
> It's run o.k , and then I tried to use the exe and it has this
> exception:
>
>
>
> First-chance exception at 0x0f62763b in uhd_find_devices.exe:
> 0xC0000005: Access violation reading location 0x02796000
>
>
>
> What can I do next??
>
>
>
> Thanks,
>
> iftah
>
>
>
>
>
>
>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTT+NOAAoJEBQ6EdjyzlHtZGUH/3H6S2ZumwxsBTfh7WqUNfqi
fHYhh4dULXmRQv8D306tuwDmXTpTwSHX7yrl6D63wZcN9uCraT5JUgl86C7ZtmmP
OXrUXFpYaYFdOXfV70c7XLcQXvd7omRgvi1s1ctOb/44Dlv7DghhxEXXP/RNMWlE
dm+6rK0QxF+0xXRBX1vWzZPw6ZXpeeEhAThwmfJelaPbEztAZf1UhMr3ddbguW+5
6S0m8unNP+Dk41mWrmkkhO+A0wWNJ/6LJDCT8Y4f8OzCnjdO7ImJIbiV+tqhqZ3R
wxRqF/Wm/3eN4i32Pk0K1WR2ZwFhtywz+topuNz63k8NKAaNdd/lGOAt7YppYRE=
=UyXB
-----END PGP SIGNATURE-----
------------------------------
Message: 17
Date: Thu, 17 Apr 2014 16:37:47 +0200
From: "Ralph A. Schmid, dk5ras" <address@hidden>
To: "'Tigor Christian'" <address@hidden>,
<address@hidden>
Subject: Re: [Discuss-gnuradio] Digital voice encryption block
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Question 3: AES is indeed a common system for voice encryption, widely used
for example in US police / public safety radios (APCO25 standard). Older
systems used often DES, but not with a neat linear predictive voice codec,
but just a CVSD digitizer, DES box and FSK radio link (Motorola SECURENET).
Then there are lots of proprietary / closed source encryption systems, some
really weak with 32 bit keys, more aimed against the casual listener /
scanner kid, but not providing real security against an advanced
eavesdropping attack.
Ralph.
From: address@hidden
[mailto:address@hidden On Behalf Of
Tigor Christian
Sent: Thursday, April 17, 2014 3:50 PM
To: address@hidden
Subject: [Discuss-gnuradio] Digital voice encryption block
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
<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/d91
a3812/attachment.html>
------------------------------
Message: 18
Date: Thu, 17 Apr 2014 14:50:17 +0000
From: "Nowlan, Sean" <address@hidden>
To: "Ralph A. Schmid, dk5ras" <address@hidden>, 'Tigor Christian'
<address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] Digital voice encryption block
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
There is no crypto in the main GNU Radio installation. I am not aware of any
public out-of-tree modules that implement crypto. Your best bet would
probably be handling crypto at the data socket layer and pushing to a GNU
Radio PDU-to-tagged-stream or using GR's message passing interface to pass
encrypted data packet between the upper layer and GR mod/demod layer. You
could use PyCrypto, as you suggested, or libgcrypt in C/C++.
http://www.gnu.org/software/libgcrypt/
GNU Radio is best suited for the PHY and basic MAC layers, but of course
this doesn't preclude wrapping libgcrypt functions into GNU Radio blocks. I
just think it would be more efficient to do crypto at a layer above the GR
mod/demod blocks. You would essentially pass data between the layers using
message queues and message handlers.
Sean
From: address@hidden
[mailto:address@hidden On
Behalf Of Ralph A. Schmid, dk5ras
Sent: Thursday, April 17, 2014 10:38 AM
To: 'Tigor Christian'; address@hidden
Subject: Re: [Discuss-gnuradio] Digital voice encryption block
Question 3: AES is indeed a common system for voice encryption, widely used
for example in US police / public safety radios (APCO25 standard). Older
systems used often DES, but not with a neat linear predictive voice codec,
but just a CVSD digitizer, DES box and FSK radio link (Motorola SECURENET).
Then there are lots of proprietary / closed source encryption systems, some
really weak with 32 bit keys, more aimed against the casual listener /
scanner kid, but not providing real security against an advanced
eavesdropping attack.
Ralph.
From:
address@hidden<mailto:discuss-gnuradio-bo
address@hidden>
[mailto:address@hidden On Behalf Of
Tigor Christian
Sent: Thursday, April 17, 2014 3:50 PM
To: address@hidden<mailto:address@hidden>
Subject: [Discuss-gnuradio] Digital voice encryption block
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<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/b8d
4d16d/attachment.html>
------------------------------
Message: 19
Date: Thu, 17 Apr 2014 17:04:18 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Digital voice encryption block
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Also, if using encryption over a wireless link, you'll need some way
to ensure that damaged data gets resent, or to ensure a damaged block
does not affect the decryptability of following data.
So I think your flowgraphs should read
Mic/Soundcard -> low pass -> source coding (at least some uLaw or so)
- -> encryption -> frame building & channel coding -> symbol
mapping/modulation -> pulse shaping -> tx system
rx system -> freq/time/clock sync (might include deframing) -> channel
decoding (equalizing might happen somewhere here) -> decryption ->
source decode -> soundcard
As Sean pointed out, this does not necessarily translate nicely into a
GNU Radio sample flow graph and you might be better of with a
combination of sample flows and message passing.
With encryption, you really really need the channel code, since a
single flipped bit will render your transmission unusable.
Also, I don't really understand: GRC creates python *flow graphs* out
of graphical representations. It can generate hier blocks, which are
just flow sub-graphs internally, but it can not generate blocks that
have a work function.
If you're already at ease with designing oot modules, then using a
python library to encode a block of data seems to be rather trivial,
and I don't see how that should be possible or easier from withing GRC ;)
Greetings,
Marcus
On 17.04.2014 16:37, Ralph A. Schmid, dk5ras wrote:
> Question 3: AES is indeed a common system for voice encryption,
> widely used for example in US police / public safety radios (APCO25
> standard). Older systems used often DES, but not with a neat linear
> predictive voice codec, but just a CVSD digitizer, DES box and FSK
> radio link (Motorola SECURENET). Then there are lots of proprietary
> / closed source encryption systems, some really weak with 32 bit
> keys, more aimed against the casual listener / scanner kid, but not
> providing real security against an advanced eavesdropping attack.
>
>
>
> Ralph.
>
>
>
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Tigor Christian Sent: Thursday, April 17, 2014 3:50 PM
> To: address@hidden Subject: [Discuss-gnuradio] Digital
> voice encryption block
>
>
>
> 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 <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
>
>
>
>
>
>
>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTT+1xAAoJEBQ6EdjyzlHtZwEIAJk86sf0TWhP+z976wDd8Oi4
tMk6Nk2rcUMEFP4TopDo4fo0uCH3n6oO9jL+6Wuh2M1gqrpj3jvdfUvPMJRPHVDo
LpWzE6V2XIcNbShA/XOp56sf3/OqS+qDAXLD2Wa1xnZIW4cPttJ0bWWNaukjxpUO
5z2M8zkWSy7pIl4eMDIexY6fedzko0ZfO7sw8ynLNmRSA2mNHsJ9qiwrhmVuzqLS
a7xgQBkFlTpmOx6t4g254uB0wWakPPcw3Td1GzSr3j5p1/Lk/FskJdM/mLTLbGuw
5CAB2Kl4fBwOy6mPTcNHrF3pDAoPrPqtNSEjFFuvaCytATYo92DeoIc6kYOZHEE=
=yCnV
-----END PGP SIGNATURE-----
------------------------------
Message: 20
Date: Thu, 17 Apr 2014 11:08:56 -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 3:38 PM, Azza <address@hidden> wrote:
> 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
>
Azza,
Maybe take a step back from trying to calculate the BER. Make sure you have
a transmitting system and receiver system that are working correctly. At
the receiver, the first thing to do is make sure you're getting a proper
constellation. If so, you should be able to extract the bits to compare
them. And by this, I mean make two flowgraphs for the tx and rx sides so
you're not confusing yourself by trying to tie everything together.
Also, make sure you are either using differential modulation encoding to
correct for unknown phase offsets or that you are somehow correcting for
this possibility. Then, you need to make sure you're getting your frames
through. There will be a delay between what you transmit over the air and
when you receive it. You'll have to account for this, too.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140417/7ef
737cd/attachment.html>
------------------------------
Message: 21
Date: Thu, 17 Apr 2014 11:10:15 -0400
From: Philip Balister <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Developer Call today at 1700 UTC
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
I'll be starting the hangout promptly at 1700 UTC. (That's 1 PM EDT)
I am 99.9% certain I will start the hangout by inviting one person, then
posting a link in the #gnuradio irc channel. This worked an hour ago, so
I expect things to go smoothly today.
Philip
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 137, Issue 17
*************************************************
- Re: [Discuss-gnuradio] help on exception on using the uhd.dll i think...,
iftah giladi <=