Re: Complex in/Complex out Hilbert?

Perhaps I'm misunderstanding what you're saying, but isn't the received signal already analytic? The goal is to step it down to real baseband. You don't need a Hilbert transform going in that direction. So, to demodulate, you'd just spin the signal to baseband, filter, and throw away the imaginary

Re: Generating CW-morse signals with a straight key

from a file" > > -- Cinaed > > > > On 12/28/19 11:18 AM, Frank Brickle wrote: > > Is there a JACK audio sink in Gnuradio these days? > > > > I'm not sure where they are housed, now, but I wrote a few programs to > > generate CW this way some years ago.

Re: Generating CW-morse signals with a straight key

Is there a JACK audio sink in Gnuradio these days? I'm not sure where they are housed, now, but I wrote a few programs to generate CW this way some years ago. They depended on having JACK audio input to the application. One of them could use either a straight key or would work as a decent iambic k

Re: [Discuss-gnuradio]JT65

Hi Don -- On Wed, Sep 8, 2010 at 3:58 PM, Don Latham wrote: > Has anyone made a gnu radio hook to JT65 for moonbounce? Something like > MAP65 that hooks to Linrad? > Is there (shudder) a Linrad implementation for the USRP1? > Sad to say, what you're asking for *ought* to be pretty easy to provi

Re: [Discuss-gnuradio] Free Signal Analysis Tool

You might get something useful out of ipython, scipy, and matplotlib. Frank On Thu, Aug 5, 2010 at 9:12 PM, Isaac Gerg wrote: > Does anyone know of a free software tool or package that allows one to do > signal analysis. Im looking for something that I can handle at least a > million samples g

Re: [Discuss-gnuradio] Piping output of, e.g., Audacity to GNURadio examples

On Wed, May 26, 2010 at 7:37 PM, Joel Koltner wrote: > -- For GNURadio examples that are expecting to receive their input from a > sound card, use the JACK plug-in for ALSA... Right... > -- If writing your own applications, GNURadio can use JACK directly via, > e.g., gnuradio-audio-jack ...als

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

On Tue, Mar 10, 2009 at 11:10 AM, Marcus D. Leech wrote: > OK, so I decided to use the averaging method, rather than the maximum > method. It produces reasonably good looking plots: > > http://www.science-radio-labs.com/files/spectral_example.ps True, not bad. One surprise, though -- what's t

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

On Tue, Mar 10, 2009 at 10:02 AM, John Ackermann N8UR wrote: > Just remember -- absinthe makes the tart grow blonder. Sigh. With fronds like these, who needs anemones? (Sorry -- done now.) Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staffing deci

Re: Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

On Tue, Mar 10, 2009 at 9:39 AM, wrote: Oh horrors. Please let it not be true that the phrase I am remembered most > for is heuristic grass. Isn't heuristic grass what gives absinthe the green color? Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staf

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

On Mon, Mar 9, 2009 at 1:08 PM, Bob McGwier wrote: > So, pardon me but, is this a pretty picture exercise or a real detection > problem? If it is a detection problem, then you might as well just > compress to the largest value in the bins to be pushed together so you > assure that your thres

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

On Mon, Mar 9, 2009 at 8:49 AM, Bob McGwier wrote: > Let [B1, B2, B3, B4, ... BN] be powers of five adjacent bins. > > Put them in rank order > > [R1, R2, R3, R4, ... RN] > > If N is even, the rank order mean is (R_(N/2) + R_/(N/2 +1))*0.5. > If N is odd, the rank order mean is R_(N/2 +0.5)

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

On Sun, Mar 8, 2009 at 6:13 PM, Marcus D. Leech wrote: Seems to me that if I have 4000 1Hz-wide bins, I should sum them to give > me the total power in a single bin that > "represents" the same amount of bandwidth. But is it more subtle than > that? As usual, yes and no. If you're concerned

[Discuss-gnuradio] Re: [dttsp-linux] Intel ATOM WHOOAAAAA Nellie

