archiv~1: SETI Pegasus again not what one thinks

SETI Pegasus again not what one thinks

Walt Williams ( (no email) )
Wed, 11 Nov 1998 10:19:59 +0000

Hello Alfred,

Have you tried 32 bit (Windows31/95/NT) Pegasus WinPmail? It has the
ability to read text files into the WinPmail program as well as many
other nice features. It is also free, does not consume 1/3 of
available hard disk space and has built in speller.

On the other hand, you could (if using Win95) cut and paste using
the notebook (temporary memory buffer). Select the topic area by
highlighting and then depress ^C (Control C keys) which copies the
highlighted text into the notebook. Then click the e-mail program
dialog box to cause focus and depress 'Shift Insert' keys to copy
from notebook to e-mail program. If the buffer is not big enough, do
it in sections.

Hope this helps.

See:
http://www.pegasus.usa.com/Default.htm

Best Wishes,

Walt Williams, 98.11.11

====================================

------- Forwarded Message Follows -------
Date: Tue, 10 Nov 1998 17:42:04 -0800
From: "Alfred A. Aburto Jr." <aburto@cts.com>
Reply-to: aburto@cts.com
Organization: Calco, Inc.
To: David Woolley <david@djwhome.demon.co.uk>, seti@sni.net
Cc: nwelstead@seti.org.au, orbiter@tin.it, astro@lists.mindspring.com
Subject: Re: SETI Arecibo message to m13

There is no way to read in a text file into an email
message. The only option is attachments unfortunately!
I've suggested to NETSCAPE and QUALCOMM to allow
reading text files directly into an email message but
no dice. They want us to use attachments ---

On UNIX for example with the 'pine' email program one
can read text files directly into the body of an email
message. This is nice since one can compose an email
off line then send it off --- no wasted time doing
everything online.

Anyway I thought NETSCAPE would put the text attachment
inline, but I guess it doesn't work with all mail
programs ... sorry about that ...

> David Woolley wrote:
>
> [ Why have you sent an empty message with a text attachment? ]
> > 1's and 0's. Each bit had a duration of 0.1 seconds. It is
> > not clear what the bandwidth of the signal was unfortunately,
>
> That would depend on whether the pulses were shaped for optimimum
> bandwith or just keyed on and off with (relatively) fast rise and
> fall times. I'd have to check the text book, but the first ought
> to put nearly everything into about +- 7.5Hz and the latter
> would generate a signal with significant power to several 10s
> of Hz and a theoretically infinite bandwidth.
>
> > but an FFT of 0.1 seconds indicates a binwidth of 10Hz. It
>
> That could be the worst possible bin width for this signal in search
> mode, as the sidebands wouldn't show up at all if you were in phase with
> the modulation (FFTs and DFTs in general do have some artefacts due to
> their finite nature). It would be the optimimum width for recovering
> the modulation, but you couldn't use any integration, and you would have
> to synchronise the start of the FFT with the start of the bits.
>
> > The 2.8 minute message was only transmitted once. Averaging
> > longer than 2.8 minutes would be counter productive as it
> > would degrade the SNR.
>
> Just for clarification, we are talking here from a hindsight point of
> view as far as the receiver is concerned. 2.8 m is rather a short
> integration time for a general search.

Perhaps. Myself, I'd go with the FFT time span and avoid averaging
altogether. Well, I'd overlap the FFT's maybe 50% at most.

Al