+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: sources with Orcas  (Read 37130 times)

Offline Josef W. Segur

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 3112
Re: sources with Orcas
« Reply #45 on: 11 Dec 2007, 02:53:39 pm »
...
I would, perhaps incorrectly, expect at least some types of obvious overflow signal [tasks] to be fairly 'white'.  It's been a long time since I looked at an autocorrelation function, from vague memory they involve a single convolution. Something like that would be able to judge the whiteness of the signal against a decided threshold dirac figure/function. I've used them in signal processing many years ago for analysis of buried periodic signals. Subtracting the autocorrelation of white noise from that of the source [ had interesting results].... but that was on a 1k node torus so algorithmic complexity and other practical considerations weren't an issue under much consideration   :P. [though they should've been]
...
Jason

I've always thought of the WUs as consisting of a lot of white noise out of which we try to extract what isn't. Although the ALFA receivers are recent state of the art with 300 MHz. bandwidth, what goes on the Multibeam recorder is 2 bit complex values representing only the signs of the real and imaginary complex data points of the 2.5 MHz. bandwidth we're examining. That digitization represents a lot of noise, no? Then after the recording is received at Berkeley, the Splitter expands the data into complex single floats, does forward FFTs at 2048 length and inverse FFTs at length 8 and repacks the output in 2 bit form to be placed in the WUs.

As a practical matter, most overflows have been on Spikes until the recent radar RFI problem caused a lot of Triplets. The record for my Willamette P4 shows 1682 Gaussians, 1807 Pulses, 11764 Spikes, and 10718 Triplets. 8162 of those Triplets are from one data set we crunched at SETI Beta before the radar RFI was understood. That's from 3524 results. The thresholds are nominally adjusted to give about an even chance of finding a signal or not if the noise level is normal, the Gaussian and Pulse counts match that but the excess Spike count probably reflects cases where random RFI caused overflows. Note that Spikes aren't exactly what the name implies, they are found by examining the power spectrum of a single FFT; if there's one frequency that's more than 24 times more powerful than the average it's counted as a Spike. A continuous narrow band interfering signal will cause a sequence of Spike reports as the FFTs are stepped through the duration of the data.
                                                      Joe

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: sources with Orcas
« Reply #46 on: 16 Dec 2007, 10:01:01 am »
Quote
I've always thought of the WUs as consisting of a lot of white noise out of which we try to extract what isn't. Although the ALFA receivers are recent state of the art with 300 MHz. bandwidth, what goes on the Multibeam recorder is 2 bit complex values representing only the signs of the real and imaginary complex data points of the 2.5 MHz. bandwidth we're examining. That digitization represents a lot of noise, no? Then after the recording is received at Berkeley, the Splitter expands the data into complex single floats, does forward FFTs at 2048 length and inverse FFTs at length 8 and repacks the output in 2 bit form to be placed in the WUs.
Yes but no. Based on some obscure reading on the black art of antennae, If I interpret [crudely but] correctly [That's a pretty big if] I can think of two ways that method of complex representation can reduce noise in the digitisation process.
    1) Dumping the magnitude data & relying instead on a temporal persistence summation- The magnitude data [if it ever existed] probably would amount to random noise like we've been discussing, I gather direct digitisation of magnitude in this realm would rely more heavily on the analog characteristics of the receiver.  Also In the method that is used, from what I gather the signal polarity is very reliable in such a setup, and already digital, and the time characteristic inherently precise, so vector summation (If that's what the splitter process simplistically amounts to maybe)  of those signals to form a single float signal, would be as precise time-wise. So the resynthesis should be a truer effective representation of the magnitude.
   2) Complex representaion cheats Nyquist: As I understand it we now get 'n' overall bandwidth capability instead of 'n/2' before nyquist induced aliasing takes over. I think that's a pretty remarkable 'something for nothing'.

Quote
As a practical matter, most overflows have been on Spikes until the recent radar RFI problem caused a lot of Triplets. The record for my Willamette P4 shows 1682 Gaussians, 1807 Pulses, 11764 Spikes, and 10718 Triplets. 8162 of those Triplets are from one data set we crunched at SETI Beta before the radar RFI was understood. That's from 3524 results. The thresholds are nominally adjusted to give about an even chance of finding a signal or not if the noise level is normal, the Gaussian and Pulse counts match that but the excess Spike count probably reflects cases where random RFI caused overflows. Note that Spikes aren't exactly what the name implies, they are found by examining the power spectrum of a single FFT; if there's one frequency that's more than 24 times more powerful than the average it's counted as a Spike. A continuous narrow band interfering signal will cause a sequence of Spike reports as the FFTs are stepped through the duration of the data.
                                                      Joe
Thanks, that description of spikes helps greatly trying to get a clearer picture of the processing sequence, I'll try to mentally process the implications. Given the definition of a spike, and that it is the predominant indicator of noise,  It may be that the only feasible method of determining a noisy workunit is indeed to process it to completion (Excepting, of course, known environmental influences, like we can make use of the radar blanking)... We are the 'precheckers'...

Jason

Offline _heinz

  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 2117
Re: sources with Orcas
« Reply #47 on: 19 Mar 2008, 03:46:19 pm »
Hi all,
my evaluation installation of Orcas is now expired.
I installed the new VS2008 Express Edition yesterday. I can open and work with all projectfiles from Orcas without any problems, parallel to VS2005 Express Edition.
Thats a really good news.

have fun  ;D

heinz

Offline _heinz

  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 2117
Re: sources with Orcas
« Reply #48 on: 22 Mar 2008, 07:26:58 am »
Hi all,
you can download VS2008 Express Edition from --->  http://www.microsoft.com/express/vc/
or --->http://www.microsoft.com/express/download/

a other good news is: students from several countries can download a free full version of Visual Studio VS2008 Professional Edition, Windows Server 2003 Standard Edition, Microsoft Expression Studio, and XNA Game Studio 2.0 from here:
---> https://downloads.channel8.msdn.com/

Happy Eastern  ;D
Joyeuse Paques  ;D

Offline _heinz

  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 2117
Re: sources with Orcas
« Reply #49 on: 30 Apr 2008, 09:34:07 am »
Hi,
You can download Visual Studio Express Edition 2008
from a new website...

heinz

 

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?
Members
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 59559
Total Topics: 1672
Most Online Today: 27
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 22
Total: 22
Powered by EzPortal