On Thu, Feb 19, 2009 at 11:17 PM, Bob McGwier wrote: ...HOWEVER, for those folks who want to build an small board computer for > supporting the Flex family of firewire devices, the Intel motherboards > are your only choice. You need the PCI slot to get the firewire support... For DttSP apps i

Re: [Discuss-gnuradio] Filterbank stuff

On Fri, Feb 13, 2009 at 10:28 AM, Marcus D. Leech wrote: > So, just feed the audio as if it's a baseband signal right into the > USRP? Or do I need to put it through an SSB modulator > first? You'll want to modulate it. WSJT gives real output. Of course "modulating" here means not much more

Re: [Discuss-gnuradio] Filterbank stuff

On Thu, Feb 12, 2009 at 11:15 PM, Bob McGwier wrote: > WSJT uses portaudio directly and that can talk to jack through its > portaudio host if jack has been compiled with that support in it. Ideally, yes. However, unless some of the WSJT code has been rewritten, despite appearances, you're limi

Re: [Discuss-gnuradio] Filterbank stuff

On Thu, Feb 12, 2009 at 7:59 PM, Marcus D. Leech wrote: > I'm looking into this for a friend who wants to use his USRP2 for EME. > I'll see if I can do something JT65-like (or exactly that!) > in Gnu Radio. You should be able to just use it via portaudio on top of JACK, talking to the USRP th

Re: [Discuss-gnuradio] usrp_siggen.py underruns

On Wed, Feb 11, 2009 at 6:03 PM, Eric Blossom wrote: > Are you really trying to use the Gaussian PRNG? If so you'll have to > fix it. If you look at the code for it, you'll see that it samples a > distribution until it gets something it likes. A classical reference for fast generation of ran

Re: [Discuss-gnuradio] CGRAN downtime

On Tue, Feb 10, 2009 at 11:44 PM, George Nychis wrote: > > But eek, what I meant was: > https://www.cgran.org/svn/ > > rather than: > https://www.cgran.org/cgran/ > > I don't think I can have the base URL used for both SVN and web. > > Still legit? Definitely. Frank -- When small birds sig

Re: [Discuss-gnuradio] CGRAN downtime

On Tue, Feb 10, 2009 at 11:12 PM, George Nychis wrote: > Due to this, I could make our base SVN URL: > https://www.cgran.org/ > > ...instead of: > https://www.cgran.org/cgran/ > > But, this would mean that everyone would need to re-checkout anything > outstanding. I think our biggest user set i

Re: [Discuss-gnuradio] Intel Atom is NICE.

On Sun, Jan 11, 2009 at 3:00 PM, Bob McGwier wrote: > IF ANYONE CAN SHOW ME WHERE IN THE INSTRUCTIONS IT SAYS THIS IS A TWO PASS > PROCESS OR WHERE DURING THE COURSE OF DOING THE FLASH IT SAYS THIS IS A TWO > STEP PROCESS, I WOULD BE PLEASED TO BE TOLD I AM BLIND. Well, sort of. I'd posted a n

[Discuss-gnuradio] Re: [dttsp-linux] Fwd: Ubuntu 8.10

8.10 seems to be delivering equal or better performance to 8.04 except in two areas: (1) Java (2) hardware functions that need proprietary binary drivers (video, wireless). 73 Frank AB2KT On Sun, Nov 23, 2008 at 12:41 AM, n4hy <[EMAIL PROTECTED]> wrote: > Leif runs Linrad and is a code efficienc

Re: [Discuss-gnuradio] updated BBN 80211 code?

On Thu, Oct 16, 2008 at 10:02 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: > > The understanding, then, is that it's explicitly OK for non-FSF-assigned > > code to go into dev branches of the official repo. That's news to me, and > > I'm glad to have it cleared up. > > Nope, sorry for the confusio

Re: [Discuss-gnuradio] updated BBN 80211 code?

