Re: [Discuss-gnuradio] sparc <--> x86 data exchange

[Lamar Owen]

[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