A1946 alfa precursor proposal: extra galactic drifts



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.


    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).


    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 :

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)

    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. 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):

    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). 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).

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)


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: 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:     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:

what could be causing this..

    Here are some considerations:
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:     Only scans of type fixedaz with more than 50 records were checked. There were 173 of these scans.
The checks made were:
  1. 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.
  2. 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
(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:

    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
14:01: 8.60
pixel ra,dec using rotation angle: +19 degrees
14:01: 08.40

    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.


  1. 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.
  2. The data time stamp and the encoder timestamp are identical
  3. 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


processing: usr/a1946/aug19_plotcross.pro