On Wed, Oct 15, 2008 at 11:20 PM, Eric Blossom <[EMAIL PROTECTED]> wrote: > Do you mean that your code can't go in the repo, or that Orange can't > go in the repo? I see no problem having code in the repo use Orange. You're describing an approach to the dev branches -- here and below -- that's

Re: [Discuss-gnuradio] updated BBN 80211 code?

On Wed, Oct 15, 2008 at 9:11 AM, Greg Troxel <[EMAIL PROTECTED]> wrote: > So I think the top-level question is whether CGRAN is for code that > isn't assigned. I think that's the only thing that makes sense; people > with assignments can more or less work directly in the gnuradio.org > repositor

Re: [Discuss-gnuradio] USRP vs alternatives

On Thu, Sep 25, 2008 at 12:57 PM, Chris Albertson <[EMAIL PROTECTED] > wrote: > Many people are using other software with softrock hardware. However > I think most of that "other" software is Dttsp based rather then > gnuradio based. The > hardware is designed to be connected to a sound card and

Re: [Discuss-gnuradio] alsa_sink busy

You might need to set your default ALSA device to be the virtual PulseAudio device. See for example Frank On Thu, Sep 25, 2008 at 10:01 AM, Dimitris Symeonidis <[EMAIL PROTECTED]>wrote: > I just noticed that, if listening to an

Re: [Discuss-gnuradio] atan2 problem

arctan = [math.atan2(x,y) for x in x_hyd_filter for y in y_hyd_filter] ? Frank On Tue, Sep 2, 2008 at 12:28 PM, Dan Halperin <[EMAIL PROTECTED]>wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sep 2, 2008, at 8:58 AM, Brian Padalino wrote: > > On Tue, Sep 2, 2008 at 11:51 AM, En

Re: [Discuss-gnuradio] python editor

Emacs. Frank On Tue, Sep 2, 2008 at 12:20 PM, Dimitris Symeonidis <[EMAIL PROTECTED]>wrote: > I wanted to ask the list, what editor are you using for python? Gedit? > SPE? Editra? something else? > I am still trying to figure out what works best for me, and hearing > from the list would be helpf

Re: [Discuss-gnuradio] boost 1.35

In /opt/boost_1_36_beta on 8.04 with kernel 2.6.24-21-rt. ./configure --with-boost=/opt/boost_1_36_beta --enable-doxygen --no-create --no-recursion Frank On Fri, Aug 22, 2008 at 2:37 AM, Firas A. <[EMAIL PROTECTED]> wrote: > > Hi, > > Has anyone been able to install boost 1.35 or 1.36 on Ubun

Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially

On Sun, Jul 20, 2008 at 3:09 PM, Rudy Moore <[EMAIL PROTECTED]> wrote: > Okay you got me. But answer me this: Why did we (the gnuradio experts) > select a license that does not provide a clear answer to Matt's question? > The answer *is* clear. It's not even very complicated. Nevertheless, for

Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially

On Sun, Jul 20, 2008 at 3:30 PM, Michael Ossmann <[EMAIL PROTECTED]> wrote: > ...An educated lawyer is going to be able to provide insights > into how a particular license or contract affects his or her client, > even after a single reading, that a layman would not notice... The complaint is ai

Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially

On Sun, Jul 20, 2008 at 7:49 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: > You should seek professional legal advice and be sure that you > understand the terms of the license. The problem is finding a lawyer who truly, actually understands the GPL. They're both pretty busy these days. ;-) Ha

Re: [Discuss-gnuradio] Re: How to scan the whole ISM band?

On Tue, Jul 15, 2008 at 7:39 AM, Martin Braun <[EMAIL PROTECTED]> wrote: > IMHO, this is pretty funky stuff, but also quite tough math... It needn't be so difficult. There's a lot of jargon and domain-specific material in [1] and [2], but the principle is pretty straightforward. There are two

Re: [Discuss-gnuradio] Standardized indentation?

