A1946 alfa precursor proposal: extra galactic drifts
aug04
Index:
24/26sep04: radar causes jumps in
the total power.
06sep04: jumps in the total power.
aug04: check the headers for consistancy
between boards and that the time steps are 1 second between records.
22aug04: drift scan through a source. data
timestamp is good, feed rotation angle is ok.
22aug04: Cross scan sources now appearing
in correct beams.
19aug04: Cross scan sources not appearing
in the correct beams.
Intro:
Project a1946 is one of the alfa precursor proposals.
It will do drift scans at fixed azimuth/za for extra galactic mapping.
The wapps were used on all 7 pixels of alfa (the 8th board is a copy of
pixel 7??). The standard setup is drift scans for 900 seconds close
to the meridian. The wapps are normally set to 100 Mhz centered at 1385
Mhz. Information from various days is described below..
24/26sep04:
radar causes jumps in the total power.
links to plots:
the
average band passes for the first scan (.ps). (.pdf)
24sep
the power versus time for the 20 Mhz around 1395 Mhz for each scan and
pixel (.ps) (.pdf).
26sep
the power versus time for the 20 Mhz around 1395 Mhz for each scan and
pixel (.ps) (.pdf).
24sep
the jumps occur when the 1350 radar is strongest (.ps) (.pdf)
26sep
the jumps occur when the 1350 radar is strongest (.ps) (.pdf)
24sep
the 1350 Mhz signal strength versus the 1395 Mhz strength (.ps)
(.pdf).
26sep04.
all 7 hours of data pwr 1395 vs time (.ps)
(.pdf)
24sep04.
pulsar data total pwr vs time shows jumps do to faa. (.ps) (.pdf)
hilltop
monitor radar power vs time for the 5 radars (.ps) (.pdf).
Intro.
Project a1946 had observations 21sep04 thru 28sep04
in the early morning (usually 12:30 am to 3am). They used their standard
setup of 100 Mhz centered at 1385 mhz and 900 second drift scans.
On 24sep04 they started to see jumps in the total power every 12 seconds.
This was weaker on 25sep04 and strong again on 26sep04. There was 2.5 hours
of data on 24sep04 and 7 hours on 26sep04.
Pulsar data taken on the evening of the 24th saw
compression when the faa radar pointed at us and it too saw jumps in the
gain during the compression.
There are 5 radars with a 12 second period in the
frequency covered by alfa (5+15 if you include the punta salinas
frequency agile radar). They are :
-
aerostat balloon: 1242 and 1257 Mhz (the aerostat has two other freq that
it is not using).
-
remy radar: 1290Mhz located at remy
-
faa airport radar: 1330, 1350 Mhz.
-
Some parameters for these radar can be found here.
Data from 24/26sep04
I looked at the 9 complete scans taken on 24sep04. The
dynamic spectra showed a flat rise in power over the entire 100 Mhz band
when the faa radar signal was pointed at us. This occurred in some but
not all off the alfa beams.
The first plot shows 24sep04:
the average band passes for the first scan (.ps). (.pdf)
-
Fig top: These are the 7 pixels for polA
-
Fig bottom: The 7 pixels for polB
To measure the strength of these jumps, two sections
of the bandpass were averaged over frequency. The first section was 300
Khz around the 1350 radar. The second section was 20 Mhz centered near
1395 Mhz (it is the area between the dashed red lines on the plot).
For each of these two bands a robust average of the 900 time points
of each scan was taken (the robust average excludes outliers from the average).
The points were then normalized to this average to put them in Tsys units.
The plots show
24sep04:
the power versus time for the 20 Mhz around 1395 Mhz for each scan and
pixel (.ps) (.pdf).
26sep04:
the power versus time for the 20 Mhz around 1395 Mhz for each scan and
pixel (.ps) (.pdf)
Each page is a different pixel for alfa.
-
top plot. PolA. Each colored line is a different scan. The scans
have been offset for plotting purposes.
-
bottom plot: Pol B
The on 24sep04 pixel0B was the strongest. On 26sep04 this switched to pixel0A
(the vertical scales for these two plots if 5 time larger than the others).The
3 large large vertical lines are the cals being fired. You can see the
12 second jumps in:
24sep04: pixel 0b,1b,2b,3a,3b,4b,5b.
26sep04:pixel 0a,1a,1b,2a,2b,3a,3b,4a,4b,5a,5b,6b
There are also discrete jumps in the power
(e.g. pix0a sample 100 redline, 150 blue line) that have been seen before
in the alfa data.
A blowup of the data from pixel 0b scan 1 shows
that jumps occur when the 1350 radar is strongest:
24sep04:
blowup of jumps (.ps) (.pdf)
26sep04:
blowup of jumps (.ps) (.pdf):
-
Fig top: This is 60 seconds of data. The red line is 300 Khz around the
1350 radar. The black line is the 20 Mhz around 1395 MHz. They are
aligned in time.
-
Fig middle: This has the vertical scale of the top plot expanded. Each
step in the plot is 1 second. The black line (1395 Mhz) is taking 6 to
8 seconds for the power level to return to the value it had before the
radar pulse occurred. The red line which measures the 1350 power drops
much faster. Since the radar is always pulsing, we will always get some
power from the radar (even when it is not pointing at us). When the radar
is pointing 180 degrees from us (6 seconds after the peak) there is a small
peak caused by the radar feed horn over illuminating its dish.
-
Fig bottom. The spectral channels of the correlator (that took the data)
have leakage. Some of the power at 1350 will leak into the other channels.
This is not what is happening in this case. The bottom plot is a spectrum
taken when the 1350 radar is pointing at us divided by a spectrum when
the 1350 radar was weakest (2 seconds before the peak). The ratio is flat
in frequency. This shows that it is not a leakage of filter channels (since
channels farther from the 1350 would then have less power from 1350).
-
Note: There are 3 radars that have 12 second periods: faa at 1350, aerostat
at 1250, and remy radar at 1290. It is possible that the phase of one of
the other radars in aligned with the faa radar. So the alignment of the
power jumps and the 1350 Mhz peaks may be a coincidence.
To see if the amplitude of the jump depended on the
size of the 1350 signal, a plot was made of the 24sep04
1350 Mhz signal strength versus the 1395 Mhz strength (.ps) (.pdf).
The data set was limited to values of the 1350 Mhz signal greater than
.4 (when the radar was pointing at us).
-
Top fig. The top figure of each page is pola
-
Bottom fig. This is polB
For pixel 0B 1350 power greater than .8 Tsys, the 1395 Mhz power
always rises above the average Tsys.
The next plot shows the
7 hours of data around 1395Mhz from 26sep04 (.pdf).
All pixels are plotted on a single page with polA on the first page and
polB on the second page. The part of the plot that looks fuzzy is where
the 12 second jumps are occuring.
Hilltop monitoring data.
The hilltop monitoring data measures a 1 minute peak
hold every 20 minutes for the band centered at 1325 Mhz. I computed
the power for each of the 5 radars versus time by summing 3 channels
or 1.8 Mhz about each radar. The plots show the hilltop
monitor radar power vs time for the 5 radars (.ps) (.pdf).
-
The top two plots are the areostat radar balloon. It was not on for 21-23
sept when a1946 did not see power jumps. It was on for 24-26 sept when
the jumps were seen.
-
The center plots is the 1291 remy radar. It was pretty constant over
this period.
-
The bottom two plots are the faa radar at 1330 and 1350 Mhz. They were
off for the 21sep04 and on for the other days. They were stronger on 24
and 26 sep when the jumps were the strongest. There looks to be som problem
with the faa radar. It should never be shut off completely (as on the 21sep04).
Pulsar data taken 24sep04.
project p1944 took alfa pulsar data on 24sep04 in the
evening. They used 100 Mhz centered at 1420Mhz. The sampling time was 64
useconds with 256 lags. The two polarizations were added together before
writing to disc. I looked at scan 267200400 in file /proj/p1944/p1944.G42.35+00.46.wapp2.53272.0032
. This held data for alfa beams 2 and 3. I took the 2e6 spectra and computed
the total power for each sample. The plots show the total
power versus time for the 130 seconds (.ps) (.pdf)
-
Top plot: This has beam 2 in black and beam 3 in red. The
data has been smoothed to 64 milliseconds. Green vertical lines have been
placed every 12 seconds starting with the first jump. Both beams are jumping.
The recovery is more than 20 seconds. The amplitude of the jump is up to
4 percent of Tsys. You can see smaller jumps almost every 12 seconds.
-
Middle plot: This is a blowup of beam3 around the jump that occurred
at 52 seconds. This has the 64 usecond time resolution. You can see the
individual ipps of the radar as the radar sweeps by the observatory. This
normally takes 80 to 100 millseconds. The negative going spikes show that
the system is in compresssion during the pulses of the radar. There are
no positive going pulses because the radars are outside the band that is
being sampled. About 5 milliseconds after the compression starts, the power
in the band jumps up. During the jump, the amplitude of the compression
decreases. If the negative going spikes showed the start of the beam, then
you would expect that the compression would be largest in when the beam
pointed directly at the ao (see an example of the faa
radar compressing with alfla). If this was the aerostat radar, it would
blank when the peak of the signal pointed at the AO so you might expect
a decrease in the midlle.
-
Bottom plot: The data in the middle plot was flattened and then
the spacing between the negative going spikes was measured. The black line
is the measured data. The red line has the ipp spacing for the FAA radar.
This shows that the compression for this pulsar data with the jump in the
middle is being caused by the FAA radar.
summary:
-
The power in the entire band increases every 12 seconds.
-
This period is aligned (to within 1 or 2 seconds) of the 1350 Mhz
radar peak.
-
This increase is broad band with no frequency structure.
-
We do not see compression (at 1 second integrations). We do see compression
on the 64 usec sampling of radar data.
-
The rise in power has a very slow recovery (many seconds) back to the normal
power levels.
-
This occurred for most of the night 24sep04, less on 25sep04, and
a lot on 26sep04.
-
The approximate strength on 24sep04 by pixel was:
| pixel |
polA [Tsys] |
polB [Tsys] |
| 0 |
0 |
.06 |
| 1 |
0 |
.01 |
| 2 |
0 |
.03 |
| 3 |
.005 |
.02 |
| 4 |
0 |
.005 |
| 5 |
0 |
.03 |
| 6 |
0 |
0 |
-
The pulsar search jumps occur when the faa radar points at us.
-
The pulsar data shows the pulses compressing and recovering rapidly. After
5 milliseconds the gain of the system increases and then takes up to 24
seconds to recover. It looks like some component heats up and after
5 milliseconds its gain jumps. The long recovery time could then be a thermal
recovery. While this is happening, the wide bandwidth devices are still
going into and out of compression with a normal recovery time.
-
Random jumps have previously been reported using alfa. These are probably
coming from the same component.
processing:
usr/a1946/jmpsep04/24sep04/doit.pro
06sep04: jumps in the total power.
(top)
Thirteen 15 minute drift scans were done on 06sep04
using alfa. Of the 13 scans done, 3 of these scans had jumps in the total
power. The setup was 100 Mhz bandwidth centered at 1385 Mhz. 1 second sampling
was done. The cals were fired using the async cal method of cima with 3
cals of 2 second duration spaced out in the 15 minute observation.
To compute the total power for each 1 second step:
-
An average bandpass was computed for each 15 minute scan.
-
corblauto() was used to create a mask to exclude rfi in the bandpass computation.
It did a12th order harmonic fit to the average bandpass. Any points
more than 3 sigma from the fit were not included in the mask.
-
After computing a mask for each pixel and pol, a global mask was computed
by multiplying all masks together (1 was ok, 0 was excluded).
-
This global mask was then used to compute the total power for each 1 second
sample.
-
For each pixel the total power was divided by the median total power and
then had 1 subtracted. The yaxis is now in Tsys units.
The total power computed still had some rfi in it. It also had 3 large
spikes where the cal was fired during each scan.
The
plots show the total power versus time for the 7 pixels of the 3 scans:
-
Fig 1: This is scan 425054203. The top plot is pol A, the bottom plot is
polB. The different colors are the 7 pixels. The blue dashed lines mark
the jumps.
-
Fig 2: Jumps for scan 425055104
-
Fig 3: Jumps for scan 425056006.
-
Fig 4: scan 425054203 blowup of 50 seconds around each of the 5 jumps.
-
Fig 5: scan 425055104 blowup of 50 seconds around each of the 6 jumps.
-
Fig 6: scan 425056006 blowup of 50 seconds around each of the 3 jumps.
The image
shows a dynamic spectrum (time vs freq) for scan 425054203 pixel 1
polA. The 5 jumps are at: [229,290,403,474, 524, and 570 seconds. The jumps
do not have much frequency structure.
Some properties of these jumps are:
-
The jumps are from 1 to 8 percent of Tsys
-
They jump up in 1 second.
-
The initial jump is always greater than the 1 to 8 percent. It then falls
back and gradually returns to the initial power level (after a minute or
two). At first i thought that the data may have been out of order in time.
I looked at just the radar pulses and convinced myself that the data is
in the correct time order
-
The different pixels don't jump by the same amount each time.
what could be causing this..
Here are some considerations:
-
It is not a celestial source since the rise time is faster than the beam.
-
Most interference has spectral shape so it it probably not "normal" interference.
It could be something like a noise diode that is broad band.
-
If it was some out of band signal causing the receiver/iflo to go into
compression, then you would expect a decrease in power rather than an increase.
-
It happens to all the beams so if it something in the electronics, it should
be common to all beams and polarizations (for example the lo).
processing: usr/a1946/jumpsep04/jumps06sep04.pro
aug04: jumps in the time stamps
in the headers for the month of Aug. (top)
The time stamps for the fixedaz patterns taken by a1946
during the month of aug04 were checked for validity. The time stamps checked
were:
-
crval5 . time stamp for data
-
mjd_obs time stamp for data (derived from crval5)
-
rate_time time that the rate was applied (for a1946
this value is not used).
-
enctm : time stamp for the recording of the azimuth and gregorian dome
encoder values.
Only scans of type fixedaz with more than 50 records
were checked. There were 173 of these scans.
The checks made were:
-
The first set of checks verified that the values were the same for all
boards of a given data sample. This did not check if the polA,polB time
stamps in the fits file were the same.
-
The second set of checks looked to see if the step between adjacent samples
was correct. This data was being taken with a 1 second (solar) time step.
For crval5, mjdobs, and raJ the allowable difference was 10 milliseconds
(before declaring an error). For the enctm is was lengthened to 100
milliseconds (since the hardware recording is 20 millisecond resolution
and we could record it in scramnet +/- a few of these.).
There were no board incompatibility errors (comparing polA's value
between all boards. Rumor has it that there were 3 records that had trouble
between pola,polb).
Plots were made of the jumps in the measured time
steps. The majority of these were encoder jumps of 0 or 2 seconds.
The plot colors specify which kind of jump it was. An * was placed at each
error with an offset so you could see if there were multiple jumps at each
spot (if not the over plotting would have hidden the first errors).
The scan number coding is ydddnnnnn where ddd is the daynumber of the year.
For reference, 234 is 21aug04 and 242 is 29aug04.
The encoder time jumps are the most prevalent. They
come from the agc scramnet block. I looked at the agc scramnet data
recorded on disc once a second for one of these jumps. I saw the same two
second jump that was in the fits header. There was no 2 second jump in
the time for the pnt scramnet blocks, so the problem was not in moving
the data from scramnet memory to shared memory on observer2. It must have
been before this. The agcProg queries the critical block data (which has
the encoder positions/timestamps) from the vertex cpu every second after
the arrival of the 1 second tick. The time it takes to get this data is
recorded with a microsecond timer. The last,min, and max times to read
this data is stored in the agcProg. On 02sep04 these times were: last;37730,
min: 2111, max:597811 microseconds. So occasionally it is taking a long
time (up to .5 seconds) to get the critical block from the vertex cpu.
My guess is this is what is causing the 2 second jumps in the recorded
encoder time.
Because of the possibility of getting a jump of two
seconds (the same data twice then a jump of two seconds) from the scramnet
encoder values, it is important to always use the time stamps with the
data that is extracted from scramnet.
The jumps of 2 or 3 seconds where all of the time
steps jump are probably related to the program writing the fits files.
processing: usr/a1946/chkhdr/chkhdrmulti.pro
22aug04: drift scan through
a source. data timestamp is good, feed rotation angle is Ok.
(Note: This page was updated on 27aug04. The
routine alfabmpos was using the beam offsets with the incorrect sign.
This was corrected on 21aug04. This correction inadvertantly also flipped
the sign of the rotation angle (since the rotation angle was included before
the minus sign was applied). After correcting for this, the rotation angle
used by the gui is correct).
On 22aug04 a drift scan was done letting the source
J1401+242
(.809
Jy from nvss at 1400 Mhz) drift through the array. The experiment setup
was:
| J1401+242 position |
14:01:08.6 24:12:56
(ra,dec J2000 from nvss) |
| flux |
.809 Jy from nvss (1400 Mhz) |
| rf Freq |
1385 Mhz |
| bandwidth |
100 Mhz |
| az,za of drift |
179.754 , 5.759 deg |
| Requested rotation angle |
19 degrees |
| pixel of peak |
4 |
| data sample of peak (1 sec rate) |
430.8 (+.5 secs since timestamp is at the start of the sample) |
| measure BmWidth |
3.11 (Amin) |
| sefd pola,polB |
3.76, 3.36 Jy |
| ra error using data timestamp |
2.7 asecs |
| dec error (from choosing az,za) |
.1 asecs |
| encTimestamp-dataTimeStamp |
.014 seconds |
pointing coord difference pix0
(dataTmStamp,az,za)
(raJ,decJ pntHdr) |
14:01:13.1 , 24:06:39 (dataTmStamp,az,za)
14:01:12.6 , 24:06:39 (pntHdr raJ,decJ)
The .5 sec ra difference is because the pntHdr raJ also needs to be
moved to the center of the sampling period (like the data ra,dec was). |
Data was sampled at a 1 hz rate on all the beams. The plots
show the total power drift scans:
-
Fig top,middle: These are the total power drifts for each beam.
The top plot is polA, the middle plot is polB. Each pixel is a different
color. The Source is strongest in pixel 4 (purple). It appears earlier
in time in pixel 3 (blue)
-
Fig bottom: Gaussian fits were done to pixel 4 in polA (black) and
polB (red). The fits are shown in blue. The fits gave a beam width (FWHM)
of 3.11 arcminutes. This is for the azimuth direction of the beam (which
is narrower than the za direction). Using the 1400 Mhz flux from nvss (.809
Jy) the sefd was 3.76 and 3.36 for polA and polB of pixel 4.
The routine alfabmpos() was used to compute the ra,dec
of each beam when the source transited beam 4. It uses the azimuth, zenith
angle, and julian date for pixel 0. I took the az, za of the encoder
from the header locations: b.b1.h.std.aztttd, b.b1.h.std.grttd (they are
in units of 1/10000 of a degree). The crval2, crval3 values in the
header were not used since they have the model offsets included in them.
The julian date was taken from b.b1.hf.mjd_obs using the interpolated
value between samples 430 and 431 (counting from 0). You need to add the
mjd to jd offset to this number. The results were:
pixel ra,dec using rotation angle: -19 degrees
|
pixel
|
ra
|
dec
|
|
0
|
14:01:13.08
|
24:06:39.00
|
|
1
|
14:01:30.96
|
24:02:25.19
|
|
2
|
14:01:35.89
|
24:08:41.15
|
|
3
|
14:01:17.72
|
24:12:55.76
|
|
4
|
14:00:54.73
|
24:10:49.72
|
|
5
|
14:00:50.55
|
24:04:32.02
|
|
6
|
14:01: 8.60
|
24:00:22.04
|
pixel ra,dec using rotation angle: +19 degrees
|
pixel
|
ra
|
dec
|
|
0
|
14:01:13.08
|
24:06:39.00
|
|
1
|
14:01:17.58
|
24:00:21.86
|
|
2
|
14:01:35.62
|
24:04:31.14
|
|
3
|
14:01:31.40
|
24:10:49.02
|
|
4
|
14:01: 08.40
|
24:12:55.93
|
|
5
|
14:00:50.25
|
24:08:42.03
|
|
6
|
14:00:55.22
|
24:02:25.90
|
The data had the peak in pixel 4 so the +19 degree
rotation is the one that the feed was rotated. The source arrived
20 seconds earlier in pixel 3 which agrees with its ra being 23 larger.
Ra error is (140108.6(nvss) - 140108.4(measured)) = . 2 seconds of time
(at dec 24) or 2.7 arc seconds on the sky. The error in dec was .1 arc
seconds so whoever picked the dec direction got it right (martha..).
I compared the time stamp of the data and the timestamp
coming from the az,za encoder reading and they were identical.
I compared the pixel 0 ra,dec using the dataTimestamp
and the az,za with the ra,dec supplied in the h.pnt header location (this
is for pixel 0).After adjusting for the .5 second that moves the time to
the middle of the data sample, they were identical.
Conclusions:
-
The time stamps of the data and the az,za position generate ra,dec positions
that place the source transit within 2.7 arcseconds of the nvss position.
-
The data time stamp and the encoder timestamp are identical
-
The ra,dec computed in step 1 agrees with the requested ra,dec positions
from the pointing headers.
processing: usr/a1946/aug22/chkdrift.pro
22aug04: Cross scan sources
now appearing in correct beams. (top)
The header keywords were changed to correspond to the
correct beams/polarizations. 4 cross scans were then done during the day.
The setup was similar to 19aug04. The plots are now one cross per page
with the 8 beams in separate plot windows. The two colors correspond to
polA and polB. The dashed red lines are the center of the az and then za
strips. The green dashed line separates the az strip from the za strip.
the rotation angle of the array is printed in the upper left corner. The
horizontal scale is sample number across the strip (starting with the azimuth
strip).
The plots show the total
power (both strips of the cross) for each pattern (ps) (pdf)
The sources are now appearing in the correct beams for the cross
scan.
processing: usr/a1946/aug22/aug22crossplot.pro
19aug04: Cross scan sources not appearing in
the correct beams. (top)
Cross scans were done on various beams. The receiver
was centered at 1381 Mhz and 100 Mhz 3 level sampling at 1 hz was done.
Cross scans were done in azimuth and then zenith angle. The extent of each
leg was 9 beams and lasted for 60 seconds each. Crosses were done on beams:
0,1,2, and 5. For each cross, data was taken on all beams, but only
one of the beams should have been centered on the source. You will see
deflections in other beams since an azimuth drive for pixel 0 will also
have the beam pass through beams 2 and 5 (if the rotation angle of the
rotator is 0). An attempt was made to rotate the horns, but the motor was
turned off. It is assumed that the rotation angle of the feeds was 0.
The sources used were:
| src |
freq (Mhz) |
flux (Jy) |
| J1257+18 |
1400 |
.315 (nvss) |
| J1311+18 |
1400 |
.718 (nvss) |
| B1345+125 |
1381 |
5.4 (csalter) |
The plots show the total
power (both strips of the cross) for each pattern (ps) (pdf)
.All beams are plotted (in different colors). The top plot is polA while
the bottom plot is polB
-
Fig 1: J1257+18. Pixel 5. no source
-
Fig 2: J1311+18. Pixel 0. We see the source in pixel 0 (black) and pixel
1 (red) of polA. We do not see the signal in pixel 0 polB. You also see
the source in beam2 of the az strip since pixel 2 is only offset in azimuth
from pix 0 (when the rot angle is 0).
-
Fig 3: J1311+18. Pixel 2. Looks like no signal.
-
Fig 4: J1311+18. Pixel 1. See something in pixel0,1 of polB in the azimuth
strip only.
-
Fig 5: j1311+18. Pixel 2. pixel 2,3 of polA za strip only.
-
Fig 6: B1345+125. Pixel 0. Beam 0,1 of polA only.
-
Fig 7: B1345+125 . Pixel 0. Beam 0,1 of polA only.
Comments:
-
It looks like board number and polarization are getting mixed up. The fits
files used to start the data as:
-
polA0,polA1,polB0,polB1 .. and it is now storing it as:
-
polA0,polB0,polA1,polB1
The software uses wappno (now called input_id) and ifval to determine the
board and polarization
-
The source is appearing in the azimuth strip about 7 seconds before the
center of the strip. In azimuth it is very close to the center. This is
probably because the telescope rate is being applied, the cal on/off is
performed, and then the strip data taking begins.
-
Using the header offsets for beam 0, i get az offsets for the strip that
goes from .1 to .4 degrees (croff2). these should probably be centered
about 0.
processing: usr/a1946/aug19_plotcross.pro
home_~phil