Send Discuss-gnuradio mailing list submissions to
address@hiddenTo 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@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. About how to write c++ based signal processing block (Alex Zhang)
2. Re: "GNU Radio is crap" and GSoc (Jeff Brower)
3. Re: "GNU Radio is crap" and GSoc (Ed Criscuolo)
4. Re: About
how to write c++ based signal processing block
(Martin Braun)
5. Re: "GNU Radio is crap" and GSoc (Jeff Brower)
6. Re: "GNU Radio is crap" and GSoc (Ben Hilburn)
7. Re: [
address@hidden: [Scan-DC] Warning of increased GSM +
TETRA attacks] (Andrew Davis)
8. Re: Volk branch on github (Josh Blum)
9. Re: [
address@hidden: [Scan-DC] Warning of increased GSM +
TETRA attacks] (Marcus D. Leech)
10. Re: "GNU Radio is crap" and GSoc (Andrew Davis)
11. Re: working with WFM sample data (emilio gonzalez)
12. Re: working with WFM sample data (Marcus D. Leech)
13. CGRAN wants your GNU
Radio projects! (George Nychis)
14. gr_sync_block, AttributeError: No constructor defined
(Jason Bonior)
15. Re: "GNU Radio is crap" and GSoc (Philip Balister)
16. Re: gr_sync_block, AttributeError: No constructor defined
(Josh Blum)
17. Re: "GNU Radio is crap" and GSoc (Tom Rondeau)
18. Re: About the use of gr.probe_signal_f() (Wu Ting)
19. Strange result when using message_sink and msg.queue (Wu Ting)
20. External Clock set to 64MHz on USRP2/N210 (rmsrms1987)
21. Re: Volk branch on github (Tom Rondeau)
22. Re: Volk branch on github (Tom Rondeau)
23. Re: About the use of gr.probe_signal_f() (Tom Rondeau)
24. Re: gr-howto installation issue (Tom Rondeau)
25. Re: CPFSK carrier frequency (Tom Rondeau)
26. Re: External Clock set to 64MHz on
USRP2/N210 (Nick Foster)
27. Re: About the use of gr.probe_signal_f() (Wu Ting)
28. Re: "GNU Radio is crap" and GSoc (Jens Elsner)
29. Re: "GNU Radio is crap" and GSoc (Andrew Davis)
30. USRP Request (guelord ingala)
31. Reminder about call today (Tom Rondeau)
32. Re: Reminder about call today (George Nychis)
33. GRC: Just compile XML, no GUI (Martin Braun)
34. problem building gr-howto-write-a-block-cmake
(Achilleas Anastasopoulos)
35. Re: problem building gr-howto-write-a-block-cmake
(Achilleas Anastasopoulos)
36. Re: problem building gr-howto-write-a-block-cmake (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Feb 2012 11:15:55 -0600
From: Alex Zhang <
address@hidden>
To: gnuradio mailing list <
address@hidden>
Cc: Tom Rondeau <
address@hidden>
Subject: [Discuss-gnuradio] About how to write c++ based signal
processing block
Message-ID:
<CA+FEAnd-Xdmx96gVRVqDWO28=38t=dFq51Tq==
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Gurus,
To learn how to write the signal processing block over C++, I downloaded
the gr-how-to-write-a-block and successfully build the block and passed the
test.
But my
question is, for a block writer who is not familiar with the complex
building tree, like the makefile writing, can the future block writing just
be simply based on the building framework provided by the
gr-how-to-write-a-block example? I mean, I do not want to dig too much the
makefile, but just reuse the current example with minor modification, to
meet all the requirements from the new block generating.
Thanks,
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/480b6e51/attachment.html>
------------------------------
Message: 2
Date: Wed, 15 Feb 2012 10:31:48 -0600 (CST)
From: "Jeff Brower" <
address@hidden>
To: "Martin Braun" <
address@hidden>
Cc:
address@hidden
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID:
<
address@hidden>
Content-Type: text/plain;charset=iso-8859-1
Martin-
> On Tue, Feb 14, 2012 at 09:11:19AM -0500, Clark Pope wrote:
>> Without a monetization strategy I don't see how the gnu radio project gets much past its current
state. The problem
>> is the functionality of a prototyper or student is implemented in about 20% of the effort for a full application.
>> The documentation, testing, deployment, and maintenance of a real application needs a lot more work and that work is
>> not educational or enjoyable. So without something like an app store where developers can get reimbursed for that
>> other 80% the applications will stay stuck at the cool demo stage.
>
> First, "cool demo stage" is already a pretty good stage.
> Second, I'd like to point out a very successful OSS project not unlike
> GNU Radio & the USRP: the Arduino.
> By itself, it's useless--it's a hardware/software development tool.
> Sounds familiar?
> If you read sites like
hackaday.com, the Arduino comes up *all the
> time* with posts like "Look what X did with an Arduino". On this
> specific site, GNU Radio comes
up 3 times, the newest article being from
> February 2009.
>
> Some coverage of cool hacks using GNU Radio certainly wouldn't hurt the
> project.
All understood. Demos that highlight GNU Radio's tremendous progress are crucial to its long-term success. But
nevertheless Clark makes a crucial point. GNU Radio is owned by National Instruments and I might guess their sales
guys are not too happy with this thread. They can't sell "cool demos". Progress must be made to create
revenue-producing applications. Like Clark says, most of that work is not fun, and it eats a lot of time and effort,
but in the real business world, there isn't a choice.
-Jeff
------------------------------
Message: 3
Date: Wed, 15 Feb 2012 12:27:44 -0500
From: Ed Criscuolo <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
On 2/15/12 11:31 AM, Jeff Brower wrote:
> ........ GNU Radio is owned by National Instruments .........
????!!!!!
You are confusing GnuRadio with Ettus Research.
GnuRadio is an open source SDR framework.
Ettus is the manufacturer of the USRP series of hardware
and the UHD driver libraries to
access it.
@(^.^)@ Ed
------------------------------
Message: 4
Date: Wed, 15 Feb 2012 18:29:35 +0100
From: Martin Braun <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] About how to write c++ based signal
processing block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Wed, Feb 15, 2012 at 11:15:55AM -0600, Alex Zhang wrote:
> Hi Gurus,
>
> To learn how to write the signal processing block over C++, I downloaded the
>
gr-how-to-write-a-block and successfully build the block and passed the test.?
>
> But my question is, for a block writer who is not familiar with the complex
> building tree, like the makefile writing, can the future block writing just be
> simply based on the building framework provided by the?
> gr-how-to-write-a-block?example? I mean, I do not want to dig too much the
> makefile, but just reuse the current example with minor modification, to meet
> all the requirements from the new block generating.
Sure that's OK.
You can also use gr_modtool.py (available at
https://cgran.org/wiki/devtools)
which does all the Makefile editing for you.
If you're using the autotools version of howto-write-a-block (which
apparently you are), you need the older version.
MB
--
Karlsruhe Institute of Technology
(KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone:
+49 721 608-43790
Fax:
+49 721 608-46071www.cel.kit.eduKIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/6e2aea87/attachment.pgp>
------------------------------
Message: 5
Date: Wed, 15 Feb 2012 11:41:44 -0600
From: Jeff Brower <
address@hidden>
To: Ed Criscuolo <
address@hidden>
Cc:
address@hidden
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Ed-
> On 2/15/12 11:31 AM, Jeff Brower wrote:
> > ........ GNU Radio is owned by National Instruments .........
>
> ????!!!!!
>
> You are confusing GnuRadio with Ettus Research.
>
> GnuRadio is an open source SDR framework.
>
> Ettus is the
manufacturer of the USRP series of hardware
> and the UHD driver libraries to access it.
Ok. I should have said "is owned by" with "substantially depends on"...
-Jeff
------------------------------
Message: 6
Date: Wed, 15 Feb 2012 09:49:23 -0800
From: Ben Hilburn <
address@hidden>
To: Jeff Brower <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID:
<CAOEVZkKZxB4dwYmdcS9_Z+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Jeff -
> All understood. Demos that highlight GNU Radio's tremendous progress are
> crucial to its long-term success. But
> nevertheless Clark makes a crucial point. GNU Radio is owned by National
> Instruments and I might guess their sales
> guys are not too happy with this thread.
Erm, what?
This reflects a really severe misunderstanding of GNU Radio.
GNU Radio is _not_ owned by NI, in any way. GNU Radio is owned by the Free
Software Foundation, and has nothing to do with NI.
Ettus Research, the creator of USRP hardware, is owned by NI. But, USRPs
are _not_ GNU Radio. You are confusing a free software project with a
company that makes hardware. USRPs can be
used with LabView, Simulink, GNU
Radio, or without any SDR framework at all; they are just general-purpose
hardware with a C++ / Python API.
> They can't sell "cool demos". Progress must be made to create
> revenue-producing applications. Like Clark says, most of that work is not
> fun, and it eats a lot of time and effort,
> but in the real business world, there isn't a choice.
>
> Ok. I should have said "is owned by" with "substantially depends on"...
NI has no control over the direction of GNU Radio. Ettus Research supports
GNU Radio, but we do not control it in any way. GNU Radio's progress is
controlled by Tom Rondeau, and its developers and users; hence, the
existence of threads like this for the community to discuss ideas.
Cheers,
Ben
> -Jeff
>
>
> _______________________________________________
>
Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/70f82d4b/attachment.html>
------------------------------
Message: 7
Date: Wed, 15 Feb 2012 12:53:02 -0500
From: Andrew Davis <
address@hidden>
To: "David I. Emery" <
address@hidden>,
address@hidden
Subject: Re: [Discuss-gnuradio] [
address@hidden: [Scan-DC] Warning
of increased GSM + TETRA attacks]
Message-ID:
<CAHdBCVcUn89i1aGqbgK-nwFeqnY4h1LDGujsm5_Zq=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
They are gonna think they can fire up GNURadio and start decrypting likes
it a program. Followed by a influx of "GNURadio is crap" comments...
On Wed, Feb 15, 2012 at 2:33 AM, David I. Emery <
address@hidden>wrote:
>
> GoMo News
>
> February 13, 2012 Monday 12:43 PM EST
>
> Warning of increased GSM + TETRA attacks
>
> LENGTH: 471 words
>
> Rating: We're back to Squidgygate and police radio scanners again
>
> Here's a bit of an ominous warning. Much worse than mere voicemail
> hacking. Greg Jones, a director of wireless security specialist, Digital
> Assurance, is warning of the dangers posed by the increasing availability
> of low cost software defined radio (SDR) solutions. He says, "It's
> extremely likely that criminal gangs, hacktivists and others will all show
> a growing interest in [SDR]. And we're not just talking about the hacking
> of individual mobile phones here but the possible compromise of critical
> infrastructure." In a nutshell, what Mr Jones is
suggesting is that thanks
> to SDR it's no longer possible to assume that calls made over commercial
> and specialist wireless networks are inherently secure. We're back to the
> bad old days when ham radio enthusiasts could list into analogue cellular
> calls. Who remembers the infamous Squidgygate tapes, for example?There's
> nothing inherently evil about SDR technology. In effect, its arrival has
> helped to make devices like cellular phones c
> heaper by dispensing with the need for multiple, dedicated wireless
> chipsets.
>
> So what's going on? Jones says, "Those attempting to compromise wireless
> communications systems in the past have used expensive equipment coupled
> with advanced signal analysis skills."
>
> This is a reference to the fact that breaking standard GSM signals
> previously required a supercomputer. Not any more,
apparently.
>
> "SDR devices typically use a standard PC to capture and manipulate radio
> spectrum potentially allowing an attacker to capture and demodulate
> advanced radio systems which were previously inaccessible to the hacking
> community," Jones explains.
>
> He doesn't actually mention it but if that 'standard PC' includes a laptop
> we could be in deep trouble. Think innocuous white van sitting outside your
> home/office.
>
> Which advanced systems is he talking about? Well, the list includes mobile
> networks such as GSM, Wi-fi, WiMAX, DECT and even TETRA.
>
> So that's not just your mobile phone, your laptop and your cordless phone
> - we're also looking at hacking emergency services.
>
> Think police radio scanners used by crooks to know if they've been
> detected yet.
>
> Just to make the point Jones even names the tools
a budding SDR hacker
> needs. The USRP (Universal Software Radio Peripheral) coupled with open
> source software like GNU Radio. Oops.
>
> What particularly worries GoMo News is the potential to 'spoof' a GSM base
> station and intercept the calls you think you are making to your bank.
>
> Jones is a master of understatement. "If one were to consider the
> implications of a co-ordinated attack against a critical communications
> system over say London - even if the attack were restricted simply to
> signal jamming - the potential is there to cause massive disruption," Greg
> Jones stated.
>
> Olympics 2012, anyone?
>
> ______________________________________________________________
> Scan-DC mailing list
> Home:
http://mailman.qth.net/mailman/listinfo/scan-dc
> Help:
http://mailman.qth.net/mmfaq.htm> Post: mailto:
address@hidden
>
> This list hosted by:
http://www.qsl.net> Please help support this email list:
http://www.qsl.net/donate.html
>
> ----- End forwarded message -----
>
> --
> Dave Emery N1PRE/AE,
address@hidden DIE Consulting, Weston, Mass
> 02493
> "An empty zombie mind with a forlorn barely readable weatherbeaten
> 'For Rent' sign still vainly flapping outside on the weed encrusted pole -
> in
> celebration of what could have been, but wasn't and
is not to be now
> either."
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/f19fccef/attachment.html>
------------------------------
Message: 8
Date: Wed, 15 Feb 2012 10:27:20 -0800
From: Josh Blum <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] Volk branch on github
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
> You would have:
>
> for(size_t i = 1; i < input_items.size(); i++)
> volk_32fc_x2_multiply_32fc(is_unaligned(), out, out,
> (gr_complex*)input_items[i], noi);
>
> You halve the amount of code in gnuradio blocks which to my opinion
> makes it much more maintainable.
>
Here is a possible solution, I dont know how viable it is.
1) Suppose that we have the gotten to a head or tail case where
the
number of samples isnt an alignment multiple or the last call to work
ended us on a non-aligned boundary.
2) In an effort to re-align, the scheduler could memcpy the *smallest*
possible chunk into aligned memory, pad the length, call work, and
memcpy the result to the output buffer.
3) Now the next call to work will always be aligned. Also, the work
function never needs to change, and will always use the aligned call.
I tried to implement this in gr block executor, but got confused trying
to handle all of the edge cases, like multiple IO ports with different
data types. And so, how the block would configure the scheduler in the
most generic of cases isnt clear to me. But, even if it was
oversimplified, I still think its the better way to solve 90% of the use
cases.
Thoughts?
-Josh
------------------------------
Message: 9
Date: Wed, 15 Feb 2012 13:40:12
-0500
From: "Marcus D. Leech" <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] [
address@hidden: [Scan-DC] Warning
of increased GSM + TETRA attacks]
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
You know, I wasn't going to respond to this, but what the heck:
July, 1930 - Anytown USA
"Criminals Use Electronics to Foil Police"
The increasing use of electronic communications by police and other law
enforcement bodies has lead
criminals to engage in methods to
interrupt and eavesdrop (listen to) those communications using
off-the-shelf or home-built devices.
Emerging retail outlets such as "Radio Shack" (Boston, Ma) and "Allied
Radio" (Chicago, Il) have facilitated such criminal activity by
providing not only complete radio receiver sets, but components such
as vacuum tubes, condensers, resistors, and such that dedicated
criminals can use to build their own specialized devices.
Even a simple "crystal set" can be modified by interested criminals to
listen to police-radio frequencies.
This is a worrying trend, and regulators are busy considering ways to
put a stop to it.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org------------------------------
Message: 10
Date: Wed, 15 Feb 2012 13:41:09 -0500
From: Andrew Davis <
address@hidden>
To: Ben Hilburn <
address@hidden>,
address@hidden
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Well some major
GNUradio program would drive up sales of USRP's :)
Back on topic, IMHO Gnuradio's problem with large apps stems from it
trying to be the source to sink and everything in?between?of a radio.
Lets take DREAM for example, they do transfer functions and digital
AGC and the likes that GNUradio by design should not do. If you want
to re-write DREAM with GNUradio you will end up writing about +200
blocks, not much fun. What people want is simple input to there
program and a simple output API, not there entire program. They?don't
what to figure out how to write a GNURadio block or know anything
about the complexities of GNURadio. They want to say "get me a signal
at 100MHz, filter and?interpolate to 1ksp?with these cutoff
frequencies?then send me the data and let me do the rest", no need to
know anything about GNURadio, what other API makes you learn as much
about it?
And Gnuradio can do that, with its C++ API,
but not with python,
python is great for demos like "source->AM demod->sink", and?that's
also great for?academic?projects too, but simply not enough DSP
control for real programs. In the web scanner program at the top of
this thread, in the developers?complimentary?they write: " I was
originally using some demo code written in Python as my base, but I
got tired of dealing with the foibles of that code and rewrote it in
C++ one night last summer.?" Isn't it strange that one of the big
examples does exactly this.
spectrum_sense.py is another great example, the block?bin_statistics_f
has only one use and that it for the program spectrum_sense, so if
spectrum_sence was writen in C++ it would have just benn part of the
program and not its own block, but insted it calls python and vise
versa in an amazingly hackish way.
?If real programs are going to be made there needs to be a better way
to use
GNUradio as an API and not an entire SDK. Just get the samples
out-of?GNURadio and into the programs hands, then back into GNURadio
in the end for final filtering and output,?possibly?some work using
GNURadio functions in the middle is all that is needed. Back to DREAM,
a lot of the filters, audio input/output, signal conditioning, etc
could be in GNURadio, but a lot of the middle section cannot. GNURadio
can not be the whole program, just helper?functions?in big programs
like this. Only about %20 of DREAM could be replaced with GNURadio API
calls, but instead you will have to rewrite it %100 as GNURadio blocks
with the current block to block only mentality </rant>
On Wed, Feb 15, 2012 at 12:49 PM, Ben Hilburn <
address@hidden> wrote:
>
> Jeff -
>
>>
>> All understood. ?Demos that highlight GNU Radio's
tremendous progress are crucial to its long-term success. ?But
>> nevertheless Clark makes a crucial point. ?GNU Radio is owned by National Instruments and I might guess their sales
>> guys are not too happy with this thread.
>
>
> Erm, what?
>
> This reflects a really severe misunderstanding of GNU Radio.
>
> GNU Radio is _not_ owned by NI, in any way. ?GNU Radio is owned by the Free Software Foundation, and has nothing to do with NI.
>
> Ettus Research, the creator of USRP hardware, is owned by NI. ?But, USRPs are _not_ GNU Radio. ?You are confusing a free software project with a company that makes hardware. ?USRPs can be used with LabView, Simulink, GNU Radio, or without any SDR framework at all; they are just general-purpose hardware with a C++ / Python API.
>
>>
>> They can't sell "cool demos". ?Progress must be made to create
>>
revenue-producing applications. ?Like Clark says, most of that work is not fun, and it eats a lot of time and effort,
>> but in the real business world, there isn't a choice.
>
>
> >?Ok. ?I should have said "is owned by" with "substantially depends on"...
>
> NI has no control over the direction of GNU Radio. ?Ettus Research supports GNU Radio, but we do not control it in any way. ?GNU Radio's progress is controlled by Tom Rondeau, and its developers and users; hence, the existence of threads like this for the community to discuss ideas.
>
> Cheers,
> Ben
>
>
>>
>> -Jeff
>>
>>
>> _______________________________________________
>> 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
>
------------------------------
Message: 11
Date: Wed, 15 Feb 2012 11:05:31 -0800
From: emilio gonzalez <
address@hidden>
To: <
address@hidden>
Subject: Re: [Discuss-gnuradio]
working with WFM sample data
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed
hi Marcus,
thanks for this tip, it pushed me the the right direction. i guess
this capture file isn't the standard "complex" datatype, and a
conversion was the answer. i found the answer on the
gnuradio.org
Octave page that said the magic word, short. i use this graph to render
on an FFT scope:
[ File Source (short) ]
-> [ Throttle (complex, 25M) ]
-> [ IShort to Complex ]
-> [ FFT Scope (complex, rate 25M) ]
using IShort to Complex was just a result of experimentation, as Short
to Complex seemed to
output only half the captured band. now i get to
delve in to the world of filters, oof!
i'm surprised this isn't listed on the
gnuradio.org Sample Data page (
http://gnuradio.org/redmine/projects/gnuradio/wiki/SampleData ), as i've
come across messages from other folks confused about the data types and
semantics of these USRP capture files. i suggest an addition to that
page that mentions the necessity of an IShort conversion.
thanks again!
- emilio
KI6NVO
> It's very likely that your on-disk sample format isn't what you've
> declared to Gnu Radio, and it's seeing some garbage numbers.
>
> Is it
> possible that it's stored as 16-bit I 16-bit Q in the file? If so,
> you'll need to convert it before any of your complex-float blocks do
> anything
with it.
------------------------------
Message: 12
Date: Wed, 15 Feb 2012 14:12:36 -0500
From: "Marcus D. Leech" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] working with WFM sample data
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02/15/2012 02:05 PM, emilio gonzalez wrote:
> hi Marcus,
>
> thanks for this tip, it pushed me the the right direction. i guess
> this capture file isn't the standard "complex" datatype, and a
> conversion was the answer. i found the answer on the
gnuradio.org > Octave page that said the magic word, short. i use this graph to
> render on an FFT scope:
>
> [ File Source (short) ]
> -> [ Throttle (complex, 25M) ]
> -> [ IShort to Complex ]
> -> [ FFT Scope (complex, rate 25M) ]
>
> using IShort to Complex was just a result of experimentation, as Short
> to Complex seemed to output only half the captured band. now i get to
> delve in to the world of filters, oof!
>
> i'm surprised this isn't listed on the
gnuradio.org Sample Data page (
>
http://gnuradio.org/redmine/projects/gnuradio/wiki/SampleData ), as
> i've come across messages from other folks confused about the data
> types and semantics of these USRP capture
files. i suggest an
> addition to that page that mentions the necessity of an IShort
> conversion.
>
>
You can capture *any* of the native sample formats in Gnu Radio, so it's
not the case that disk-resident samples are necessarily recorded
in "complex short" format. It depends on what the program that
recorded them asked for, and you have to understand what the
program that recorded them intended.
Gnu Radio doesn't use file headers or any other such technique--the file
sinks records raw samples in whatever format they're presented
in.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 13
Date: Wed, 15 Feb 2012 10:48:43
-0500
From: George Nychis <
address@hidden>
To: discuss-gnuradio <
address@hidden>
Subject: [Discuss-gnuradio] CGRAN wants your GNU Radio projects!
Message-ID:
<CA+7oygd8wAGzonm8NV=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Just your friendly CGRAN update to the mailing list. I've seen a slowdown
in projects posted to the CGRAN, yet not a slowdown in account signups.
So, I thought I'd just e-mail out a quick update.
The usual quick blurb (
https://www.cgran.org/):
*The Comprehensive GNU Radio Archive Network (CGRAN) is a free open source
repository for 3rd party GNU Radio applications that are not officially
supported by the GNU Radio project. CGRAN provides a subversion repository
for users to develop or submit new applications, and wiki access for full
project documentation. *
*
*
Recent projects:
- Logitech27MHzTransceiver<
https://www.cgran.org/wiki/Logitech27MHzTransceiver>
-
Transceiver for 27 MHz wireless keyboards from Logitech
- Stream Tagging Tools <
https://www.cgran.org/wiki/stt> - A growing
collection of blocks relating to handling tags
- simple_ra <
https://www.cgran.org/wiki/simple_ra> - A simple Radio
Astronomy application to replace gr-radio-astronomy
- gr_iqtx <
https://www.cgran.org/wiki/gr_iqtx> - A tool for sending
generic I/Q data from a FIFO, and providing various analysis options
- RSSI-based 802.15.4
localization<
https://www.cgran.org/wiki/RSSIbased802154localization> -
802.15.4 receiver with RSSI feature added, and application code for channel
estimation, ranging and localization
*Note: * I've noticed a general move from SVN to git. I don't have the
time to move CGRAN to git right now, but I am more than okay with
someone
hosting their code on github, and adding their project to the project list,
linking to their github. Because ultimately, your code is available in a
public location that people can fork from, etc. CGRAN can still provide
you the exposure to the GNU Radio community if you want it, just link to
your github.
- George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/738b91e1/attachment.html>
------------------------------
Message: 14
Date: Wed, 15 Feb 2012 18:22:36 -0600
From: Jason Bonior <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] gr_sync_block, AttributeError: No
constructor defined
Message-ID:
<CAJp-0GTuO-E=1RH9WoFacmF30oS+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
I am trying to create a block using gr.gr_sync_block which will select
a value from an input vector, pass that value to output, and discard
the rest of the vector:
!/usr/bin/env python
from gnuradio import gr
import numpy
class vector_parser(gr.gr_sync_block):
def __init__(self):
gr.gr_sync_block.__init__(
self,
name = "vector_parser",
in_sig = [(numpy.float32, 5)],
out_sig = [numpy.float32]
)
def work(self, input_items, output_items):
output_items[0] = input_items[2]
return len(output_items[0])
class test(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.samp_rate = samp_rate = 32000
self.gr_vector_source_x_0 = gr.vector_source_f((1, 0, 2, 0, 3), True, 5)
self.gr_null_sink_0 =
gr.null_sink(gr.sizeof_float*1)
self.vector_parser = vector_parser()
self.connect((self.gr_vector_source_x_0, 0), (self.vector_parser, 0))
self.connect((self.vector_parser, 0), (self.gr_null_sink_0, 0))
def get_samp_rate(self):
return self.samp_rate
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
if __name__ == '__main__':
tb = test()
tb.Run(True)
Each time I try to run this script I receive the following error:
Traceback (most recent call last):
File "./tone_filter_test.py", line 40, in <module>
tb = test()
File "./tone_filter_test.py", line 28, in __init__
self.vector_parser = vector_parser()
File "./tone_filter_test.py", line 12, in __init__
out_sig = [numpy.float32]
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 2121, in __init__
def __init__(self, *args, **kwargs): raise AttributeError("No
constructor defined")
AttributeError: No constructor defined
Can anyone tell me what is causing this error?
Thanks!
--
Jason
------------------------------
Message: 15
Date: Wed, 15 Feb 2012 16:27:39 -0800
From: Philip Balister <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 02/15/2012 09:41 AM, Jeff Brower wrote:
> Ed-
>
>> On 2/15/12 11:31 AM, Jeff Brower wrote:
>>> ........ GNU Radio is owned by National Instruments .........
>>
>> ????!!!!!
>>
>> You are confusing GnuRadio with Ettus Research.
>>
>> GnuRadio is an open source SDR framework.
>>
>> Ettus is the manufacturer of the USRP series of hardware
>> and the UHD driver libraries to access it.
>
> Ok. I should have said "is owned by" with "substantially depends on"...
Or Ettus found that hiring people active in the GNU Radio community is a
way to recruit excellent SDR people.
There is a similar situation in the Linux
kernel space, the number of
independent kernel developers is dropping slowly with time, because
people that show an ability to contribute code to the kernel are prized
by employers.
Philip
------------------------------
Message: 16
Date: Wed, 15 Feb 2012 16:48:00 -0800
From: Josh Blum <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] gr_sync_block, AttributeError: No
constructor defined
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 02/15/2012 04:22 PM, Jason Bonior wrote:
> I am
trying to create a block using gr.gr_sync_block which will select
> a value from an input vector, pass that value to output, and discard
> the rest of the vector:
>
> !/usr/bin/env python
>
> from gnuradio import gr
> import numpy
>
> class vector_parser(gr.gr_sync_block):
> def __init__(self):
> gr.gr_sync_block.__init__(
This should be gr.sync_block. gr.gr_sync_block is actually the swigged
representation of the c++ class, and I dont think it should be there. Oh
well...
Also, to get this feature you will need to install my next branch or
python_blocks branch. Sorry, writing blocks in python is not a mainline
feature. I hope someday it will be accepted.
This is my git repo with said branches:
git://
gnuradio.org/jblum.githttp://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#Synchronous-Block
-Josh
------------------------------
Message: 17
Date: Wed, 15 Feb 2012 20:07:54 -0500
From: Tom Rondeau <
address@hidden>
To: George Nychis <
address@hidden>
Cc:
address@hidden
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Feb 15, 2012 at 11:52 AM, George Nychis <
address@hidden> wrote:
> A bit late on this conversation... I just noticed it after I posted an
> update for CGRAN.
>
> GNU Radio has been largely successful in the academic community, because
> it provides us the flexibility to perform the style of research we need.
> Ultimately though, the limitations of the framework that were put in place
> to achieve this flexibility, I believe hurt the ability of GNU Radio to
> support more high-end applications. I'm not talking about the lack of
> someone coming around to do it, I'm talking about
the lack of GNU Radio and
> USRP to support many of the current wireless standards today. This is
> going to be slightly biased in my area of research... but, what would be a
> great app? Show interoperability of GNU Radio and 802.11, ZigBee, DECT,
> RFID (thanks Michael), NFC, Bluetooth, etc.
>
> To me, pushing GNU Radio to the next level has never been about building
> the next set of applications on what is currently supported, but really
> pushing the platform to the next level. Being able to support low latency
> applications, support wide ranges of MAC protocols, different PHYs. This
> opens up the ability to build so much more and new on GNU Radio.
>
> I can't express how many times I've gotten personal e-mails about my MAC
> work and about projects on GNU Radio of people wanting to do some pretty
> cool things and I'm just like... "well,
the architecture just doesn't
> support that." For example, meta-data between blocks IMO was something
> brain-dead that should have been in GNU Radio 7 years ago which would have
> really enabled new things to be done with the framework. Instead, it took
> 7 years for stream tags ;) This is functionality that pushes the frame and
> the architecture, that is the kind of stuff that I think will push the
> platform.
>
> So to me, it's not about having the next demodulation block, it's about
> what is going to happen to the architecture and the framework to support an
> 802.11, a ZigBee, DECT, RFID, NFC, Bluetooth, Xbox controller... things
> that people want to play with and showcase the capabilities of the radio.
>
> I think what "we" should be doing is taking what is "hot" in the radio
> world, and asking whether or not it can be supported by GNU Radio
and the
> USRP. I really think that GNU Radio needs to get passed its major
> application being simple streaming or demodulation and really push packet
> radio. Two way low latency communication. Networks, I suppose.
>
> To me, I go "well, in 6 years GNU Radio really hasn't changed" ... has it?
> Yeah, block details, new blocks, the amount of bandwidth from the USRP,
> but like, what has fundamentally pushed the limitations of the system?
>
> Just my 10 cents! I am unbelievably grateful for GNU Radio and the USRP.
> They truly transformed my view of the RF world, the radio, and have given
> me invaluable experience that I would have never gotten on any other
> platform. The community itself is great, and I've been happy to be a part
> of it (in and out) for the past 6 years. That's the reassuring part that
> I'm on your
side, these are just my thoughts on where I wish GNU Radio &
> USRP would go :)
>
Those are fair points, George, but just keep an eye on what's been
happening lately. Yep, we've introduced stream tags, I just included more
control over latency between GR blocks, and we're about to merge in support
for Volk to drastically increase the compute power of the system. And take
a look at the presentations from the last GNU Radio conference,
specifically the event scheduler. All of this is pushing in the direction
of supporting packet communications.
Also, keep in mind that without input from users, developers, and would-be
users, we develop either in the black-box of our own wants and desires. We
respond to those who comes to us with ideas for what's really needed.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/34c06cce/attachment.html>
------------------------------
Message: 18
Date: Thu, 16 Feb 2012 10:21:59 +0900
From: "Wu Ting" <
address@hidden>
To: "'Andrew Davis'" <
address@hidden>,
<
address@hidden>
Subject: Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()
Message-ID:
<011501ccec49$61b06660$25113320$@
comf5.comm.eng.osaka-u.ac.jp>
Content-Type: text/plain; charset="gb2312"
Thanks. This site is helpful. It would be really great if it has some
examples for each function.
Wu
From: Andrew Davis [mailto:
address@hidden]
Sent: 2012?2?15? 14:29
To: Wu Ting;
address@hiddenSubject: Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()
http://gnuradio.org/doc/doxygen/modules.html is a good place to browse what
available.
2012/2/15 Wu Ting <
address@hidden>
Hi Tom,
Thank you very much for your detailed explanation. That really works!
I really want to learn more about GNURadio by myself. But I don?t know how
should I go on. How can I find the right function/module/block for some
specific purpose? Do you have any suggestion?
Thanks again.
Wu
From:
address@hidden [mailto:
address@hidden] On Behalf Of Tom
Rondeau
Sent: 2012?2?15? 0:01
To: Wu Ting
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] About the
use of gr.probe_signal_f()
On Tue, Feb 14, 2012 at 4:00 AM, Wu Ting <
address@hidden.
jp> wrote:
Hi all,
I?m trying to read the real-time value of a stream from USRP. I?m
considering using gr.probe_signal_f, but it seems to not work. I?m really
new to GNURadio, so please forgive me if I ask some stupid question.
My method is like this:
#First generate a source from USRP:
self.source = uhd.usrp_source(device_addr=??,
stream_args=uhd.stream_args(?fc32?, ?sc16?), args=?scalar=1024?)
#change from complex to interleaved short:
op1 = gr.complex_to_interleaved_short()
#change from short to float
op2 = gr.short_to_float()
#create probe
self.probe =
gr.probe_signal_f()
self.connect(self.source, op1, op2, self.probe)
And in a true while loop, I print the value of the probe, but the value is
always 0.0
Could anyone tell me what is the problem? And is there any better way to
realize this function?
Thanks.
Wu
Hi Wu,
A couple of things. First, you're doing one too many operations. You are
going from complex float to short to float. You could just go from complex
to float. There is gr.complex_to_float that will provide two output streams
for I and Q; complex_to_real or complex_to_imag for each stream
independently; of you could use complex_to_mag or complex_to_mag_squared for
the magnitude of the complex number.
Second, and the main reason for your question, is that you are never running
the flow graph. You construct a flow graph using the connect functions,
but
that doesn't start any samples running through it. So, given the class
you've defined here, call it wu_top_block, we need to return an object:
tb = wu_top_block()
Then you need to run the flowgraph:
tb.start()
This will start your system running and collecting data. After this, you
should be able to set a while loop to look at the data:
while(1):
print tb.probe.value()
time.sleep(1000)
So the value get's printed every second.
Something like that.
Tom
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/9de1943a/attachment.html>
------------------------------
Message: 19
Date: Thu, 16 Feb 2012 11:36:17 +0900
From: "Wu Ting" <
address@hidden>
To: <
address@hidden>
Subject: [Discuss-gnuradio] Strange result when using message_sink and
msg.queue
Message-ID:
<014001ccec53$c2dbfee0$4893fca0$@
comf5.comm.eng.osaka-u.ac.jp>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I'm now trying to use message_sink and msg_queue to receive data from USRP.
And I'm having a problem that I cannot figure out. Please tell me where I am
wrong.
####top block:
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args('fc32', 'sc16', args="scalar=1024"))
self.source.set_samp_rate(4e5)
self.queue = gr.msg_queue()
self.sink = gr.message_sink(gr.sizeof_float*2, self.queue, False) #what does
True and False mean here?
self.connect(self.source, self.sink)
###top block
if __name__=="__main__":
tb = probe_this()
tb.start()
while True:
sleep(1)
count = tb.queue.count()
print count
if count>0:
msg = tb.queue.delete_head()
print msg.arg1(), msg.arg2(), msg.length()
The result is like this:
8090
8.0
2172.0 1737616309
8.0 362.0 2896
24536
8.0 724.0 579232724
8.0 362.0 2896
40906
8.0 362.0 289649133
8.0 362.0 289657362
8.0 724.0 579265574
8.0 362.0 289673798
8.0 362.0 289681997
8.0 362.0 289690221
8.0 724.0 5792
98433
8.0 362.0 2896106643
8.0 362.0
2896
114872
8.0 362.0 2896123094
8.0 724.0 5792
131263
8.0 362.0 2896139448
8.0 724.0 5792
147621
8.0 362.0 2896155840
8.0 724.0 5792
164050
8.0 362.0 2896 It seems that the number of data in each message is limited. I hope the
number can be much larger, say, 4e5 data in one message, so that each
message can hold the data of one second.
Anyone can tell me where is the problem and what should I do about it?
Thanks.
Wu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/47a17cd6/attachment.html>
------------------------------
Message:
20
Date: Wed, 15 Feb 2012 19:06:15 -0800 (PST)
From: rmsrms1987 <
address@hidden>
To:
address@hidden
Subject: [Discuss-gnuradio] External Clock set to 64MHz on USRP2/N210
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hello All,
There was a previous project done in my research group where a external
device generates a 64 MHz clock to the USRP1 in addition to a PPS
signal. Currently I am making appropriate changes so a similar project
can be used for the USRP2/N210. I was wondering if the same 64MHz
external clock is connected to the
USRP2, would this override the
default 100MHz master clock? I am still fairly new to the USRP, so this
could be a very trivial question. My understanding right now is that an
external reference clock has to be equal to an integer division of
100MHz (i.e 100MHz/n), but this could be totally wrong. Any advice on
this issue would be greatly appreciated.
Thank you very much,
Rob
--
View this message in context:
http://old.nabble.com/External-Clock-set-to-64MHz-on-USRP2-N210-tp33333495p33333495.html
Sent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 21
Date: Wed, 15 Feb 2012 22:06:00 -0500
From: Tom Rondeau <
address@hidden>
To:
Martin DvH <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] Volk branch on github
Message-ID:
<CA+SzT6iXbBp2w0bT+kZxOTqrWu86v0w+P7zQ68bS=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Feb 15, 2012 at 6:45 AM, Martin DvH <
address@hidden>wrote:
>
> I think it would make sense to change the volk interface by adding
> kernel calls which can handle the two
alignment cases (aligned,
> unaligned).
> We would have to add a is_unaligned parameter to the volk kernel calls.
>
> The gnuradio blocks would then change in the following way:
>
> So in stead of:
>
> if(is_unaligned()) {
> for(size_t i = 1; i < input_items.size(); i++){
> volk_32fc_x2_multiply_32fc_u(out, out, (gr_complex*)input_items[i],
> noi);
> }
> } else {
> for(size_t i = 1; i < input_items.size(); i++){
> volk_32fc_x2_multiply_32fc_a(out, out, (gr_complex*)input_items[i],
> noi);
> }
> }
>
> You would have:
>
> for(size_t i = 1; i < input_items.size(); i++)
> volk_32fc_x2_multiply_32fc(is_unaligned(), out, out,
> (gr_complex*)input_items[i], noi);
>
> You halve the amount of code in gnuradio blocks which to my opinion
>
makes it much more maintainable.
>
>
> Martin
Martin,
I think that's a good idea. The only real question is if we can (easily)
implement it with the runtime dynamics of the Volk calls. It basically
moves the decision from GNU Radio into Volk, but since we're looking at
Volk as behind-the-scenes stuff, it's more logical to place the
responsibility there than expose it to GR block developers.
Thanks,
Tom
> On Wed, 2012-02-15 at 12:06 +0100, Martin DvH wrote:
> > On Tue, 2012-02-14 at 22:56 -0500, Tom Rondeau wrote:
> > > There's been a ton of work going on in getting us ready to really
> > > start using Volk in GNU Radio blocks. Instead of repeating myself,
> > > here, you can see more about the who/what/when/why/how of the changes
> > > here:
> > >
> > >
> > >
>
http://www.trondeau.com/blog/2012/2/13/gnu-radio-is-crap-and-other-such-insights.html
> >
> > I think you copied the wrong link.
> > You probably meant:
> >
>
http://www.trondeau.com/blog/2012/2/13/volk-integration-to-gnu-radio.html
> >
> >
> > Martin
> >
> > >
> > >
> > > The basic summary is that I'm seeing amazing performance results and
> > > I'm very excited to get this into our project.
> > >
> > >
> > > I'm really hoping that people can check out the branch and test it out
> > > against their applications. A number of changes were made inside GNU
> >
> Radio and a handful of blocks have been converted to using Volk, and
> > > I'd like to see how the performance compares. My own tests show great
> > > results, but I have a pretty heterogeneous setup (Linux/Ubuntu and
> > > Intel processors).
> > >
> > >
> > > I should have another post on my website later this week discussing my
> > > benchmark results for the Volk blocks, but anyone interested in
> > > testing it out on their own should check out
> > > gnuradio-examples/python/volk_benchmark. The README in that directory
> > > should help you understand what to do and how to do it.
> > >
> > >
> > > We would like to get this merged into GNU Radio master (and therefore
> > > version 3.5.2) as soon as possible, so I would really appreciate
> > > feedback and bug reports
as soon as possible.
> > >
> > >
> > > Thanks!
> > > Tom
> > >
> > >
> > > _______________________________________________
> > > 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> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/c112563b/attachment.html>
------------------------------
Message: 22
Date: Wed, 15 Feb 2012 22:12:45 -0500
From: Tom Rondeau <
address@hidden>
To:
address@hidden
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Volk branch on
github
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Feb 15, 2012 at 1:27 PM, Josh Blum <
address@hidden> wrote:
>
> > You would have:
> >
> > for(size_t i = 1; i < input_items.size(); i++)
> > volk_32fc_x2_multiply_32fc(is_unaligned(), out, out,
> > (gr_complex*)input_items[i], noi);
> >
> > You halve the amount of code in gnuradio blocks which to my opinion
> > makes it much more maintainable.
> >
>
> Here is a possible solution, I dont
know how viable it is.
>
> 1) Suppose that we have the gotten to a head or tail case where the
> number of samples isnt an alignment multiple or the last call to work
> ended us on a non-aligned boundary.
>
> 2) In an effort to re-align, the scheduler could memcpy the *smallest*
> possible chunk into aligned memory, pad the length, call work, and
> memcpy the result to the output buffer.
>
> 3) Now the next call to work will always be aligned. Also, the work
> function never needs to change, and will always use the aligned call.
>
> I tried to implement this in gr block executor, but got confused trying
> to handle all of the edge cases, like multiple IO ports with different
> data types. And so, how the block would configure the scheduler in the
> most generic of cases isnt clear to me. But, even if it was
> oversimplified, I still think its the better
way to solve 90% of the use
> cases.
>
> Thoughts?
>
> -Josh
Josh,
I already tried this approach. It was the first thing that I went after
when working on the alignment issues with the buffers. It becomes way too
big of a hassle to follow through with it in the end. It only really makes
sense to always move the data to an aligned buffer, but that's too
expensive. Like you ran into, the corner cases and the issues of keeping
track are way too much. It makes the code confusing and fragile.
Also, you never want to work on the smallest amount of memory possible.
This is covered in my discussion on my blog. Making arbitrarily small calls
to work functions causes much more overhead than just running the unaligned
version of a Volk call. I found this out pretty quickly when I started
looking into things. Better to process a large chunk to get back into
alignment than try to handle
calls to small amounts of data.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/a35e4c72/attachment.html>
------------------------------
Message: 23
Date: Wed, 15 Feb 2012 22:20:30 -0500
From: Tom Rondeau <
address@hidden>
To: Wu Ting <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] About the use of
gr.probe_signal_f()
Message-ID:
<CA+SzT6g4Gp-aC4Oaxu=sGfLMbb5z4gJAv=
address@hidden>
Content-Type: text/plain; charset="utf-8"
2012/2/15 Wu Ting <
address@hidden>
> Thanks. This site is helpful. It would be really great if it has some
> examples for each function.****
>
> ** **
>
> Wu
>
Wu,
There are lots of examples, but they don't necessarily cover every block in
GNU Radio. Another place to look, though, is in the QA code. This is code
used during a 'make test/check' to verify that the code produces the
correct results. We _try_ to make QA code cover all cases of a block,
and
they are nice in that they are generally the simplest possible flowgraph
needed to run the block being tested (vector_source_x -> block ->
vector_sink_x).
The QA code can be found in a few different locations. For new top-level
blocks (like gr-digital), you can find it in the 'python' directory. They
are all named with a 'qa_' prefix.
The majority of the QA code, though, is for the blocks in gnuradio-core.
You'll find these in gnuradio-core/src/python/gnuradio/gr. Again with the
'qa_' naming convention.
To run a stand-along QA code, it's easiest if you're using the cmake build,
because it uses ctest to run them. You can run a specific test by using a
regular _expression_ match by passing the -R option to ctest and -V to make
it verbose. Say you wanted to run just the gr_fft_filter test, you can use
'ctest -V -R fft_filter'. The regular _expression_ will match just that code.
You can get
fancier, too, if you want.
Now that you bring it up, since these programs are spread throughout the
code and are not just Python programs you can necessarily just run (since
they work as part of a test suite), I could see a small project set up
using CGRAN and/or Github to hold a set of small programs used just as
examples of a particular block.
Tom
> *From:* Andrew Davis [mailto:
address@hidden]
> *Sent:* 2012?2?15? 14:29
> *To:* Wu Ting;
address@hidden>
> *Subject:* Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()****
>
> ** **
>
>
http://gnuradio.org/doc/doxygen/modules.html is a good place to browse
> what available.****
>
> 2012/2/15 Wu Ting <
address@hidden>****
>
> Hi Tom,****
>
> ****
>
> Thank you very much for your detailed explanation. That really works!****
>
> ****
>
> I really want to learn more about GNURadio by myself. But I don?t know how
> should I go on. How can I find the right function/module/block for some
> specific purpose? Do you have any suggestion?****
>
> ****
>
> Thanks again.****
>
> ****
>
> Wu****
>
> ****
>
> *From:*
address@hidden [mailto:
address@hidden] *On Behalf
> Of *Tom Rondeau
> *Sent:* 2012?2?15? 0:01
> *To:* Wu Ting
> *Cc:*
address@hidden> *Subject:* Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()****
>
> ****
>
> On Tue, Feb 14, 2012 at 4:00 AM, Wu Ting <
>
address@hidden> wrote:****
>
> Hi all,****
>
> ****
>
> I?m trying to read the real-time value of a stream from USRP. I?m
> considering using gr.probe_signal_f, but it seems to
not work. I?m really
> new to GNURadio, so please forgive me if I ask some stupid question.****
>
> ****
>
> My method is like this:****
>
> ****
>
> #First generate a source from USRP:****
>
> self.source = uhd.usrp_source(device_addr=??, stream_args=uhd.stream_args(
> ?fc32?, ?sc16?), args=?scalar=1024?)****
>
> ****
>
> #change from complex to interleaved short:****
>
> op1 = gr.complex_to_interleaved_short()****
>
> ****
>
> #change from short to float****
>
> op2 = gr.short_to_float()****
>
> ****
>
> #create probe****
>
> self.probe = gr.probe_signal_f()****
>
> ****
>
> self.connect(self.source, op1, op2, self.probe)****
>
> ****
>
> And in a true while loop, I print the value of
the probe, but the value is
> always 0.0****
>
> ****
>
> Could anyone tell me what is the problem? And is there any better way to
> realize this function?****
>
> ****
>
> Thanks.****
>
> ****
>
> Wu****
>
> ****
>
> Hi Wu,****
>
> A couple of things. First, you're doing one too many operations. You are
> going from complex float to short to float. You could just go from complex
> to float. There is gr.complex_to_float that will provide two output
> streams for I and Q; complex_to_real or complex_to_imag for each stream
> independently; of you could use complex_to_mag or complex_to_mag_squared
> for the magnitude of the complex number.****
>
> ****
>
> Second, and the main reason for your question, is that you are never
> running the flow
graph. You construct a flow graph using the connect
> functions, but that doesn't start any samples running through it. So, given
> the class you've defined here, call it wu_top_block, we need to return an
> object:****
>
> ****
>
> tb = wu_top_block()****
>
> ****
>
> Then you need to run the flowgraph:****
>
> ****
>
> tb.start()****
>
> ****
>
> This will start your system running and collecting data. After this, you
> should be able to set a while loop to look at the data:****
>
> ****
>
> while(1):****
>
> print tb.probe.value()****
>
> time.sleep(1000)****
>
> ****
>
> So the value get's printed every second.****
>
> ****
>
> Something like
that.****
>
> ****
>
> Tom****
>
> ****
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML
attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/8998110b/attachment.html>
------------------------------
Message: 24
Date: Wed, 15 Feb 2012 22:21:03 -0500
From: Tom Rondeau <
address@hidden>
To:
address@hidden
Cc: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] gr-howto installation issue
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Feb 15, 2012 at 8:55 AM, Achilleas Anastasopoulos <
address@hidden> wrote:
> Tom and others,
>
> I resolved it.
>
> I was NOT building the "gr-howto-write-a-block-cmake", but the
> "gr-howto-write-a-block" so i suppose i was mixing the two builds....
> I have never had boost problems...
> This is on Fedora 15 with the master branch.
>
> thanks
> Achilleas
>
Good to know, thanks!
Tom
> --------------------------------
> Yes, seems like a problem with
Boost, but it's strange that it doesn't
> happen when just building GNU Radio.
>
> Achilleas, when you say you're using the latest trunk, are you talking
> about the master or next branch? I'm assuming the next branch since
> the master branch's "gr-howto-write-a-block" is autotools only and a
> separate "gr-howto-write-a-block-cmake" exists for the cmake build.
>
> Also, what OS?
>
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/d914a44e/attachment.html>
------------------------------
Message: 25
Date: Wed, 15 Feb 2012 22:32:25 -0500
From: Tom Rondeau <
address@hidden>
To: anju babu <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] CPFSK carrier frequency
Message-ID:
<CA+SzT6gDf+Gig-2d1r_GzFrMKnOpeR3Ar8jxS2JsYV+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Feb 15, 2012 at 5:14 AM, anju babu <
address@hidden> wrote:
> hi all,
>
> I'm using gnuradio companion to perform fsk modulation using
> CPFSK
block .in that we don't have an option to set the carrier
> frequency.so can anyone please tell me how can we set the carrrier
> frequency.I'm not using USRP.Also how can we perform FSk demodulation in GRC
>
> Thanks in advance
>
> --
> *ANJU BABU*
Anju,
If you aren't using a USRP, are you using any radio hardware system? If
not, there's really no such thing as a "carrier frequency."
For FSK demodulation, I recommend starting with the GMSK mod/demod block
(in gr-digital/python). You can use a similar technique for FSK with
different filtering and parameters.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/a164083b/attachment.html>
------------------------------
Message: 26
Date: Wed, 15 Feb 2012 20:05:42 -0800
From: Nick Foster <
address@hidden>
To: rmsrms1987 <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] External Clock set to 64MHz on
USRP2/N210
Message-ID:
<CALALHJV2=S8ADcO3sHgx-2owYgsuLNLVD_RM=
address@hidden>
Content-Type: text/plain;
charset="iso-8859-1"
On Wed, Feb 15, 2012 at 7:06 PM, rmsrms1987 <
address@hidden> wrote:
>
> Hello All,
>
> There was a previous project done in my research group where a external
> device generates a 64 MHz clock to the USRP1 in addition to a PPS
> signal. Currently I am making appropriate changes so a similar project
> can be used for the USRP2/N210. I was wondering if the same 64MHz
> external clock is connected to the USRP2, would this override the
> default 100MHz master clock? I am still fairly new to the USRP, so this
> could be a very trivial question. My understanding right now is that an
> external reference clock has to be equal to an integer division of
> 100MHz (i.e 100MHz/n), but this could be totally wrong. Any advice on
> this issue
would be greatly appreciated.
>
USRP2 and N210 were designed to take a 10MHz reference clock, the type
commonly generated by reference oscillators and GPSDOs. It is possible to
use a different frequency which is divisible into 100MHz, but you will have
to modify uhd/host/lib/usrp/usrp2/clock_ctrl.cpp to cope with a different
reference frequency. There is no easy path to getting a 64MHz external
reference into the USRP2/N210.
--n
>
> Thank you very much,
> Rob
> --
> View this message in context:
>
http://old.nabble.com/External-Clock-set-to-64MHz-on-USRP2-N210-tp33333495p33333495.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Discuss-gnuradio mailing
list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120215/6c18c79a/attachment.html>
------------------------------
Message: 27
Date: Thu, 16 Feb 2012 15:27:12 +0900
From: "Wu Ting" <
address@hidden>
To: "'Tom Rondeau'" <
address@hidden>
Cc:
address@hidden
Subject: Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()
Message-ID:
<019801ccec74$04a02f70$0de08e50$@
comf5.comm.eng.osaka-u.ac.jp>
Content-Type: text/plain; charset="utf-8"
Hi Tom,
Thank you for your information. Reading examples are currently a major way for me to learn GR. I will try to read and run the QA code as you introduced.
Wu
From:
address@hidden [mailto:
address@hidden] On Behalf Of Tom Rondeau
Sent: 2012?2?16? 12:21
To: Wu Ting
Cc: Andrew Davis;
address@hiddenSubject: Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()
2012/2/15 Wu Ting <
address@hidden>
Thanks. This site is helpful. It would be really great if it has some examples for each function.
Wu
Wu,
There are lots of examples, but they don't necessarily cover every block in GNU Radio. Another place to look, though, is in the QA code. This is code used during a 'make test/check' to verify that the code produces the correct results. We _try_ to make QA code cover all cases of a block, and they are nice in that they are generally the simplest possible flowgraph needed to run the block being tested (vector_source_x ->
block -> vector_sink_x).
The QA code can be found in a few different locations. For new top-level blocks (like gr-digital), you can find it in the 'python' directory. They are all named with a 'qa_' prefix.
The majority of the QA code, though, is for the blocks in gnuradio-core. You'll find these in gnuradio-core/src/python/gnuradio/gr. Again with the 'qa_' naming convention.
To run a stand-along QA code, it's easiest if you're using the cmake build, because it uses ctest to run them. You can run a specific test by using a regular _expression_ match by passing the -R option to ctest and -V to make it verbose. Say you wanted to run just the gr_fft_filter test, you can use 'ctest -V -R fft_filter'. The regular _expression_ will match just that code. You can get fancier, too, if you want.
Now that you bring it up, since these programs are spread throughout the code and are not just Python
programs you can necessarily just run (since they work as part of a test suite), I could see a small project set up using CGRAN and/or Github to hold a set of small programs used just as examples of a particular block.
Tom
From: Andrew Davis [mailto:
address@hidden]
Sent: 2012?2?15? 14:29
To: Wu Ting;
address@hidden
Subject: Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()
http://gnuradio.org/doc/doxygen/modules.html is a good place to browse what available.
2012/2/15 Wu Ting <
address@hidden>
Hi Tom,
Thank you very much for your detailed explanation. That really works!
I really want to learn more about GNURadio by myself. But I don?t know how should I go on. How can I find the right function/module/block for some specific purpose? Do you have any suggestion?
Thanks again.
Wu
From:
address@hidden [mailto:
address@hidden] On Behalf Of Tom Rondeau
Sent: 2012?2?15? 0:01
To: Wu Ting
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] About the use of
gr.probe_signal_f()
On Tue, Feb 14, 2012 at 4:00 AM, Wu Ting <
address@hidden> wrote:
Hi all,
I?m trying to read the real-time value of a stream from USRP. I?m considering using gr.probe_signal_f, but it seems to not work. I?m really new to GNURadio, so please forgive me if I ask some stupid question.
My method is like this:
#First generate a source from USRP:
self.source = uhd.usrp_source(device_addr=??, stream_args=uhd.stream_args(?fc32?, ?sc16?), args=?scalar=1024?)
#change from complex to interleaved short:
op1 = gr.complex_to_interleaved_short()
#change from short to float
op2 = gr.short_to_float()
#create probe
self.probe = gr.probe_signal_f()
self.connect(self.source, op1, op2, self.probe)
And in a true while loop, I print the value of the probe, but the value is always 0.0
Could anyone tell me what is the problem? And is there any better way to realize this function?
Thanks.
Wu
Hi Wu,
A couple of things. First, you're doing one too many operations. You are going from complex float to short to float. You could just go from complex to float. There is gr.complex_to_float that will provide two output streams for I and Q; complex_to_real or complex_to_imag for each stream independently; of you could use complex_to_mag or complex_to_mag_squared for the magnitude of the complex number.
Second, and the main reason for your question, is that you are never running the flow graph. You construct a flow graph using the connect functions, but that doesn't start any samples running through
it. So, given the class you've defined here, call it wu_top_block, we need to return an object:
tb = wu_top_block()
Then you need to run the flowgraph:
tb.start()
This will start your system running and collecting data. After this, you should be able to set a while loop to look at the data:
while(1):
print tb.probe.value()
time.sleep(1000)
So the value get's printed every second.
Something like that.
Tom
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/f247a3f2/attachment.html>
------------------------------
Message: 28
Date: Thu, 16 Feb 2012 14:52:28 +0100
From: Jens Elsner <
address@hidden>
To: <
address@hidden>
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed
Andrew,
Am 15.02.2012 19:41, schrieb Andrew Davis:
> Well some major GNUradio program would drive up sales of USRP's :)
>
> Back on topic, IMHO Gnuradio's problem with large apps stems from it
> trying to be the source to sink and everything in?between?of a radio.
> Lets take DREAM for example, they do transfer functions and digital
> AGC and the likes that GNUradio by design should not do.
If you could elaborate on this
point - why should GNU Radio not
implement
channel equalization (I assume that's what you mean?) or digital AGC?
> If you want
> to re-write DREAM with GNUradio you will end up writing about +200
> blocks, not much fun.
Since I suggested this particular project, I obviously cannot agree.
:-)
Pulling the code base into GNU Radio might be a nice addition to
the available receivers and it can be useful for all amateur radio
operators world wide.
Plus DRM is broadcasting so we don't need to worry about timing issues,
a real drawback of GNU Radio (and high level SDR in general).
How fine the signal processing chain needs to be chopped up is a
matter of taste and performance, I believe.
> What people want is simple input to there
> program and a simple output API, not there entire program. They?don't
> what to figure out how to write a GNURadio block or know
anything
> about the complexities of GNURadio. They want to say "get me a signal
> at 100MHz, filter and?interpolate to 1ksp?with these cutoff
> frequencies?then send me the data and let me do the rest", no need to
> know anything about GNURadio, what other API makes you learn as much
> about it?
I am not sure I understand your point here. That is not GNU Radio, I
see GNU Radio as a scheduler with a big collection of signal processing
blocks attached.
[...]
> Back to DREAM,
> a lot of the filters, audio input/output, signal conditioning, etc
> could be in GNURadio, but a lot of the middle section cannot.
> GNURadio
Then it would be nice to find out what exactly is lacking to add this
to GNU Radio.
> can not be the whole program, just helper?functions?in big programs
> like this. Only about %20 of DREAM could be replaced with GNURadio
>
API
> calls, but instead you will have to rewrite it %100 as GNURadio
> blocks
> with the current block to block only mentality </rant>
I don't agree. We'll hopefully settle the matter some day. :-)
Jens
------------------------------
Message: 29
Date: Thu, 16 Feb 2012 09:02:37 -0500
From: Andrew Davis <
address@hidden>
To: Jens Elsner <
address@hidden>,
address@hiddenSubject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
>I don't agree. We'll hopefully settle the matter some day. :-)
Me too, DREAM is an amazing SDR program that could benefit from
GNURadio and show off GNURadio as-well. But this idea has been batted
around before and never really develops, possibly due to the way
GNURadio is currently setup. When I get some free time i'll continue
getting some of the python examples ported to C++, so that potential
developers who prefer C over python can see how things can be done
from C world. I think this will get people who find GNURadio to start
porting other C based programs to the GNURadio framework.
On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner <
address@hidden> wrote:
> Andrew,
>
> Am 15.02.2012 19:41, schrieb Andrew Davis:
>
>> Well some major GNUradio program would drive up sales of USRP's :)
>>
>> Back on topic, IMHO Gnuradio's problem with large apps stems from it
>> trying to be the source to sink and everything in?between?of a radio.
>
>
>> Lets take DREAM for example, they do transfer functions and digital
>> AGC and the likes that GNUradio by design should not do.
>
>
> If you could elaborate on this point - why should GNU Radio not implement
> channel equalization (I assume that's what you mean?) or digital AGC?
>
>
>> If you want
>> to re-write DREAM with GNUradio you will end up writing about +200
>> blocks, not much fun.
>
>
> Since I suggested this particular project,
I obviously cannot agree. :-)
>
> Pulling the code base into GNU Radio might be a nice addition to
> the available receivers and it can be useful for all amateur radio
> operators world wide.
>
> Plus DRM is broadcasting so we don't need to worry about timing issues,
> a real drawback of GNU Radio (and high level SDR in general).
>
> How fine the signal processing chain needs to be chopped up is a
> matter of taste and performance, I believe.
>
>
>> What people want is simple input to there
>> program and a simple output API, not there entire program. They?don't
>> what to figure out how to write a GNURadio block or know anything
>> about the complexities of GNURadio. They want to say "get me a signal
>> at 100MHz, filter and?interpolate to 1ksp?with these cutoff
>> frequencies?then send me the data and let me do the rest", no
need to
>> know anything about GNURadio, what other API makes you learn as much
>> about it?
>
>
> I am not sure I understand your point here. That is not GNU Radio, I
> see GNU Radio as a scheduler with a big collection of signal processing
> blocks attached.
>
> [...]
>
>
>> Back to DREAM,
>> a lot of the filters, audio input/output, signal conditioning, etc
>> could be in GNURadio, but a lot of the middle section cannot. GNURadio
>
>
> Then it would be nice to find out what exactly is lacking to add this
> to GNU Radio.
>
>
>> can not be the whole program, just helper?functions?in big programs
>> like this. Only about %20 of DREAM could be replaced with GNURadio API
>> calls, but instead you will have to rewrite it %100 as GNURadio blocks
>> with the current block to block only
mentality </rant>
>
>
> I don't agree. We'll hopefully settle the matter some day. :-)
>
> Jens
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 30
Date: Thu, 16 Feb 2012 14:41:15 +0000 (GMT)
From: guelord ingala <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] USRP
Request
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="utf-8"
I started a new project involving GNURadio and USRP.
I'm using
Ubuntu 11.10 and GNU Radio Companion v3.5.1-9-g4beff39a. The hardwares
I've got are: 2 units of USRP1 Rev 4.1 and DBSRX Rev2.1.
I've got 2 questions:
1. These versions of USRP and daughter boards are still compatible with the version of the software above?
2. Could you please show me how to set the USRP-Source in the Gnuradio-companion so that to target each daughter boards.
For your information, the 2 USRP's were long ago synchronized as master and slave. So I've got 4 units of DBSRX daughters boards.
You help will be
positively appreciated.
Dominique
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/f81d5ea8/attachment.html>
------------------------------
Message: 31
Date: Thu, 16 Feb 2012 10:50:06 -0500
From: Tom Rondeau <
address@hidden>
To: GNURadio Discussion List <
address@hidden>
Subject: [Discuss-gnuradio] Reminder about call today
Message-ID:
<CA+SzT6i0Zmcm3ev5crSXc4R1cfPXNUkMg-8fg7Dz+r=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
This is just a reminder about today's Developers' Call. Due to other
conflicts, the time has been changed from the normal time to 1600 EST or
2100 UTC.
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216We'll probably want to spend a significant amount of time on discussing the
projects we want to put forward for the GSoC, so please join us if you are
interested in participating.
Thanks,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/c0d1db66/attachment.html>
------------------------------
Message: 32
Date: Thu, 16 Feb 2012 11:06:43 -0500
From: George Nychis <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] Reminder about call today
Message-ID:
<CA+7oygePBm3BPesFdc2uVwAUjxXRkrhQ+
address@hidden>
Content-Type: text/plain;
charset="iso-8859-1"
Hey all,
I actually really want to join the call, because I have a GSoC idea, but I
have a conflict with teaching assistant duties during that time.
So I thought I'd briefly share, and if it does become of interest then
maybe someone can get ahold of me and I could try to mentor or something.
I thought it might be cool to show that GNU Radio and the USRPP can be
more than just about wireless technology, pushing forward on a hot topic
recently: PowerLine networking.
I've been trying to dig up details of PowerLine implementations, but I
think they are typically very "wireless PHY" oriented. I think they are in
general OFDM based with Turbo Convolutional Codes. I think that GNU Radio
already provides a lot of the blocks that would be necessary to build the
PHY. I am not sure of what the necessary frontend might be for this, but
maybe by the summer if Matt and GNU
Radio folks are truly interested, a
prototype could be made.
Some info i found on PowerLine details:
http://helpfromageek.com/2011/05/18/white-paper-powerline-networking/
On Thu, Feb 16, 2012 at 10:50 AM, Tom Rondeau <
address@hidden> wrote:
> This is just a reminder about today's Developers' Call. Due to other
> conflicts, the time has been changed from the normal time to 1600 EST or
> 2100 UTC.
>
>
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216
>
> We'll probably want to spend a significant amount of time on discussing
> the projects we want to put forward for the GSoC, so please join
us if you
> are interested in participating.
>
> Thanks,
> Tom
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/ffba5101/attachment.html>
------------------------------
Message: 33
Date: Thu, 16 Feb 2012 17:39:10 +0100
From: Martin Braun <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] GRC: Just compile XML, no GUI
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi (most likely Josh),
I was wondering if it's a big deal to give gnuradio-companion a switch
to just compile a .grc file without firing up the GUI.
Specifically, I was hoping to have unit tests for GRC files, so I wanted
to automatically use the GRC checking features to test .grc files.
However, I started digging in the code... and it seems to be very
closely intertwined with the GUI.
And, to be honest, I got a bit lost in
there :)
So, something like direct access to the Generator class would be
great. Any hints?
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone:
+49 721 608-43790
Fax:
+49 721 608-46071www.cel.kit.eduKIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/999a9426/attachment.pgp>
------------------------------
Message: 34
Date: Thu, 16 Feb 2012 11:49:10 -0500
From: Achilleas Anastasopoulos <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] problem building
gr-howto-write-a-block-cmake
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
OK, I am having a problem building the howto module with CMake.
Here is the output of all the steps:
address@hidden build]$ cmake ../
-- The CXX compiler identification is GNU
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.46.0
-- checking for module 'gruel'
-- found gruel, version 3.5.2git
-- Found GRUEL: /usr/local/lib64/libgruel.so
-- checking for module 'gnuradio-core'
-- found gnuradio-core, version 3.5.2git
-- Found
GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so
-- Boost version: 1.46.0
-- Found the following Boost libraries:
-- unit_test_framework
-- Found SWIG: /usr/bin/swig (found version "2.0.4")
-- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES)
-- Found PythonInterp: /usr/bin/python2.7
-- Found Doxygen: /usr/bin/doxygen
-- Configuring done
-- Generating done
-- Build files have been written to:
/n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build
Then
address@hidden build]$ make
[ 12%] Building CXX object
lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o
[ 25%] Building CXX object
lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o
[ 37%] Building CXX object
lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o
Linking CXX shared library libgnuradio-howto.so
[ 37%] Built target gnuradio-howto
[ 50%]
Building CXX object
lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o
Linking CXX executable qa_howto_square2_ff
[ 50%] Built target qa_howto_square2_ff
[ 62%] Building CXX object
lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o
Linking CXX executable qa_howto_square_ff
[ 62%] Built target qa_howto_square_ff
[ 62%] Generating __init__.pyc
[ 62%] Generating __init__.pyo
[ 87%] Built target pygen_python_6b399
[ 87%] Shebangin howto_square.py
[100%] Built target pygen_apps_19307
Then
address@hidden build]$ sudo make install
Built target gnuradio-howto
Built target qa_howto_square2_ff
Built target qa_howto_square_ff
Built target pygen_python_6b399
Built target pygen_apps_19307
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/include/howto/howto_api.h
-- Installing: /usr/local/include/howto/howto_square_ff.h
--
Installing: /usr/local/include/howto/howto_square2_ff.h
-- Installing: /usr/local/lib64/libgnuradio-howto.so
-- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so"
-- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.py
-- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc
-- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo
-- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml
-- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml
-- Installing: /usr/local/bin/howto_square.py
Now in python I try:
address@hidden build]$ python
Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16)
[GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import howto
Traceback (most recent call last):
File "<stdin>", line
1, in <module>
File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py",
line 45, in <module>
from howto_swig import *
ImportError: No module named howto_swig
The module howto_swig is missing....
Any thoughts?
thanks
Achilleas
------------------------------
Message: 35
Date: Thu, 16 Feb 2012 11:57:31 -0500
From: Achilleas Anastasopoulos <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] problem building
gr-howto-write-a-block-cmake
Message-ID:
<CADpWGZ3rKmT=nT1oZ6QZ_6KPQucLjSv14u+M+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
BTW, I forgot to say that I am building from the latest master branch
and I have already built/installed the latest gnuradio from
the master branch.
Achilleas
On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos
<
address@hidden> wrote:
> OK, I am having a problem building the howto module with CMake.
>
> Here is the output of all the steps:
>
>
> address@hidden build]$ cmake ../
> -- The CXX compiler identification is GNU
> -- Check for working CXX compiler: /usr/lib64/ccache/c++
> -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
>
-- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.46.0
> -- checking for module 'gruel'
> -- ? found gruel, version 3.5.2git
> -- Found GRUEL: /usr/local/lib64/libgruel.so
> -- checking for module 'gnuradio-core'
> -- ? found gnuradio-core, version 3.5.2git
> -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so
> -- Boost version: 1.46.0
> -- Found the following Boost libraries:
> -- ? unit_test_framework
> -- Found SWIG: /usr/bin/swig (found version "2.0.4")
> -- Could NOT find PythonLibs (missing: ?PYTHON_LIBRARIES)
> -- Found PythonInterp: /usr/bin/python2.7
> -- Found Doxygen: /usr/bin/doxygen
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
>
/n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build
>
>
> Then
>
>
>
> address@hidden build]$ make
> [ 12%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o
> [ 25%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o
> [ 37%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o
> Linking CXX shared library libgnuradio-howto.so
> [ 37%] Built target gnuradio-howto
> [ 50%] Building CXX object
> lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o
> Linking CXX executable qa_howto_square2_ff
> [ 50%] Built target qa_howto_square2_ff
> [ 62%] Building CXX object
> lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o
> Linking CXX executable qa_howto_square_ff
> [ 62%] Built target
qa_howto_square_ff
> [ 62%] Generating __init__.pyc
> [ 62%] Generating __init__.pyo
> [ 87%] Built target pygen_python_6b399
> [ 87%] Shebangin howto_square.py
> [100%] Built target pygen_apps_19307
>
>
> Then
>
>
> address@hidden build]$ sudo make install
> Built target gnuradio-howto
> Built target qa_howto_square2_ff
> Built target qa_howto_square_ff
> Built target pygen_python_6b399
> Built target pygen_apps_19307
> Install the project...
> -- Install configuration: "Release"
> -- Installing: /usr/local/include/howto/howto_api.h
> -- Installing: /usr/local/include/howto/howto_square_ff.h
> -- Installing: /usr/local/include/howto/howto_square2_ff.h
> -- Installing: /usr/local/lib64/libgnuradio-howto.so
> -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so"
> -- Installing:
/usr/local/lib64/python2.7/site-packages/howto/__init__.py
> -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc
> -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo
> -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml
> -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml
> -- Installing: /usr/local/bin/howto_square.py
>
>
> Now in python I try:
>
> address@hidden build]$ python
> Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16)
> [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import howto
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ?File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py",
> line 45, in
<module>
> ? ?from howto_swig import *
> ImportError: No module named howto_swig
>
>
> The module howto_swig is missing....
> Any thoughts?
>
> thanks
> Achilleas
------------------------------
Message: 36
Date: Thu, 16 Feb 2012 17:57:46 +0100
From: Martin Braun <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] problem building
gr-howto-write-a-block-cmake
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Thu, Feb 16,
2012 at 11:49:10AM -0500, Achilleas Anastasopoulos wrote:
> >>> import howto
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py",
> line 45, in <module>
> from howto_swig import *
> ImportError: No module named howto_swig
>
Hi Achilleas,
stupid question, but did you try 'sudo ldconfig'?
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone:
+49 721 608-43790
Fax:
+49 721 608-46071www.cel.kit.eduKIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part
--------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120216/4dc95a73/attachment.pgp>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 111, Issue 17
*************************************************