Some incantation like indent -br -brs -cdw -ce -cs -hnl -i2 -lp -nbad -nbbo -nprs -psl -saf -sai -saw -nss -npcs works well for most C-ish code. Substitute -i4 if you don't use graduated lenses in your glasses. Frank On Thu, Jun 5, 2008 at 6:00 PM, Josh Blum <[EMAIL PROTECTED]> wrote: > Steven

[Discuss-gnuradio] Re: [hpsdr] AB2KT and the opera

On Mon, Mar 10, 2008 at 11:47 AM, Bob McGwier <[EMAIL PROTECTED]> wrote: > Well I apologize for sending that note out inviting everyone to come to > a sold out performance. I hope no one was inconvenienced... For the record, it should be noted that the N4HY crowd in the audience led the cheer

Re: [Discuss-gnuradio] gnuradio C++ engineer wanted

On Jan 31, 2008 12:52 PM, Jeff Brower <[EMAIL PROTECTED]> wrote: > Maybe you're right, it's inevitable. But I don't think it helps the cause > of GNU > radio at government agencies... I for one would be far more interested in using gnuradio to *spoof* the surveillance. That would really endear

Re: [Discuss-gnuradio] anyone implement the Raleigh fading model / multi-path?

There is a standalone, offline HF channel simulator in C for Linux, available through http://www.johanforrer.net/SIMULR/. The code is GPL 2. It might give a head start to anybody developing a gnuradio block. 73 Frank AB2KT On Jan 24, 2008 12:34 AM, George Nychis <[EMAIL PROTECTED]> wrote: > Lord

Re: [Discuss-gnuradio] OLPC - next generation with SDR?

On Dec 24, 2007 5:11 PM, John Gilmore <[EMAIL PROTECTED]> wrote: The Odyssey board operates at 10MHz IF; so wouldn't it need an external > tuner? Yes, but many different tuners (band sets) can be serviced by the same IF processor. > What kind of antenna would this require? Something external

Re: [Discuss-gnuradio] OLPC - next generation with SDR?

John -- Have you looked at all at the Siren board? It's part of the HPSDR and Suitsat II projects: a low-power, low-cost SDR engine using the dsPIC33F embedded controller from Microchip. The current design uses 10 MHz RF in and out, and the QSD and QSE for complex sampling and excitation. There i

Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts

Greg Troxel wrote: > ... > Given that new versions of python can be installed and made default > (meaning invoked as 'python'), it's necessary to bind the scripts to the > same version of python used to build .so modules and install .py files > in site-packages... I'm curious -- really just curio

Re: [Discuss-gnuradio] For those who are keeping up on various cognative radio projects.

John Clark wrote: > Here's a paper written on a research project on the topic. > > http://research.microsoft.com/research/netres/publications/lanman07.pdf Stand back in awe, my friends. Microsoft has innovated *both* spectral activity detection *and* the transverter. Yeesh. Frank ___

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

Hsin-mu Tsai wrote: > I didn't change the nice value (with top or nice, etc.). I thought > enabling the real time setting (gr.enable_realtime_scheduling) in the > script will automatically change priority to (max + min) /2. I don't actually know what the gr.enable_realtime_scheduling function do

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

Hsin-mu Tsai wrote: > This is my limits.conf > > @usrp - rtprio 90 > @usrp - memlock 2048000 > @usrp - nice-19 > > The user running the code is in usrp group. > > I'm running kernel 2.6.20-0119.rt8 from > http://people

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

Hsin-mu Tsai wrote: > I don't think my problem is related to the CPU. Here are my reasons: > > 1. I tried overclock my CPU from 2.6 GHz to 3.2 GHz in order to see if > an increase of CPU performance can decrease the packet loss ratio. > However, no significant change was observed. And I'm using I

Re: [Discuss-gnuradio] A problem with ALSA

Check the running processes. If there are any sound daemons such as esd running, kill them and give it another try. Frank ??? (Yuankai Ge) wrote: > Hi, > > I'm also tring to making some sound out of the USRP box, however, even > test with the most simple script to generate a dial tone given by >

Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates

