31. Normalization of the receiver band pass (12/7/2001 - 2/4/2002).
Problem - The Waterfall display has equalizer lines in it
The modification of the WiNRADiO 1500i to get 20
KHz of bandwidth works well. Using my scanner software and 2048 point
FFT I can see a signal come into the band pass and move through each of the
bins of the FFT. The problem is that the receiver gain is not uniform
over the band. The portion from about 100 Hz to about 3 KHz shows a high
output but the area above that to about 17 KHz is much less. Between 17
KHz and 20 KHz it rolls off very rapidly.
This difference in amplitude is to be expected because the receiver is
optimized for audio not wide band. When I display the data in a
waterfall format it makes the audio portion of the display appear much
"hotter" than the remainder.
I thought I solved the problem by coding up a twenty position audio
equalizer. Using that and the receiver audio noise output I simply
moved the sliders until the scanner display looked flat. The equalizer
sliders then formed a 'V" shape which is the inverse of the
receiver audio response. Joy is found.
The problem came to light when I changed the dynamic range of the waterfall
display. I now takes the FFT power spectrum output directly and displays
it as a color pixels. Right away lines appear in the display and I
realized that they are right on the boundaries of the 20 equalizer
sliders. The equalizer sliders are causing the lines. No Joy.
Solution - I am going to try to build a replacement of the
equalizer. This will be a separate routine that normalizes each bin of
the FFT rather than grouping 100 bins under each slider. This routine
will use the receiver noise (better yet a noise generator) and calculate a
factor for each bin. This will be applied to the data array on its way
to the waterfall display.
As of this date I still don't have a good solution to this problem. I
have all but given up on a good automatic way to normalize the receiver and I
still have lines in the output do to the sliders on my equalizer.
Late note: 2/4/2002 - I went back and
reworked the original design of 20 equalizer sliders. Now each bin is
equalized by the slider it is controlled by (100 bins / slider) but the
adjustment is a linear interpolation between the slider and its next
neighbor. Problem solved
Even Later Note: 3/12/2002 - None of
the 'high tech' solutions worked. Not the averaging then subtraction
method suggested by many, not the use of software sliders, not filters of any
type. The final solution was the installation of a simple analog
equalizer between the radio output and the sound card line input.
The equalizer was bought from EBay for less than $80. It is mono and
has 31 sliders so it covers the top end of the band where it is needed the
most. Once installed it was a simple matter to tune to a quite place in
the waterhole (anywhere really) and simply play with the sliders to get the
flattest display possible. Task Complete.
30. Recording and Playback of Raw Data - (11/1/2001 )
The best way to archive the data generated by the SETI
Net receiver is to simply save it away all the raw data for future
analysis. The problem is that this represents between 20 and 30 Meg of
data every three minute collection period . Three minutes is the
collection unit I have settled on where one unit fills the screen of a
waterfall display.
The solution to this POD will be a trade analysis as it usually is.
Basic Problem - Large amounts of data collected and narrow window
for processing (it always comes down to space and time doesn't it).
Best Case Scenario - System running in two channel, 16 bit stereo
recording at the highest recording rate (44100 samples per second). Each
buffer of this data would be recorded and run through the SETI Net 4096 point
Fast Fourier Transform (FFT) and the resulting power spectrum used to produce
a spectrum display and one line on the waterfall display.
When a full waterfall screen is completed (600 lines) the screen would be
analyzed for ET lines. Hits would sound alarms and mark the raw data for
recovery.
The system would be configured to accept raw data from either the receiver
or from a recorded WAV file for playback of any hit data.
Recording of raw data rather than the much smaller power spectrum data will
allow the development of analysis algorithms that can go back and 'mine' the
raw data for undiscovered hits.
Trade Off - Well my pick is bent. After spending a huge amount
of time trying various 
approaches
I have come to the following conclusions:
- The people that invented the RIFF format for WAV files are maniacs and
must be watched closely (who were these people anyway).
- You can't collect WAV data in a thread. Something to do with the
way Windows manages messages (Bill G. screwed this one up big time).
- Since I can't run the data collection in a thread I can't concurrently
collect and analyze the data.
- I must put three minutes of data on the screen as a waterfall and then
run an analysis of it for hits.
- If there is anything interesting in the waterfall the system will rerun
the same point (Az/El, Frequency etc) and save that to a file as .WAV data
along with SML data to keep it identified.
- There will also be a mode where it will display three minutes then save
three minutes then display 3, save 3 etc. (huge file generator).
- The waterfall data will be saved in a format that can include the SML
tags as well.
- I have to stop letting myself be sidetracked into these software pits.
29. Waterfall (9/9/2001) - The waterfall presentation doesn't seem
to be working correctly, it has to be fixed, and I need to make some decisions
on how I will analyze the data in the display. Problems are:
-
Pixel
Access - I need to update each pixel on the display based on
the output of the FFT bin at that point. I doesn't have to be the
swiftest access in the land but it can't slow the rest of the system
down. ScanLine function seems to work but a DirectX implementation
might be better. Solution
- ScanLine was not the solution at all. In fact it was a wild
goose chase that cost me several day of hunting around. Once more my
good friend David Taylor put me
straight in his answer a Delphi newsgroup question of mine. If you
would like to look at the code you can download it from the software
section.
-
Pixel
Color - I would like to color each pixel based on the
perception of the human viewer of its relative heat. A low amplitude
pixel would be a cool color, the highest amplitude would be a hot
color. I need to find a translation scheme and decided on the color
depth of the image (256 color, 32,000, high color, etc). This is the Next
problem to tackle
-
Analyze
- The hard part will be to build an automatic color analyzer
for each screen. When each screen full is completed it should come
on and search for lines and edges in the image and make a decision to
rescan, move off beam and rescan, ring alarm etc.
-
Save
- I need to be able to save the data in an archive. Right now I am
thinking that I'll simply run the .WAV files off to a huge hard drive (see
the next POD).
Many decisions to make in this POD. I have moved to the problem of
recording of the data generated for the first step.
28. Antenna Position Lock ( 6/15/2001) - For
the antenna to be able to "lock" or track a position in the sky
requires the following tasks:
a. Conversation Software - Write software with the ability to convert
Declination and Right Ascension to Azimuth and Elevation.
This is completed and can be downloaded in the form of the SETI
Net Clock. Create a downloadable library to be made available to
other users. Task Complete (7/1/2001)
Where in the world am I?
As I was constructing the SETI Net clock I was
forced to come to terms with the fact that I didn't know where I was -
that is where my antenna was pointing. I had lined it up with a
compass - one of the better ones with a good rose and a sighting slit,
but when I compared where my antenna was pointing with where my software
thought it was pointing the software was way off.
I finally got it sorted out with the help of
the US Navy. They publish a list of the location of the sun and
moon for any spot on earth during the day. With this list I was
able to drive my antenna to where the sun should be at say 12:20 today
and then, when that time came by, loosen the bolts on the antenna rotor
and move it so that it actually pointed to the sun.
I know when I'm pointed at the sun by the
shadow of the feed horn on the dish surface. I just jockey the
dish back and forward until the shadow falls in the center of the dish.
This technique should give me the pointing
accuracy needed to move the dish and be assured that I know where I'm
looking. |
|
|
b. Radio Sky (7/4/2001) - Create a
bitmap of the radio sky similar to that shown on page 8-3 of "Radio
Astronomy" by J.D. Kraus .
So far I have digitized the image directly from my copy of Kraus. and
have attempted to merge it into my application - it's not working out.
The BMP is too poor and not sized right. I have attempted to convert it
to a vector using Corel but the results are not encouraging. I have
searched the web for a suitable image but have found none.
Good News - I have found a better sky map than the one in Kraus. This
one came directly from the SETI@home
project Tobias also allowed me to use the
Delphi code from his project which helped a lot
c. Integrate the sky map (7/9/2001) - The completed Sky Map will
allow the antenna pointing software to track the selected point. It will
show the range of movement possible imposed over the map. This will
allow me to schedule the antenna movement to the target selected.
Using the SETI Time software library, the same code that is the backbone of
the Sidereal Clock, I was able to paint a rectangle on the sky map that
represents my current 'searchable area'. This is derived from the
antenna minimum and maximum pointing angles in both Az and El. The
software then converts those four points to four Dec/RA points. These
points are then painted on the original Sky Map image using the BitBlit
function in the windows operating system.
The search area changes with mechanical settings of the antenna. When
I move the antenna elevation 'wedge' up from 0 degrees to +15 degrees to get
more of the upper sky, the search area will move accordingly. When I
turn the antenna mounting from home-west to home north, east or south
the search area will change as well.
Now that I can draw the area that can be searched with these settings I
will be able to draw a circle inside the rectangle that shows the exact area
under examination. I expect this to be a three degree circle but due to
the distortions caused by the mercator projection Sky Map it may not be a very
good looking circle (in fact it shouldn't be). To get an idea of the
distortions find the big dipper on the chart, top right, and see what this
projection does to the Big Dipper (UMr).
8/3/2001 - It took a lot longer than I expected but I now have a Sky
Map that is active and shows the current searchable area and the area now
being searched. Click on the image below.
Click to expand
This figure shows two graphics drawn by the SETI software the Search
Area and the Current Antenna Position.
The Search Area is made up of all the area that can be searched with
the antenna mount configured as follows:
- AZ: 270 to 90 Degrees
- EL: +23 to +63 Degrees.
The top curve is calculated by finding the line of equal elevation
(63 degrees) and the points between 270 and 90 Az. The bottom
curve is the same except the minimum elevation (23 degrees) is used.
The right and left side lines are calculated similarly by varying the
elevation with a fixed azimuth. During the observation session the
Search Area moves across the screen and appears on the other side.
When this screen was grabbed the Search Area had moved to the left side of the
screen and some of it reappeared on the right.
The reason that the space isn't a rectangle is because the background map
is distorted to make square Dec and RA grid lines. This is the same
image that is used by the SETI@home project and
is a 'Mercator' projection.
To search other areas of the sky requires that the antenna mount be moved
to another home position (north, east, south, or west) or that the elevation
be adjusted higher with a swing arm mount - the 'wedge'. This operation
takes about 20 minutes to complete. When the antenna is reconfigured
this way the Search Area changes accordingly.
Current Antenna Position - The real eye opener is the Current
Antenna Position shown on the figure near Gemini. This small circle
represents the three degree beam width of the SETI Net antenna (12' diameter)
running at the water hole (1420 MHz). Small isn't it!
This spot stays locked onto the selected star until the star moves out of the
Search Area.
Observation Cycle - During an operation cycle the operator
selects a point within the Search Area with the mouse and right clicks on
it. The 3 degree circle appears and the antenna to slews to that
point. The software then causes the antenna to follow that point until
it moves outside of the Search Area. The antenna movement then shuts
down and the operator is notified.
The size of the Current Antenna Position
spot makes you realize how huge the area is to be searched is - and
remember that this is just one axis. The frequency must also be
searched at those same points.
In effect one spot can be selected
and searched for the duration of the project.
There is no crowding in
space.
|
There is still a lot of software to cleaned up on this POD but it should be
completed this week sometime.
d. Joy Stick - Consider using a joy stick to set the position
of the antenna in Dec and Right Ascension. The more I look at this the
less likely it seems to be necessary. I think I'll move on to more
productive area.
