Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
make distclean; ./bootstrap;./configure;make;sudo make install definitely seems in order. Bob Johnathan Corgan wrote: On Tue, 2006-12-19 at 08:12 -0500, Greg Troxel wrote: Undefined PLT symbol "_ZN14gr_basic_block11basic_blockEv" (symnum = 81) This symbol is defined in a new file that was recently checked in, gr_basic_block.cc, in gnuradio-core/src/lib/runtime. For some reason it looks like this isn't getting linked in during the compile on your system, though it's definitely in the Makefile.am list of source files. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "If you board the wrong train, it is no use running along the corridor in the other direction. " - Dietrich Bonhoffer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VT receives NSF grant for SDR security
Greg - I think the concept of "software defined radio" being explored by the VT folks is a concept I persoally refer to as "crippled software radio". It is based on a discredited theory of "security" that was called a "secure kernel" when I was a student 30 years ago. In other words - that there is a small, well-defined portion of a system that can be certified separately from the rest of the system, which has the essential property that its *correct* operation *guarantees* that the entire system will be secure according to *all possible interpretations* of the word secure. I worked on a project of this sort, and am currently ashamed that I helped perpetuate that charade. I can only say that many others helped - it funded lots of work on "proving programs correct" - on the theory that it was feasible to prove small programs correct, and thus whole systems "secure". The big lie, of course, is that the researchers essentially redefined the word "secure" to mean the trivial notion of security that you couldn't compromise the "kernel". Of course today we stare the fraudulence of that idea in the face: phishing, XSS, and other very dangerous attacks do not depend one whit on a failure to secure a "kernel" of the operating system, or even the "kernel" of a router. Yet the idea that incorrectness is the same thing as insecurity persists in such ideas as the idea that you need "hardware inegrity" to prevent attacks on radio systems. I suggest that it is impossible to carry on a dialog with folks like the VT researchers, because they must necessarily buy into the "certification of correctness" notion of security.If they were concerned with "correctness" that would be fine - we could carry out a meaningful discussion about the difficulty of determining correctness in a system that is inherently focusing on getting reliable communications through unreliable channels (information theory). But since they play to the gods of deterministic correctness - unreliability doesn't fit in their notion of "security" - they cannot even consider the idea that there is no "kernel" that can be certified to reduce risk. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
On Tue, 2006-12-19 at 08:12 -0500, Greg Troxel wrote: > Undefined PLT symbol "_ZN14gr_basic_block11basic_blockEv" (symnum = > 81) This symbol is defined in a new file that was recently checked in, gr_basic_block.cc, in gnuradio-core/src/lib/runtime. For some reason it looks like this isn't getting linked in during the compile on your system, though it's definitely in the Makefile.am list of source files. -- Johnathan Corgan, AE6HO Corgan Enterprises LLC [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
On Tuesday 19 December 2006 23:42, Greg Troxel wrote:
> I probably didn't rebuild all since swig upgrade to 1.3.31.
> I suppose the Makefile.am's need to have a dependency on the swig
> executable :-) (I know, ENOPATCH...)
>
> I got a different error, so I did make distclean and a full rebuild.
> Now I get this, which I'll look into when I get a chance.
>
> gdt 199 /usr/adroit/lib/python2.4/site-packages/gnuradio > python
> Python 2.4.3 (#1, Jul 11 2006, 02:04:00)
> [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd3
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> from gnuradio import _audio_oss
>
> Traceback (most recent call last):
> File "", line 1, in ?
> ImportError:
> /usr/adroit/lib/python2.4/site-packages/gnuradio/_audio_oss.so:
> Undefined PLT symbol "_ZN14gr_basic_block11basic_blockEv" (symnum =
> 81)
FYI:
Works fine here on NetBSD-4.99.5, swig-1.3.31 and gcc-4.2.1:
barossa: {48} python
Python 2.4.3 (#1, Aug 20 2006, 03:28:21)
[GCC 4.1.2 20060628 prerelease (NetBSD nb2 20060711)] on netbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import _audio_oss
>>>
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
I probably didn't rebuild all since swig upgrade to 1.3.31. I suppose the Makefile.am's need to have a dependency on the swig executable :-) (I know, ENOPATCH...) I got a different error, so I did make distclean and a full rebuild. Now I get this, which I'll look into when I get a chance. gdt 199 /usr/adroit/lib/python2.4/site-packages/gnuradio > python Python 2.4.3 (#1, Jul 11 2006, 02:04:00) [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import _audio_oss Traceback (most recent call last): File "", line 1, in ? ImportError: /usr/adroit/lib/python2.4/site-packages/gnuradio/_audio_oss.so: Undefined PLT symbol "_ZN14gr_basic_block11basic_blockEv" (symnum = 81) >>> -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Numeric.concatenate
I have searched the archives for this problem (if it truly is one) and could not find it so I am seeing what anyone knows. when I go to run ./usrp_wfm_rcv.py I get this error which keeps repeating itself as I listen to the radio station. Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/fftsink.py", line 276, in set_data points[:,1] = Numeric.concatenate ((dB[L/2:], dB[0:L/2])) ValueError: matrices are not aligned for copy Thanks, Newell ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Setting Intermediate Frequency (IF)
Il giorno lun, 18/12/2006 alle 12.44 -0800, Chris Stankevitz ha scritto: > I'm curious, why do you want to bring the L1 carrier to an IF of > 15.42? I'm workin' on the code written for a custom board who uses this IF. I need to replicate the behaviour of the custom board in the USRP to reuse a large amount of already written code. So I need this IF, a selectable A/D conversion frequency and 1 bit quantization. I don't know if it is possible to do that with USRP. I'm a newbie of GNU Radio and something is cryptic for me... and in general any kind of documentation is very full of gaps and it doesn't help who don't know how GNU Radio works. And if you include my crappy english :D Regards, -- Davide Anastasia web: http://www.davideanastasia.com/ email: [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