/etc/udev/rules.d/10-usrp.rules which sez ACTION=="add", BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002", GROUP:="usrp", MODE:="0660" Frank On 4/23/07, Bob McGwier <[EMAIL PROTECTED]> wrote: I will profess complete ignorance. What udev rule? _

Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates

Eric Blossom wrote: > Is your udev usrp rule still in place? Aha, that's a very good question. I'll be able to check this out yet today myself. > Which kernel comes with Feisty Fawn? 2.6.29-15 Frank ___ Discuss-gnuradio mailing list Discuss-gnuradi

Re: [Discuss-gnuradio] CVSD vocoder

Tom Rondeau wrote: > Just an announcement that I've just merged in a CVSD vocoder. You can > use it through the wrapper blocks blks.cvsd_encode and blks.cvsd_decode. Nice work all around. It does need to be said, though. Do you know just how many people have been made miserable by that [EMAIL PR

Re: [Discuss-gnuradio] Polymorphic Computer:

Martin Dvh wrote: > "Typically, a chip is optimally designed either for front-end signal > processing or back-end control and data processing," > "The MONARCH micro-architecture is unique in its ability to reconfigure > itself to optimize processing on the fly. MONARCH provides exceptional > c

Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?

Dan Halperin wrote: > I can't think of what else to try... /etc/security/limits.conf? Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Playstation 3

Robert McGwier wrote: > They are $599 at my local Target. So much for bargains at Costco. > Eric A. Cottrell wrote: >> I was at my local Costco tonight and noticed they have the 60GB PS3 for >> $699. I almost bought one but decided to check a Costco in NH first. $699 gets you one from Terrasoft

[Discuss-gnuradio] ALSA/jack

For those of you using ALSA and jack there may be immediate relief. The ALSA jack plug slave PCM device and the aoss dspN devices appear to work together without incident. So, if you put the following in $HOME/.asoundrc: pcm.jackplug { type plug slave { pcm "jack" } } pcm.jack { type

Re: [Discuss-gnuradio] Heard FM on the basic RX hooray!

Johnathan Corgan wrote: > On Fri, 2007-01-05 at 13:35 -0500, M. Ranganathan wrote: > >> ...I have the worlds most expensive FM radio finally > > That's okay, I sometimes listen to the local AM BCB on my Icom PRO II HF > transceiver--that's a (US) $2K+ equivalent of a crystal set :-) > It has th

Re: [Discuss-gnuradio] Interfacing GNURadio with other software

Eric A. Cottrell wrote: > Is there a loopback audio device, maybe using Jack? This is exactly the sort of thing jack was designed to do. You can think of jack as providing virtual patchcords among the inputs and/or outputs of all the audio applications you have running. What you have to be awa

Re: [Discuss-gnuradio] Squelch developments

Exactly. 73 Frank AB2KT Johnathan Corgan wrote: Frank Brickle wrote: Yes, although half a cycle of a raised cosine is almost as easy, and analytically correct. 1/2 - cos(x)/2, for x from 0 to pi? Should this be applied (in reverse) as a decay window when squelch cuts in, as well as the

Re: [Discuss-gnuradio] Squelch developments

Johnathan Corgan wrote: Good catch. Would a linear ramp from 0.0 to 1.0 as a multiplier against the audio stream, applied over a user specified number of samples, be sufficient? Yes, although half a cycle of a raised cosine is almost as easy, and analytically correct. 73 Frank AB2KT _

Re: [Discuss-gnuradio] EDACS Control Channel

Rick Parrish wrote: I think "Trunk Tracker" is a trademark of Uniden. See http://www.trunktracker.com/ ... Yes, right, sorry. It's been awhile. Things to be wary of the code: It was written for Borland's Turbo-C compiler as a 16 bit DOS program. The size of a C "int" is 16 bits here. The pr

Re: [Discuss-gnuradio] EDACS Control Channel

