archiv~1: Re: SETI Linux signal analysis

Re: SETI Linux signal analysis

Ed T. Toton III ( (no email) )
Tue, 24 Nov 1998 14:15:37 -0500 (EST)

On Tue, 24 Nov 1998, David Bridgham wrote:

> > From: "Ed T. Toton III" <etoton@UU.NET>
> >
> > Well, for one thing, I think an interface for XFree86 goes
> > without saying.. But I'm saying it anyway. :-)
> Say on, I want to sit and watch the waterfall go by as much as the
> next guy. By the way, do waterfall displays typically scroll up or
> down?

I believe most of them scroll the same way normal text output
does... Meaning, the whole view scrolls up as new lines are added
at the bottom. Someone correct me if I'm wrong.

> > I think a nice feature would be to have an option for periodic
> > automatic screen-captures to be saved to disk, so that you can have
> > "real time" images available by http or ftp if you wish.
> I was thinking of storing the raw data (before any signal processing)
> and making the program capable of displaying stored data as well as
> real-time. That's potentially an awful lot of data (especially if we
> get higher bandwidth equipment) even with the enormous disks available
> these days so I was thinking to, optionally, keep only the last N
> minutes such that if we register a potential hit, we have a record
> leading up to the signal.

Right, that's a good idea. I was also thinking that for unattended
processing, that it might want to save the data that surrounds any
hits that it can automatically detect. Perhaps have certain adjustable
parameters or thresholds for detecting hits, and then maintain an
on-screen display of how many such hits are stored and need to be
looked at. That way, if you walk away for a week and come back, you
can look at the possible hits and not have the hard drive eaten up
by recording the whole week's worth of raw data.

> Should it also be able to save spectrum/power data? Screen dumps?
> The issue of making the data available over the net is interesting.
> The save files would be a standard format of some sort and they could
> be ftp'd around. Should we think about something more elaborate? I'm
> thinking that since I was planning to write the display porgram in
> Java anyway (it's a lot easier to deal with AWT then libX), maybe it
> wouldn't be too hard to make it an applet that can look at remote
> datasets.

Right, a common and easy to encode/decode format would be a good
idea.. Something flexible that can be easily updated without making
older programs unable to read newer data (GIF's were designed this
way, but I'm not suggesting storing all the data if GIF format).
GIF's would be good for the periodic screen-dumps.

Ed T. Toton III, System Programmer - UUNET Server Operations
"I have not lost my mind! It's backed up on disk somewhere."