Re: [Discuss-gnuradio] Python function processing block
Thanks Eric.sox will get me started but I would eventually like my application to be able to open wav files. Unfortunately the Python wave library limits the sample size to 16 bits - OK for USRP but not for HPSDR. I have a feature request in at python.org to expand it. I'm still struggling to get my head around GNU Radio but I see a network source as having a single output and a sink as having a single input. If you want to split or combine then subclass hier_block to do the job. Also, I see the network blocks operating at a higher level than raw sockets. As for the data types, it should deal with a range of them appropriately and transparently. The source output type should be whatever was pumped into the sink at the other end. If the flow graph mechanism is too rigid for that then have different classes for different data types.In terms of performance, I would have thought that if you can play wave files in Python (you can) then it's probably fast
enough as a wave source. Network I/O should be more of a bottleneck than Python. (I must research on-the-fly compression.)I have skimmed through howto-write-a-block.html but need to understand the relationship between Python and C++ better to make use of it (I have a rudimentary understanding of SWIG). The occasional evening time-slice that I get to devote to this stuff just doesn't make for rapid progress. Cheers,MurrayVK6HLEric Blossom <[EMAIL PROTECTED]> wrote: On Tue, Oct 17, 2006 at 02:31:28PM +1000, Murray Lang wrote:> How did you go Marcus?> > I hunted high and low for a class that I could subclass to implement> a gr.block in Python. My initial reason is that I want to implement> a source that reads I/Q data from WAV files so that I can compare my> GNU Radio results
with PowerSDR using exactly the same data. Wav> files are much easier to work with in Python than C++.The easiest thing may be to convert the WAV files with sox.I think something like this will work: $ sox -V foo.wav -f foo.rawand foo.raw will end up with floating point values.If the input has two channels, then I think you'll get interleavedfloats as output, which is equivalant to gr_complex (== std::complex)> I would also like to implement network data sources and sinks for> remote SDR operation. Network programming is much easier in Python> than in C++.Agreed. Just open the sockets in python then pass the correspondingfile descriptors (s.fileno()) to gr.file_descriptor_{sink,source}.> In short it seems to me perfectly natural to have a gr.block class> implemented in Python, particularly (but not only) sources and> sinks. It would be really nice if there
was a Python class that we> could simply subclass to achieve that.It's natural, but will be dog slow ;)If that doesn't scare you off, then the next question is what i/o signature do you want to use? Will the blockaccept a single input and produce a single output, or will it accept avarying number of inputs and produce a varying number of outputs?I can imagine several common cases: float -> float complex -> complex float -> complex complex -> floatWould you expect your python code to accept input and produceoutput a single sample at a time, or to deal with arrays of input andoutput samples?If you haven't already, please take a look at http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.htmlThough it's C++ centric, the same issues will exist in a pythonimplementation. After reading that, please ask the question again,and I can provide further
assistance.> Murray> VK6HLEric Send instant messages to your online friends http://au.messenger.yahoo.com ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python function processing block
How did you go Marcus?I hunted high and low for a class that I could subclass to implement a gr.block in Python. My initial reason is that I want to implement a source that reads I/Q data from WAV files so that I can compare my GNU Radio results with PowerSDR using exactly the same data. Wav files are much easier to work with in Python than C++.I would also like to implement network data sources and sinks for remote SDR operation. Network programming is much easier in Python than in C++.In short it seems to me perfectly natural to have a gr.block class implemented in Python, particularly (but not only) sources and sinks. It would be really nice if there was a Python class that we could simply subclass to achieve that.MurrayVK6HL Do you Yahoo!? Join the Girlfriend magazine VIP Club for inside info, freebies and more ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compile source code on Fedora Core 5
I'm a beginner as well - about 2 or 3 days ahead of you it would seem. Murray At 10:20 PM 29/09/2006, Tarun Tiwari wrote: Thanks a lot. I can see there are lot of things to install in FC5 and for that one need to have admin privilages. As a beginner, which version of fedora core I should prefer for the gnu radio development. Should I proceed forward with the network computer or get one standalone computer? On 9/29/06, Murray Lang <[EMAIL PROTECTED]> wrote: I ran "su root" in the terminal window to give me admin priviledges for the build. By the way the statement that Fedora Core 5 is known to be shipped with all the dependencies doesn't tally with my experience. FTTW is missing as is wxPython. If you want Doxygen documentation you'll need to download the *source* for doxygen and build it because the binaries have a dependency on an older version of the standard C++ library than is shipped with FC5. I think there were other things missing as well but I've lost track because I've downloaded a lot of extra stuff to build as much as I can of gnuradio. I've had no problems except for version mismatches with portaudio and jack, which I've let go for now. Now all I need to do is understand it! Cheers Murray VK6HL ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Suggestion re svn:eol-style for configure and bootstrap
Hi Don At 03:30 AM 1/10/2006, Don Ward wrote: Murray Lang wrote: Can I suggest that the svn:eol-style attribute be changed from "native" to "CR" for ./configure and ./bootstrap. Did you mean "LF"? Ok, I was going from memory and mixed up CR with LF. They aren't going to be much use for Windows builds anyway. It's a trap for young players who svn at work on their Windows machines (because their dialup at home is slow). Bash barfs on unexpected "^M" (LF). It took me a while to nut that one Whose bash? Cygwin? MSYS? Other? And which svn? (And I think you mean "^M"(CR).) Bash on Fedora. I've tried both Tigris and Tortoise on Windows. When changing the eol-style at my end didn't work I discussed it with my IT guys, who said that the style needs to be applied at the svn host, not the client. Yes, I could have used unix2dos but it seems to me that fixing the style for shell scripts isn't going to hurt anyone because *native* Windows tools aren't going to use them anyway. I think native Windows compilers can deal with unix style source files (though I'm not %100 certain of that), so they can be left as is. In the end I ssh'ed to a unix machine here and ran svn from there, but I thought I'd post this so that anyone searching for info on the same problem will find something. Murray ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Suggestion re svn:eol-style for configure and bootstrap
Hi Can I suggest that the svn:eol-style attribute be changed from "native" to "CR" for ./configure and ./bootstrap. They aren't going to be much use for Windows builds anyway. It's a trap for young players who svn at work on their Windows machines (because their dialup at home is slow). Bash barfs on unexpected "^M" (LF). It took me a while to nut that one out. Why am I not surprised that the bash authors haven't bothered to deal with CRLFs even after all this time? Murray VK6HL ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compile source code on Fedora Core 5
I ran "su root" in the terminal window to give me admin priviledges for the build. By the way the statement that Fedora Core 5 is known to be shipped with all the dependencies doesn't tally with my experience. FTTW is missing as is wxPython. If you want Doxygen documentation you'll need to download the *source* for doxygen and build it because the binaries have a dependency on an older version of the standard C++ library than is shipped with FC5. I think there were other things missing as well but I've lost track because I've downloaded a lot of extra stuff to build as much as I can of gnuradio. I've had no problems except for version mismatches with portaudio and jack, which I've let go for now. Now all I need to do is understand it! Cheers Murray VK6HL At 02:23 PM 29/09/2006, Tarun Tiwari wrote: Can somebody enlighten me regarding authorization level for a user on network computer running on Fedora Core 5. Does it need root access to the network computer for GNU Radio development? If always not, then what is the other option for that? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