If you poke around the net, you will probably be able to find the source for an old DOS program that decodes EDACS control channel. It's called "Trunk Tracker." I also have original source for an EDACS control channel decoder of my own from a number of years ago. Unfortunately all that remains

Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}

Robert McGwier wrote: There are subtle race conditions that might occur but they are minor irritants compared to the stupidity of what we were doing. In particular you'd want to make sure any values that can be read in the callback are set atomically in the client code. That includes flags th

Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

Eric Blossom wrote: ... I ended up remounting the relevant filesystem as ext2 to avoid the problem...If we never go to the disk, it might not matter at all. > ... It's been a long time since I looked at these pages: http://ardour.org/requirements.php http://ccrma.stanford.edu/planetccrma/soft

Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

Eric Blossom wrote: Bottom line, it hasn't actually been proved that running SCHED_FIFO will squash the existing latency and continuity problems, so I'm not at all sure much is missing without that capability. Frank, is this a statement or a question? It's a statement. I don't have any rea

Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

Eric Blossom wrote: Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL) behavior, which means that acquiring an uncontested mutex requires a trip to the kernel. I believe it also means that mutexes won't work in shared memory across process boundaries. Those seem like total los

Re: [Discuss-gnuradio] Ubunto and GnuRadio, Lovely together

Dave Dodge wrote: You can expect to have to run synaptic several times and keep enabling/installing yet more packages before you'll finally have a reasonably complete set of headers, tools, and documentation -- unless there's some meta-package that grabs everything at once, and I just haven't no

Re: [Discuss-gnuradio] Re: gr-audio-jack - mono only?

Stephane Fillod wrote: The fact the port names of the jackified alsa application (ie. the GR app) are not known before runtime is one drawback. The name is derived from application name, PID, whatnot. Maybe I haven't found yet the option to specify it through alsa manipulators. I believe the p

Re: [Discuss-gnuradio] Thread-Safe Blocking?

Robert McGwier wrote: ...A sound system callback wants to feed and be fed and never get blocked. When it has new data, it should issue a semaphore release on the dsp/data processing system... To generalize this just a very little bit: any sort of mechanism will do, that will let the DSP pr

Re: [Discuss-gnuradio] FFT of FFTs

Eric Blossom wrote: Once you've got your individual streams of signals, for each one I would compute an estimate of whether it is occupied. Good suggestions. Elaborating on this a little, you might consider taking differences of successive magnitude or power spectra. If you're actually look

Re: [Discuss-gnuradio] gnuradio/usrp (almost) working / IIR filter design code

Eric Blossom wrote: There are at least two existing packages we might want to use: libfilth and part of scipy. gmeteor is also worth a serious look. It's currently embedded in guile; a Python embedding would be very natural. ___ Discuss-gnuradio

Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping

James Cooley wrote: ...I'm sure there's a way to come up with a compression scheme that's tailored to the sort of sample data we see... A topic for a dissertation if ever there was one :-) In the general case, you're going to have to work hard to beat Ziv-Lempel. You might improve the performanc

Re: [Discuss-gnuradio] USRP and GnuRadio for OSX

FWIW the version of jack that runs on OSX appears to have matured quite a bit. PortAudio also has an OSX version, but given a choice, I'd bet more on jack. Matt Ettus wrote: Also, there is no audio support for OS X yet. I was under the impression that OS X offered OSS (Open Sound System) emulat

Re: [Discuss-gnuradio] pipe trick

Proviso: I could be *seriously* misunderstanding what's up here. If so, my apologies and please ignore. Have you tried setting the pipe reads/writes to O_NONBLOCK, and checking on read to see whether anything actually arrived? Obviously you wouldn't want to be spinning on empty reads, so selec

Re: [Discuss-gnuradio] Raw sample storage format

Is there some reason not to use a standard format like .au or .wav, seeing as either of these is supported in Python (wave.py and sunau.py)? Chuck Swiger wrote: At 12:38 AM 3/10/2005 +, you wrote: A standard header for data files makes a lot of sense. It sure does - as it is I put clues in