[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] sparc <--> x86 data exchange
From: |
Lamar Owen |
Subject: |
Re: [Discuss-gnuradio] sparc <--> x86 data exchange |
Date: |
Tue, 20 Dec 2005 15:08:45 -0500 |
User-agent: |
KMail/1.9.1 |
[back onlist; my fault for not reply-all]
On Tuesday 20 December 2005 14:41, Eric Blossom wrote:
> On Tue, Dec 20, 2005 at 11:37:02AM -0500, Lamar Owen wrote:
> > Certainly. But if I save a file on one arch it should be able to be
> > played back on another without me having to write anything.
> I understand the inter-machine portability issue. I prefer native
> because I often manipulate the files outside of GNU Radio. Some of
> the tools I use can read and write in either format, but it's also
> nice to be able to mmap the files in and use them directly. Think
> about files in the GB plus category..
I'm looking at a 116GB pulsar data capture file on that dual Xeon machine
right now. 2 hours continuous capture, 25 USB underruns.
> Perhaps we add an additional "endian" argument to
> gr_file_{sink,source} where the default is read from a configuration
> file. You could set the default on your systems to "big", I'd set
> mine to "native" and we'd both get what we'd want, and the scripts
> remain arch agnostic.
Hmm, perhaps.
> We could also use "reader makes right", but that would require that we
> tag the files with a header of some kind or use a file naming
> convention. Not having a header is very convenient, but again,
> there's room for discussion.
Perhaps WAV format could be investigated, which would open things up
dramatically. Of course, there's overhead, too. WAV is standard, and lots
of tools and libraries are available for WAV. In the absence of WAV, FITS
format is the next best fit (pun intended).
> The other problem with all of this, is that the file sinks and source
> don't actually *know* the format of the data.
> Without knowing the structure, blind swapping won't work.
Yeah, it either has to always be the same or metadata has to be added. Either
WAV or FITS have lots of libraries available to do that.
> Right now we have very few complete apps. Emulating SpectraVue would
> be a good start. Making it better can be left for later.
I'll grab some screens, perhaps Thursday or Friday (very very busy today and
tomorrow).
> > What one would do is be able to choose from a pallet of blocks, wire
> > them together, and have the app generate the code to plug the GUI into.
> Tad Dreier at UCLA is looking at gluing GNU Radio into Ptolemy II.
> This would give us something along these lines.
> http://ptolemy.eecs.berkeley.edu
>
> Tad, now would be a good time to de-cloak ;)
Cool. Java? Hmmm, seems heavy-weight, but I'll withhold criticism (after
all, our Smiley remote controlled radio telescope uses Java).
> > GNUradio
> > is like a kit of IC's ready made that you need to wire together and
> > solder (and test, and package, and...). It makes software radio easier to
> > do, but it is still a kit.
> Now we need some directions and a front panel for those radio kits ;)
Precisely.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, (continued)
- Message not available
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Chuck Swiger, 2005/12/19
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, cswiger, 2005/12/19
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, michael taylor, 2005/12/19
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Eric Blossom, 2005/12/19
- Message not available
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Chuck Swiger, 2005/12/20
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Eric Blossom, 2005/12/20
Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Eric Blossom, 2005/12/15
Message not available
- Message not available
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange,
Lamar Owen <=